The question comes up a lot about the different ways of representing game maps. While I am no expert in this field, I feel I am at a stage where I can demonstrate working prototype, without so much complexity that they baffle the user.
Please see below for an outline of the different types of game map storage that I know about.
This example uses enums for tile types.
- Less code, easier to understand at a glance.
- Pretty obvious what tile types do what.
- Tile type specifics need to be stored away from the tile types themselves, thus breaking single source of truth.
- Not particularly flexible.
- Will end up with lots of if statements.
- Tile type implementation will likely need to be done in different places, and Python has no notion of a switch statement.
- Adding more tile types requires potentially more work.
- Not obvious at a glance what the effects of a particular tile type are.
This method allows you to specify a set of tile types, then reference them with pure numbers.
For this example, I used a python list. The data type isn't necessarily important, so long as you can index it.
It has to be said, this is my least favourite method. Just because your possible tile types are ['sand', 'grass', 'water', 'lava'], doesn't stop you from accidentally setting a tile to 12345678. Because of the way Python deals with negative integers (-1 is the last element in a list), you might not even notice you were messing stuff up if you were setting the indices wrong.
Honestly, this isn't a style I'm familiar with. See this post on audiogames.net for explanation.
- It would be trivial to dump these maps to JSON.
- According to the post linked above: This data structure meshes well with using paint tools to draw maps to easily load into your game.
- Same problems as with enums.
- Impossible to do meaningful type checking.
This is probably the most advanced method here. It uses generics, to set the type of your tiles.
If you create a base TileType class to work from, you can use that as your type argument.
- Very flexible.
- You can save all the data associated with tile types on the type classes themselves.
- It is easy to see at a glance what each tile type does.
- Adding new tile types is as easy as subclassing the base
TileTypeclass.
- Would be moderately difficult to dump maps to JSON.
- Generics might be confusing.
- Involves a bit more code.
- Probably requires a bit more memory to hold instances. Of course you should be reusing instances, so there you go.
Because creating a 100x100 map with tiles would be tedious, error prone, and maddeningly long-winded, we instead create tiles using boxes. These are a rectangle of tiles, where we say "Let every tile from (10, 10) to (50, 50) be grass".
There is an example and full test coverage of that as well in box.py.