And the Lord gave unto Moses two tablets…

November 30th, 2016 1 comment

Facebook users, rejoice, for this is not a drill: in Version 2.47 we will introduce a number of usability improvements for tablet and smartphone users. Using the latest advances in web technology, we hope to make the game work smoothly with both mouse and touch input. The game will continue to work best on large screens (such as those of the Surface Pro and larger iPad Pro model) but even phone users will reap some benefits from our latest push.

The West 💔 Scrollbars

  • Mobile browsers will now load the game at our minimum supported resolution of 1024px instead of the default 980px, avoiding a horizontal scrollbar at 100% zoom.
  • Ever noticed a vertical scrollbar after opening your inventory? Poof – it’s gone too!

Window Management

  • The quest tracker/notepad will now be minimised by default if your browser is 1024 scaled pixels wide or less. Additionally, the default position will be saved locally instead of syncing to the server, so the window won’t start off in the Never Never if you login using a computer with a narrower screen.
  • Windows will be repositioned more rationally when the screen changes size, for example when an onscreen keyboard appears.
  • In supporting browsers (see below), windows can be repositioned by dragging their title bar with one finger.

Safari is the New IE

Internet Safari Explorer logo

The artistic work of Jacob Rossi.

Unfortunately, some of the best changes I’ve saved for last are reserved for users of Microsoft Edge, Chrome 55 for Desktop/Android, Opera 42 for Desktop/Android and eventually Firefox for Desktop/Android. The notable omission is Apple Safari and all derived iOS browsers. In 2007, with the release of the original iPhone, Apple heavily invested in the mobile web. Since then, a number of forces have caused Safari to drop from leader to laggard:

  1. Apple has a vested interest in promoting its own App Store over the web, where it takes a 30% cut of all app revenue.
  2. Safari no longer shares its core engine with Chrome and can’t ride on its coattails with joint development.
  3. All iOS users are monopolised into using Safari’s core engine, Webkit, harming competition and innovation.

Pointer Events, the World Wide Web Consortium specification that drives our touch and stylus support, are not supported by Safari for now. We hope we can fill this gap in the future but please understand that, like with Internet Explorer, this is not always possible in a timely fashion.

Other Touch Support

  • In the pre-battle screen, your fort starting position and target can be adjusted by dragging them with one finger.
  • On devices with a screen width of at least 1366 scaled pixels, the map can be dragged with one finger.

That’s All, For Now…

We hope you enjoy testing these changes on the public beta! If the update is well received we would like to go further and implement additional tweaks for mobile browsers. The suggestions on our radar at the moment include allowing full screen mode as well as improvements to pinning the game to the home screen. Please let us know if you have any others!

Categories: Uncategorized Tags:

It’s the Final Countdown 🎹🎶

September 3rd, 2016 5 comments

After several months and two test phases on the Polish servers it is almost time to release our changes to fort battles. Thanks to everyone who took part in the testing! It is impossible to please all players of every language but your feedback has helped guide us to a solution we believe will be a solid improvement upon the current situation.

With the next update we plan to implement a minimalist suite of changes from our testing. Compared to the version currently on Polish servers, we will leave the fort battle map’s original sector bonuses almost completely unchanged. Furthermore, defenders will no longer receive an inverse bonus from the flag penalty; instead they will merely receive no penalty from these sectors. Additionally we will slightly reduce the new worker class bonus. This leaves the final balancing changes as:

  • Stamina and hiding for attackers and defenders respectively are swapped with hiding and setting traps.
  • The flag and surrounding sectors provide no penalty to defenders.
  • The flag has a penalty of -10 and the surrounding sectors -5, halved from before.
  • Aiming and dodging add x0.5 to attack and defend values instead of x0.4.
  • Harambe is lost but never forgotten.
  • Workers receive an overall 20% bonus to their attack and defend values instead of 30% from sector bonuses only.

Of course no changes are ever really final. We will continue to monitor their performance over the coming weeks and apply any tweaks as necessary. At present evaluation, the changes satisfy our original criteria except for one element, reducing the likelihood that a battle reaches 55 rounds. That is something we may address in a future balancing initiative targeting damage and resistance calculation but for now we look forward to seeing some hard fought contests between attackers and defenders.

Categories: Fort battles Tags:

Make fort battles great again!

June 6th, 2016 6 comments

After a long stint on the beta servers, last week we finally released our fort battle changes to the Polish servers. The results were very pleasing: defenders once more resembled a well drilled force instead of WW1 conscripts waiting to go “over the top” and workers loudly roared. But as we wave goodbye to the era of fort ownership transferring more easily than the common cold, it is difficult to part with killing all defenders being the preferred method of attacker victory. While the suspense of capturing and holding the flag can lead to some of the most exciting battles, nothing beats the satisfaction of sending your enemies for a nice long sleep. Of course this trade-off is through necessity — if it’s possible to wipe all defenders then capturing the flag is mere child’s play — but what if we could change that?

The core balance behind fort battles is quite simple. The defenders receive aiming and dodging advantages via sector bonuses while the attackers receive numerical and line-of-sight advantages for an even fight. To shift the midpoint of this balance, merely adjust team sizes and/or the fort’s sector bonuses. As you know, this balance breaks down completely once the attackers pierce any section of the fort; defenders are forced to huddle around the flag allowing the attackers to seize the towers and walls. Prevention has been the prescribed cure to date, strengthening the walls to avoid the scenario in the first place, but clearly that also makes the defenders harder to kill. A new approach is needed.

The flag is providing the pictured defender with a bonus instead of a penalty.

A well fortified defender ready for battle. An attacker standing here would be penalised -20 instead.

After a little brainstorming we devised a simple change to make the flag more defensible: invert the aiming and dodging penalties of the negative sectors into bonuses for defenders. (The attackers continue to receive a penalty as normal.) This significantly slows the cascade of defenders being funneled towards the flag only to be killed almost immediately. It also provides leeway to reduce other building bonuses without adversely affecting overall team balance, as requested by our Polish testers. Of course, it is not our intention to add a fifth tower to the centre of the map, so the bonus/penalty to aiming will be lowered substantially to prevent sniping out the gate while the bonus/penalty to dodging remains high.

Besides making for happy Polish players, reducing the sector bonuses of buildings should improve our other metrics. Consider:

  • Reducing the dodging chances of 9 defenders shot at by 50+ attackers has a greater impact than reducing the aiming chances of 9 defenders who can only fire 9 shots collectively per round. This decreases the likelihood a battle will reach 55 rounds.
  • Decreasing sector bonuses increases the relative importance of player skills, which are in competition with health. This encourages players to diversify their skill points.
  • Reducing the effectiveness of the defenders means fewer attackers are required for a balanced fight. This allows us to bring the maximum attacker to defender ratio closer to 1:1.

Despite that, of course, these priorities are secondary and the overall team balance comes first. We cannot allow the defenders to continue to get steamrolled every battle 😉

Categories: Fort battles Tags:

O Come, All Ye Fortful

December 1st, 2015 16 comments

Now that we have released our third suite of changes to duelling, it is time to turn our attention elsewhere. For now our focus remains on fixing bugs, however the next major project is clear: adjustments to the fort battle formula! We plan to focus on five priorities here:

  1. Improve the balance between attackers and defenders.
  2. Improve the balance between all four classes.
  3. Maintain or decrease the chance of battles reaching fifty five rounds.
  4. Decrease the importance of health.
  5. Bring the maximum attacker to defender ratio closer to 1:1.

For this we wish to bring back an old approach from a couple of years ago. The attackers currently enjoy a significant advantage because by placing attribute points in strength, they gain points in both health and their strongest aiming/dodging/resistance skill. Clearly this is unfair for the defenders, who must choose between the two. It also leads to weird flow on effects in battle strategies, which increases the importance of duellers (sniping through the gate) and decreases the effectiveness of workers (not mounting fortifications). Simply removing this advantage should, at least in theory, reverse the series of unfortunate events. With that in mind, we intend to swap the following skills:

  • The attackers will use hiding instead of stamina.
  • The defenders will use setting traps instead of hiding.

These two changes will mean health and leadership become the lone fort skills in their respective attributes, while mobility and dexterity each contain two fort skills. We anticipate this will mean a decrease in the attacking team’s average health and therefore the length of battles. It would also increase the desirable attacker to defender ratio for a balanced battle from about 1:1 back closer to 1.2:1, although likely not quite as high as before. Hopefully the better team will be joyful and triumphant and not always the largest.

Of course, any major changes will undergo significant testing before they reach your local worlds. We are also mindful of avoiding disruption to the fort battle championships. However, in the meanwhile we’d love to know your thoughts!

Categories: Fort battles Tags:

Duelling Changes: FAQ

August 24th, 2015 5 comments

G’day g’day… this thing still works, right?

Over the past few weeks you’ve been eagerly peppering your local community managers with plenty of questions and feedback about the most recent duelling changes released on the public beta. Words always sound better straight from the horse’s mouth, so I’ve compiled a list of frequently asked questions from a developer’s perspective.

How did resistance calculations change?

As in the previous change to the duelling formula, the impact of the secondary resistance skill was adjusted. (That is, reflex against melee duellers and toughness against ranged duellers.) In the 2008 formula, the secondary skill added 50% of its value to the calculations, which was reduced to 25% in the 2011 formula. We leave it to you and your trusty Wyatt Earp Colt Buntlines to estimate the new midpoint for yourselves.

How did the stance bonuses change?

Selecting the correct dodging position no longer attracts a 50% upfront chance of the shot missing entirely. Of course, you will continue to receive a significant percentage bonus to your dodging skill.

How did the other duelling calculations change?

Most of the other changes are inline with the 2008 duelling formula. The internal workings have never been discovered and I’m not about to change that, but most notably look out for less of an emphasis on aiming and dodging in favour of appearance and tactics.

Resistance skills were originally overpowered, won’t they become so again?

This problem has been carefully considered, so the answer is no, provided our estimates are in the ballpark. The previous change to the duelling formula saw melee-resist duellers swing from grossly overpowered to somewhat underpowered. Since we expect many of the other changes to favour ranged duellers, we feel it is appropriate to give resistance duellers a bit of an initial boost. We will make further adjustments as necessary.

Charisma builds were overpowered too, what about those?

That’s debatable. Charisma builds gained popularity amongst soldiers because they play to the strengths of their class bonus, effectively reducing losses while offline, when you cannot actively adapt to your challengers’ weaknesses. (As you know, zero motivation duellers are especially focused on minimising losses; it’s not as critical to experience duellers.) There was no real problem to speak of in other contexts. As the past few years have demonstrated, massively weakening appearance and tactics to address this issue was a mistake, eliminating fundamental diversity in skillsets and tactics. It would be foolish to conflate class and duel balancing a second time.

Okay then, how did you account for soldiers?

So far we haven’t but it’s an issue we’re actively monitoring. Most duellers pick the soldier class because it has always been the only class that provides an in-duel advantage. (The dueller class has had additional convenience bonuses added over the years, though, to account for this.) It would be possible to decrease its effect from 50% to, say, 20%. However, we don’t intend to do so lightly and therefore no changes are being even trialled for now.

When will the formula changes be released?

When we are satisfied they are an improvement for both game design and community popularity!

Are more changes to zero motivation duelling planned?

No, not at the moment. We believe we have addressed almost every reason for zero motivation duelling, shifting the advantages and conveniences in favour of experience duelling. In doing so, we have done our job: providing the mechanisms and mechanics to promote a fun game for everyone. We can’t rule out any further tweaks and adjustments for the rest of time but it wouldn’t be an RPG if we tied strings to the limbs of every player.

That’s all folks! Chuck us a comment if there is something you’d like us to write about 🙂

Categories: Duels Tags:

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: