Map Grids

The scenario and saved game files for all citybuilders contain a number of n x n "grids" that store various properties of the map. One of such grids is the terrain map: which terrain element (tree, rock, water, ...) is at which location. All these grids are the same size, that is, n is always the same: the length of one element in the grid may be a byte, a short (2 bytes) or an int (4 bytes). Contrary to intuition, n does not depend on the map size: it's always a fixed number, depending only on the game.

If those grids are the same size for every map size, how does data get stored then? The answer is: smack in the middle of those grids. A second question that arises: what about the non-Caesar 3 maps? They are not square but diamond-shaped if you look at them from a programmer's view. First, let's go for a table:

Game Map sizes available Map shape Grid size
Caesar 3 40, 60, 80, 100, 120, 160 square 162x162
Pharaoh 56, 84, 112, 140, 170, 226 diamond 228x228
Zeus 56, 84, 112, 140, 170, 226 diamond 228x228
Emperor 56, 84, 112, 140, 170, 226 diamond 228x228

Note that the grid sizes are always two tiles more than the largest map. This provides a border of at least 1 element on all sides.

Square maps

Square maps are easy to store in the grids. Calculate the size of the border in this way: border = (grid_size - map_size) / 2. The map sizes and maxima are always even numbers. For example, take a 10x10 maximum map size and a map size of 6. The grid would be stored in this way: (0 = unused, 1 = map data)

0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 1 1 1 1 1 1 0 0
0 0 1 1 1 1 1 1 0 0
0 0 1 1 1 1 1 1 0 0
0 0 1 1 1 1 1 1 0 0
0 0 1 1 1 1 1 1 0 0
0 0 1 1 1 1 1 1 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0

Diamond-shaped maps

Diamonds are a little harder than square maps, but it's still fairly easy. The map sizes quoted in the table above are measured from the top corner of the diamond to the bottom corner (or left to right). Continuing the example above, consider a 10x10 maximum map size and a map size of 8 this time:

0 0 0 0 0 0 0 0 0 0
0 0 0 0 1 1 0 0 0 0
0 0 0 1 1 1 1 0 0 0
0 0 1 1 1 1 1 1 0 0
0 1 1 1 1 1 1 1 1 0
0 1 1 1 1 1 1 1 1 0
0 0 1 1 1 1 1 1 0 0
0 0 0 1 1 1 1 0 0 0
0 0 0 0 1 1 0 0 0 0
0 0 0 0 0 0 0 0 0 0

Usage

So what are these grids used for? A few examples occurring in all games:

Terrain grids
Each element in these type of grids are basically bit vectors: if bit 1 is set, the terrain is a tree, if bit 2 is set, the terrain is a rock, and so forth. Terrain elements can easily be combined in this way: fertile land with a road (or a building) on top of it. These bit vectors are 2 bytes (C3) or 4 bytes (Pharaoh and Zeus).
Building edge grid
This may not be an accurate term, but this byte grid does indicate for multiple-tile buildings where each building tile is. This grid is important enough to have its own page.
Random grid
This byte grid is completely made up of random numbers. These numbers are used for, among others, determining which graphic should be used for that tile (leading to a more natural terrain appearance), whether 4 1x1 houses will merge to a 2x2 house, and it also influences which direction roaming walkers will take when they encounter a road intersection.

Last modified on 2007-12-27 10:23:55