Plan for new save format

This plan is done. See RSAV for information about the new save format. See Plan for saving more data in saved games for future RSAV plans.

---

The current save format is a big binary file with fixed offsets. it is pretty messy, wastes a lot of space, and is inconvenient and bug-prone to extend.

A new save format would accomplish the following goals:

• Easier to extend while maintaining back/forward compatibility
• Each save slot should be one separate file (or folder?)
• Each type of save data should be a separate lump (or file?)
• Space should be provided for optionally storing things which are not already stored
  • saved NPC state
  • saved map state
  • the script interpreter state: all currently running scripts
  • other script object state such as strings or slices
• Some provisions should be made for RPG file upgrades obsoleting certain SAV data (this is a problem in the current SAV format for things like shop stock and hero spell lists)
  • It is possible that this could be as simple as a game-specific version number that could be used to display a warning message about possible bugs when opening SAV files created with older versions of the same RPG file.
  • Some of the items above, like script interpreter state, are going to be impossible to recover if the relevant game data (ie compiled scripts) has changed in the slightest, unless maybe a copy of the old data is available for examination (eg temporarily load old instead of new copy of script).
  • It might make sense to store some kind of checksum or hash of this sort of upgrade-volatile data so that it can be invalidated if necessary at load-time.
• Old SAV files need to be convertible into the new format.
  • The import globals and export globals commands will need to be re-written for the new format.

A modified proposal (not adopted)

Save game data will be a collection of files in a specially named subdirectory. On Windows this will be inside %APPDATA%\OHRRPGCE\GameName\ and on Linux it will be in $HOME/.ohrrpgce/GameName/ (see the prefsdir global var for access to this location)

Inside that location would be a folder named saves and inside that would be numbered RELOAD files, one for each save slot. So for example, save slot zero for Wandering Hamster being run by a user named Fred on Windows XP would be something like:

C:\Documents and Settings\Fred\Application Data\OHRRPGCE\wander\saves\0.rsav

Implementation plan

• Move all save code to a single module (done)
• separate public interfaces for saving/loading from old save game format saving/loading (done)
• Implement saving game state to a reload document (done)
• Implement writing a game state reload document to disk (done)
• Implement loading a game state reload document from disk (done)
• Implement restoring game state from a reload document (done)
• Implement reading old-style save data into a reload document (done)
• Implement reading just globals for scripting from a reload document (done)
• Implement reading just slot preview data from a reload document (done)
• Implement conversion of old save slots to new save slots (done)
  • After a successful conversion, it should move gamename.sav to gamename.sav.old
• Save and use new format by default (done)
• Remove all old save format code except the one for reading old save slots into reload documents

Sharing Data Between Games

Based on discussion, the best way to do this would probably be to allow games to read the globals of another game, either by ID number, or by name, or both. With the Plan for dynamic types in HamsterSpeak this will allow for sharing of not just integers, but also more complex data structures.