Extendable Map Format

Creating a Map is a very time consuming process even so creating a tileset. Both pieces of hard work should be able to survive all changes in program flow and game philosophy so that work once done must not be redone. Nobody knows what happend in a long process of game development.

What is needed for an tileset and game version independent map?

Game Extensions

One major problem are new features or changes in game flow that haven't been considered in existing maps. The development is going on and nobody wants to constantly update all the old maps. Some changes might be simple and the maps still work and is playable but if we think about new building and restrict the abilities of the old ones or about logistics we come very fast to the conclusion that old maps can't simply moved to new game versions.

To solve this the map must contain information about the game features it uses and needs. With this information the game could enable or disable certain features to make the map playable the old way. The easiest way to do this is a flag word.

Which new features needs a flag must be decided from case to case. The only thing we have to do now is to define all extra features as disabled on a 0-flag. This measn that all new and yet unknown features will be disabled for old maps and must explicitly enabled for new ones. This guarantees a high compatibility level and full freedom for new flags and features.

Tileset Dependency

Another big problem is that a special map is drawn with a specific tileset. If this tileset changes the map becomes unusable. The same is valid, if a tileset should be replaced by another one but this tileset contains only a tile subset of the first one. This examples and a little bit phantasie draw a horrible scenario for the future of this game. If nothing changes the time will come where all developers only rework old maps rather than doing new ones and push the game development further.

What is needed here is an translation layer between the map and the game. Currently the map definition contains directly the number of the tile in the tileset. Insert or remove a tile will destroy all related maps. This could be avoided if the map only contains tile symbols which tell the game what tile it should use, similar to the X11 keymap definition.

Instead of 112, which should be a plains tile here the map would contain for example PL03 (third plains tile). The map reader could translate this PL03 internally to 112 and work as usual. The change in game flow were limited to the map reader which have to do the translation.

If the current tileset doesn't have a PL03 tile, the map reader could automatically replace the tile with an equivalent tile from the same tile class. For example the current tileset only contains PL01 and PL02 but no PL03. The map reader automatically choose PL02 as replacement because this tile has the smallest difference in properties. The result: The map is playable.

Suggestions for a Tileset Symbol System

To be continued ...