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

[brett l. <wak...@gm...>]

On 7/1/06, Erik Vos <eri...@hc...> 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.
>
> That was indeed my point: serializing is a existing mechanism to save state.
>
> I understand that serialization propagates automatically, as long as
> contained objects are serializable too. But I don't know what happens if the
>
> containment is circular, of which we have quite some cases.
> Is Java smart enough to recognize that?
> Easy enough to try out one of these days.
>


I'm going to need to read up on serialization. I know very little
about it, so I can't really make a good decision on whether we should
use it or not.


> > >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.
>
> Does having a DTD save any coding then?
> I'm not aware of that, but perhaps you know better?
>


A DTD defines all of the allowed syntax for a particular XML file.  It
serves as a guide for what tags and parameters are valid.

It might save work, but I not completely certain. One thing it does
afford is clarity in the format of the saved file.

> > >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).
>
> Exactly.
> Saving the undo would not be a goal, but a means to achieve reloading
> cheaply.
> But reloading this way might not be a pretty sight.
>


That's what I'm worried about.


> My (still vague and provisional) plan would be to start working on Undo,
> trying to include Redo as well. If Redo works, we would have a
> potential save/reload mechanism. Would that not work or be too ugly,
> then we could try serialization or XML.
>
> Of course there is a lot more work to do (because of which I find assigning
> version number 1.0 at this stage a bit overpromising):
>

>From the beginning, I've said that 1.0 is simply working hotseat play
of 1830, which is what we've currently got.  Beyond that, it's just an
arbitrary number to tell us that we've hit our first major goal.

I'm not really invested in any particular versioning scheme. If
there's one you prefer, I'm willing to consider it.


> - Implementation of the Route concept and all features that need it:
> tile laying validation, revenue calculation, effect of tokens).
>
> - Help (still very rudimentary).
>
> - UI improvements.
> I expect most user comments will relate to the UI.
> And there are still glitches (the Game Status has started flickering again
> in certain cases. I know it is caused by something I did recently,
> but I don't remember what that 'something' is....  Old age, I suppose).
>
> - Client/server operation & Internet playability
> (I think the latter is more complex than the former,
> because authentication and other safety measures come into view).
>

This is going to be a big task even if we leave out the security
aspect.  I'm hoping we can find at least one more person to actively
to help out before we tackle this.

> - Implementing other games.
> For me, this would be the most interesting thing to work on,
> and I can hardly wait to start implementing all games I have (quite a lot).
> But I think that finalizing the base code for 1830 with all the
> above extra features is more urgent now.
>

If this is the most interesting to work on, then let's do this.  I
agree that these other features are important, and we'll deal with
them eventually. However, being that it's just you and me working on
this project, we are free to pursue the features that we're most
interested in.

Being that few people have expressed more than passing interest, we
are the only "customers" that we really need to worry about pleasing
at this point.

Let's just go ahead and start working on adding the next game.  Is
there one you had in mind?  I'm leaning towards 1870.  There's only a
handful of minor rules differences, so it shouldn't be a huge effort
now that we've got much of the basic infrastructure built.


---Brett.