Saved game analysis: savegame file structure

I would like to develop a tool that reads the savegame and provided useful statistics about the different players.
Stats and comparisions between players for example for:
*Idle time vilagers as the game progresses and total
*Idle time military units as the game progresses and total
*Battle efficiency between micro managed and auto battles
*Resource usage efficiency: free resources while key upgrades not done
*Military units efficiency: how many unit(fractions) a unit kills in “his life”

  • etc. etc.


  1. Tool to improve game skills
  2. Used to create AI algorithm that can learn to play
  3. Real-time adviser that can be turned on/off while user plays the game (can use real tie stream of events read from the save game file if the user chooses to recored the game)

What I need:
Savegame file structure specification

So :slight_smile: how can I ask for help and are you interested?


You need to analyze recording (whole game) not savegame (single point in game).
Maybe this will help

Thanks - sure I intend to take a closer look to this one!
My bad - what I actually meant was record game (I never save game so far :)).
The solution pointed might be a good start but still there are tens of unknown events.

My hopes were more like to connect somehow with the development team and to receive a spec. related to the recorded games.
As the events in the sample app. are very few and not enough for analyses of this type.
I’m a software engineer myself, and I was looking for a way start the development with a spec in hand. :slight_smile:

Hi, I maintain the most complete DE recorded game parser. It is available here:

You maybe disappointed to find out that none of the information you want is present or derivable from the recorded game file alone.


Thanks a lot - I’m reading your docs now.

However as you guessed, I’m very confused for the magnitude of event that are missing.
Any guesses of HOW actually the recorded game can unfold if only the player actions are recorded?
Any idea for information like:
*For example when TRAIN action can we derive what type unit has been trained as a a building can create few types?
*Unit ID, Building ID, etc. are IDs of the types (like Man-At-Arms, Blacksmith, etc.) or unique IDs for he unit
*when a unit dies some info for which unit causes it’s death
*when resources being gathered

things like that.
Thank you

Hi, I’m happy to explain!

The recorded game file has two main components:

  1. The initial state
  2. A series of player actions

When you replay a game, the engine loads the initial state into memory. Then, as each action is applied, the state transforms based on the engine rules, just like it happened when the match was actually played.

Consider this example: I queue a villager in the TC. The TC building ID and unit type are indicated in the player action. The game engine now ticks forward and eventually a villager is produced (abiding by the engine rules). Now there is a new object in state, resources have dropped, etc. None of this is reflected in the recorded game file - it doesn’t need to be. Now I move that created villager. The “move” player action specifies the unit ID and a desired location. The villager may or may not actually get to the location I proposed. Maybe it gets killed, maybe there is impassable terrain. Only the engine state knows this information.

If you’ve ever seen any out-of-sync, this is because a player action was issued that was impossible to resolve given the current game state.

Read this article by Mark Terrano (creator of the game engine): It touches on how the shared simulation model works.

If you want the information you’re after, you have to interrogate the actual game state in memory.

1 Like

Red the article - now the approach becomes more clear.
Synchronous simulation - I got the intuition from the beginning now after the article it’s far more concrete.
Look what I found:

This looks very close to what I would need. I mean If I find a tool that can provide for example a CSV stream of the actions that will be very good source for my further statistics analysis engine (to be).

Yet in this link I see the DEATHs and for example info for what type of unit is created and what unit cased a DEATH on a what unit. I mean not only PLAYER (and AI) actions but also other actors.
Like what a unit can do to another unit.
Ex: DEATH of unit
S 3896 00:14:55.180 GAIA *** DEATH *** Archer|Skirmisher|Spearman (2375) belonging to Zuppi
Last action: R 1355 00:14:54.780 Zuppi Patrolled 5 Archer|Skirmisher|Spearmans to 1 waypoints
Killed by: R 1351 00:14:51.180 JorDan_23 Attacked a Archer|Spearman (2292) belonging to Zuppi with 1 ScoutCavalrys at (39.38245, 86.837234)

You can use BowSwung’s method to derive some events based on the data in actions, but it will be incomplete and require assumptions in some cases. The “Death” events you see there are generated by a combination of actions:

  1. Player moves sheep (establish ownership of sheep by a player)
  2. Player targets sheep with villager (makes assumption that villager killed sheep)

That sequence is not possible for military units of course.

But then I don’t see how it will be possible at all from these events he game to be reconstructed?
For example

  • Player A: group of military units just stay without a command
  • Player B: enemy units pass by as a result of rally point
  • Will player A units attack: this can be derived only by the game engine in this case

I mean as the event reader can’t effectively simulate the game engine than it will not know if the Player B units will pass close enough so they’ll be attacked.

Not to mention that there are some randomness in the events and some “game AI” initialed events (like attack when being attacked".

If this is like that it will be impossible to derive how a battle will end - I mean who will kill who.
One should make all the game calculations that is least to say unproductive.
Like calculate armor state, attack upgrades civ bonuses etc etc…

Yes, that is correct. It absolutely cannot reconstruct the match from events. That’s why I said it will be incomplete.