[Adonthell-devel] Re: Loading/saving engine state

[Kai Sterker]

On Fri, Sep 25, 2009 at 11:59 PM, Kai Sterker <address@hidden> wrote:

> Feel free to experiment a bit with serializertest.py too. The
> underlying code should be pretty solid by now, but there might still
> be issues left.

Had lost loading/saving out of sight for a bit, but was reminded by
Fredericos recent commit that there was more I wanted to do in this
area :-).

Getting worldtest to actually read all data from ... uh ... data files
will require a bit of work yet, but I should probably make a start at
least. In beginning with rpg::character, I discovered the following:

There's a pair of load/save methods, for loading/saving individual
characters. I guess initially they were meant to be used by the
character editor, whereas the engine would use put_state/get_state to
read/write all characters from/to a stream. However, with the current
gamedata implementation, I'd now prefer static save/load methods to
write all characters into a character.data file. A future editor can
as well work with a file containing all characters. Might even be the
better approach.

Anyway, that brings me to introduce the following conventions for
serializing data:

    bool put_state (base::flat &) const
    bool get_state (base::flat)

for saving/loading one instance from/to a stream.
Where really required

    bool put_state (std::string & file) const
    bool get_state (std::string & file)

to save one instance to one file.
Usually, you just have

   static bool save (std::string & path) const
   static bool load ()

to save all instances (provided we keep track of them somewhere) into
a single file, whose name is hardcoded in the engine. We pass the path
when saving (so you'd do path + "/" + "hardcoded_name.data"), but when
loading we locate the file via base::Path.find_in_path(filename).
(Careful with that one, as it modifies its argument!)

I'll go ahead and start changing worldtest and make sure that anything
I'm going to load from a file will adhere to the convention above.
This might call for a common interface, but I actually tried to avoid
that, as (a) not every class needs all of the methods and (b) I'm a
bit wary of multiple inheritance.

Should probably document the convention above somewhere on the Wiki, too.

Kai