Savegame Files

Originally written by Ishtvan on http://forums.thedarkmod.com/topic/1538

Savegame files are not plain text files.

Since I have to save the state of AI/player team relationships eventually, I started looking at the savegame files. I looked at savegame.cpp, and, I could not believe my eyes, Id ACTUALLY WROTE SOME DOCUMENTATION on savegames! I think the later levels of doom3 just froze over.

So without further ado, here is a cut and paste of that info on how savegames work:

From src/game/gamesys/savegame.cpp

Save game related helper classes.

Save games are implemented in two classes, idSaveGame and idRestoreGame, that implement write/read functions for
common types.  They're passed in to each entity and object for them to archive themselves.  Each class
implements save/restore functions for it's own data.  When restoring, all the objects are instantiated,
then the restore function is called on each, superclass first, then subclasses.

Pointers are restored by saving out an object index for each unique object pointer and adding them to a list of
objects that are to be saved.  Restore instantiates all the objects in the list before calling the Restore function
on each object so that the pointers returned are valid.  No object's restore function should rely on any other objects
being fully instantiated until after the restore process is complete.  Post restore fixup should be done by posting
events with 0 delay.

The savegame header will have the Game Name, Version, Map Name, and Player Persistent Info.

Changes in version make savegames incompatible, and the game will start from the beginning of the level with
the player's persistent info. 

Changes to classes that don't need to break compatibilty can use the build number as the savegame version.
Later versions are responsible for restoring from previous versions by ignoring any unused data and initializing
variables that weren't in previous versions with safe information.

At the head of the save game is enough information to restore the player to the beginning of the level should the
file be unloadable in some way (for example, due to script changes).

Preliminary notes, will edit/correct as I find out more

So the save/restore workings are sort've in src/game/gamesys/class.*

This is the base class for every single class apparently, and it has Save and Restore functions that are called automatically.

It also has stuff like Init() and Shutdown(). This would explain why my soundprop::Shutdown method is called more times than I call it when shutting down (that's always bothered me); apparently the game also automatically calls this method under certain circumstances (like shutting down).

If you want a list of all the methods that the game might call automatically (on instancing, destroying, etc), check out class.h . class.h of course does not explain WHEN these methods are called. smile.gif

Anyway, for savefiles, the relevant methods are idClass::Save and idClass::Restore. Restore is apparently called whenever an object is instanced. I have no idea how Save and Restore know where in the savefile to check... the functions I've seen just write their stuff to the savefile without saying where in the savefile to write it.

The 'document' above might explain that. The savegame file might automatically index every object, and know if an object that was in the savefile is instanced, know where to look in the savefile for its info and read from there when calling Restore. (Cleary Restore and Save have to write exactly the same information or things get very screwed up) .