The West Dev Blog

This blogpost was written – but not published – a month ago. I finally had some time to prepare the images which hopefully makes this post a little bit easier to understand.

The first prototype of MPIs had already featured a bear and a working pathfinding implementation. Unfortunately, it only worked because it was incomplete and the bear itself was smaller. Nowadays though, the bear (and the MPIs, more on that later) has received a facelift and increased in size – from a 2×2 object on the map to a big 2×3 object. Unfortunately, this change led to a problem that was known in advance but postponed for a prototype at a later date (read: now) to deal with. So, what’s the issue? Objects can turn; they also have a “front” (their face, basically). Now try to turn a square around its center – it remains in the same position, albeit the front is facing another direction. Now do it again and turn a big 2×3 object around – the position of the object changes:

The old bear didn’t turn. It would always look in one direction and would walk either forwards, sidewards or backwards but it would never turn around – and it didn’t need to, as the bear in the first prototype had a 360 degrees field of view, not 90 degrees. What I was working on over the last couple of days was to make the bear turn around; to create a more pleasant, more natural looking path.

This turned out to be not as straight forward as people might think. The old pathfinding algorithm was working but the grid system had several shortcomings. Pathfinding basically boils down to how you visit your current neighbours and rank them relative to your actual goal. Before you can rank each neighbour, you also have to make sure that it’s actually free. That was slow in the old system because it basically moved the complete entity (which is several cells big) and tried to place it on the new coordinate – if it succeeded, the cell than would be ranked, if not, the cell was not picked as a candidate. Let me tell you, that is a lot of overhead: the more cells an object covers, the longer this check would take. I was banging my head against the table looking for another option, and it came in form of a method called clearance-calculation.

According to the article, a cell’s clearance value defines which object of what size fits in that specific spot. If a cell has a clearance value of 8, every object with the size of 8×8 or less can be moved without issues to the cell in question. Instead of checking each of the object’s cells, one only needs the size of the object and the positon it wants to move to, check the clearance value of the cell and decide accordingly.

There’s a catch though: it only works for square objects, but our bear grew to 2×3 which ain’t one. Using a clearance value of 3 doesn’t work all the time, since there can be areas where a 3×3 object wouldn’t fit, but a 2×3 one would, so the information available with the given clearance value is not complete.

Based on the clearance value, I was thinking about ways to pre-calculate if an object fits a particular position and ended up at calculating a clearance value for each unique layout per map. The 2×3 layout is moved to any non-blocked cell to see if it fits. If yes, save a clearance value of 1 for this cell or 0 when it doesn’t, then continue with the next one. That’s still not enough information though as the 2×3 is, when turned around, a 3×2, so I had to do the above again for a 3×2 layout and merge those values together: if both 2×3 and 3×2 fit in one cell, it has a clearance value of 3, if only 2×3 fits, it’s 1 and if only the other one fits it has a level of 2 – so the bear could fit into that specific spot if it would turn around before.

The next issue on the list I had to fix was object blocking. Objects block each other, meaning they need to be taken into account when calculating a cell’s clearance values. As the current calcuation only works for static stuff like buildings (since they’re placed in advance and cannot move), the clearance map needed to be updated every time an object got placed on the map (e.g. player) and moved around to be useful for pathfinding. Luckily updating the clearance value is straight forward and only cells to top left need to be recalculated:

(12 = clearance value of 3 (1 + 2))One thing I wasn’t paying attention to up until now was the object’s positioning on the grid. Every object has a center of rotation which is also used as the coordinates to place the object on the grid – the other cells which an object covers are relative to the rotation center. The rotation center is, who would’ve guessed, in the center of an object – on the other hand, the clearance value does not specify that the rotation center, but the top-left cell that an object occupies. Easy solution: either move the calculation to the rotation center or let the layout reference the top-left corner in each direction. I chose the latter one, problem solved.

With all these pre-calculated and dynamically updated clearance values I finally was able to go back to the actual problem: letting the bear turn around. As I stated earlier, it boils down to the neighbour-selection and ranking for each possible neighbour. Instead of only considering the neighbours of the direction the bear is facing, I also visited the neighbours of the other directions, adding them to the list of possible candidates. Unfortunately, that wasn’t enough as the rotation was calculated as an additional step which reduced the likelyhood of being chosen. The bear kept going sideways. I was able to remove the additional step due to the fact that I now visit the other direction’s neighbour instead of the direction itself. Theoretically this should increase the amount of checks but it practically decreases them as a valid path is found faster with less traversing. I also heavily increased the likelyhood of choosing one of those direction neighbours as the next waypoint if the direction the bear has to walk (e.g. left) and the directional neighbour would face to same direction (e.g. both would go left), so the bear turns around and goes left instead of sidewards.

Colorcode – green: walking north, yellow: walking east, blue: walking south, red: walking west. Also for the following images. The yellow area at the start is just the starting point though.
Almost the way I’d like it to be, but do you catch one last issue? The bear has a tendency to go upwards and I was scratching my head why it would like to do that. It came down to a default value: if the bear moves diagonally, the directional value was set to 1 (= facing upwards) as a diagonal direction is not supported. This means every time it moves diagonally, it sometimes would highly prefer to face to the north and go down from there.

How to resolve that issue? If I wasn’t able to calculate a natural looking direction for the next waypoint, I just used the direction the bear should face relative to the actual target. If a bear’s target was south from its current standpoint, the default direction would be 3 (= south) – this little tweak reduced the occurance of weird behaviour to a minimum!

Are we done yet? No, the algorithm still needs some tweaking as there are still some weird issues where the bear moves in the proper direction but then decided to do a quickturn before going back on the orignal, good-looking path.

Also, in the current version, there is an issue with AI finding a proper goal to walk towards – where the pathfinding actually can find a way – to. However in the last month we have been focusing on the frontend instead which you can see every now and then when our Community Manager Joony leaks a screenshot on facebook, the MPIs are covered in the latest Innogames TV.

It has been a little bit quiet around here but that silence should be broken today! As we have been secretly working on the Multiplayers Instance whenever we had spare time, the hard labour finally paid off and first results are on their way. I won’t show you anything fancy today, I’m sorry, but maybe it’s interesting nonetheless. Today I’ll talk about the stuff you normally don’t see but is crucial to everyone – the server architecture.

Independence Day

What we wanted to achieve is independence. Independence from location, independence from servers, independence from worlds. Well, the game has to run *somewhere* on *some server*, but we wanted to lift the restriction that games from world 1 can only run on the servers of world 1. It’s a common problem that one server has spare resources while others are busy, slowing everything down on their world. Adding the in-development feature MPIs to those might slow things down even more during peak hours, having a negative impact on the normal gameflow. As a result, we had been thinking about splitting the MPI systems into three parts: a world server, manager server and battle server – each with different tasks.

World server

This one basically is the player’s gate to the MPI system in general. It serves you everything you need: the client to connect to other parts of the system, a list of available games, allows you to create games and forwards you to the battle server where the actual game will take place.

Battle server

The battle server is the heart of the MPI in terms of game logic. It handles all the instance specifc data, lets you attack other players or move to another cell on the grid. Everything that is related to the game itself is communicated between the battle server and you, the player directly. As previously said, you will be forwarded to a dedicated server as soon as you create and start a game.

Manager server

All the data needs to be kept somewhere, and that is the manager server’s responsibility. It knows who is playing from where, in what game and on which battle server, who is currently queued and searching for a game and who just lost an instance.

What I briefly described in words can also be nicely illustrated with the help of a picture:

A Workflow Example

A client (player) connects to its world server, tells the world server that it want to create a new instance which the world server then tells the manager server, which then will create a gamelobby for the instance. From that point on, other clients can see the newly created game and join in. If the number of players are sufficient, the host (the client who created the game) can start the game. Again, the world server forwards the information to the manager server. Now the manager has to decide on a free battle server to host the game on. After it found one with a low load, it tells the chosen battle server to create the game and forward all information needed to connect to the battle server back to the world server who then pushes the answer back to its clients. On recieving the information, the clients finally connect to the battle server and the game can start. As soon as it finishes, the battle server will inform the manager that it’s over along with the actual game result and if any rewards are set for the given result, the manager will push the data back to the world server who will grant the players their deserved rewards. Rinse and repeat.

The Idea Behind

The interesting part of this architecture is: while it’s technically possible to run everything on one actual hardware-server (and that’s how we start rolling out the MPIs), it’s designed to be split among different ones. While each world will have its own world server, there is no need to have a manager server and battle server for each world. The world servers can connect to any configured manager which can forward games to any battle server the manager server knows about. In the end, it’s specifically designed to let each world server from the same market connect to one, and only one for the complete market, manager server. And if it’s only one manager server, there is one big queue, one big list of available games. Every player would be thrown into the same pot and players from different worlds could play together … or against – world vs. world, anyone?

I’m sorry – you’re thinking too small.

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:

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: http://map.the-west.de/view.html

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

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.

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.

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.

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.

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’, ‘http://www.example.com/’);

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.

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!

Items

 

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.

Emoticons

 

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.

 

Job

 

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.

 

 

 

Chat

 

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.

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!

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!