MPI: Hide’n Seek

November 4th, 2013 5 comments

Over the last few weeks, more and more information has been released regarding a feature called multiplayer instances. Since those are quite long and boring words, we internally go with MPIs. Yeah, that’s not really creative, but for now, function over form has to suffice.

Today I’ll add to the information already available. As mentioned, the MPIs are derived from the current fort battle system and are, in the first iteration, PvE content. Unlike fort battles, you can undertake a MPI whenever you want (as long as your character is not busy doing something else) with either your friends or random players. Right now, we’re working on the first playable prototype which will have one main character besides the players: The Bear(tm). Short and sweet, you and a handful of other players are sleeping in a forest when suddenly a bear shows up! As you have been a bad boy scout (otherwise you’d have realized that there’s a cave just next to your resting place) you have to protect yourself and fight the bear. Luckily, the bear is not the smartest bear you could’ve faced and only attacks the closest player – but it makes up for its lack of cleverness with some very strong attacks and boy, it’s fast, too!

The Art of Drawing

Although I completely made this story up, the scenario in fact is not and covers a couple of features (AI, anyone?), none of which I will talk about today though. A feature which is not mentioned in the story but I do want to talk about is the bear’s and the players’ eyes. Sure you have beautiful ones, but the most important job of your eyes is to actually see what is going on. Fort battles do already have lines of sight, but these are actually pre-compiled for every map as the sight-blocking objects are known in advance and other players don’t block each other’s sight.

This is different for the upcoming MPIs. Every actual object will block your view. There’s a tree? You won’t know what’s behind it. There’s a big fat bear standing on his hind legs in front of you? You should get comfortable with his furry belly (or just get crushed) because you’ll see nothing else. Besides some static objects (e.g. walls, trees), there’s a lot of movement going on which means that what you see changes almost every turn – everything has to be calculated in real time.

So what we need is an algorithm that calculates what the players see and don’t see, and that’s what I’ve been working on for the last couple of days. It first started with an art class as we had drawn nice lines and circles to get used to the actual problem. Here’s what it looks like when non-artistic software developers go on a drawing-spree:

MPI View Drawings

Nice, isn’t it? I’m thinking of starting a more artsy career – or at least I am now aware that I’ll always have an alternative available. What’s actually more interesting is the meaning of all those lines and boxes. Since I’m a good guy and not your art teacher, I’ll tell you directly. You might not be able to see it, but there are several ideas hidden within the picture. At first we dug up our geometric skills and drew some straight lines at a couple of angles to each other (you’ll have different view radii, so far: 90, 180 and 360 degrees). Our first approach was to project the lines from a specific point (the player’s eyes) in the direction they are facing. This is also known as ray tracing. If a line (or ray) hits a blocking object, the stuff behind that object is hidden. That is one approach, but from the beginning we have also been working on another one which you can see in the upper right corner.

Instead of sending out rays, another way is to iterate over the player’s field of view and, if you hit a blocking object, calculate the shadow of this object. Finally, add the resulting squares to a list that contains all of the hidden squares. When displaying the grid, just check if a square is in the hidden list or not and show its content accordingly. The algorithm to calculate an object’s shadow is the interesting part. It was quite easy to start with, and still somewhat is, but there have been quite a number of edge cases and there are still some bugs left.

After the implementation, we started on a ray tracing algorithm. Since a ray doesn’t fit one-to-one on a square grid, we have to convert that information using the Bresenham Algorithm to match the straight ray to the underlying squares. The code is easier, shorter and more efficient but yields different results. How can we check if the results are appropriate though? Quite early on I was not keen on writing tests for such a visual feature, so I decided on writing a simple, quick and dirty standalone visualizer to test it. Now to the fun part: it’s available online! Before you head over there, please keep in mind that it’s not at all optimized but is just a proof of concept (as the code you can look at is seriously bad). It’s also very slow when not opened with a decent computer and a decent browser (Firefox does not count as decent here, unfortunately; Chrome should run well enough).

Space Invaders Incoming!


A quick explanation of what is shown and what you can do:

When hovering over the grid, there’s a red square beneath your mouse cursor. This is you, the player, whose position is used to calculate what you can see from that point and what you cannot see. Hidden stuff is either dark green or grey (have a look at the legend to the right), light green squares are objects which will block the red square’s view, thus having a shadow. The rest, the white squares, are things the player can see. You can add / remove blocking objects by clicking on a grid square.

To the right of the grid, there are a couple of settings you can change: a different direction (it defaults to a 360 degrees view) and a different view angle, which itself results in a different raw field of view. You can also customize how far the player can see. Next on the list, Show Shadows, only works when the other one, Use Ray tracing, is not active and shows the actual calculated shadows. If you tick “Use Raytracing”, the ray tracing algorithm described above is used. If it’s off, the algorithm we started out with comes into play.

So, here you go:

I found myself building quite a number of labyrinth maps, wandering through them.
What did you build?

Categories: Uncategorized Tags:

Fort battle – mixing things up

September 19th, 2013 3 comments

As you all might know there are some problems in the actual state of the fort battles. We think the addition of the resistance and damage formula were a good step into the right direction, but there are still lots of balance issues left and we are aware of it. But as usual the main problem is “where should we start to find a better balance” there are tons of advices from players through all the market forums and of course a lot on the public beta.

Maybe some of you know already that i made a first step to find a better balance on public beta weeks ago my approach was to switch the stamina skill with fine motor skills. I thought and still think it is a step in the right direction, because actually attackers have much more advantages with red skills then defenders have. The outcome is just simple if defender and attackers are equal at health points its 95% clear that the attacker will win, so one thing is clear we need to change something!

After lot of research, mining data and internal discussion we agreed on a more general approach. As first step, which is not really related to the actual balance situation, we want to bring more players to the fort battles with less restriction and easy attending. I will show up how we want to approach that

–       You will no longer need to belong to a town to attend on fort battles

–       We want to add an attending button in the fort battle overview

–       A player does not be present at a fort to register, just during the battle

–       Fort battles of my alliance will be more highlighted in fort overview

–       Screen to choose your side will be reworked and simplified

–       The tactic screen will be simplified and will give you an overview what is required todo

–       You will get a kind of buff icon if you are attending to a battle which also shows the timer when the battle starts and reminds you to travel

–       There will be chat announcements if battles starts within an hour and not full yet

–       You will have the option to get a reminder mail for fort battles


With these changes we hope to get more players back to the fort battles.

As our second step we definitely want to do something about the balance lot of player are very unhappy with the actual situation. Health points and red skills are more or less the only viable option and for the evaluating health points are the most important value.

So we finally want to try to change things, but it is very complicated to start and we are aware that we will need to test a lot and a long time and we will need to change many things for example all the fort battle items and sets.

Nevertheless I finally created a prototype of 2 absolute new formulas, which I want to test with you on public beta. The goal or better my intend why I created two new formulas instead of change the old one is I think that the old formula have to much problems in itself and it is not transparent enough for player. Another problem, which many players also mention, is that the old formula has such a very high luck factor in it.

Finally I will present my first version of the formulas to you right now, please keep in mind it is just an idea for now and most of the factors are more or less a blind guess. This is the reason why I want to test it a lot and then adjust it with the feedback the community gives, because I think I am not able to create the perfect formula it should be developed hand in hand with the community / public beta players.

First we have a new hit chance formula, which looks like that:

50 + Leadership^0.3 + Aim^0.4 + Hide^0.5 + ownSectorBonus * 0,5 (max 5%) + offenseBonus * 0,5  (max 5%) – distance^0.6 – targetSectorBonus * 0,5 (max 10%)  // (max 90% hit chance)


With this formula is a max value of 90% possible, this means even with more skill points on aim or leadership I cannot get over 90%, but I should think about if I go a little over the top because the distance will be a minus value for myself and the enemy sector bonus will also be a minus value of max -10% (this equals for now a fully build town on biggest fort), with this knowledge it might make sense to skill a little bit over the top to compensate those factors. Just as remark a non – fort battle skilled player will have at least 50% hit – distance – targetSectorBonus.

Second we have a new dodge formula, which looks like that:

5 + Leadership^0.3 + Dodge^0.4 + Endurance^0.5 + defenseBonus * 0,5 (max 5%) // (max 40% dodge)


We will also do some smaller adjustments to the resistance and damage formula:

Damage: Weapondmg + Pitfall^0.7

Resistance: resistance(items) + Trade^0.7


If Player A hits Player B the Player B has the possibility to dodge with this formula with a max value of 40% I cannot get more that these 40% and I have at least 5%.

So the sequence changes a bit:

–       Player A attacks Player B

–       Player A needs to calc hit chance

–       If he hits Player B calc dodge chance

–       If Player B fails to dodge the damage and resistance will be calculated still in the same way


What is the goal of that changes and the 2 formulas?

Quite a lot people will now say that it becomes even more worse, because you will have 2 chances to miss/dodge and this is more or less right. Since we have a calculation for hit and one for dodge there will be another new luck factor, but both new formulas are more stable in their luck behavior and we have some kind of minimal values, which every player reaches. In the actual system it is possible to counter a set of skill directly but it is now that viable, so many player invest most of the points in health points.

So back to the goal of the 2 new formula first we want to reduce the luck factor this is why we added a minimal value and added some caps like (max 10% sector bonus) this also sets the focus back to the skill points. Another goal we want to achieve: make other skills more viable beside health points. We want to see other directions of skill sets such as tanks with much life and a high dodge value or some kind of a sniper with an incredible high amount of hit but low life and dodge, who is protected by the team tanks and stuff like that J

And last but now least we want a system which is more transparent to the player this means that in the evaluating overview the leader will see any hit/dodge/damage/resistance and life values and can do a better decision making. You will also be able to see those stats in the battle in future.

Categories: Uncategorized Tags:

Track It or Frak It!

February 14th, 2013 10 comments

If you’re a beta player, you’re already enjoying the recently added Quest-Tracker in it’s purest and most prototypal form we could offer you. Although working hard on getting it done for the just released 2.03, we had to postpone it to 2.04. Despite the fact that it basically works sufficiently, we felt it still needed a little bit more love regarding its feature-set and looks. Therefore we sat down, read your first impressions and collected your features-requests. As always, we couldn’t add everything but I hope we found a good middle ground.

Quest Book

How do I activate the Quest-Tracker?

It’s activated by default and every quest you accept will be automatically added to the Quest-Tracker.

If you want to add already accepted quests, just go to your beloved quest book and tick the new shiny check box.

How do I deactivate the Quest-Tracker?

If you manage to keep track of all the requirements by yourself and remember everything, you can deactivate the Quest-Tracker completely via

Settings -> Interface -> Quest-Tracker

You could also remove all the wachted quests but this would only last until you accept a new one of course.

Quest-Tracker Remove Quest

How do I remove a quest from the Quest-Tracker?

You can either deselect the check box in the quest book or hover over the quest’s title in the Quest-Tracker. You should see a little ‘x’ appearing which will happily remove the quest from the tracker.

How many quests can I track / will it overlay with the TaskQueue?

As many as you can accept which is currently 15 quests. However, depending on your screen size, you will get a scroll bar sooner or later. This is the only proper solution we came up with to avoid issues with other elements of the user interface.

The dynamic size calculation of the Quest-Tracker might need some adjustments, so let us know how you feel about it. As a last resort, you can always drag the window to another place (although the position is not saved).


Can I collapse the quests?

Yes, you can also do that in the current version but now it also saves the status of the single quests but it takes about five seconds till the status is transferred to the back-end.

So don’t instantly refresh your browser after (un)collapsing to prove me wrong, please :-).

Does it update itself?

Yes, it does update itself most of the time. However, since we have a lot of quest requirements, the Quest-Tracker doesn’t react to every requirement out there. If you encounter a requirement which doesn’t trigger an update, tell us. We’ll have a look and might implement it afterwards.

Some requirements are not implementable though. Also, the update might take up to five seconds. If it hasn’t updated itself, you can always reload the Quest-Tracker manually to get the latest status.

Anything else worth mentioning?

Well, the little quest book next to the label “Quest-Tracker” will open the quest book. A click on the quest’s title will open the quest (unfortunately, this doesn’t work for quests whose quest-giver are located on the map (like Waupee)).

Oh, and you can minimize the Quest-Tracker (I just added this feature while I was writing this blog post … I’m too lazy to take new pictures though, bear with me!).

That’s it for today. I don’t know when we gonna update the beta servers to 2.04 yet.

Categories: Uncategorized Tags:

2.03: TheWestApi change

January 25th, 2013 2 comments

Recently there is a small addition on our TheWestAPI which can be used by scripters.
The belonging The West API page on this blog will be updated soon.

Our TheWestApi.register method now returns a GameScript object.

It contains most of the functionality as the TheWestApi.
Due to backward-compatibility the usual methods are still there, but are marked as deprecated and will be removed in the future versions.

When at least one script is registered to our Api a new interface element shows up.

It opens a new window where all registered scripts are located.
The content of the tab is left to the scripter itself.

It is quite simple to use. Just take a look at this javascript code-snippet:

var MyScript = TheWestApi.register(‘myscript’, ‘My Script’, ‘2.03’, ‘2.03’, ‘Myname’, ‘’);

MyScript.setGui(“<b>THIS</b> is my personal tab for my script.”);


Let us know when you want to have additional features implemented to the GameScript.

Categories: Uncategorized Tags:

2.03 Sneak Peek: Fetch All The Markers

December 13th, 2012 6 comments

In the last weeks we’ve mostly been working on fixing bugs and preparing events I’m not allowed to talk about (thus no blog posts, I’m afraid). Recently I’ve been working on a couple of minor features the community has been requesting for ages though. Unfortunately, those additions will be in 2.03 which won’t be released in 2012 anymore.

Gotta Fetch’em All!

With the upcoming 2.03 release you’ll be able to collect all of your finished or expired bids and offers from the market you’re currently at. No premium required. Money will be transferred to your character (not bank), items will be added to your inventory. Forget the times where you needed to collect 20+ items manually, just click this little icon:

(Disclaimer: icon might change until release)

Put A Needle On It!

Did you ever wanted to share a nice spot on the map with your fellow players? Or save a location on the map because you wanted to visit it later again? Guess what, your wishes have been heard!

In 2.03 , there’s the possibility to add up to (currently) 10 markers on the map which can be shared with other players in chats, town forums and telegrams. A short headline has to be added to each marker to describe the spot and to distinguish different markers from each other. Additionally, those markers are shown on the minimap and from there, you can also directly jump to a marker’s position.

As I’m writing this our artist is still working on the graphics for the markers, so I randomly choosed some icons. Their won’t be any blue questionmarks on the map, promise :-).

We also have been working on the “midnight issue”. Every midnight, when we’re handing out bonds, players cannot log in for a couple of minutes (depending on the amount of players playing on the world).

That is annoying and we slightly changed the handout process to reduce the block-time per player significantly. It’s still in testing though.

That’s it for this 2.03 sneak peek, enjoy your holidays and a happy new year!

Categories: Uncategorized Tags:

Link all the Items!

September 28th, 2012 12 comments



At the end I was able to implement a quite small but cool feature which we wanted to have since ages: Link Items.
It was almost painful to show up a friend the just acquired recipe he may need or just share the epic item you’ve found during a job.

With 2.0 this problem is gone.
On the picture to the right you can see how it actually works. The syntax is really easy and it will be translated after you’ve sent it.

Of course we are aware that it wouldn’t make things easier when you first have to figure out which id your desired item have.
So here we’ve got another small feature: Focus a text field where you want to share it and then Shift+Click on the specific Item you want to share (it doesn’t matter where the item is shown). After that the quickcode is shown on the text field.

From the picture it seems like this feature is just limited to the Chat, but here I can ease you.
Sharing items is available everywhere you can write (e.g: Profile, Town profile, Fort profile).
Sadly there is one problem: Town Forum. Due to technical behaviours you are not able to directly link the item into the textfield. But here you can just copy the quickcode
to it and it works as intended, but there is one exception, because linking items is a game feature they will not be displayed when the town forum is opened externally.

Another solution which i’m currently working on is just enclose the item name into the quickcode.



Also our new emoticons (smilies) are available everywhere, too. Now we are able to have a more emotional Western experience. Furthermore we are going to implement a smiley bbcode which will show up the available emoticons.

Of course we havn’t removed the good old chicken which will stay as a little remembrance to our beloved devzet.




One more small feature is upcoming. On the job page you will be able to click on the skill which is opening the inventory and instantly displaying the items containing the required skill.






Last but not least we removed the maximum size of the chat. This will give you the ability to expand the chat below the game interface. Also we are going to do some improvements to the positioning behaviour when saving and opening on different screen sizes.

Categories: 2.00 Tags:

The Return of the Message Highlights

September 13th, 2012 6 comments

Since West 2.0 hit the Beta Servers the players kept sending bug reports about the missing visual notifications regarding new telegrams and reports.  We knew that this feature was missing as we released West 2.0 but didn’t think that it was a ground-breaking feature which should further postpone the update. Time is a rare and precious thing; we needed (and still need) all the time we could get to properly test and balance the major changes. While everything’s calming down a bit and me being in dire need of a change of scene (besides fixing a bug every now and then, I was pretty much working on the still-in-progress taskqueue), I looked through our open tickets and spotted the highlights.

TL;DR: reports & message highlights will be back soon (pictures at the end)!

Unfortunately, being a nice and friendly developer, you start talking about features you’re about to re-implement with your Game Designer and Community Manager before you start working on it. Suddenly a dozen of ideas are thrown at you and you have to decide what’s technically possible (almost everything’s possible – but it’s about the feature and how long it would take to implement). Sometimes that means opening Pandora’s box, though this time the ideas have been reasonable (enough ;)) and could be implemented without a lot of work. Compared to 1.x, there will be more blinking-action going on but before you run away screaming, stay a while and listen. If you read the complete post, you are allowed to go to you favourite communication platform and start flaming :-).

What will blink in the future?

You will get a visual highlight for the following things:

  1. you get a new message
  2. you get a new report
  3. somebody writes in the town forum
  4. you have free skills or attribute points
  5. you get an item which you never had before

So far, so good. Points 1 – 3 are basically the re-implementation I was talking about. Number 4 was already in 1.x as well, but it changed a little bit. The icon you open the skill screen with will not stop blinking until you allocated all your free skill- or attribute points.  Don’t worry, the blinking effect is different compared to the other 4 and is very discreet. It’s the same as you hovering over the icon with your mouse – only that you don’t need a mouse anymore to activate the hover-effect. Awesome, isn’t it? The last point is new and should help realizing that there’s a completely new item which you never had in your inventory. The item itself is not highlighted though, you still have to search for it in your bag (if it was a recent discovery, it’s probably somewhere in the new-category).

I’m getting crazy, how will I stop it?

Except for number 4, every highlight will vanish if you open the corresponding window (if you have new messages and new reports, you have to open both tabs to remove the highlight from the button). That said, for removing the highlight from the inventory, open up the inventory. To remove it from the town button, open the town-forum (yea, the actual town forum button has still to be moved somewhere else).

What will the highlights look like?

It’s blue again, no change of plans there. It’s bigger though and and you’ll notice it faster – probably together with a higher urge of making it stop. But see yourself:

The highlight will fade in & out every second. Fading time might be adjusted at some point in the future, but I think’s ok the way it is. We’ll see.

Anything else noteworthy?

Yes. The functionality of the message-button has changed. If you got a new report, the button will automatically open the reports tab. If you got a new message, it will launch the message tab. If you got both, a new report and a new message, it will fire up the message window. Using the hotkeys n and b (defaults) to open the message or the reports tab respectively will ignore the highlight status of the button.

Are we done yet?

No! There’s one last thing I want to tell you: If you’re opening up the messages window, for example with the hotkey, and you have new reports, it will also be visually represented in the tab and vice versa. Switching to the tab will remove the new-flag.

That’s  it for today! I actually wanted to show you something else regarding the little guy you see ingame, but there have been some difficulties and I had to change my plans. Maybe somewhere next week. Anyways, back to the taskqueue!

Categories: 2.00 Tags:

FFP: Upcoming Changes to the TaskQueue

September 4th, 2012 9 comments

Hey, fellow players. My name’s melkon and after a year of being part of the great West-Team, I’m finally feeling confident enough of telling you about the stuff I’m working on 😉 While the current community Hot Topics are the new Job-System and the amount damage you receive while doing jobs, I don’t want to put any more fuel into that discussion. Seriously, those topics are as heavily covered in our office as in the forums and, luckily, you players are far more civilized when arguing about the pros and cons than we are. Sometimes it even escalates into a good ol’ western-style shoot-out:

That used to be our Game-Designer’s monitor but nowadays he’s utilizing it as a shield against the developer’s wrath. That said, you definitely should take part in the recently launched Beta contest – those nerf-guns are a good way to compromise someone’s authority and are a lot of fun too.

Anyhow, we have been a little bit suprised that the update to 2.0 on the Beta worlds went quite smoothly. Of course, there are still a lot of small bugs and balance issues which have to be addressed, but really big “OMG EVERYONE’S GONNA DIE!!!”-bugs are notably absent. One big issue though is the performace – especially when starting a new world. Therefore we continued the FFP: Fight For Performace. The team already did a good job and, in general, the performance is much better than it has been in 1.36 but we still have a couple of areas where we can improve.

Performance issues regarding the new tutorial have already been addressed, but to further smoothen the starting experience, there’s another heavily used game mechanic: doing jobs. Particularly during the starting phase, players are way more active and queueing up way more jobs than in the midgame. This increased activity results in more requests which itself results in a higher server load which, in the end, usually leads to some kind of lag on the clientside.

So, what are our plans to reduce that load?

There are several approaches but the one I’m currently working on is to reduce the requests made to the server. Where to start? An educated guess was pointing us to the action which starts a job and the taskqueue overall. Analyzing the logs confirmed our assumption. Players are hitting the “Start” button in a very short interval to queue up jobs and therefore sending one request with every click. A player who wants to add 9 new jobs to his queue will accordingly fire 9 requests. Multiply that with the amount of players who are starting on a new world and you have a ton of requests made, in a very short amount of time.

Now back to the idea of reducing requests. If a player hits the button in a couple of times in a short interval, why do we have to send every click as a single request? That was the question we have been asking ourself and that’s what I’m working on right now. When I’m done, hitting the “Start” button will not instantly result in a request but will add it visually to the taskqueue.

After an amount of time, say, 500ms, the actual request will be triggered. If the player hit the “Start” button again before those 500ms have been passed, the timer will reset, waiting another 500ms before the actual request will be made. After the 500ms, every added job will be send to the backend, resulting in only one request instead of 9. The backend then processes the request, adding the jobs to the player’s queue and send one single batched answer back. The client on the other hand will parse the server’s answer and update the tasks which are already in the queue with the proper information. Everything in one request!

Thing is, it’s easier said than done: the complete task-system was never designed to be batchable. It’s quite a big task which will take sometime until’s finished and there are always things, like bugs you guys report, which have to be dealt with first. Speaking of which, we have still a lot of things to do. Besides fixing bugs, we’re working for example on the backend to bring back your beloved highlights when you get a new report or telegram and on properly refreshing your health, energy and experience. We’re doing all that while we’re constantly reading the forums and are discussing your feedback. We are very thankful for your constructive criticism, good ideas and we’re keeping it in mind when doing changes to the system, so keep it coming!

Categories: 2.00 Tags:

Be ready for 2.0 public beta

August 13th, 2012 7 comments


i am proud to announce that the development of the version 2.0 has reached a beta state. We plan to update the public beta this week, more precisely on Thursday. We await your feedback and we know that we have still a lot to do and of course we will have a lot more to do if we get the first wave of feedbacks. 🙂
Public beta World 2 (Amchitka) will get the update first. After that we will launch a new world 3 which will get the 2.0 update too. World 1 is planned for next week, the reason for that is simple: we have to migrate stuff like towns etc on the new map and we want to make sure that everything works fine. On world 2 there are just less towns and player. On a new world we don’t have any problems with migrations.

Explore the feature list here

Categories: 2.00 Tags:

Interface implementation started

July 5th, 2012 10 comments

We started last week with the implementation of the new interface and of course i will show you the first elements 🙂 First of all here is the new status bar with the standard information like bonds, money, deposit and nuggets. With the nugget button in the middle you will get to the premium window to active or longer premium bonuses, with the plus button in the nuggets label you will be redirected to the premium buy window.

We have a new bottom bar with buttons for the common windows there are 4 kinds of buttons: normal, non active if a feature is not available yet (for example crafting before you reach level 20 or town button before you are a member of a town), hover if you mouse over and active if a window is already opened

Last element for this week is the chat. This is how the chat looks if you login into the game it just shows you how many friends online and if you got some new friend requests or chat messages. If there are new chat messages or friendrequests the button will start to blink. To see chatrooms and friends you will need to open that box (i will show the opened box view in the next blog post).

We are very very busy at this point of development we have already a little delay. There is a lot of javascript code which has to be changed, because we will finally get rid of mootools. There are also a lot of changes in backend for example changes for storing and loading the new map, chat improvements, daemon improvements. We are very excited how the 2.0 version will perform on client machines and on our servers because we invested a lot of time in optimization of code in the 2.0 development.

On graphical side the new map is nearly finished. There is one map editor left, who does the finishing at the moment.

The internal beta version is planned for the beginning of the next week it is a very hard deadline but we will do our best.

Categories: 2.00 Tags: