Transcripts as game save files
David Fisher
What if the current game state was stored as a list of all player commands
entered so far (taking into account "undo", "restart", etc) ?
Advantages
* Implementing "undo" is very simple (just revert to the initial game state
& replay all the commands).
* For that matter, "unlimited undo" is also simple - and doesn't chew up
memory.
* The player could potentially select an exact point to "undo" to, by
viewing the transcript so far and going back to a particular point. This
alleviates the problem of having to save the game all the time (in effect,
the game is "saved" at the end of every turn) - doing 10 undos is the same
as reverting to a game that was saved 10 turns ago.
* (The player could still save games if they wanted to, eg. the final game
state or an interesting branch they want to continue later but undo at the
moment).
Disadvantages
* File size is dependant on number of turns played (but would still probably
remain small).
* Reloading a game may be slow (since it involves replaying every command
entered so far).
* Undo may be slow (it involves replay as well).
* Must ensure that the random events (and real time based events, if any)
are identical to the original ones during replay.
The main problem seems to be slowness (during undo and reloading a saved
game). One possible solution would be to save the actual (internal) game
state periodically, so that the most recent "complete save" is never more
than N turns ago - and replaying the player's commands would only need to be
done from that point.
Such game saves could be done automatically during the game, eg. after every
100 moves. The game might give a message like "[auto saving]" when this is
happening, if that is not too distracting. Or this could be done in the
background without the player even knowing it. The player would need to
enter the name of the game save file at some stage, though (unless it has a
default name and location - and only bothers the player if there is a
problem saving to that location).
David Fisher
Jan Thorsby
"David Fisher" <da...@hsa.com.au> skrev i melding
news:Lrgbe.9009$Le2....@nasal.pacific.net.au...
> Just thinking about the format of "game save" files ...
>
> What if the current game state was stored as a list of all player commands
> entered so far (taking into account "undo", "restart", etc) ?
I don't think it would work if there is anything random in the game.
Agnes Heyer
"Jan Thorsby" <no_jthor...@broadpark.no> skrev i melding
news:426e...@news.broadpark.no...
What you're describing here is basically the recording/replay actions in
Inform, where all commands are recorded into a text file, which you can
later replay. And, as David mentions, it is a problem with random events,
since at some point, the whole thing could get cut short by e.g. an npc
moving, and then the rest of it won't work as the objects you want to handle
simply aren't there.
JohnnyMrNinja
David Fisher wrote:
> Just thinking about the format of "game save" files ...
>
> What if the current game state was stored as a list of all player
commands
> entered so far (taking into account "undo", "restart", etc) ?
The ability to save and play from a text command list would be great
for beta testing. You could have different files for different endings
(quickwin.txt, headexplode.txt, etc.), to make sure no minor changes
have butterfly effects.
Paul Du Bois
commands
> > entered so far (taking into account "undo", "restart", etc) ?
Jan Thorsby wrote:
> I don't think it would work if there is anything random in the game.
Don't give up so easily! This savegame technique is used by games much
more complicated than a typical IF game (like Bungie's _Myth_). As
long as you are careful to start at a consistent state and record all
significant input, it works fine.
For random numbers this means using a fixed seed, or recording the
seed.
Of course, the more external state you rely on (eg exact time of day,
bits from some entropy source, uninitialized memory) the harder you
make it on yourself.
p
Matthew Russotto
David Fisher <da...@hsa.com.au> wrote:
>Just thinking about the format of "game save" files ...
>
>What if the current game state was stored as a list of all player commands
>entered so far (taking into account "undo", "restart", etc) ?
It's actually quite practical, if unaesthetic. You do have problems
when games use auxiliary files which may change between save and
restore, though.
>Disadvantages
>
>* File size is dependant on number of turns played (but would still probably
>remain small).
Small by modern desktop standards, but quite large compared to Quetzal files.
Speed is less of a disadvantage than you might think, on a modern
machine.
However, most of the advantages really aren't; multi-undo can be done
more easily by saving game state deltas. The big advantages are the
human-readable output and the ability to backtrack arbitrarily by
looking at that output.
Any interpreter with record/playback that handles the state of the
random number generator can be used to do this; I've used it for
making walkthroughs.
--
There's no such thing as a free lunch, but certain accounting practices can
result in a fully-depreciated one.
Matthew Russotto
Agnes Heyer <ag...@retinaleclipse.com> wrote:
>
>What you're describing here is basically the recording/replay actions in
>Inform, where all commands are recorded into a text file, which you can
>later replay. And, as David mentions, it is a problem with random events,
>since at some point, the whole thing could get cut short by e.g. an npc
>moving, and then the rest of it won't work as the objects you want to handle
>simply aren't there.
Zip Infinity saves the random number seed in the recording.
Damian Dollahite
> Speed is less of a disadvantage than you might think, on a modern
> machine.
>
I wouldn't say that. My medium-length WIP is only about 25% playable,
and it already takes a significant amount of time for HTML TADS to
replay my test script. I have a 2gHz machine with plenty of RAM and HDD
space. It only takes an instant to restore a sav or t3v format file, but
replaying a script take 20-30 seconds for even a small number of moves.
My feeling on this proposal is that while it might be a viable method of
saving games, it's a very crude and inefficient one. It requires
performing every incremental change in game state over again to arrive
back at the savepoint; formats like quetzal and t3v only store the final
state at the end of the sequence. Using transcripts as savegames could
be a quick-and-dirty hack for a homebrew IF system, but I don't see any
established VM with a binary save format switching over.
Dan Shiovitz
Damian Dollahite <ryu...@aol.com> wrote:
[..]
>I wouldn't say that. My medium-length WIP is only about 25% playable,
>and it already takes a significant amount of time for HTML TADS to
>replay my test script. I have a 2gHz machine with plenty of RAM and HDD
>space. It only takes an instant to restore a sav or t3v format file, but
>replaying a script take 20-30 seconds for even a small number of moves.
I thought about raising this objection myself, but on second thought
I'm not sure this is a good comparison. Isn't a large part of the
delay here all the rendering of the text, word-wrapping, and other UI
stuff you wouldn't do when restoring? (It would, admittedly, be cool
if restore restored scrollback, but that certainly would be slow).
--
Dan Shiovitz :: d...@cs.wisc.edu :: http://www.drizzle.com/~dans
"He settled down to dictate a letter to the Consolidated Nailfile and
Eyebrow Tweezer Corporation of Scranton, Pa., which would make them
realize that life is stern and earnest and Nailfile and Eyebrow Tweezer
Corporations are not put in this world for pleasure alone." -PGW
danie...@hotmail.com
save-state every time a command is given in a big file and index it by
commands. You could use keyframe encoding to reduce filesize if
necessary, and it would probably also be a good idea to save
scrollbacks while you're at it.
Matthew Russotto
>> Speed is less of a disadvantage than you might think, on a modern
>> machine.
>>
>
>I wouldn't say that. My medium-length WIP is only about 25% playable,
>and it already takes a significant amount of time for HTML TADS to
>replay my test script.
That's TADS. I was talking Z-machine. I'm sure TADS can be made much
faster during replay in any case.
Damian Dollahite
> In article <d4mcu0$fqu$1...@domitilla.aioe.org>,
> Damian Dollahite <ryu...@aol.com> wrote:
> [..]
>
>>I wouldn't say that. My medium-length WIP is only about 25% playable,
>>and it already takes a significant amount of time for HTML TADS to
>>replay my test script. I have a 2gHz machine with plenty of RAM and HDD
>>space. It only takes an instant to restore a sav or t3v format file, but
>>replaying a script take 20-30 seconds for even a small number of moves.
>
>
> I thought about raising this objection myself, but on second thought
> I'm not sure this is a good comparison. Isn't a large part of the
> delay here all the rendering of the text, word-wrapping, and other UI
> stuff you wouldn't do when restoring? (It would, admittedly, be cool
> if restore restored scrollback, but that certainly would be slow).
>
I don't think so -- I'm replaying in Quiet mode, which only updates the
status line, not the transcript. Of course, it may be doing all that
internally and just not showing it, but you'd have to ask Mike about
that.
Besides, with TADS, and especially TADS 3, rendering takes far less time
than the actual processing of the game state. One of the drawbacks to
Adv3's world model sophistication is that it has to do a lot of
calculations every turn just to track what objects are in scope.
-- Ryukage
David Fisher
news:d4mcu0$fqu$1...@domitilla.aioe.org...
> Matthew Russotto wrote:
>> Speed is less of a disadvantage than you might think, on a modern
>> machine.
>>
>
> I wouldn't say that. My medium-length WIP is only about 25% playable,
> and it already takes a significant amount of time for HTML TADS to
> replay my test script. I have a 2gHz machine with plenty of RAM and HDD
> space. It only takes an instant to restore a sav or t3v format file, but
> replaying a script take 20-30 seconds for even a small number of moves.
>
> My feeling on this proposal is that while it might be a viable method of
> saving games, it's a very crude and inefficient one. It requires
> performing every incremental change in game state over again to arrive
> back at the savepoint; formats like quetzal and t3v only store the final
> state at the end of the sequence.
One possibility to make "replay" to a certain point (including the final
state) faster, as I mentioned in the first post, would be to periodically
save a "checkpoint state" in the traditional way ... see the last two
paragraphs of the original post for more info on this idea.
Thanks for the input (& everyone else, too !)
David Fisher
David Fisher
news:XYOdnfDNfoC...@speakeasy.net...
> In article <Lrgbe.9009$Le2....@nasal.pacific.net.au>,
> David Fisher <da...@hsa.com.au> wrote:
>>Just thinking about the format of "game save" files ...
>>
>>What if the current game state was stored as a list of all player commands
>>entered so far (taking into account "undo", "restart", etc) ?
>
> It's actually quite practical, if unaesthetic. You do have problems
> when games use auxiliary files which may change between save and
> restore, though.
Good point !
> However, most of the advantages really aren't; multi-undo can be done
> more easily by saving game state deltas. The big advantages are the
> human-readable output and the ability to backtrack arbitrarily by
> looking at that output.
Multi-undo to an arbitrary point is the main advantage I was thinking of
(another small advantage being the fact that you don't need code to store
deltas, just complete "current state" saves).
What got me thinking along these lines was an old RAIF thread from Feb 2000
on informing the player when they get into an "unwinnable" state. The issue
of having lots of saved games, overwriting a winnable save with an
unwinnable one, etc. kept on coming up. The best solution to me seems to be
a selectable undo, where you can decide exactly what point you want to go
back to - this is equivalent to having a separate, saved game for every
single turn you have made so far.
(The "Unwinnable situations" thread was
http://groups-beta.google.com/group/rec.arts.int-fiction/browse_frm/thread/a191da0eed0e861e/6f95522701b1430a
if anyone is interested).
David Fisher
David Fisher
news:Lrgbe.9009$Le2....@nasal.pacific.net.au...
> What if the current game state was stored as a list of all player commands
> entered so far (taking into account "undo", "restart", etc) ?
>
> Advantages
>
> * Implementing "undo" is very simple (just revert to the initial game
> state & replay all the commands).
> * For that matter, "unlimited undo" is also simple - and doesn't chew up
> memory.
> * The player could potentially select an exact point to "undo" to, by
> viewing the transcript so far and going back to a particular point. This
> alleviates the problem of having to save the game all the time (in effect,
> the game is "saved" at the end of every turn) - doing 10 undos is the same
> as reverting to a game that was saved 10 turns ago.
I just found a similar idea in an old (Mar 1999) thread:
Just for people's information,
David Fisher
Graham Holden
wrote:
>
>One possibility to make "replay" to a certain point (including the final
>state) faster, as I mentioned in the first post, would be to periodically
>save a "checkpoint state" in the traditional way ... see the last two
>paragraphs of the original post for more info on this idea.
>
>Thanks for the input (& everyone else, too !)
>
>David Fisher
>
Coming in a bit late to the thread; the "snapshot and replay" approach is
something I use when playing/testing games. At periodic points I'll make
a new saved game, and then work on a replay-script in between. Actually,
I probably don't bother with replay-script most of the time, only multiple
saved games. If the game warrants it (longish, puzzly, where there's an
element of wanting the "best" solution), I'll "hone" replay-script from the
last save-point.
As far as coping with random events, I hacked the interpreter I use
(FrotzS5) so that I can "pause" replay until a certain event happens, e.g:
n
w
give sleeping tablet to dog
!wait for dog to fall asleep
get collar
...
The "!..." line tells the 'terp to take input from the keyboard until I
begin a line with "!" at which point the replay resumes.
Regards,
Graham Holden (g-holden AT dircon DOT co DOT uk)
--
There are 10 types of people in the world;
those that understand binary and those that don't.
samwyse
> As far as coping with random events, I hacked the interpreter I use
> (FrotzS5) so that I can "pause" replay until a certain event happens, e.g:
>
> n
> w
> give sleeping tablet to dog
> !wait for dog to fall asleep
> get collar
> ...
>
> The "!..." line tells the 'terp to take input from the keyboard until I
> begin a line with "!" at which point the replay resumes.
I like that. It's enough to make me finally write a patch that I've
wanted: command line options for Frotz to cause RECORDING, REPLAY,
RESTORE or SCRIPT commands to be executed before the game starts. I've
hacked together some ways to use dfrotz to do automatic regression
testing of things, but I've always thought that triggering things in the
interpreter before the game starts would be better. Combined with your
idea, there's a lot of stuff that I'd be able to do.