The West Dev Blog

Thanks to everyone who responded to our last dev blog post, we are very encouraged by the positive feedback we received. Previously I planned to write this post about the experience changes and some other small utilities we wrote along the way, and that post will still come soon, but today instead I will mostly share some explanation on the next tranche of changes deployed to the beta server yesterday. Onwards!

Simply Irresistable

The battle summary from our admin tools.

Some of you wrote to us that despite the previous changes to our formulas allowing you to hit more often, many lower level players still registered 0 damage, which is no better than missing. To investigate this further, we did a deep dive into this battle, with a particular focus on the attackers. Looking at the players’ stats, we had some interesting observations.

Factoring in most sources of damage and resistance such as weapon average, item buffs, leadership, hiding, own sector damage bonus and resistance bonus (but not critical hits), we found that the attacker with the highest damage had about 3.5x the damage compared to the resistance of the attacker with the highest resistance. The players with the highest resistance tended to be high level and receive the majority of it directly from resistance bonuses on items, with only a small portion coming from other sources, ie skills.

We also simulated a ’round robin’ where every attacker fired one shot at every other attacker but couldn’t die. From our calculations, we found that approximately 10.6% of shots resulted in zero damage because the target had higher resistance than the shooter had damage. Of course, we cannot directly apply this number to an ordinary battle – not every player fires the same number of shots and certainly not at their own teammates – but it’s a helpful approximation and one we want to lower.

To achieve this, we decided to split the resistance formula into two parts, giving different priority to each. One part contains the direct resistance bonuses given by items and buffs, the other part contains the remaining sources of resistance (which you remember means skills). For now we’ve given these parts the names of secondary resistance and primary resistance respectively in our code but we’re interested to see how the community chooses to label them. At the moment we still show both combined in the battle interface but this may change in the future, if we decide to keep the change long term. The differences are shown below:

Going back to our small simulation, we found that across the 19 740 shots, there were a little over 6 400 shots that resulted in some resistance being clipped, up from just under 1 900. (After all, once you resist all the damage, your extra resistance won’t heal you!) This resulted in an average damage increase of approximately +50 per simulated shot. Using some back of the envelope calculations, we estimate that would convert to an extra 76 000 total damage for the attackers based on the number of shots fired in our focus battle.

There are some caveats to these calculations. Firstly, this is only a rough guess – more incoming damage generally means more knockouts and fewer shooters in later rounds, but also less players available to block sectors – although we’re satisfied that the results appear reasonable and worth trying. Secondly, we must also bear in mind that our focus battle has an abnormally high number of lower level players for an established world; high level players with high resistance bonuses being shot at by other high level players with 3.5x higher damage bonuses are less affected. In particular, we expect this change will have the largest impact on the international servers.

All the Small Things

Your community managers have been collecting feedback about the changes so far and we were pleased to see that most markets except one were generally positive about them. The rewards were a recurring theme in your messages to us, which will be discussed in a future post.

If you have any other requests regarding fort battles, please be sure to share them with us. Based on your earlier feedback, we already scheduled some time to change how the fort battle player caps are shown in the planning screen, which we hope to include in the next beta update. In particular, since converting our fort battle frontend from flash to HTML5, any interface ideas we may have previously passed over could be back on the table.

See you next time!

As developers, one of the areas of the game we most enjoy working on is fort battles. This year I am pleased to say that changes to them have been placed at the very top of our internal roadmap. Yesterday, we announced our latest efforts, follow-up changes to the attack and defend formulas. Over the next couple of posts, I would like to offer our rationale behind the changes we settled on, as well as show you some of the internal analysis we performed.

After our Christmas holidays, we were immediately given a short brief for the expected changes: raise fort battle rewards (with a particular focus on experience) and adjust the team balance to strengthen the attackers and weaken the defenders. We also examined feedback from the community, whose priorities helped inform the specific design of our changes. In no particular order:

• Spread rewards more evenly between classes/roles, with a particular focus on adventurers and tanks
• Increase the competitiveness of lower-level characters on established worlds
• Balance the teams such that fewer extra attackers over defenders are needed for an even fight
• Design systems that are more robust against the idiosyncrasies of ever-changing equipment and metas

A nicer photo than mine of Sydney’s New Year’s Eve.

Previously, we have attempted to address this last point by changing the fort structures to give percentage-based bonuses rather than fixed bonuses. In the upcoming update, we’re expanding this approach to the base bonuses and distance penalty. Currently, your character receives a fixed +25 attack value and +10 defend value bonus. Soon, +15 of that attack value bonus will be converted into a 15% attack value bonus. This is expected to increase the attack value relative to the defend value of high-level characters, advantaging the attackers.

Conversely, this change in isolation would cause lower-level characters to lose some attack value. To offset that, we’re introducing a new ‘beginner bonus’, offering up to +15 attack and defend value bonuses to characters below the level cap. Initially this will scale linearly; for example, if your character is level 125 (half of the maximum), they will receive a +7.5 bonus. We feel this is an improved solution that will also help the survivability of lower-level characters in established worlds.

As mentioned earlier, the distance penalty is undergoing a similar transformation. Here are some simplified comparisons from our help resources:

You may immediately be wondering, why not 10%, 25% and 44%? There are a couple of other major changes here affecting our comparison. Firstly, we’re reducing the distance’s exponent in the formula from 1.4 to 1.2 or, as you may have also seen it written in the past, the squared distance’s exponent from 0.7 to 0.6. This matches how it was previously; in the past we increased it to offset power creep, but now we are reverting that change with the switch to percentage-based bonuses.

Secondly, we will apply the penalty to the shooter’s attack value rather than as a bonus to their target’s defend value. Now our attack and defend value formulas are monomial, we can make this change without affecting the probability of two characters hitting/missing, calculating it behind the scenes in keeping with how players traditionally understand it. However, this change will reduce the difference between the attack and defend values when a high-level character is shot at by a lower-level character, and likewise when a high-level character shoots at a lower-level character.

I will finish this post with another comparison. Imagine two level 150 characters with 697 leadership, 831 aiming and dodging, 591 hiding and trapping, 22 multiplayer attack and 1 sector multiplayer attack, not standing on any structure. They would shoot each other with the following expected values:

That’s all for now! We hope you like our changes so far and look forward to hearing your feedback. There is still a little more time set aside for further fort battle changes so keep attending those battles and help us to help you. Please let us know if you found this post interesting and we may share some more insights about the little utils we developed to analyse our data and the change proposals.

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 x^0.5 to attack and defend values instead of x^0.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.

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.

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 😉

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!

The flash client for the fort battles has been developed in an extremely short time (compared to the rest) and due to this, it is not as efficient as it could be. I fixed the worst issue in the drawing algorithms of the client about 2 weeks ago: The sectors.

Sectors and onlinestate of players

The reason was the algorithm of how the sectors have been drawn: For each cell, the algorithm checked the borders of the sector, and if the cell is next to different sector, a border is drawn on that side of the cell. So this check was done 4 times for each edge of the rectangle and for every rectangles on the map. This is a stable and simple approach, however, also one of the slowest approaches.

In order to fix that, I changed the approach of drawing the sectors: Instead of checking each cell one by one (about 600-700 cells), I wanted to draw each sector one by one (there are about 50 sectors). Therefore, I needed to determine the sector boundaries at first. This can be done ahead of time when the map is loading, so that algorithm for detecting these boundaries can be somewhat complex as long as the description of the boundaries can be easily used afterwards. Detecting the outline is in general a simple algorithm – also known as left-hand rule [1]: If you are in a maze and you want to find all possible ways, you can simply stretch out your hand and keep it on the wall. That way, you are traversing the complete maze – at least if it is an ordinary maze. Though this excludes mazes where there is a center maze where the walls are not connected with the walls on the entry of the maze, but for my problem, this doesn’t matter.

Actually, I tried at first a much simpler approach even, but that would have worked only for convex sector shapes, and we have a couple of concave sectors (If you don’t know the meaning of concave and convex, you might look it up here[2]).

I find graphics programming often very nice because even the bugs can look pretty:

Wrongly implemented left hand rule

So what went wrong here was that my “left hand” left the “wall”. Quite wrong. After a while the result looked like this:

The correctly found sector outlines

Which is looking more correct. It also looks funny because I also used a small trick to detect problems in my border tracing: During the implementation it happened, that my algorithm did not notice that it traced a part that it had visited before, so my border description contained redundant information.

To see these multiple lines, I drew the outlines with random vector offsets at each point. This gave the output such a scribbled look. You can also see that way, that I already stripped the points away between the corners – if a line stretches over a couple of cells, the initial algorithm would record points at each corner of the rectangle. These points are not required to draw the sector, so I tweaked the algorithm to reduce the amount of drawn vertexes:

Removing the unneeded points when drawing a straight line saves time during drawing.

If the algorithm had still these unneeded points, it would have become visible when drawing the outlines with random vector offsets.

The performance win of this improved technique was not crucial but in deed measurable. There are other parts that could be optimized, but as this improved already one of the worst algorithms, this can now wait a bit.

[1]: Maze solving algorithm: http://en.wikipedia.org/wiki/Maze_solving_algorithm

[2]: Convex Hull: http://en.wikipedia.org/wiki/Convex_hull

1.20 has been released on the German world 1 – quite successfully I would say as there haven’t been so much problems, although quite a few bugs of different severity haven’t been found during the beta testing and we had / have to fix a lot of bugs.

I have to say that I’ve been a bit disappointed by the beta testers regarding cheating: I would expect beta players to try to cheat in the game wherever possible. For example: It’s been possible for attackers to set the starting position on the flag points just by modifying the requests that are sent to the server. I only got aware of that when some players were affected by another bug that occurred when they tried to join more than one fort fight. That happened only after the 1.20 release on world 1.

That’s been a quite bad bug that shouldn’t have been released, yet it got through. Over the months of development I just always “moved” the responsibility of checking illegal positions to other code parts that I had not been working on at that moment – i.e. when getting the values from the players and I wrote it into the database, I expected to filter illegal positions on the fortbattle server. When I implemented the fort battle server, I expected that the values in the database would be correct. Due to the different times when I wrote these parts, I never implemented that checking anywhere. Nice, isn’t it? Yet, such glitches are normally found by evil cheaters quite quickly and they can be used to their advantage. Just imagine a group of attackers spawning on the flag just when the battle starts. Wouldn’t be so nice for the defenders…

So I would like to remind our beta testers: Try to break our rules on purpose! Don’t avoid unfair play but enforce it! You won’t get banned for that (unlike as on the public game worlds). Some of you did already do some testing like that, but we need more of that (like making fort member towns ghost towns (sorry for not having fixed that issue yet on the beta server, but we are not community managers and we had quite busy weeks…)).

Anyway, I wanted to write here now about what all went wrong during the release and how it happened.

Thursday, 7:45 am

I turned up at work at that time because it was the plan to make the release in the morning time so that the first forts would be finished around 4 pm / 5 pm. We thus expected that then the first battles would happen at Friday around 4 pm / 5 pm. I started working on several minor bugs, like fixing a glitch in the fort management and a problem with that particular piece of javascript when executed with Internet Explorer browsers.

9:30 am

About at 9:30 am Anthraxx pushed the button to make the release. About 9:31 am Eiswiesel ran into our office and yelled “Build time for Forts is 30 seconds”. That’s how it’s been on the beta worlds. Uops. We immediately fixed that wrong value, but when we did that, 3 forts had already been built by players. 8 other followed because we forgot to change the values in the task queues that had already been inserted into the database. These players had of course a minor advantage over other players since they were the first to have forts. Some players asked to undo that unfair development but that is not a simple request. We just decided that these lucky ones were just lucky winners in the fort build lottery. Their prize was the immediate attack of other players.

And that was how it came that the first fort battle was to be fought at 9:37 am on Friday instead of 4pm as we planned to. But that was not really to our disadvantage however.

10 am

A few minutes later the first bugs reports dropped in. It was my change at that morning that on the one hand stabilized the IE browser but also introduced a bug that made it impossible to invite other towns. But other bugs got visible too – IE 6 users were unable to build forts because the name field of the founded fort did not turn up on their screens. A little bit later other players reported that a county had 4 forts while the one below had 3. Oups. Another oups when players found a cozy little location of another fort:

Quite a nice location I’d say, but also quite wrong.  Later it also turned out that the county with 4 forts had not 4 but 3 forts and there was one fort missing on the map that is shown in the minimap. The other county with 2 forts in the minimap had however 3 forts and the 3rd one doesn’t show up in the minimap.

We still have no clue what to do with Fort Los Angelus, neither do we know what is causing the minimap to behave that strange.

Thursday afternoon

Ok, so the first battle was to be fought on Friday morning. I checked if the policy port (1028) was reachable and after a few tweaks it worked. I should have checked the other port as well then (1578? Too lazy to look it up now), but I didn’t. Instead I spent some time on implementing battle logs so that we can later replay the battles. Don’t ask for a playback function, I still don’t know if the recorded actions are complete since I lack a playback function myself. I did also fix some other errors, just like my 3 colleagues in the office.

Around the late afternoon a bug turned up that always existed but never became visible: Due to the fort battles, for the first time in west it made sense for players to gather at a single location. When about 150 players had been luring at the first fort that was declared war on, the player list functionality broke due to too many players at one spot. That was also eventually fixed at afternoon.

When I left the office I had an intensive 11 hour day behind me and I had a bad feeling about the 200 players who were about to fight the first fort battle on a public server. Due to the mishap in the morning time, I had to turn up around 8 am on Friday as well (I normally come in around 10 am).

Friday, 9 am

I still had not checked the second port when the first battle was about to be fought. I just expected that if the policy port was running that the other port would be forwarded as well. Well, checking the port was not that simple because I had no application to test that in a valid way anyway. Had no time to write such a tool.

And this is what went wrong when the battle started at 9:37:

We instantly noticed that we couldn’t connect with flash to the game. That was bad. Looking into the server logs we saw that the server was bombarded with policy file requests that got answered promptly. But no connect request came through. After a couple of WTFs all over the place, hastily hacking on console windows and checking connectivity we realized that of the 3 ports that the server opened, 2 were forwarded correctly and that was the policy port – and the maintenance port that shouldn’t be available to the Internet at all. The game port that is used for the flash communication was simply not addressed by anyone.

After we figured that out we were able to fix it in time and about 10 minutes later the connection worked to my great relief. We could view the battle taking place and the final report to be sent to the spectators.

Later on Friday we noticed that players reported that they were playing on the wrong locations when they joined multiple battles. Also we noticed that the final report was not successfully sent to the users (but that was not noticed by the players due to the lack of information that there should be a report shown). Turned out that the reports became larger than 65kb which was the upper limit for reports at that point. I fixed that bug along with the bug of illegal player positions.

Over the day several battles were fought and the battle server stabilized. We made a few minor changes then – and now I am curious how stable the java server is going to be over the weekend. That is quite a stress test that is currently running. But I am quite optimistic that since the server has survived now for quite some time that it will run stable for some time. Yet I am not sure if we fixed all memory leak issues and so I don’t know if the server is not going down within the next 48 hours. I can’t predict anything there yet, but we’ll see.

I hope that the next week is going to be a bit more calm so that we can fix a couple of other problems and do a bit planning for upcoming features. I would expect that after this huge version release that 1.21 is not going to introduce such large features but will only provide minor features that we couldn’t get into 1.20 yet – but we’ll have to see what we will work on for that release.

We will also see next week when we are going to unroll 1.20 on other worlds and also other languages. This could take the whole week maybe, but I am not sure on that. I hope that the players of other worlds are patient – it shouldn’t take so long anymore.

PS: I am getting constantly requests to increase the number of beta players on the beta world. I am aware that a lot of players want to get into the public beta but you have to understand that I can neither change the player limit nor can I make the decision myself. It has however been decided that the player limit is going to be raised in the future. I can’t really tell you more on that because I simply don’t know more about it myself.

So, today we made the decision that 1.20 is to be released on the German world 1 during the morning time of Thursday. Other worlds will follow if it turns out to be running stable. Of course, since we have the beta world we are a bit more confident among the devs, but to be honest: There are a lot of places where we fear that something could go wrong.

As for my part I would expect that the fort battle server is going to have troubles in the first fight. When the first battle is being fought, there’ll be a lot of players involved and also a lot of spectators will try to watch it. However there’s a limit of how many players are going to be able to watch it. We’ve spent quite some time to prevent that an overflow of incoming connections are going to shut down the server. Instead it should simply denying new connections if there are too many connections open. We have a limit of 64 spectators for one battle and a limit of 512 connections in total. So in theory two battles could be fought at the same time or 4-5 when only fewer people are involved.

During the week I did also not only work on the server but also a bit on the client here and there. I added some artworks from our artists and also added the feature to the client that you can see who is actively playing in the game and who is not connected. There are also now popup information on the map so that it is easier to identify players on the map. Next to that we fixed bugs bugs and more bugs. Have I mentioned fixing bugs?

I am really curious how the release is going tomorrow, especially when the first fort battle is starting.

Hi,

I am Eike Decker, also as known as Zet. I am working at InnoGames as a developer since January and I have been assigned to The West at the end of february. The first project that I’ve been working on for The West was the tutorial mode for the game which was introduced in 1.19. Since then I’ve been working on the fort battles non-stop. I wrote the flash client as well as the HTML frontend for the battles and also the parts on the game server that are related to the game play. If something doesn’t work as expect in these departments I am probably the person to blame. For anything else I am less likely to know what’s going on – I have only a limited overview on other features than the fortbattles. Simply because I have not done much else apart from that.

But as far as I can tell, the fort battles are a big deal different from any other part of The West. The most significant difference is probably the quite intensive interaction between a lot of players during the battles which normally last between 5 and 10 minutes. We’ve had battles with up to 50 players running and so far I am quite content with the results.

Attackers are swarming the defenders on the beta server

Since the introduction of the fort battles on the public beta server I became more curious about user opinions (especially on the fort battles) and started reading a few threads about the beta and the fortbattles during the breaks on the public forums. Because I have never played The West before starting working on the forts, I have a lot of things to learn about the game and the players. While reading about opinions about the public beta I realized how much the new features are awaited but also that quite a few are upset because of the delay and the limited amount of players on the public beta.

I can understand the disappointment among the players about the delay and other problems. And although I am not to blame for all of them I want to express that I appologize for this and that I want to explain this or that with this first blog entry.

The development of the fort battles

As mentioned above, the fort battles are a complete new feature that was developed practically from scratch While it was fairly simple to develop a prototype server and client, it turned out more to be a problem to integrate the game tightly into the game itself which was quite surprising for me. It was extremely difficult to estimate the development time of that feature beacuse of this.

The development can be roughly divided into four components which partially reflects the gameplay:

• The HTML frontend that is used for joining the fort battles
• The Flash frontend that is used while the battle is running
• A Java server that communicates with the Flash frontend
• and a PHP backend that integrates the fort battles into The West.

The HTML frontend

The HTML frontend should allow players to set their starting position and targets that are used during the fort battles. It does not use Flash since we wanted to allow players to take part in the fort battles even if they can not use flash. The frontend should provide all important information about the battlefield and the positions. Characters that are not controlled by connected players will move to their chosen destiny on their own. They are – no question – much less flexible as the characters that are actively played, however they can still provide the tip on the scales that changes the battle outcome.

The Flash frontend

We decided that flash should be used for the battle itself. It should establish a connection with the server and gather / receive information on demand. This was the key reason why we chose flash next to the additional graphic effects that Flash provides. We accepted the fact that a minority of players are going to be unable to play the game that way (for example if they don’t have Flash or if they are behind a firewall that they cannot influence) in favor of these technical advantages. We will try to bypass these problems in the future and I have already ideas how to work that out. But for the moment, the connection itself seems to be stable enough for the release.

The Java server

For a couple of reasons we decided to develop a Java server which would be used only for the fort battles and nothing else. The reason for this was that Java is more efficient than PHP and that a crash of the Fortbattle server should not influence the game itself. The server simulates the game and communicates with the flash clients. Because it is less of a problem to manage different threads in Java and also having more control on the memory, it also doesn’t cost too much performance. We have no facts so far, but we expect that this solution will work much better while using less resources than using PHP.

In theory, if the Java server would crash, the battle would restart at round 1. Of course this would also upset the players that are involved, but that seemed to be the most acceptable consequence compared with other outcomes of other technologies. We hope that this won’t happen and we also planned to restore partial gameplays once the basic features are working.

The PHP backend

Most of the database related processing is done in the PHP backend. It informs the Java server about new battles and once a battle is finished, a PHP process receives all results and takes all kind of actions on players and forts.

Features vs. Time, Time vs. Bugs

There are tons of features that did not get into the fort battles. There are plenty of ideas that we have for future releases and we tried during the design of the system to provide enough room to make these changes when we have the time to do them. We are only working right now on features that are eminent for the gameplay or that are mostly done. Right now we are denting out bugs that we oversaw so far.

At this point I also want to thank all beta testers who help us to find bugs and testing the game. Some hints had been really a great help to prevent that the release would fail. Of course there are no guarantees for the planned release, but I feel much more confident because of our beta testers.

Future blogging

For the future, I am planning to blog constantly on development about The West. If this is not possible because new features are not yet to be mentioned yet, I’ll just come up with rants on technical details about what I already did at InnoGames.