From: Erik V. <eri...@hc...> - 2006-06-30 20:52:36
|
> I agree with Erik, I think Loading and Saving games ought to be the > next feature we add. > > I suppose the big question is... how? > > I don't think we necessarily need to worry about people tampering with > the saved game files. Most anti-cheat measures are futile unless we > commit to providing constant updates to an anti-cheat system. > > So, I think a saved game can just be an XML file that stores the state > of the game. > > Due to our setup, we'll need to define saved game data specific to > each game. For example, 1856 needs to store amount of debt a company > has, while 1830 doesn't. > > We're probably going to want to define a DTD for each game to provide > a template for saved game files of a particular game type. > > Then, we can just build the saved game based on the DTD. I see two alternatives: 1. Serialize all classes that hold the current state. I have no experience with serializing, so I don't know if this really is a good idea. 2. Store the Undo stack. The second option presupposes that we create a stack of atomic actions, which can be played back (Undo) and forward (Redo) as far as back to the start of the game (as you can do in Lemmi's moderator). Loading a saved game then would amount to ReDoing the whole stack (e.g. an XML file consisting of a sequence of <action> tags). The nice thing about this last option is that one solution can provide for two needed features. But, again, I'm not sure if this really is a good idea. Not the least reason that I'm bringing forward these alternative ideas is, that I think these are a lot less work ... for me ... Erik. |