saves, seeds, and sessions

[Vincent Povirk <madewokherd gmail com>]

I've been thinking about how aisleriot could accomodate game saves
(for playing the same game again in different places and/or resuming
across sessions), and Alan's recent comment about seeds has gotten me
back on this subject, so here's what I think (sorry if I'm repeating
myself, I'm not sure what parts of this I might have said earlier):

We can overcome any compatibility problems related to seeds by not
using them at all. Instead, we would just store the initial set of
cards (produced by shuffle-deck). Correct me if I'm wrong, but
shuffle-deck is the only time any current game needs to randomize
anything, and it's always called only once, in new-game (or a helper
function called by new-game).

Of course, the list of cards would need to be validated (probably
stored in such a way that it is easy to validate--maybe a list of
indices used to scramble the original deck?), and in order to preserve
compatibility, the order in which cards are dealt could never be
changed. Options could probably be stored there too (but if it's just
a replacement for seeds, it wouldn't be necessary).

The ability to enter seeds could be implemented as an option specific
to Freecell, for compatibility with the windows Freecell numbers (and
wasn't there some other program with a larger range of seeds that are
sort of standard?).

Now, saving and loading undo history is where this gets crazy. That
would really only be needed for preserving games across sessions,
which isn't necessary at all (but would be nice--so maybe it's just
not worth it).

The simplest solution would be to just write out the undo history,
redo history, and current state as raw scheme. I'm pretty sure we have
helper functions and built in scheme functions that would make this
easy. The resulting files would not be safe at all (or compatible if
the layout or anything about the game changes--we'd need a way to
detect that), and should probably be hidden from the user.

Another possibility would be to store the initial state, a list of
user actions, and an undo count. This would, of course, be much harder
to implement. It could be made more safe (and could be validated since
it would have to follow a very specific format and all the moves would
have to be valid), but would be even less compatible. It'd also be the
most convenient form for debugging.

--
Vincent Povirk aka MadEwokHerd
Primary email: madewokherd gmail com
Secondary email: madewokherd comcast net
Tertiary email: vrp5000 psu edu
Jabber: madewokherd jabber org