Re: [Rails-devel] Load/Save games.

[John A. T. <ja...@ja...>]

brett lentz wrote:

>This seems like a non-trivial amount of work, including reworking many
>of our existing classes.
>  
>
So would any other way of getting the state from a save file into the 
tree of objects.  You could probably do it with the least impact on the 
interface of the existing objects by creating a save state object and 
passing it down the tree to a restoreSave() member or similar, and each 
object would have to know enough to construct its child objects and then 
pass the saved object down to their restoreSave() member etc.  However, 
that is likely to be more work than simply making all of the classes 
important to the save state be serializable.

>I agree, that Undo/Redo is a much needed feature. However, I don't
>think it eliminates questions about how to store the data and defining
>game-specific templates of what to store.
>
>I think we're going to need a DTD (or similar template) to define the
>syntax of the saved game file.  Having it hard-coded doesn't seem like
>a wise idea.  Though, I certainly could be wrong here.
>
>I am also concerned about the time it will take to load a saved game
>if we're going to go with the 'replay all steps' model.  Perhaps we
>should store both the state of the game when saved, and the list of
>previous plays?  This would allow us to only need to reload the game
>state while still having access to the previous actions for either
>loading later or loading asynchronously.
>  
>
I agree that could be a problem, depending on how long it will take.

>What do you think of this?
>  
>
You still have the problem of getting the state from the file into the 
hierarchy of objects, and if you don't do it through a log replay 
mechanism then you need something like option 1 to be able to load the 
data into the objects.  Even in the case of the log replay 
implementation, you still have to expose connectivity to all these 
objects (or add pass-through calls to higher level objects) that know 
which child objects to pass the replay entry down to.

>Also, one other alternative is to allow undo/redo during a game, but
>not save it to the file, and just decide that undo/redo after the
>application closes is just simply not supported.
>  
>
I think you are missing his point -- it wasn't so much about preserving 
the undo history after a save, but rather using that to perform the 
save.  If you do the save by a different mechanism, then I agree it is 
not necessary to save the undo history (though it wouldn't be hard to do 
at that point, you just have to serialize the undo log objects).

-- 
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                		 		Smyrna, GA  30082-3723