Having all the content in a game created dynamically simplifies many aspects of game design. One code base can potentially create an infinite number of unique gaming experiences. However, what if you want to include a save game feature? If the game content is created anew every time the game is loaded, how is it possible to close the game, then pick it up tomorrow without losing all my progress?
Fortunately, the very act of creating locations and objects can be used to allow data to persist across multiple sessions. Here is an example:
Imagine you have created a dungeon crawl in a procedurally generated cave. The player has the option to dig through walls to reach e.g. deposits of minerals. You want to have a save-game feature, but you don’t want to have the caves reset to new every time the game is reloaded.
Every location in the cave has a unique x/y coordinate, starting at the upper left corner with (0,0) and ending at the lower right with (63,63). Each of these points is either a wall or a floor tile. Now here is the brain-twisty part: you don’t need to store the individual tiles of the original state. Every time the tile map is regenerated, it will be exactly the same. It doesn’t need to be stored.
Your character blows up a chunk of wall, say, at (20,20). Suddenly, the tile map has changed. It has history. It exists in a state different from the one which was produced by the algorithm which created it. Does that mean the entire map needs to be saved now? No! The only piece which needs to be saved is the piece which has changed. And this can be done by creating a data file which saves only the changed pieces of the map.
{
x:20,
y:20,
z:0
terrain:0
}
Reading the above data, we can see that the map coordinate 20,20 on level 0 should be to the terrain-type 0. So a workflow would look something like this:
- generate the initial map data
- look for a save game file
- iterate through the save game file and, where necessary, change the tiles.
- render the map to the screen