The West Dev-Blog

1.23 is going to introduce custom fort battle maps – as stated earlier. This post is going to explain this a bit more detailed what is going to be changed about the fortbattle maps.

Every fort is pretty individual because of its size and building levels. Well, of course unless the levels are maxed out, but that goes without saying. But the building levels are also not fixed for the forts – once we have custom maps, we’ll introduce destructable building structures in a following release, but that is not the topic for now. What matters is, that we have all these forts with different building levels and the battle map should reflect this fact.

So what’s going to be changed to make this happen?

• Every building is present on the map, and the better the level is, the more advantages will be given to the sectors that belong to the building.
• Character class sector bonus: Every tower will belong to a certain character class. Characters with the right character class that are located at such a building are going to have an additional bonus next to the sector bonus that the building structure is already providing.
  
• The player limits are going to be lowered for the small and medium sized forts. There’s still a discussion going on about what the right values should be, but the initial version is most likely to set the limit to 30 players per side for the small and 60 players per side for the medium sized forts. Please note that there are unavoidable technical limitations that are limiting the number of players above the limit of 128 players, so please don’t even try to suggest to raise the limits instead of lowering them. Also, statistics of the battles show that most battles are played with about 60-70 players in average. So the limitation is mostly only hitting the small forts. The intention is to strengthen smaller alliances in the game, as the maximum limit does not involve so many players any more. Large battles can of course still happen at large forts, so the impact should be acceptable for the game.
  

And this is how it could look like (the map is done by me for testing purpose, please don’t start arguing about the bad sector layout):

This is the map in a basic configuration

This map is the same as before, except that three towers are now enlarged.

This introduces of course quite lot’s of changes to the tactics of the game play: The forts are most likely going to be not completely symmetric, then the topology might give an advantage to certain movements on the map. The smaller fort battles are going to be more tactical because of the lower player limits. All in all, battles are going to be, like the forts themselves, more individual and more unique. The motivation is, that we hope to see more battles in effect of these changes.

I stated sometimes that the there are logs of all battles that have been fought and that the players could analyse them themselves if they know how to use javascript.

So what this blogpost is about is: Explaining the battle logs so that you can (maybe) build your own statistics tool. If you are not a programming nerd, you probably can skip this post as boring and useless for your gameplay, but if you are one, you’ll most likely find this interesting unless you haven’t figured this stuff already out yourself. So here we go.

The data format

If a battle is opened on the cemetary (you know, on the forts), all the required data is transferred. It contains really everything. For example, this is a battle of only 2 players being involved:

{
	"attackerlist":[
		{"westid":60,"name":"foo124663470921","flagholdcount":1,"hitcount":2,
		"totalcauseddamage":131,"takendamage":260,"takenhits":4,"killedby":1,
		"finishedhp":0,"starthp":260,"maxhp":260,"townid":3,"townname":"cccc",
		"weaponid":100,"weaponname":"Stein","weaponmindmg":50,"weaponmaxdmg":110,
		"posidx":356,"diedwhen":0,"targetidx":356}
		],
	"defenderlist":[
		{"westid":1,"name":"testxx","flagholdcount":0,"hitcount":4,
		"totalcauseddamage":260,"takendamage":131,"takenhits":2,"killedby":-1,
		"finishedhp":1389,"starthp":1520,"maxhp":1520,"townid":5,
		"townname":"attackers of doommmm","weaponid":100,"weaponname":"Stein",
		"weaponmindmg":50,"weaponmaxdmg":110,"posidx":396,"diedwhen":8,"targetidx":396}
	],
	"log":[0,2, 1,1, 2,396, 3,1520, 4,1, 1,60, 2,356, 3,260, 4,0, 8,594, 0,3, 1,1, 2,396, 3,1520,
		4,1, 5,60, 7,62, 1,60, 2,356, 3,198, 4,0, 5,1, 7,67, 8,560, 0,4, 1,1, 2,396, 3,1453, 4,1,
		5,60, 7,62, 1,60, 2,356, 3,136, 4,0, 5,1, 8,492, 0,5, 1,1, 2,396, 3,1453, 4,1, 5,60, 1,60,
		2,356, 3,136, 4,0, 5,1, 8,424, 0,6, 1,1, 2,396, 3,1453, 4,1, 5,60, 1,60, 2,356, 3,136, 4,0,
		5,1, 7,64, 8,390, 0,7, 1,1, 2,396, 3,1389, 4,1, 5,60, 7,85, 1,60, 2,356, 3,51, 4,0, 5,1,
		8,356, 0,8, 1,1, 2,396, 3,1389, 4,1, 5,60, 6,51],
	"map":{
		"tiles":[[3,5,2,1,11,9],[8,4,1,2,18,7],[6,6,3,1,11,15],[0,11,3,4,11,11],[3,11,3,4,21,6],
			[6,11,3,4,21,11],[20,0,4,3,10,6],[128,0,2,2,16,9],[0,0,4,4,6,2],[8,0,5,4,24,2],[8,6,5,5,24,14],
			[0,6,4,5,6,14],[1,4,2,2,7,6],[1,4,2,2,7,8],[1,4,2,2,7,10],[1,4,2,2,7,12],[1,4,2,2,26,6],
			[1,4,2,2,26,8],[1,4,2,2,26,10],[1,4,2,2,26,12],[4,1,4,2,10,3],[4,1,4,2,14,3],[4,1,4,2,18,3],
			[4,1,2,2,22,3],[4,1,4,2,10,16],[4,1,2,2,14,16],[4,1,2,2,18,16],[4,1,4,2,20,16],[5,8,2,2,16,16]],
		"cells":[0,0,0,0,1,1,1,1,1,1,1,1,1,2,2,2,2,2,2,2,2,3,3,3,3,3,3,3,3,3,4,4,4,4,0,0,0,0,1,1,1,1,1,1,1,
			1,1,2,2,2,2,2,2,2,2,3,3,3,3,3,3,3,3,3,4,4,4,4,0,0,0,0,1,1,5,5,5,1,1,1,1,2,2,2,2,2,2,2,2,3,3,3,3,
			6,6,6,3,3,4,4,4,4,0,0,0,0,1,1,5,5,5,7,7,7,7,7,8,8,8,8,8,8,9,9,9,9,9,6,6,6,3,3,4,4,4,4,0,0,0,0,1,
			1,5,5,5,10,10,11,11,11,11,12,12,12,12,13,13,13,13,14,14,6,6,6,3,3,4,4,4,4,0,0,0,0,15,15,15,16,10,
			10,10,11,11,11,11,12,12,12,12,13,13,13,13,14,14,14,17,18,18,18,4,4,4,4,0,0,0,0,15,15,15,16,10,10,
			19,19,19,11,11,20,20,20,20,13,13,21,21,14,14,14,17,18,18,18,4,4,4,4,0,0,0,0,15,15,15,16,22,22,19,
			19,19,23,23,20,20,20,20,24,24,21,21,25,25,25,17,18,18,18,4,4,4,4,26,26,26,26,15,15,15,16,22,22,22,
			27,27,23,23,28,28,29,29,24,24,21,21,25,25,25,17,18,18,18,30,30,30,30,26,26,26,26,15,15,15,16,22,
			22,22,27,27,23,23,28,31,31,29,24,24,32,32,25,25,25,17,18,18,18,30,30,30,30,26,26,26,26,33,33,33,
			34,35,35,35,27,27,36,36,37,31,31,38,39,39,32,32,40,40,40,41,42,42,42,30,30,30,30,26,26,26,26,33,
			33,33,34,35,35,35,43,43,36,36,37,37,38,38,39,39,44,44,40,40,40,41,42,42,42,30,30,30,30,26,26,26,
			26,33,33,33,34,35,35,35,43,43,36,36,45,45,45,45,39,39,44,44,40,40,40,41,42,42,42,30,30,30,30,26,
			26,26,26,33,33,33,34,46,46,46,43,43,47,47,45,45,45,45,48,48,44,44,49,49,49,41,42,42,42,30,30,30,
			30,26,26,26,26,33,33,33,34,46,46,46,47,47,47,47,50,50,50,50,48,48,48,48,49,49,49,41,42,42,42,30,
			30,30,30,26,26,26,26,51,51,52,52,52,46,46,47,47,47,47,50,50,50,50,48,48,48,48,49,49,53,53,53,54,
			54,30,30,30,30,26,26,26,26,51,51,52,52,52,55,55,55,55,55,55,55,56,56,57,57,57,57,57,57,57,53,53,
			53,54,54,30,30,30,30,58,58,58,58,51,51,52,52,52,51,51,59,59,59,59,59,59,60,60,60,60,60,60,54,54,
			53,53,53,54,54,61,61,61,61,58,58,58,58,51,51,51,51,51,51,51,59,59,59,59,59,59,60,60,60,60,60,60,
			54,54,54,54,54,54,54,61,61,61,61,58,58,58,58,51,51,51,51,51,51,51,59,59,59,59,59,59,60,60,60,60,
			60,60,54,54,54,54,54,54,54,61,61,61,61,58,58,58,58,62,62,62,62,62,62,62,62,62,63,63,63,63,63,63,
			63,63,64,64,64,64,64,64,64,64,64,61,61,61,61,58,58,58,58,62,62,62,62,62,62,62,62,62,63,63,63,63,
			63,63,63,63,64,64,64,64,64,64,64,64,64,61,61,61,61,58,58,58,58,62,62,62,62,62,62,62,62,62,63,63,
			63,63,63,63,63,63,64,64,64,64,64,64,64,64,64,61,61,61,61,58,58,58,58,62,62,62,62,62,62,62,62,62,
			63,63,63,63,63,63,63,63,64,64,64,64,64,64,64,64,64,61,61,61,61],
		"height":24,
		"sectors":[{"height":0,"attackerSpawn":true},
			{"height":0},{"height":0},{"height":0},{"height":0,"attackerSpawn":true},
			{"height":6,"attackerBonus":6,"defenderSpawn":true,"defenderBonus":7},
			{"height":6,"attackerBonus":6,"defenderSpawn":true,"defenderBonus":7},
			{"height":4,"attackerBonus":3,"defenderSpawn":true,"defenderBonus":4},
			{"height":4,"defenderSpawn":true},{"height":4,"attackerBonus":3,"defenderSpawn":true,"defenderBonus":4},
			{"height":0,"defenderSpawn":true},{"height":0,"defenderSpawn":true},{"height":0,"defenderSpawn":true},
			{"height":0,"defenderSpawn":true},{"height":0,"defenderSpawn":true},{"height":0},
			{"height":4,"attackerBonus":3,"defenderSpawn":true,"defenderBonus":4},
			{"height":4,"attackerBonus":3,"defenderSpawn":true,"defenderBonus":4},
			{"height":0},{"height":3,"attackerBonus":1.25,"defenderSpawn":true,"defenderBonus":1.25},
			{"height":0,"defenderSpawn":true},{"height":3,"attackerBonus":1.25,"defenderSpawn":true,"defenderBonus":1.25},
			{"height":0,"defenderSpawn":true},{"height":0,"defenderSpawn":true},{"height":0,"defenderSpawn":true},
			{"height":0,"defenderSpawn":true},{"height":0,"attackerSpawn":true},{"height":0,"defenderSpawn":true},
			{"height":0,"attackerBonus":-5,"defenderSpawn":true,"defenderBonus":-5},
			{"height":0,"attackerBonus":-5,"defenderSpawn":true,"defenderBonus":-5},
			{"height":0,"attackerSpawn":true},{"flag":true,"height":0,"attackerBonus":-10,"defenderSpawn":true,"defenderBonus":-10},
			{"height":0,"defenderSpawn":true},{"height":0},{"height":4,"defenderSpawn":true},{"height":0,"defenderSpawn":true},
			{"height":0,"defenderSpawn":true},{"height":0,"attackerBonus":-5,"defenderSpawn":true,"defenderBonus":-5},
			{"height":0,"attackerBonus":-5,"defenderSpawn":true,"defenderBonus":-5},{"height":0,"defenderSpawn":true},
			{"height":0,"defenderSpawn":true},{"height":4,"defenderSpawn":true},{"height":0},
			{"height":3,"attackerBonus":1.25,"defenderSpawn":true,"defenderBonus":1.25},
			{"height":3,"attackerBonus":1.25,"defenderSpawn":true,"defenderBonus":1.25},
			{"height":0,"defenderSpawn":true},{"height":0,"defenderSpawn":true},
			{"height":0,"defenderSpawn":true},{"height":0,"defenderSpawn":true},
			{"height":0,"defenderSpawn":true},{"height":0,"defenderSpawn":true},
			{"height":0},{"height":6,"attackerBonus":6,"defenderSpawn":true,"defenderBonus":7},
			{"height":6,"attackerBonus":6,"defenderSpawn":true,"defenderBonus":7},{"height":0},
			{"height":4,"attackerBonus":3,"defenderSpawn":true,"defenderBonus":4},
			{"height":0,"attackerBonus":3,"defenderSpawn":true,"defenderBonus":4},
			{"height":4,"attackerBonus":3,"defenderSpawn":true,"defenderBonus":4},
			{"height":0,"attackerSpawn":true},{"height":0},{"height":0},{"height":0,"attackerSpawn":true},
			{"height":0,"attackerSpawn":true},{"height":0,"attackerSpawn":true},{"height":0,"attackerSpawn":true}],
		"mapname":"Test",
		"width":34},
	"logtypes":["ROUNDSTART","CHARTURN","CHARTARGET","CHARHEALTH","CHARONLINE","SHOOTAT","KILLED","HIT","MOVED"],
	"roundsplayed":8,"maxrounds":50,"battleid":81,"outcome":"ATTACKER_WIPED","fortname":"abcfort",
	"declarerid":6,"declarername":"foo12464580102","attackertownid":3,"defendertownid":5,"defendertownname":"attackers of doommmm",
	"attackertownname":"cccc"}

That’s quite a chunk, so let’s rip it apart and look at it one by one.

Attacker- and Defenderlist

Both arrays contain identical descriptions of all the involved players. Each player has following descriptions:

• westid: the id of the player in this world. Identical to the id used in ranking etc.
• name: the name of the player
• flagholdcount: number of rounds that the player was holding the flag
• hitcount: number of hits the player made
• totalcauseddamage: the total amount of damage caused by this player
• takendamage: how much damage the player got
• takenhits: how often the player was hit
• killedby: a player id (westid) of the player who knocked the player out
• finishedhp: how much hitpoints that have been left at the end of the battle
• starthp: hitpoints on start of the battle
• maxhp: the maximum amount of hitpoints the player may have
• townid: the id of the town the player belonged to
• townname: the name of that town at the moment when the battle started
• weaponid: the id of the used weapon
• weaponmaxdmg: the maximum damage the weapon can cause
• weaponmindmg: the minimum damage that the weapon is causing
• posidx: The starting position of the player
• diedwhen: The round the player was knocked out (bugged, fixed with 1.23)
• targetidx: The target of the player when the game started

A lot of data is already supplied in these arrays, but there’s far more.

The log

Each battleresult contains a complete log of the whole battle. This is most likely the most interesting thing for you, as this contains a lot of data (as a side note, this data might be bugged as it has never been used yet anywhere). A part of the log looks like this:

"log":[0,2, 1,1, 2,396,(...)

I inserted whitespaces at each second comma, because each pair of numbers describes what happened. The first number tells us what operation this was, the second number describes the operation. The mere numbers are useless unless we know the codes for the numbers. The codes are supplied with the log. The values are represented in an array called "logtypes":

"logtypes":["ROUNDSTART","CHARTURN","CHARTARGET","CHARHEALTH","CHARONLINE","SHOOTAT","KILLED","HIT","MOVED"]

The array tells us that 0 means “ROUNDSTART”, 1 means “CHARTURN” and so on. The order can change anytime when we change some implementations on our sides, so in case of developing a tool in javascript, I would suggest to figure out the right numbers before analyzing the log.
This codebook tells us now following information:
“logtypes”:

"log":[ROUNDSTART,2, CHARTURN,1, CHARTARGET,396, CHARHEALTH,1520, CHARONLINE,1,
CHARTURN,60, CHARTARGET,356, CHARHEALTH,260, CHARONLINE,0, MOVED,594,
ROUNDSTART,3, ...

So this is more meaningful now and with a bit of description, this is the log, encoded in these number pairs:

1. ROUNDSTART,2: The game begins with round 2 (1 is the first round where everyone is choosing their starting position and target position.
2. CHARTURN,1: The character with west id 1 is now active
3. CHARTARGET,396: The character 1 is trying to go to the cell 396 (which is his starting position, so we’re there already)
4. CHARHEALTH,1520: The character 1 has a health of 1520 hitpoints
5. CHARONLINE,1: The player for character 1 was online during this round
6. CHARTURN,60: It is now the turn of player with id 60
7. CHARTARGET,356: The character 60 wants to go to cell 356
8. CHARHEALTH,260: The character 60 has 260 hitpoints
9. CHARONLINE,0: The player of character 60 was not online
10. MOVED,594: Character 60 moves to cell 594
11. ROUNDSTART,3: Round 2 has ended, round 3 begins

This pattern repeats all over the place and we can reconstruct the whole battle for each player. We do even know who was online and who was not online! The keys “SHOOTAT”,”KILLED” and “HIT” describe further actions:

• SHOOTAT: the id of the player that this character is shooting at
• KILLED: if the shot was knocking the player out, this key is used. The value represents the damage that was caused the player to be knocked out. Can be larger than the player’s hitpoints
• HIT: if the shot was a hit, the damage is described with the value

If no hit was made, the SHOOTAT value exists but without a following HIT / KILLED actions.

The map description

The map description is also supplied here. It could be used for replaying the whole map visually. The first thing to know is how a x,y coordinate is represented in the map – since we know the width and height of the map, we can recalculate a pair of numbers to a single number and back with this small function:

// javascript code
function toxy(idx,mapwidth) {
	return {x:idx%mapwidth,y:Math.floor(idx/mapwidth)};
}
function toidx(x,y,mapwidth) {
	return x+y*mapwidth;
}

Both functions can be used to do the required calculations. The width and height of the map is supplied by the map description as well with the keys “width” and “height”.
Furthermore, we have various arrays now: “tiles”, “cells” and “sectors”. The “mapname” parameter is currently not really used, it still has the name “test” on the productive worlds, something that I didn’t know about yet – as it’s nowhere used right now.

The tiles

The tiles are simple arrays of arrays containing each 6 numbers, describing the visual layout with out tileobject:

1. The x coordinate on the tile texture
2. The y coordinate on the tile texture
3. The x size of the tile
4. The y size of the tile
5. The x coordinate on the map where the tile is being drawn (left side of the tile)
6. The y coordinate on the map where the tile is being drawn (top side of the tile)
   • height: The height of this sector
   • attackerbonus / defenderbonus: What bonus the sector provides
   • defenderspawn / attackerspawn: A boolean value that tells us if players can spawn here
   • flag: True if this is a flag sector

This information allows us to draw the hole map using the tile texture. It contains only eyecandy information – nothing else.

The sectors

That array describes the attributes of each sector that is present on the map. Following attributes are available:

There will be further values if there’s a bonus for a certain playerclass, but I think that the whole sector description is pretty self explanatory.

The cells

The most important description for the game is the layout of the sectors. The sectors can have any kind of form, so what we do is, we define for each cell on the map what sector it belongs – it refers here to an index in the sector array. The array called “cells” describes now for each cell, starting from top left the sector for each cell, left to right, top to bottom (just like reading letters in a book). For example:

"cells":[0,0,0,0,1,1,1,1,1,1,1,1,1,2 ...

What we see here is, that the cell located at x=0 and y=0 is described with the attributes given by the sector description at index 0 of the sector array. The same attributes are used for x=1,y=0 and x=2,y=0 and x=3,y=0. The next sector starts at x=4,y=0. Every cell that refers to the same sector id belongs to the same sector (of course…). From the game logic we know that if a sector is taken by a team, the other team can’t enter that sector. So in theory, there could be sectors that are disjunct – which means that a sector could be split. However, this should not be the case.

That’s it!

So that’s everything that is needed to know if you really want to analyze the logs of a battle yourself. How can you get now the data? Well, there are several ways – for example taking the text from the ajax call using firebug. Or by overwriting the FortBattle.makeStats function:

javascript:(function() {
  var orig = FortBattle.makeStats;
  FortBattle.makeStats = function (data,element,fortx,forty,bool) {
    alert(Json.toString(data));
    return orig(data,element,fortx,forty,bool);
  }
})(); void(0);

If you execute this code in your browser’s address bar, you’ll get an alert message the next time when you look at a fort battle result. Copy & paste the result and you’ll have the data anywhere you want it to have.

So, I am back from Vacation – I’ve been to Japan and enjoyed it very much over there. Anyway, now I am back and getting into work again.

First: The chat is being delayed. The reason for this are technical reasons on the serverside. It’s unlikely that it becomes a feature of 1.23.

So what’s on the agenda for 1.23 then?

• Stabilization: Certain features need smaller or larger improvements that are going to be done in 1.23.
• Small user interface & graphical improvements: A larger map, a bit more comfort in the game internal forums a new ranking
• Custom fort battle maps
• New rewards

The custom fort battle maps are the most complex feature here. For the resizable map, it’s a bit easier but should help players to get a more comfortable overview on the game map, as it can be seen in this screenshot:

A map that fits into the browser’s screen

For the custom battle maps, it’s far more complex. First we have 3 different fort sizes, then we have a vast amount of different building level configurations. In order to provide as much diversity as possible, each building will be represented in the battle map dependent on its level when the battle starts (don’t ask me what happens if to positioned players in case of a tower level up – I don’t know yet). But in order to achieve this, we must create a description of all this somehow and this can not be done using a mere text editor – we need a tool for this. And I have started working on just that. In theory, once we have the tool ready and created all the data that is required for creating custom battle maps for each fight, the deployment is of important question – how will it be deployed to players and representation. Of course, most of this has already been foreseen and most stuff should work right away from the start, but of course, all that and the testing will require quite some time. But we’ll see how it goes on and how long it’ll take.

1.22 is also getting a new minor feature in the battle preview (but alas not to the flashclient): it will show the actual bonus of a sector. It will show the attack, defense and height of a sector. And before someone starts screaming “These values are different from the help manual !!!1111″. Yes. They are – because we are changing them. The walls and towers will get a boost, so the influence to the battle should be more significant.

And by the way: from Thursday on I am going to be on Vacation for three weeks. As you might know, I am currently working on the chat feature for the west – or more precisely, I am working much more on the userinterface for it than on the technical details that is running serverwise (so this time I am less likely to be blamed for technical problems that might arise during the introduction phase of the chat).
Anyway: I am soon on vacation and I won’t be able to be present when the chat is being introduced. Unless it gets delayed because of technical problems of course. I already wrote the deactivation code so that the game can be released without the chat in case of troubling server software – don’t be disappointed if 1.22 is released with deactivated chat, I still regard the awards as the more important feature. Also a lot of features are still missing in the chat that you are certainly going to complain about… but the most important things are working by now: Townchat and fortbattle chat (for defenders / attackers).
Some people have asked why we did the chat now – the answer is a bit difficult. More or less, it’s because of the fort battles. Communication is an important factor in battles and so, the chat is an important strategical component, even if it does not affect the battle mechanics themselves directly at all. We were uncertain about the order of implementation – should we do the custom battle maps first, the fort shop, character bonus depending on the class of the character and so on. There are still a lot of features missing and we intend to integrate them one by one. So more or less, the battlegrounds are still being actively developed and thus changed. There are so many countless ideas around of what we can do with the battle system… but there’s simply a limit of how much we can do at a time.

So keep playing, I’ll look foraward to integrate the rest of all the still missing features after my vacation!

Long time no blog
Still not much to tell
I have an idea:
I leak a screenshot!

Do I have to mention that I am still working on that?

I’ve seen quite a few requests for getting an image of the battlemap.  So here is it, free of any attackers. Feel free to use it for your battle planning.

However be warned: Sometime with the upcoming releases, we’ll introduce custom maps for each fort. Then the map will be layouted depending on the fort size and the building levels.

Since the introduction of fort battles, the players have developed a strategy to weaken the enemy by letting low level players join the opposite side. While this is a quite valid strategy, it is still nerving and not wanted. As a result we made a decision at the end of the development of 1.21 to pull a feature that we wanted to have in 1.22 into 1.21: The mustering page.
Since this feature got in so late it is not so well tested and the user interface is initially not so obvious. So let’s explain it here shortly:
When you are a member of a directly involved town (means the attacking town or one of the fort members) and you are a councilor or a founder of one of these towns, then you are allowed to muster the troops that are joining the battle. You will see the recruiting button once you are taking part in the battle (so you have to join). Then the screen shown above is opened and you can see everyone who has joined the battle already.
By clicking now in the status columns in the cells, you can give players a star or a red cross. The star means that this player has precedence to enter the battle. If the player has a red cross it means that the player will only allowed to join the battle if there is still space left in the battle. You can also remove a precedence by toggling the cell again.
Once you have changed the status, you will notice that it turns orange. This means that you have modified your list, but it is not yet sent out. To do that, you click on “muster” or, if you think you do not wish to change anything, on “cancel” so that nothing is changed at all.
You will also see who has changed the player’s precedence rating, so you might spot people who shouldn’t modify the status of a player (i.e. spies). It is of course possible that a member town has a spy that modifies the list to the attacker / defender’s favor right before the battle starts, but well, you should take care who you promote in your town or who you invite…

A minor addon to this feature did not made it into 1.21 yet – since such a spy could do such a change in the last moment before the battle starts, it would be quite hard to make out who changed the rating of the players. In order to keep this information, it’ll be sent to all players that are taking part in a battle. But this feature is not yet in 1.21.

We have updated today the beta and a few additional smaller feature leaped into 1.21.

First, there’s an overview on the rules for a fortbattle. That should clear any doubts on how the battle is being judged and when it’ll be a loss or a win. If we change anything in the future, i.e. the number of rounds that a battle takes, this will be automatically shown in this fact sheet.

Then there’s a still-to-be-improved feature that shows which towns are fighting on which side:

In this case, you can see which towns are defending the town already. That list includes the main defenders (fort owners) and also every town that has at least one member having joined the battle already. Picking the right side should now be simpler.

Last but not least, there’s a security feature that should greatly help you to identify attacks on your account:

By the time, most of all wanted features are now on the beta. 1.21 is running quite smoothly and we are looking forward to switch to 1.21 once we consider it stable.

A feature that still needs some tweaking is the XP gain for battle participation. But we should be able to fix this till the end of the week.

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.

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:

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

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:

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

Due to a recent ugly take over of a town on the beta, we devs have just been busy cleaning up the beta. Seems like a multi took a town and kicked out all other players. We won’t restore ownership of that town, but we got rid of a couple of players on beta now. Apparently we gathered quite a few multis / passwordsharers on the beta – turned out that noone was responsible for that job till now. We are going to take care about that so that our precious development time is not going to be spent on managing the beta world. Although it’s been a quite interesting break. And I guess that some players are now at least a bit satisfied (or not…).

Anyway, I had no experience with banning players, so I took a lesson on how to hunt multis today. Don’t say you haven’t been warned.

By the way, this is not what I was referring to when I was saying that I would appreciate more cheaters on the beta. Multi account, password sharing and stuff like that are still bannable offenses.

And meanwhile … – I haven’t been blogging so much recently because there was not so much to blog about, but I have  a couple of topics I am working on… for example the one on “how to cheat”. But that’ll need some time. But it’s on my list, really!