Archive for October, 2009

The battle logs

October 28th, 2009 16 comments

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:

		"townname":"attackers of doommmm","weaponid":100,"weaponname":"Stein",
	"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],
	"declarerid":6,"declarername":"foo12464580102","attackertownid":3,"defendertownid":5,"defendertownname":"attackers of doommmm",

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


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:


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) {
    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.

Categories: Uncategorized Tags:

Back from Japan!

October 16th, 2009 11 comments

japanSo, 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

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.

Categories: Uncategorized Tags:

First leaked picture from 1.23

October 8th, 2009 13 comments

Hey ho 😀

I currently don’t wanna talk too much about the 1.23 update so i currently just release some pictures showing some new interface designs (nope no new feature previews leaked yet)

new town profile with additional data

new town profile with additional data (click to raise)

new ranking interface (click to raise)

new ranking interface (click to raise)

Categories: Uncategorized Tags:

Premium for everyone

October 6th, 2009 4 comments

paI’ve take care of that the beta server has a fairer premium model that fits a beta testing server. it was admittedly too expensive for a pure testing and beta world. So I’ve now raised the gained nuggets by three, of course only for the public beta world, so please don’t cry 😀

Really sorry all other 🙂

Categories: Uncategorized Tags: