Week 57: game save and reload
Added 2023-12-11 18:41:20 +0000 UTCI started the week adding a new simple game asset to complete room 1. This is the first room and is very simple: the player needs to take a key from a key-holder and drop it into a keyhole. This opens the door that gives access to room 2.
Before starting to work on room 2, I thought I’d have a go at implementing game save and restore functionality. This will be pretty handy for future development as I can restore the game to the point I want to test rather than having to go through all the preceding rooms.
Implementing the infrastructure to save the game state to disk and reload it is pretty easy. Using this infrastructure correctly, however, is a bit tricky. Let me explain. When saving the game state you could take two approaches: the first is saving absolutely everything: positions and velocities of all objects in the scene, etc. This is quite a bit of work, it is unnecessary and maybe undesirable. For example, if you save the game when the player is moving, then the player would move as soon as the game reloads. That’s not what a player expects to see when restarting a game.
The other option is saving only relevant parts of the game state. This, however, can very easily lead to inconsistent states if not done carefully. For example, if you put a key into a keyhole and save the game before the corresponding door has opened you may end up restoring the game to a state where the key is locked into the keyhole but the door is closed and cannot be opened.
This is just one example. In general, it is easy to end up in these kinds of situations if what you are saving is not the full state of the game, but a distilled/partial version of it. I am not quite sure what the best solution is. Maybe I should save the state only at certain points when I know it is safe to do so. Or use a collection of pre-saved states and match them to the game progress? I'll need to sleep over it a few more nights. For now, I have what I need to proceed with room 2 and 3.
