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

[Kai Sterker]

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

I have had a more detailed look at the existing code, so I can comment
further on a potential design for loading/saving.

> Since the engine is split into separate modules, it is not so
> easy to save everything from a single method or class. One possible
> place would be the main module.

This does seem like the proper place. We already have a static pointer
to the main app instance, so it is easy to write static wrappers
around a load/save method that could later be called from a Python
loa/save user interface. However, for convenience I would write
something like a savegame manager that keeps track of existing save
games, offers a quick save and auto-save slot, etc., so that the UI
will only have to worry about the presentation.

On a second thought, here is a better design: implement that save game
manager in the base module and allow all the other modules to register
the classes that need to be saved or loaded. Then, on saving, the
manager will just iterate over those and call the appropriate
interface method. This would also allow for a rough progress
indication as we'd know in advance how many classes need to be
loaded/saved.

Obviously, there still need to be static "managers" or factories that
register themselves at module startup and know how instantiate the
individual objects upon loading. Like a map manager that will know
which maps to load, or an audio manager that knows about all the
background music and sfx required. But each of these factories can
exist independently from the others without the need of a module-wide
save/load function.


With that desing in mind, lets revisit what to save for each module:

> event: the game time

Statically accessible in events::date. No problem.


> audio: background music that had been loaded and any registerd audio events

As seen in test/audiotest.py, only the lowlevel audio functionality is
in place. There is nothing to keep track of loaded tracks and sfx,
currently playing track or registered audio events. This needs to be
implemented before the state can be saved or restored.


> rpg: item storage, quest tree and characters, including equipment,
> inventory, etc

All of these are statically accessible. But there is also the quest
log/journal, which is not yet fully implemented. Might need a log book
manager with quest log, dialogue log, etc.


> world: map and everything on it, including schedules, path finding tasks, etc

This gave me the biggest headaches so far. Again, we might need a map
manager that is used to keep track of the different maps and the path
finding (I am not really happy about my decision to make the
pathfinding_manager completely static.) A map manager that knows which
is the current map can also handle pathfinding for each map (and
transitions between maps). It will also have to take care that all
maps end up in each saved game in their current state, even though
they haven't been visited in between loading and saving. I.e.
unchanged maps have to be copied from the originating saved game into
the newly created save. The alternative is to always load all maps and
save them back, but that doesn't sound very efficient. OTOH, maybe
there never will be more than a few maps anyway.


Finally, there is the question whether there will be extensions to the
engine on python side that need their state saved too. Right now I
can't imagine anything that would be completely separate from the core
C++ code and as such couldn't be saved through that. But if required,
it should not be hard to register it at the savegame manager as well.


Comments? Suggestions?

Kai