The planned unified networking calls for a different approach to savegames. The system needs to be able to gracefully cope with the client/server divide.
This article also describes a new Doomsday savegame format. The internal map file format is closely related.
- Save files based on ZIP. A compressed directory (zlib deflate) containing several files, including:
- Player view screenshot image.
- Serialized world state.
- Serialized map objects.
- Any other serialized state.
- Extensible chunk-based format.
- Portable: all data is stored using libdeng2.
- Engine-side save state management UI:
- What to do about missing clients? It may be that when a savegame is loaded, all clients are not yet present.
- Set up an "invisible placeholder" so that a particular client will spawn at the appropriate saved location.
- How to handle split between server and client? Which data is where? The same on both sides?
- Server-side savegames should be transferrable in the sense that if you make one on your local dedicated server, you should be able to copy it to another machine and load it up in another dedicated server. After this clients can join the loaded game as normal.
- How to handle addons? Need to save information about which addons were present when the save was created? See bug report about this.
- I think the correct thing to do here is to record the addons and the load order used. Perhaps with a hash/checksum of the pertinent definition tables. --danij 17:54, 2 March 2012 (UTC)
Saved games should be stored in .save packages with appropriate metadata about the clients.