Object-Oriented 'Save Game' Techniques?

GreyArtist asks: "I took a course in C++ a year ago in which the instructor claimed that global (file-scope or inter-file-scope) variables were antiquated and not to be used under any circumstances. I immediately thought of a counter argument that involved the method I use for saving game data. The games (and many of the other programs) I write use not only global variables, but consecutive global variables declared in their own separate module. To save the game (or user settings) to file, I simply save a single large segment of data that contains all the necessary information. How do other coders do it? Would they create a 'MyObject.savemyself()' method for every object in their game? Do they save all the game code along with the data? Either way, it seems like a horrid case of code (or data) bloat. What do you die-hard object-oriented fanatics have to say about this, and what method they would you use for saving games?"

Comments

They're called singletons now

[mrami]

:) You make a singleton called "Prefs" and each module stores its values in a map under its own key (and in GCC, the key could be as easy as __PRETTY_FUNCTION__)

eh? mygame.savemethod()??

[torpor]

Would they create a 'MyObject.savemyself()' method for every object in their game?

isn't the purpose of 'object oriented programming' that you don't have to think like this? you just call the one big 'Game Object' save method, and .. all other derived/related objects, do their big save?

seems a bit wonky to me.

"game saves" is not just a game problem, of course. there are many, many parallels in other types of application .. embedded data loggers, for example, getting a warning that the shack is about to flood for winter, need to save their state too ..

for me, the 'global context save and restore' is a 'built-in' to the design. i'm rather fond of libs and services which provide persistence natively .. though i think that some would argue that mmap's to flash RAM are cheating ... ;)

Single instance

[Bluelive]

This only makes sense if you have a single instance. (ie. Singleton) class. Sounds like your a C user lost in OO land

easy

[DrSkwid]

just ignore the instructor

there are no rules !

Serialization

[SteveX]

It's called serialization, and most OO frameworks support it in some way or another.

Usually it's a way for an object to render itself to a stream, and reconstitute itself from a stream.

That way you can save the objects to disk, or send them over the network, or whatever else you need to do with them.

Every object serializes itself, and all of it's immediate children. Once every object does this, you can save the whole tree of objects with one call.

How can this fail, let me count the ways...

[wowbagger]

Summary of your technique:
Declare various global variables.
Save game state into them.
On Save Game, write block of memory out.

How can this fail, let me count the ways:

1. Layout of global section can change from link to link due to project changes, thus making saves version dependant.
2. Non-save game global data can exist between save items, bloating save file.
3. You can get the size of the save block wrong, and end up not saving the data you need. e.g. you use &foo and &bar as your start and end pointers, but due to a change there are variables after &bar that need to be saved.
4. If the items you are saving become full-blown objects with compiler generated information (virtual function tables) you are overwriting that data with possibly incorrect data.
5. No error checking in file - so a recovered file may screw the game up.

And that's just what I can come up with before my morning coffee.

Look, I disagree with your instructer about "global variables are NEVER needed" - what, then are stdout/stderr/stdin/cout/cin/cerr, if not global variables?

However, global variables are like salt - a little may be needed, but too much will raise your blood pressure.

Again, this is before my morning coffee, but here's a couple of techniques that are better:

• Define a function to allocate a block of "saved space" - sort of a "save_malloc()" function. Allocate the objects you wish to save via that function. In that function, you grab a block of N bytes at initialization, you initialize an end pointer, and you "malloc" by moving the end pointer (no freeing allowed). You now know exactly what you need to save. You can also write a version # at the beginning of the file, and you can compute a checksum of the data. For OO types, you can fancy this up by writing a "Save_game" base class, and implementing new() for that base class.
• The more OO approach: Implement a "Save_game" base class. The base class implements a linked-list, with a static member as the head pointer. The class has Register/Deregister functions, and a pure virtual Size() method. Derived classes implement Size() { return sizeof(*this);} and call Register in their ctor. To save game, walk the list. This also allows you to save the size of the object (even better if you use RTTI, you can save the actual type of the object), and to checksum each object.