Tileset Independent
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 still playable.
Suggestions for a Tileset Symbol System
- The tile symbols should be hirarchical organised
- each symbol should be a 4 char long string containing the class and the tile number. This makes it possible to handle the strings as 32-bit identifiers including a lot of performace advantages.
- The tile classes should have a significant difference in behaviour like the classes currently used: Plains, Forest, Mountain, etc.
- Tiles within a class might have different properties
Tile Classes
Name | Short | CF | Description |
roads | RD | (x) | Roads makes movements of ground troops faster but they can be destroyed by gun fire. |
rails | RL | (x) | terrain independent fast moving but inflexible. Trains stick on rails and they can be destroyed by gun fire. |
plains | PL | x | |
debris | DB | x | small movement disadvantage, bonus in defence |
hills | HI | x | bigger movement disadvantage, bonus in defence |
mountains | LM | x | too steep for all sort of ground vehicles |
high_mountains | HM | only crossable by high flying aircraft | |
forest | FO | x | the bigger the vehilce the slower it can cross this field |
mud | MD | wet and soft ground. Heavy vehilces will cave in | |
swamp | SW | x | wet and soft ground with water holes. Bad terrain for vehicles |
snow | SN | soft and slippery ground. Movement will be hard and slow | |
deep water | DW | x | deep enough for diving vehicles like submarines |
water | NW | x | |
shallow water | SW | x | shallow water, only up to a few meters deep. |
iced water | IW | frozen water, solid enough to carry heavy vehicles | |
fortress | FT | (x) | human built barricades and trenches not easy to cross but destroyable by gun fire. |
Classes marked in the CF column are already implemented in Crimson Fields.