Re: Doing away with SAVE and RESTORE


Tue, 9 May 1995 20:29:14 GMT

In <D8BCqJ.KDn@news.tudelft.nl>, klooster@dutiag.twi.tudelft.nl (Marnix Klooster) writes:
>Reading of an IF story is often done using a computer program, an IF
>reader. All IF readers I know of (including the TADS and Infocom
>interpreters) store the history of a 'reading session' in essentially
>the same way. They keep a sequence of all stories that have been
>seen, from the initial story to the current story (or maybe the last N
>stories seen). When one performs a SAVE, all that is saved is this
>sequence. The UNDO command (when provided) removes the last story
>from the sequence, returning us to the previous story.

This is simply not true of Infocom, in which only the current state is
preserved. UNDO is implemented by the crude technique of doing a SAVE into
RAM after every move.

The situation within more complex games is also more involved than you think.
In most, including authentic versions of the original Adventure, other people,
robots, and various things like that contain their own logical programming,
sometimes with as much freedom to act as the player. (In Galactic
Civilizations -- I realize it is not really IF, but it's an interesting case
-- your opponents are real artificial intelligences who are playing by the
same rules you are.)

This does not mean that a persistent-tree technique such as you wish is
impossible. With modern OO techniques, it can be done quite easily. However,
in order to avoid repeating actions, it is necessary to splice the tree, and
that may not be feasible in the general case. I'm not really sure that the
approach would, in the long run, gain anything.

Since I play Infocom games on OS/2, using my port of ZIP, I can name save
files whatever I want (up to 254 characters), and I can get a list of them at
any time. This helps.