On Fri, Sep 11, 2009 at 11:23 PM, Kai Sterker <kai.ster...@gmail.com> 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 _______________________________________________ Adonthell-devel mailing list Adonthell-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/adonthell-devel