Author Archive

A Happy End

August 25th, 2014 4 comments

Adventures have been on the public beta for almost two weeks now and we are very happy with how things are going. The servers are stable (and bored, which is good thing to be when you’re a server) and we notice – and get – hardly any bug reports. Players do keep reporting connection issues but those are harder to resolve unfortunately. But most importantly, the feedback that you, our players, give us is extremely positive and we’re very glad that you enjoy the adventures. To give you some numbers: more than 5 000 adventures were played in the first week of release. With each match taking about 15 minutes that’s a playtime of 1 250 hours – or 1 250 fort battles. In total, more than 40 000 (non-unique) players played the adventures, an average of eight players / adventure. Again, that would mean you could fill up more than 150 (big) fort battles – which is almost a year worth of big fort battles on most worlds.

Looking at those numbers, we concluded that the adventures beta-launch was very successful and that the work we put into the adventures, even though we’re knowingly opening another job-site, was The Right Thing to do.

Moar numbers!

You want more numbers? Sure! For example, 1.3 million abilities have been executed – Move and Attack obviously leading the ranking, followed by current meta ability selection of Quickshot, Snakeshot and Heal. Coming back to the Move ability, players walked more than 2 million fields. If we define one field to equal one meter, you guys walked about 2 131 km. That’s about the distance from our HQ in Hamburg to the most southern part of Italy and it would take you about 446 hours (according to Google Maps). Apart from that, 93 million damage has been dealt in total. As healing is not that effective, more than 28 000 players were knocked out – and, unfortunately, more than 1 200 players were shot in the back by their friends.

west_mpi_players-weeklythat’s the typical adventure activity – can you see when it’s night? ūüôā

So, what’s next?

We’re now finalising The Last Things that need to be done before we can launch worldwide. We’re still working on improvements from user feedback, adding more gameplay information (like a scoreboard at the end of a game) and making the adventures in general easier to pick up and play. We’re adding more stuff to earn from playing adventures (the most obvious are achievements) and, post-launch, we’ll add a new map every now and then. We also know about the issues of afk-players and lobby-leavers and have several ideas and things in the making to reduce the pain those players cause, e.g. a ready-dialog before the lobby opens (the elite testers do know that one already) but haven’t decided on a solution yet. So there’s still a lot going on and a lot of things which will change – and hopefully create an even better experience. It’s honestly a very exciting time to play, keep playing or come back to The West.

A Happy Goodbye

With all that good news, there’s one sad piece of news as well – this is my last devblog post because I am leaving the team to start working on a new project. I have been working for The West almost three years now and I am glad that I was able to do so. The West changed a lot in those three years, for better or worse and I got to know quite a lot of players and people. It’s always nice to talk to actual people (and then being surprised that they are able to talk and criticise in a constructive way instead of flaming only ;)). However, I’m very happy that you, the players, have lifted the burden from our shoulders concerning the adventures as it was my last big project with a lot of uncertainty and high risks. I’m sad that I won’t be able to escort the adventures into the real life actively, but I’ll follow its progress for sure and hope that the rest of the world thinks the same as the players who have been able to test them already on beta.

So long, thanks for your time. My horse and I keep riding into the setting sun.


Categories: Uncategorized Tags:


July 28th, 2014 7 comments

Most things start with a simple idea. Although I was not working for InnoGames at the time The West was created, I’m pretty sure there was an idea which resulted in the game you play today. The multiplayer instances, in short MPIs, started off with an idea as well but as the development progressed, that idea evolved into more than everybody would’ve thought of. When we first started working on the MPIs, it was designed as an improved fort battle, with similar graphics and gameplay but different maps and objectives. After a couple of technological decisions, the developers started working on an initial visual prototype, a proof-of-concept:

First MPI prototype

There was a small graphical update with an actual cowboy and some trees and stones:

Slightly improved graphics

After a couple of playtests, however, we thought that we could do better visually. Meetings were conducted and several options discussed. We looked at different games and their perspectives and, in the end, decided to try out an isometric one. We got back to work and started on another visual prototype. The initial result was the following:

First isometric prototype

From there on, we went with both versions, top down and isometric. The player was able to switch between them while playing the game as the top down view presented a better overview but the isometric view looked nicer. Although it was better, the visual quality of the images was lacking as they were mainly dummy images. After a couple of iterations, sweat and tears, we put together a simple new map with the latest version of our graphic assets:

High quality graphics in the isometric view

And it looks great. With the art style and high-quality images finished, there was one more big task to take on: the UI. Again, ideas had been gathered, nerf-guns had been used but we, as we always do, settled on a first version:

There’s also a new, second setting: desert. No grass here!

However, although we have played the MPIs quite a lot, we haven’t with such an UI. More playtests and your feedback will decide on the UI’s future. There was also another victim that couldn’t keep up with the pace of changes: the top-down view. As the isometric view received more and more visual information, the top-down did not. At one point, the isometric display had the better general overview and therefore we decided to cut the top-down, freeing up resources to focus on the remaining view.

Anyway, did you see the icons in the bottom bar? Those are your abilities! Not just the graphics, but also the gameplay evolved. Instead of a basic Attack and Move, one will have the possibility to choose between different abilities, such as Eagle Eye, which increases the chance of your next shot to hit critically, or a Quickshot, which shoots your target twice!

We are very happy with how the feature evolved, and we hope that you, as soon as you’ll have a chance to play the MPIs, will also like it. There surely are still a lot of question marks around your head but we’ll try to answer those in the upcoming weeks with further information and dev blog posts!

Categories: Uncategorized Tags:

How We Taught A Bear To Turn

May 30th, 2014 2 comments

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.

Categories: Uncategorized Tags:

Are You Talking To Me?

April 15th, 2014 2 comments

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.

Categories: Uncategorized Tags:

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:

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 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:

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: