Forced replays and other sins

27 views
Skip to first unread message

Matthew Amster-Burton

unread,
May 2, 1996, 3:00:00 AM5/2/96
to

One thing that really galls me when I'm playing a game is being forced
to replay a large section because I missed a small detail many scenes
back. This happened to me in Trinity so many times that I still
haven't gotten around to finishing it. In fact, last time I played, I
used a walkthrough, and *still* managed to screw up. I'm sure most
players dislike this as much as I do.

I can think of a couple of ways to deal with this situation, from the
designer's point of view. (A way to deal with this situation from the
*player's* point of view is to make a stuffed doll in the image of the
author and throw it off a pier.)

1. Make it impossible to get stuck. This is the tack taken by the
LucasArts games, i.e. Day of the Tentacle, Sam n' Max. The
only text game I can think of off the top of my head that works
this way is Perdition's Flames, and I haven't played it, only
heard about it.

2. Give stern warnings when the player is about to do something that
will get her stuck. This seems mostly unworkable, unless you have

designed your game so there are only a few, obviously stupid,
things to do to end up in a corner. ("Stimpy, press the
history-eraser button" is probably a bad idea, for example.
Maybe.)

3. Don't do anything about it--text adventures aren't easy, and if
you get stuck and have to replay the last two hours, tough
noogies.

Option (1) has always appealed to me, but I've rarely seen it in
practice. A friend of mine has an unfinished game that worked this
way, and it seemed no less enjoyable for it (you couldn't die,
either). But a poster once said they found the unstuckable aspect of
Perdition's flames annoying. I like the idea that the solution to the
puzzle that has me stumped is around somewhere, and is not dependent
on the frying pan that I dropped into the volcano fifty moves back.
Thoughts?

Option (2) may characterize many games already out there. "This might
be a good time to save the game..." is a variation on the concept.
Unfortunately, this tactic never would have saved my butt in Trinity,
because I would have been more upset to see "Are you SURE you want to
enter the white door without the axe?" than just being allowed to fuck
up.

I'm thinking about the directions my own game--should I ever finish
it--should go, and though I'm no slave to public opinion, I'm
interested to know how people feel about playing a game where you know
in advance that you will not get stuck.

Matthew

---
Matthew Amster-Burton .sig revision 0, 5/1/96
I speak for myself, not for UW


Kathleen Fischer

unread,
May 2, 1996, 3:00:00 AM5/2/96
to

mam...@u.washington.edu (Matthew Amster-Burton) wrote:
>One thing that really galls me when I'm playing a game is being forced
>to replay a large section because I missed a small detail many scenes
>back. This happened to me in Trinity so many times that I still
>haven't gotten around to finishing it. In fact, last time I played, I
>used a walkthrough, and *still* managed to screw up. I'm sure most
>players dislike this as much as I do.

That depends on how small a detail (how many times it happens) and wether
or not I can fix it...

If I can't board the ferry boat because I didn't pick up the quarter I saw
on in front of the bank (20 rooms back) then, well, I'm screwed and
I accept that as part of the game. So long as the quarter is still then when I
return (and the ferry still there when I get back), no problem.

If I can't board the ferry boat because I did pick up the quarter but bought a
yummy gum ball instead then I'm stupid and I accept that as a fact of life.

If I can't board the ferry boat because I didn't think to put the banana on the
ground and the day old newspaper over the grate and wait by the bank for 3
turns until the drunken bum walks by and slips... (and since he has already
walked by the bank I'm out of luck) then I will probably not play the game
again.

Kathleen

ps. Are traveler's checks something found world wide? Can you buy them in the
UK, Japan, Canada... etc?

--
// Kathleen Fischer
// kfis...@greenhouse.llnl.gov
// *** "Don't stop to stomp ants while the elephants are stampeding" ***


Christopher E. Forman

unread,
May 2, 1996, 3:00:00 AM5/2/96
to

Matthew Amster-Burton <mam...@u.washington.edu> wrote:
: 2. Give stern warnings when the player is about to do something that

: will get her stuck. This seems mostly unworkable, unless you have
: designed your game so there are only a few, obviously stupid,
: things to do to end up in a corner. ("Stimpy, press the
: history-eraser button" is probably a bad idea, for example.
: Maybe.)

I experimented with this approach in "The Path to Fortune," but restricted
myself to warning the players about things that they wouldn't catch
otherwise. For instance, if one of the dark elves is encountered without
the proper item, it's impossible to safely retreat (unless you use UNDO
immediately), and you're stuck. But if you've turned on the game's
"warning mode," you'll be alerted ahead of time, before you enter the
location with the elves.

The important thing to keep in mind is that warnings should be optional.
Players should be able to decide whether to turn them on or off, much like
the "notify" command for scoring. Some players find that being warned of
danger unnaturally spoils the fantasy worse than having to restore.

Also, you'll have to decide just which situations to include. With PTF, I
restricted myself to situations where whe player wouldn't normally guess
that s/he's about to get stuck. It doesn't cover obviously stupid actions
like throwing items in the river, or actions the results of which can be
easily guessed with a little thought (such as eating the dough -- it's
pretty obvious it'll work and the dough will be gone, plus the player can
always UNDO here).

: Option (2) may characterize many games already out there. "This might


: be a good time to save the game..." is a variation on the concept.
: Unfortunately, this tactic never would have saved my butt in Trinity,
: because I would have been more upset to see "Are you SURE you want to
: enter the white door without the axe?" than just being allowed to fuck

: up. ^^^^

Real adventurers do not use such language.
(Sorry, had to say it. B-)

(2) is my preferred method, if it's feasible and not too much of a pain to
add. (1) is hard to do, since it might directly contradict what you have
in mind for the design -- and revising the whole design simply to prevent
a player from getting stuck is better left to the true masochists, though
the LucasArts games you mentioned handled it quite well. (Then there's
always LGOP2...) (3) is the traditional approach, and is still used
widely enough that players suspect that getting stuck is a possibility.
It's also the easiest to deal with.

The problem with requiring people to save is that it induces paranoia.
"Am I saving a game that's already unwinnable?" You've got two extremes:
people who don't save enough (and then complain when they get stuck) and
people who save every few turns (and then whine about the huge number of
saved games they have to manage).

--
C.E. Forman cef...@rs6000.cmp.ilstu.edu
Read the I-F e-zine XYZZYnews, at ftp.gmd.de:/if-archive/magazines/xyzzynews,
or on the Web at http://www.interport.net/~eileen/design/xyzzynews.html
Vote I-F in 1996! Visit http://www.xs4all.nl/~jojo/pcgames.html for info!

Russell L. Bryan

unread,
May 2, 1996, 3:00:00 AM5/2/96
to

Just a note here, as a crossover between the mimesis threads and here,
it is a great crime against mimesis for a game to ensure that you are
prepared for every threat you face. Sudden death may be considered a
sign according to the Player's Bill of Rights, but hell, it happens all
the time.

-- Russ

Neil K. Guy

unread,
May 2, 1996, 3:00:00 AM5/2/96
to

Kathleen Fischer (kfis...@greenhouse.llnl.gov) wrote:

: ps. Are traveler's checks something found world wide? Can you buy them in the
: UK, Japan, Canada... etc?

Um... is this a trick question? I mean, the point of traveller's cheques
(or traveler's checks for Americans) is that so you can have some form of
money that can't be cashed by anyone but you when you go travelling. So,
yes, you can buy and cash traveller's cheques in most industrialized
countries and cash them in most countries with some form of tourist
industry. (though the viciously poor rates that they offer means I
usually end up just carrying around cash when I travel and hope for the
best.)

Ob. r.a.i.f: I hope your game recognizes common localized synonyms for
words like traveller's cheques. :) That was something in Graham Nelson's
player's bill of rights, I think. Stuff like cheque/check,
football/soccer ball, dustbin/trash can/garbage can etc.

- Neil K. Guy

--
Neil K. Guy * ne...@sfu.ca * n...@vcn.bc.ca
49N 16' 123W 7' * Vancouver, BC, Canada

Roger Giner-Sorolla

unread,
May 3, 1996, 3:00:00 AM5/3/96
to

Actually, this makes IF games more "realistic" than most linear fiction
with its obligatory "happy ending" -- in IF there's a multitude of
unsatisfactory endings, and you're bound to see at least a few of them
when you mess up.

In IF it's *possible*, but not ensured, that the player overcomes every
threat. True, the Model Story that results from winning the game is
somewhat pat; but then, so's most popular fiction, TV, and cinema.

I wonder if anyone who has read the stories of Lord Dunsany can forget
the ending of "The Hoard of the Gibbelins."

[Dunsany spoilers below; "Hoard" and many other tales are online at
http://www.greyware.com/authors/Doyle&Macdonald/l_wonder.htm]

Dunsany is a major influence on modern fantasy; he wrote in the first
half of the century. One of his most anthologized stories, "The Hoard of
the Gibbelins", concerns a knight in a droll, pseudo-medieval setting who
sets out on a quest to steal a fantastic treasure of gems from a nameless
tower on the world's edge, home to a horrid clutch of ... well, Gibbelins.

The knight does a number of clever things to reach the hoard, and the
ending of the story is thus:

... By a faint ray of the moon he saw that the floor was green with
[emeralds], and, easily filling a satchel, he rose again to the surface;
and there were the Gibbelins waist-deep in the water, with torches in
their hands! And, without saying a word, /or even smiling/, they neatly
hanged him on the outer wall -- and this tale is one of those that have
not a happy ending.

>restore

Actually, a lot of Dunsany's stories read like classic Infocom, thanks to
his laconic, wry style, archaic settings and witty adventure plotting.
Here's the "puzzle" whereby Thangobrind the Jeweller steals the diamond
from the spider-idol Hlo-Hlo:

Thangobrind offered honey to Hlo-Hlo and prostrated himself before him.
Oh, he was cunning! When the priests stole out of the darkness to lap up
the honey they were stretched senseless on the temple floor, for there
was a drug in the honey that was offered to Hlo-Hlo.

(Gods, Men and Ghosts: The Best Supernatural Fiction of Lord Dunsany, ed.
E.F. Bleiler, Dover Publications, New York, 1972)

Roger Giner-Sorolla New York University, New York, NY
gi...@xp.psych.nyu.edu Dept. of Psychology (Social/Personality)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This scholar, rake, Christian, dupe, gamester, and poet.
David Garrick, "Jupiter and Mercury"

Matthew Amster-Burton

unread,
May 3, 1996, 3:00:00 AM5/3/96
to

cef...@rs6000.cmp.ilstu.edu (Christopher E. Forman) wrote:

>I experimented with this approach in "The Path to Fortune," but restricted
>myself to warning the players about things that they wouldn't catch
>otherwise. For instance, if one of the dark elves is encountered without
>the proper item, it's impossible to safely retreat (unless you use UNDO
>immediately), and you're stuck. But if you've turned on the game's
>"warning mode," you'll be alerted ahead of time, before you enter the
>location with the elves.

This is a good system, but puts some constraints on game design. As I
mentioned before, a warning system smart enough to figure out when
you've gone wrong in "Trinity" would be an abomination. No sane
player would appreciate its warnings.

Perhaps "Trinity" is anomalous, though. Most games don't contain a
series of vital vignettes, or if they do, they make them
self-contained (i.e., Jigsaw, or...uh, Nord and Bert). I can't
remember which way "Spellbreaker" worked. Even though "Trinity" was a
fine game, the forced saves-and-restores seriously limited my
enjoyment of it, and as I said, I haven't even finished it, although
I'd like to at some point.

>: enter the white door without the axe?" than just being allowed to fuck
>: up. ^^^^

>Real adventurers do not use such language.
>(Sorry, had to say it. B-)

Mmm...maybe I was being emphatic. Or maybe that's one of the "other
sins" in the subject, which I never got to.

>(2) is my preferred method, if it's feasible and not too much of a pain to
>add. (1) is hard to do, since it might directly contradict what you have
>in mind for the design -- and revising the whole design simply to prevent
>a player from getting stuck is better left to the true masochists, though
>the LucasArts games you mentioned handled it quite well. (Then there's
>always LGOP2...) (3) is the traditional approach, and is still used
>widely enough that players suspect that getting stuck is a possibility.
>It's also the easiest to deal with.

Haven't played LGOP2, don't intend to. I have a feeling that my ideal
IF experience is still closer to (1), but as I said, I've never really
seen it done in a text game. It must be time to buy Perdition's
Flames, and if it annoys me, perhaps I'll change my tune.

>The problem with requiring people to save is that it induces paranoia.
>"Am I saving a game that's already unwinnable?" You've got two extremes:
>people who don't save enough (and then complain when they get stuck) and
>people who save every few turns (and then whine about the huge number of
>saved games they have to manage).

Are there any games (graphical or otherwise) that, instead of
requiring you to give your saved game a name, just generate a fairly
good description of where you are, your inventory, etc.? It would be
trivial, of course, and might be very helpful when you can't remember
whether "cave1" or "cave2" was before your lamp went out. Bad
example, but you know what I mean.

Kenneth Fair

unread,
May 3, 1996, 3:00:00 AM5/3/96
to

In article <4mbgob$e...@milo.vcn.bc.ca>, n...@vcn.bc.ca (Neil K. Guy) wrote:


> Ob. r.a.i.f: I hope your game recognizes common localized synonyms for
>words like traveller's cheques. :) That was something in Graham Nelson's
>player's bill of rights, I think. Stuff like cheque/check,
>football/soccer ball, dustbin/trash can/garbage can etc.

Though I have yet to figure out what a "demijohn" is.

--
KEN FAIR - U. Chicago Law | Power Mac! | Net since '90 | Net.cop
kjf...@midway.uchicago.edu | CABAL(tm) Member | I'm w/in McQ - R U?
"You're fooling yourself. We're living in a dictatorship, a
self-perpetuating autocracy..." - Dennis

Matthew Amster-Burton

unread,
May 3, 1996, 3:00:00 AM5/3/96
to

kjf...@midway.uchicago.edu (Kenneth Fair) wrote:

>Though I have yet to figure out what a "demijohn" is.

(Oh, boy, are you going to hate me.)

demijohn

A large bottle with bulging body and narrow neck, holding from 3 to 10
(or, in extreme cases, 2 to 15) gallons, and usually cased in wicker-
or rush-work, with one or two handles of the same, for convenience of
transport.
An ordinary size is 5 gallons. Demijohns of clear glass, of
ovate-quadrilateral section in the body (14 x 16 inches diam.), are
employed to export vinegar and spirits to the West Indies, and are in
common household use in the islands. The name is sometimes also given
to vessels of earthenware or stoneware similarly cased.

demijohn ('demId3on). Forms: 8 demijan, 9 demijean, demi-john,
demijohn. [In Fr. dame-jeanne (1694 Th. Corneille dame-jane, 1701
Furetiere Dame Jeanne, lit. `Dame Jane'); so Sp. dama-juana (as if
Dama Juana); mod.Pr., in different dialects, dama-jana, damajano,
damojano, damejano, dabajano, debajano; Cat. damajana; Ital.
damigiana; mod. Arabic damajanah, damajanah, etc. in 19th c.
lexicons.

The current Eng. form is the result of popular perversion as in
`sparrow-grass'; the earlier demijan, demijean, approach more closely
to the Fr. and Romanic, whence the word was adopted. The original
nationality and etymology of the word are disputed: see Rev. A. L.
Mayhew in Academy 14 Oct. 1893. Some have assumed the Arabic to be
the source of the Romanic forms, and have sought to explain this as of
Persian origin, and derived from the name of the town Damghan or
Damaghan , a commercial emporium S.E. of the Caspian. But
this is not supported by any historical evidence; moreover, the word
does not occur in Persian dictionaries, nor in Arabic lexicons before
the 19th c., and the unfixedness of its form (damijanah, damajanah,
damajanah, damanjanah) points, in the opinion of Arabic scholars, to
its recent adoption from some foreign language, probably from
Levantine use of Ital. damigiana. Assuming the word to be Romanic,
some have taken the Provencal and Catalan forms as the starting-point,
and conjectured for these either a L. type *dimidiana from
dimidium half (Alart in Rev. Lang. Rom. Jan. 1877), or the phrase de
mediana of middle or mean (size) (in illustration of which Darmesteter
cites from a 13th c. tariff of Narbonne the phrase `ampolas de mieja
megeira' = L. ampullas de media mensura). But these suggestions fail
to explain the initial da--prevalent in all the langs.; on account of
which M. Paul Meyer (like Littre) thinks that all the Romanic forms
are simply adaptations or transliterations of the French, this being
simply Dame Jeanne `Dame Jane', as a popular appellation (cf.
Bellarmine, greybeard, etc.). This is also most in accordance with
the historical evidence at present known, since the word occurs in
French in the 17th c., while no trace of it equally early has been
found elsewhere.]

Nulldogma

unread,
May 3, 1996, 3:00:00 AM5/3/96
to

>One thing that really galls me when I'm playing a game is being forced
>to replay a large section because I missed a small detail many scenes
>back. This happened to me in Trinity so many times that I still
>haven't gotten around to finishing it. In fact, last time I played, I
>used a walkthrough, and *still* managed to screw up. I'm sure most
>players dislike this as much as I do.

Yes! Yes! I played through 90% of Trinity before I realized I needed those
!@%^!%^&# breadcrumbs!* I finally started over from scratch, but still
haven't even gotten back up to where I was the first time...

My suggestion for avoiding this are three-fold: 1) Let the player go back
to earlier parts of the game as much as possible; 2) Make sure that
getting stuck only requires going back and replaying a small part of the
game (if I'd only played 10% of Trinity, I wouldn't have been so annoyed);
and 3) use TADS, which supports multiple undo.

Neil

*That's not a spoiler, BTW; they're at the very beginning of the game, and
ever player should be warned that you need to take them.

Kenneth Fair

unread,
May 4, 1996, 3:00:00 AM5/4/96
to

In article <4me1l8$r...@nntp4.u.washington.edu>, mam...@u.washington.edu
(Matthew Amster-Burton) wrote:

>kjf...@midway.uchicago.edu (Kenneth Fair) wrote:
>
>>Though I have yet to figure out what a "demijohn" is.
>
>(Oh, boy, are you going to hate me.)
>
>demijohn
>
>A large bottle with bulging body and narrow neck, holding from 3 to 10
>(or, in extreme cases, 2 to 15) gallons, and usually cased in wicker-
>or rush-work, with one or two handles of the same, for convenience of
>transport.

[etc.]

Actually, that was pretty interesting. And more comprehensive than
my New Shorter OED version. (I don't know WHY I didn't check that first!)

--
KEN FAIR - U. Chicago Law | Power Mac! | Net since '90 | Net.cop
kjf...@midway.uchicago.edu | CABAL(tm) Member | I'm w/in McQ - R U?

"Next to being witty yourself, the best thing is to quote
another's wit." - C.N. Bovee

Mark J Tilford

unread,
May 4, 1996, 3:00:00 AM5/4/96
to

Matthew Amster-Burton (mam...@u.washington.edu) wrote:
: One thing that really galls me when I'm playing a game is being forced

: to replay a large section because I missed a small detail many scenes
: back. This happened to me in Trinity so many times that I still
: haven't gotten around to finishing it. In fact, last time I played, I
: used a walkthrough, and *still* managed to screw up. I'm sure most
: players dislike this as much as I do.

: I can think of a couple of ways to deal with this situation, from the


: designer's point of view. (A way to deal with this situation from the
: *player's* point of view is to make a stuffed doll in the image of the
: author and throw it off a pier.)

: 1. Make it impossible to get stuck. This is the tack taken by the

<snip>

: 2. Give stern warnings when the player is about to do something that
: will get her stuck. This seems mostly unworkable, unless you have

: designed your game so there are only a few, obviously stupid,
: things to do to end up in a corner. ("Stimpy, press the
: history-eraser button" is probably a bad idea, for example.
: Maybe.)

Regarding this point, what would happen in a position where the character
would recognize something as being dangerous, but the player may not?
... Can't think of an example of it now...


<snip>

Den of Iniquity

unread,
May 5, 1996, 3:00:00 AM5/5/96
to

On Thu, 2 May 1996, Matthew Amster-Burton wrote:

> One thing that really galls me when I'm playing a game is being forced
> to replay a large section because I missed a small detail many scenes
> back.

[snip]
> 1. Make it impossible to get stuck...[snip]


> 2. Give stern warnings when the player is about to do something that

> will get her stuck. [snippety-snip]
> 3. Don't do anything about it [snip]

The LucasArts games are a good example - but there 'getting stuck' means
something else. Monkey Island was very enjoyable and although you
couldn't get irrevocably stuck you could become extremely annoyed because
you didn't know what to do to move the plot on a bit more. I seem to
remember having serious trouble at one or two points, and of course the
whole 'never die' thing gave the rubber-tree joke much more impact - I
hadn't saved the game in a very long time and when the "You have died"
message appeared on the screen my heart sank very heavily - for a moment.

I thought of another possibilty - which reflects the way we have to
tackle problems in life. When you try to do something in life and
things get 'fubar', then sometimes, as with games, that's it, you'll
never achieve certain goals. In a game you restart or restore, in life
you settle, disappointed, for less points. But more often in life, there's
another way to do it - only it's much more difficult. And if that doesn't
work, then there's an even more problematic solution that could take some
time. Suppose you come home and the door is (as it should be) locked...


a) Did I remember to bring my key?

if not: b) Did I stick a spare key under the window-sill (or similar
hiding place)?

if not: c) Did I leave a spare key with the neighbours (and are they in)?

if not: d) Are any unlocked windows on the ground floor that I can open
and climb through?

if not: e) How about the upper floor(s) (and is there an easily accessible
ladder or other means to scale the wall)?

if not: f) Can I break in quietly and doing as little damage as possible...

And so on. Obviously this could go much further. (z: persuade the
policewoman (with talk of drug-smugglers) to break into the neighbours'
house for you so you can get your spare key without being arrested...)
Maybe not a good example for an adventure but this is the kind of
reasoning I have in mind.

So I propose

4. Provide increasingly complex alternative solutions to the problem.

Difficult to provide lots of alternatives for every problem but then you
only need provide them until such a point as the adventure is technically
impossible to fail at... Even if solving one puzzle - without, say, the
frying pan you threw into the volcano and the marzipan gnome which you ate
to stave off your growing hunger - is extremely difficult.

The result is an adventure in which you might get quite far before finding
the going very tough, but when you restart you find that satiating Vulcan
with the marzipan gnome instead of the pan allows you to make some
pancakes later in the game and suddenly opens all kinds of new
possibilities.

Den

John Ruschmeyer

unread,
May 5, 1996, 3:00:00 AM5/5/96
to

In article <4mbbps$o...@lll-winken.llnl.gov>,
Kathleen Fischer <kfis...@greenhouse.llnl.gov> wrote:

>mam...@u.washington.edu (Matthew Amster-Burton) wrote:
>>One thing that really galls me when I'm playing a game is being forced
>>to replay a large section because I missed a small detail many scenes
>>back. This happened to me in Trinity so many times that I still
>>haven't gotten around to finishing it. In fact, last time I played, I
>>used a walkthrough, and *still* managed to screw up. I'm sure most
>>players dislike this as much as I do.
>
>That depends on how small a detail (how many times it happens) and wether
>or not I can fix it...

I can empathize with this one and am *really* beginning to hate Steve Meretsky
games for this reason.

>If I can't board the ferry boat because I didn't pick up the quarter I saw
>on in front of the bank (20 rooms back) then, well, I'm screwed and
>I accept that as part of the game. So long as the quarter is still then when I
>return (and the ferry still there when I get back), no problem.

This reminds me of my least favorite puzzle in HHGttG. My first time through
I got almost to the end before realizing that I had needed to feed the dog
back on earth (in the opening moves of the game). Very frustrating, particularly
in that the Douglas Adams humor really did not give you a clue that you
had not make a mistake.

>If I can't board the ferry boat because I didn't think to put the banana on the
>ground and the day old newspaper over the grate and wait by the bank for 3
>turns until the drunken bum walks by and slips... (and since he has already
>walked by the bank I'm out of luck) then I will probably not play the game
>again.

OTOH, this sounds like a puzzle straight out of LGOP. I still want to know how
I should know, when I'm on the spaceship, that I should proceed to the airlock
with all due haste.

Personally, I prefer much less "dependant" puzzles, like the afore-mentioned
ferry, where I can go back and "correct" my actions.

<<<john>>>
--
John Ruschmeyer jrus...@csc.com
Computer Sciences Corp.
Eatontown, NJ 07724 908-542-8383

Christopher E. Forman

unread,
May 5, 1996, 3:00:00 AM5/5/96
to

John Ruschmeyer <jrus...@csc.com> wrote:
: >>One thing that really galls me when I'm playing a game is being forced
: >>to replay a large section because I missed a small detail many scenes
: >>back. This happened to me in Trinity so many times that I still
: >>haven't gotten around to finishing it. In fact, last time I played, I
: >>used a walkthrough, and *still* managed to screw up. I'm sure most
: >>players dislike this as much as I do.
:
: I can empathize with this one and am *really* beginning to hate Steve Meretsky
: games for this reason.

Actually, Brian Moriarty wrote "Trinity."

: This reminds me of my least favorite puzzle in HHGttG. My first time through


: I got almost to the end before realizing that I had needed to feed the dog
: back on earth (in the opening moves of the game). Very frustrating, particular

: in that the Douglas Adams humor really did not give you a clue that you


: had not make a mistake.

There's another chance to feed the dog - as Ford. Of course, it's always
possible to overlook that as well.

: OTOH, this sounds like a puzzle straight out of LGOP. I still want to know how


: I should know, when I'm on the spaceship, that I should proceed to the airlock
: with all due haste.

If you examine the ship's porthole (or look through it), you'll see that
the other ship is about to leave. Obscure, but Meretzky must've though it
worked.

George E Caswell

unread,
May 6, 1996, 3:00:00 AM5/6/96
to

On 5 May 1996, John Ruschmeyer wrote:

>
> >If I can't board the ferry boat because I didn't pick up the quarter I saw
> >on in front of the bank (20 rooms back) then, well, I'm screwed and
> >I accept that as part of the game. So long as the quarter is still then when I
> >return (and the ferry still there when I get back), no problem.
>

> This reminds me of my least favorite puzzle in HHGttG. My first time through
> I got almost to the end before realizing that I had needed to feed the dog

> back on earth (in the opening moves of the game). Very frustrating, particularly


> in that the Douglas Adams humor really did not give you a clue that you
> had not make a mistake.
>

You actually have -two- chances to feed the dog... and one can come
-after- you go to the space fleet.

IMHO, the games aren't -supposed- toe be EASY... there are a few
challenges. It's not purely IF, it's a GAME. Zork was a game, it was a
game made for people logged in to a mainframe to waste time (working on,
-or- playing) That's why it included things like player damage, the thief
and troll- things to make the game a bit unpredictable. If you want
something EASY, watch TV. (Well, given what's -on-, that might -not- be
easy if you have low tolerance for shit... <g>)

>
> OTOH, this sounds like a puzzle straight out of LGOP. I still want to know how
> I should know, when I'm on the spaceship, that I should proceed to the airlock
> with all due haste.
>

Time waits for no man... I don't remember if anything spells it out
for you...

T I M B U K T U
________________ _/>_ _______
<___ ___________// __/<___ /
// <> _____ <_ > / ____/
// /> / / __/ / / <___________
// </ </</</ <_ _/ <_____________/
</ </


Richard G Clegg

unread,
May 6, 1996, 3:00:00 AM5/6/96
to

John Ruschmeyer (jrus...@csc.com) wrote:

(MINOR LGOP spoilers)

: OTOH, this sounds like a puzzle straight out of LGOP. I still want to know how


: I should know, when I'm on the spaceship, that I should proceed to the airlock
: with all due haste.

Well, it's a spaceship and someone else is on-board and has just run
away - where the heck else are they going to go?

IMHO the only reason I (like you) didn't think of it either is because
we're so used to adventures where

`With a flash X appears, does action Y and vanishes'

i.e. characters run on stage and off again only to have vanished utterly
and never be seen again. Perhaps this should be considered a
"crime against mimesis" (unless a reasonable explanation for the character's
total disappearance can be given).

--
Richard G. Clegg There ain't no getting round getting round
Dept. of Mathematics (Network Control group) Uni. of York.
email: ric...@manor.york.ac.uk
www: http://manor.york.ac.uk/top.html


Richard G Clegg

unread,
May 6, 1996, 3:00:00 AM5/6/96
to

Matthew Amster-Burton (mam...@u.washington.edu) wrote:
: 1. Make it impossible to get stuck. This is the tack taken by the
: LucasArts games, i.e. Day of the Tentacle, Sam n' Max. The
: only text game I can think of off the top of my head that works
: this way is Perdition's Flames, and I haven't played it, only
: heard about it.

My problem with a game where you can't get stuck is that every
action is a "right action" - even if something seems wildly incorrect,
you know that it's the correct thing to do if you can't reverse it.
For example, in Stationfall, I'm currently weighing up whether to
purchase the large drill bit or the timer - I have no idea which is
the right purchase (well, actually, I think ?I have a pretty good idea).
I assume that if I make the wrong purchase I'm stuck. On the other hand,
if it were an "unstickable" game then this just wouldn't be a problem.

Admittedly I do find it VERY annoying when you get stuck in a game
for failing to perform a trivial action near the start.

I do like LucasArts games but I find the "if you can do it, it is the
correct thing to do" attitude means that they're only difficult when they're
deliberately obscure (or include f****g arcade sequences).

L.J. Wischik

unread,
May 6, 1996, 3:00:00 AM5/6/96
to

Kenneth Fair <kjf...@midway.uchicago.edu> wrote:
>Though I have yet to figure out what a "demijohn" is.

A particular shape of wine bottle container thing, named after it's shape.

O
.-'-.
'.'.'
.:::.
':':'
: :
' '

--
Lucian

John Elliott

unread,
May 7, 1996, 3:00:00 AM5/7/96
to

In article <4mbdit$1r...@thor.cmp.ilstu.edu>, Christopher E. Forman (cef...@rs6000.cmp.ilstu.edu) wrote:
: Matthew Amster-Burton <mam...@u.washington.edu> wrote:
: : being allowed to f*ck up.
^^^^

: Real adventurers do not use such language.
: (Sorry, had to say it. B-)

Try playing The Very Big Cave Adventure...

>SWEAR

You are in the Swear Box.

It is a bare room with neither windows nor doors.

In one corner is a washstand and a cake of soap.

You know what to do.

[followups set]

-------------------- http://users.ox.ac.uk/~sjoh0132/ ---------------------
John Elliott |BLOODNOK: "But why have you got such a long face?"
|SEAGOON: "Heavy dentures, Sir!" - The Goon Show
:-------------------------------------------------------------------------)

Phil Goetz

unread,
May 8, 1996, 3:00:00 AM5/8/96
to

> My problem with a game where you can't get stuck is that every
>action is a "right action" - even if something seems wildly incorrect,
>you know that it's the correct thing to do if you can't reverse it.
>For example, in Stationfall, I'm currently weighing up whether to
>purchase the large drill bit or the timer - I have no idea which is
>the right purchase (well, actually, I think ?I have a pretty good idea).
>I assume that if I make the wrong purchase I'm stuck. On the other hand,
>if it were an "unstickable" game then this just wouldn't be a problem.
>
>Richard G. Clegg There ain't no getting round getting round

I don't have a problem with this. For me the fun of a puzzle
is not in selecting one action from a set of obvious actions,
but in the sudden creative spark when I think of a non-obvious action.


Phil Go...@cs.buffalo.edu

Marnix Klooster

unread,
May 9, 1996, 3:00:00 AM5/9/96
to

Hello all,

In article <4mb79c$6...@nntp4.u.washington.edu>,


Matthew Amster-Burton <mam...@u.washington.edu> wrote:
>One thing that really galls me when I'm playing a game is being forced
>to replay a large section because I missed a small detail many scenes
>back. This happened to me in Trinity so many times that I still
>haven't gotten around to finishing it. In fact, last time I played, I
>used a walkthrough, and *still* managed to screw up. I'm sure most
>players dislike this as much as I do.
>

>I can think of a couple of ways to deal with this situation, from the
>designer's point of view. (A way to deal with this situation from the
>*player's* point of view is to make a stuffed doll in the image of the
>author and throw it off a pier.)

>1. Make it impossible to get stuck.


>2. Give stern warnings when the player is about to do something that
> will get her stuck.

>3. Don't do anything about it

[I snipped the explanations and discussions of these options.]

I offer a fourth option: Create an I-F reader (i.e. an alternative to
ZIP, Frotz, the TADS runtime, and others) which allows you to easily
alter any decision taken, offering a way to explore alternate paths,
doing away with the need to save & restore at critical moments. No
changes would be needed to the stories themselves; it might even make
playing Weather a pleasure !-) I've been toying with the idea to write
something like that (for the Z-machine, i.e. Infocom/Inform games),
but lack of time has prevented me from even beginning.

>Matthew

Greetings,

<><
Marnix


--
Marnix Klooster
kloo...@dutiba.twi.tudelft.nl

rich...@msi-uk.com

unread,
May 10, 1996, 3:00:00 AM5/10/96
to

In article <4mssj9$7...@mo6.rc.tudelft.nl>, kloo...@dutiag.twi.tudelft.nl says...

>In article <4mb79c$6...@nntp4.u.washington.edu>,
>Matthew Amster-Burton <mam...@u.washington.edu> wrote:
>>One thing that really galls me when I'm playing a game is being forced
>>to replay a large section because I missed a small detail many scenes
>>back.
>>
>>I can think of a couple of ways to deal with this situation, from the
>>designer's point of view. (A way to deal with this situation from the
>>*player's* point of view is to make a stuffed doll in the image of the
>>author and throw it off a pier.)
>
>>1. Make it impossible to get stuck.
>>2. Give stern warnings when the player is about to do something that
>> will get her stuck.
>>3. Don't do anything about it
>
>[I snipped the explanations and discussions of these options.]
>
>I offer a fourth option: Create an I-F reader (i.e. an alternative to
>ZIP, Frotz, the TADS runtime, and others) which allows you to easily
>alter any decision taken, offering a way to explore alternate paths,
>doing away with the need to save & restore at critical moments. No
>changes would be needed to the stories themselves; it might even make
>playing Weather a pleasure !-) I've been toying with the idea to write
>something like that (for the Z-machine, i.e. Infocom/Inform games),
>but lack of time has prevented me from even beginning.

this must be the `many worlds' interpretation of interactive fiction!
all we need is a version of zip which calls fork() before processing each
user command & discards the command in the child.

-- richard

--

-------------------------------------------------------------------------------
richard barnett rich...@msi-uk.com
-------------------------------------------------------------------------------

Magnus Olsson

unread,
May 10, 1996, 3:00:00 AM5/10/96
to

In article <4mssj9$7...@mo6.rc.tudelft.nl>,

Marnix Klooster <kloo...@dutiag.twi.tudelft.nl> wrote:
>I offer a fourth option: Create an I-F reader (i.e. an alternative to
>ZIP, Frotz, the TADS runtime, and others) which allows you to easily
>alter any decision taken, offering a way to explore alternate paths,
>doing away with the need to save & restore at critical moments. No
>changes would be needed to the stories themselves; it might even make
>playing Weather a pleasure !-) I've been toying with the idea to write
>something like that (for the Z-machine, i.e. Infocom/Inform games),
>but lack of time has prevented me from even beginning.

Hmmm. I'm not sure I understand exactly what you're intending to do, but
such an IF reader sounds like a pretty tall order to me.

You can't simply be referring to unlimeted "UNDO" capability, since
TADS already has that, and undoing things a move at a time gets pretty
tedious if you want to undo more than just a few moves. Personally, I
find that I get lost very quickly - if I dropped something ten moves
ago, and want to undo that, I'm never quite certain whether I've typed
"undo" nine or eleven times.

So I suppose you must be after the more ambitious goal of letting the
player undo _any_ action, not just the last one.

Let's consider a scenario: in move 456, I find a pen. I use it to
draw mustaches on all portraits I see, including the big painting of
Dimwit Flathead the Excessive (move 788) and the Flathead portrait on
a ten-zorkmid banknote (move 898) which I then hand over to a shopkeeper
(move 1213) who is so amused by my vandalism that he gives me some candy
(move 1214).

However, in move 6712, I discover that the pen was an enchanted object and
that moving it has angered my ancestral spirits. So I decide to undo my
taking the pen on move 456.

However, undoing that move means not just that the pen is moved back
to where it was before, but that the portrait is restored to its original
state, as is the banknote, that I don't get the candy, and, of course,
that my ancestral spirits don't get angry at me.

This very simple example shows that undoing one action can cause a lot of
seemingly unrelated changes to take place. How are you going to take
care of that?

Or will you opt for the simpler solution of undoing *everything* that
happened after move 456? But that is equivalent to saving after
*every* move. Of course, instead of creating an enormous number of
almost identical save files, one could reduce redundancy, perhaps only
saving the _changes_ in game state (which, BTW, is a solution used by
some Web-based adventures). But there would still be a lot of saved
information.

And there's a user interface problem as well: how do I tell the
interpreter that I want to go back to the state the game was in before
I took the pen? Or before I took the pen for the second time? Or
before I shouted "Boo" at my infirm great-uncle, thereby causing his
demise 69 moves later?


I'm sorry for being a wet blanket, but I can't really see how you
could implement such an IF reader. It would of course be very exciting
if you could, so if you have any ideas, please share them.

--
Magnus Olsson (m...@df.lth.se)

Nulldogma

unread,
May 13, 1996, 3:00:00 AM5/13/96
to

>Or will you opt for the simpler solution of undoing *everything* that
>happened after move 456? But that is equivalent to saving after
>*every* move. Of course, instead of creating an enormous number of
>almost identical save files, one could reduce redundancy, perhaps only
>saving the _changes_ in game state (which, BTW, is a solution used by
>some Web-based adventures). But there would still be a lot of saved
>information.

Isn't this essentially what TADS does, with multiple undo?

I suppose you could enhance this even more by letting the player indicate
how many turns they'd like to undo ("UNDO 20" would be the equivalent of
typing "UNDO" 20 times). I'd be more interested in getting Inform to
support multiple undo in the first place, though. (This isn't in v.6 by
any chance, is it?)

Neil

Matthew Amster-Burton

unread,
May 13, 1996, 3:00:00 AM5/13/96
to

null...@aol.com (Nulldogma) wrote:

>I suppose you could enhance this even more by letting the player indicate
>how many turns they'd like to undo ("UNDO 20" would be the equivalent of
>typing "UNDO" 20 times). I'd be more interested in getting Inform to
>support multiple undo in the first place, though. (This isn't in v.6 by
>any chance, is it?)

It's in WorldClass, if I remember right.

Trevor Barrie

unread,
May 13, 1996, 3:00:00 AM5/13/96
to

m...@marvin.df.lth.se (Magnus Olsson) wrote:

>You can't simply be referring to unlimeted "UNDO" capability, since
>TADS already has that, and undoing things a move at a time gets pretty
>tedious if you want to undo more than just a few moves. Personally, I
>find that I get lost very quickly - if I dropped something ten moves
>ago, and want to undo that, I'm never quite certain whether I've typed
>"undo" nine or eleven times.

Well, in games done under Worldclass you could just say "undo 10", but
I'm not sure if that's included in standard TADS.

I think this is pretty much the same functionality that he was talking
about, but with a nice interface.


Andrew C. Plotkin

unread,
May 14, 1996, 3:00:00 AM5/14/96
to

null...@aol.com (Nulldogma) writes:
> I'd be more interested in getting Inform to
> support multiple undo in the first place, though. (This isn't in v.6 by
> any chance, is it?)

No, every version of the Z-machine spec specifies single undo. It
would be easy enough to change this, but it would be an interpreter
change. I think some interpreters already have it, though.

The Inform library has a flag to prevent multiple undo attempts;
that's what prints the "Can't ~undo~ twice in succession. Sorry!"
message. That's easy enough to change if you're writing a game,
though. (The aforementioned interpreters don't run into this because
their multiple undo function is invoked by an interface command (menu
or hotkey), as opposed to player typing "undo". This potentially
breaks puzzles, of course, but I think we had that discussion last
year.)

Either way, this is not something that needs support from the Inform
compiler.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."

Andrew C. Plotkin

unread,
May 14, 1996, 3:00:00 AM5/14/96
to

>Or will you opt for the simpler solution of undoing *everything* that
>happened after move 456? But that is equivalent to saving after
>*every* move. Of course, instead of creating an enormous number of
>almost identical save files, one could reduce redundancy, perhaps only
>saving the _changes_ in game state (which, BTW, is a solution used by
>some Web-based adventures). But there would still be a lot of saved
>information.

It could be done better, but it would require more cooperation between
the game and the interpreter. Let the game specify a plot graph, more
or less equivalent to the plot diagrams we all love. Whenever the game
decides that the player has reached a new node, it signals the
interpreter to do a "save". At any time, the player can call up a
picture of the graph (or as much of it as he has reached). If he
clicks on a node, the game restores to the saved game associated with
that node.

It's up to the game (ie, the game programmer) to ensure that all
microstates within the node are essentially equivalent. Picking up or
dropping the sword wouldn't change your node. This means that if you,
for example, click "back" one node in the plot graph, you may find
some trivial changes -- the sword is on the ground, even though you
never dropped the sword during this particular game session. (This
would be because the *first* time you played to that node, you had
dropped the sword, so that's what's in the node save.)

To simplify things, complicated action sequences (like fights) are
outside of all nodes. You're on one node before the fight, a second if
you win, a third if you lose. During the fight you're in the hazy
wasteland between the three, and no node saving is performed. This is
correct from the player's point of view; the plot graph shows that you
can click to before or after the fight, but there's no point to
clicking to the middle of the fight.

This could probably be implemented in TADS right now. The only barrier
to implementing it in Inform is the lack of file manipulation; the
Z-machine can't save to several different files without prompting the
user for a name for each. Nor can it open an arbitrary file from a
stored filename; it has to prompt for a file to open. I think.

Marnix Klooster

unread,
May 14, 1996, 3:00:00 AM5/14/96
to

In article <4mvvmg$i...@news.lth.se>, Magnus Olsson
<m...@marvin.df.lth.se> replied to the following ramblings of mine:

>>I offer a fourth option: Create an I-F reader (i.e. an alternative to
>>ZIP, Frotz, the TADS runtime, and others) which allows you to easily
>>alter any decision taken, offering a way to explore alternate paths,
>>doing away with the need to save & restore at critical moments. No
>>changes would be needed to the stories themselves; it might even make
>>playing Weather a pleasure !-) I've been toying with the idea to write
>>something like that (for the Z-machine, i.e. Infocom/Inform games),
>>but lack of time has prevented me from even beginning.

Magnus said:

>Hmmm. I'm not sure I understand exactly what you're intending to do, but
>such an IF reader sounds like a pretty tall order to me.
>

>You can't simply be referring to unlimeted "UNDO" capability, since

[snipped...]


>So I suppose you must be after the more ambitious goal of letting the
>player undo _any_ action, not just the last one.

Correct. Let me try to express my thoughts a bit clearer. The key
idea is that interaction with a work of I-F (e.g. in Inform or TADS)
can be viewed as a `decision tree'. At certain points, the user
chooses a path by entering a command, or pressing a key. (Note that
in this view the "UNDO" command is a command just like all others; it
is one of the choices a player can make, if the piece of I-F
understands it.)

In most I-F readers (e.g. ZIP and the TADS runtime), the user can only
go forward in the decision tree. But for example in Frotz, one can
press a special key (ALT-U, I think), and move one step _back_ in the
tree. (This feature enables one to undo a move even in .z3 games,
which have no "UNDO" command.) In Frotz the number of steps that can
be undone is only limited by the amount of RAM available. I propose
an extension of this idea, with the following properties:

* The decision tree is stored completely, containing all decisions
made by the user. (The user can cut away parts of the tree,
indicating that those decisions will never be redone, e.g. because
of typing mistakes.)
* The number of steps that can be undone is only limited by the amount
of _storage_ available: data can be stored on disk too.
* Undoing a step results in exactly the state the game was in before
the decision was taken, including the screen. (Frotz does not take
the screen back to its previous state, but instead prints the
current location as a reminder to the user.)
* After undoing one or more steps, the user can `redo' commands that
were undone earlier. In other words, at any point in the decision
tree the user can choose from a list of decisions made earlier at
that point. (Of course, the user can also try out a new decision.)
* At any time, the user can view the list of decisions that lead to
the current state. By editing this list, the user can try out
alternative decisions. (Changing, inserting, or removing a command
in this list generally forces replaying of all subsequent moves,
which costs a lot of computing power. The user might have to change
later commands too: removing the "GET PEN" command from Magnus's
example make later "DRAW MOUSTACHE ON PAINTING" commands result in
"But you have nothing to draw with!". My point is, however, that
the replaying can be done automatically. It is the user's
responsibility that later commands still make sense.)

In summary, I propose to maintain a history that contains all the ways
in which a piece of I-F has been read. The advantage is clear: the
user has more control, without depending on author-supplied undo
mechanisms. This aids replayability, replacing the useful but crude
save-and-restore mechanism.

Magnus continues with a small example showing how removing an
arbitrary command can get one into trouble, and concludes:

>This very simple example shows that undoing one action can cause a lot of
>seemingly unrelated changes to take place. How are you going to take
>care of that?

As explained above, the computer takes care of the replaying, and the
user must make sure that later commands still have the desired effect.

>Or will you opt for the simpler solution of undoing *everything* that
>happened after move 456? But that is equivalent to saving after
>*every* move. Of course, instead of creating an enormous number of
>almost identical save files, one could reduce redundancy, perhaps only
>saving the _changes_ in game state (which, BTW, is a solution used by
>some Web-based adventures). But there would still be a lot of saved
>information.

Essentially, my proposal is not to save the _game state_ after every
move, but to store all _moves_. This is enough, since the state after
a move can be reconstructed from the initial state and all moves up to
that point. Whether the state of the game after every move is to be
stored is an (admittedly important) implementation detail, on which
more below.

A note on randomness. As the proverbial astute reader might have
noticed, here I assume that a reading of a piece of I-F is completely
determined by the user's decisions. This is not true in the case of
random numbers, because then the system makes a decision. This is
easily incorporated in the above view, by also storing system
decisions in the decision tree. Such decisions will normally not be
seen by the user, and only be made the first time that decision point
is reached.

>And there's a user interface problem as well: how do I tell the
>interpreter that I want to go back to the state the game was in before
>I took the pen? Or before I took the pen for the second time? Or
>before I shouted "Boo" at my infirm great-uncle, thereby causing his
>demise 69 moves later?

As will probably be clear from the above, this is done simply by
performing enough undo steps, or by choosing a move from the list of
commands that led up to this situation.


The ideas set out above are _concepts_, disregarding how these might
be transformed into an _efficient implementation_. (Maybe that is why
I consider myself to be a mathematician working in the area of
computer science, instead of a computer scientist doing mathematics
:-) Therefore, here are a few thoughts on implementation.

* Only a limited number of games states needs to be stored. For
example, one could store after every tenth move, plus after the last
ten moves. (Other states can be reconstructed from these by
replaying the user's decisions.) In addition, the user can indicate
that the current state will probably be returned to, in which case
it probably should be stored. [Aside. It might be useful to have a
Z-machine instruction (with no effect on the game state) which
indicates that something drastic is happening, so that the user is
likely to undo the latest move. This removes the need for questions
such as: "If you really want to jump off of this skyscraper, you
probably also want to SAVE the game. Am I correct (y/n)?"]
* A state should be stored efficiently, probably by storing the
differences w.r.t. a previous or later state. (This is similar to
Frotz and other interpreters storing `saved games' as differences
w.r.t. the initial state.)
* For speed, the most recent game states should be in memory, and the
others on disk.
* It _might_ be possible to simplify treatment of commands that have a
very small effect on the game state. For example, the only game
effects of the "LOOK" and "INVENTORY" commands are usually the
printing of some text, and incrementing the moves counter. Thus
adding or removing such a command has only minor effects on
subsequent commands. Except, of course, when the later commands
depend on the number of moves, or on the current cursor position.
Fortunately this happens seldomly, and perhaps these cases can be
identified automatically.

I'm sure there are other optimizations possible. Together, they might
make it possible to create an efficient implementation. I suffer from
lack of time; any takers?

>I'm sorry for being a wet blanket, but I can't really see how you
>could implement such an IF reader. It would of course be very exciting
>if you could, so if you have any ideas, please share them.

I hope I made my ideas a bit clearer in this post.

>--
>Magnus Olsson (m...@df.lth.se)

PAZ SALGADO

unread,
May 14, 1996, 3:00:00 AM5/14/96
to

Marnix Klooster (kloo...@dutiag.twi.tudelft.nl) wrote:
: Correct. Let me try to express my thoughts a bit clearer. The key

: idea is that interaction with a work of I-F (e.g. in Inform or TADS)
: can be viewed as a `decision tree'. At certain points, the user
: chooses a path by entering a command, or pressing a key. (Note that
: in this view the "UNDO" command is a command just like all others; it
: is one of the choices a player can make, if the piece of I-F
: understands it.)

I'm really terrified because of the idea. I can't see an I-F as a
*decision tree*. This kind of adventures are very linear and bored, without
life. In my adventures it may be easier to save the whole world state
than the player and computer decision, because of my dozens of NPCs
decision by each player decision.

This kind of life make sense on I-F against graphical adventures.Please,
don't think puzzles-like-IFs! Make NPCs lifes!


Meliton Rodriguez, from 115 room


Mark Green

unread,
May 14, 1996, 3:00:00 AM5/14/96
to

In article <4mvvmg$i...@news.lth.se> m...@marvin.df.lth.se "Magnus Olsson" writes:
>
> Let's consider a scenario: in move 456, I find a pen. I use it to
> draw mustaches on all portraits I see, including the big painting of
> Dimwit Flathead the Excessive (move 788) and the Flathead portrait on
> a ten-zorkmid banknote (move 898) which I then hand over to a shopkeeper
> (move 1213) who is so amused by my vandalism that he gives me some candy
> (move 1214).
> However, in move 6712, I discover that the pen was an enchanted object and
> that moving it has angered my ancestral spirits. So I decide to undo my
> taking the pen on move 456.

Plus, there's the old time-paradox problem:

>GET PEN
Taken.

>DRAW MOUSTACHE ON PORTRAIT
Done.

>UNDO GET PEN
Undoing core: "Get Pen."
Undoing consequence: "Draw Moustache on Portrait."
Undoing consequence: "Undo Get Pen."
Command undone during execution, abandoning.

>INVENTORY
You have a pen.

Mg
--

Joseph Strout

unread,
May 15, 1996, 3:00:00 AM5/15/96
to

On 14 May 1996, PAZ SALGADO wrote:

> Marnix Klooster (kloo...@dutiag.twi.tudelft.nl) wrote:
> : can be viewed as a `decision tree'. At certain points, the user


> : chooses a path by entering a command, or pressing a key. (Note that
>

> I'm really terrified because of the idea. I can't see an I-F as a
> *decision tree*. This kind of adventures are very linear and bored, without
> life. In my adventures it may be easier to save the whole world state
> than the player and computer decision, because of my dozens of NPCs
> decision by each player decision.

No, you could always completely reproduce the state of the game from the
starting state (including random number seed) and the player's
conditions. Just run the game exactly as you did before, but take the
player's actions from the file (or whatever) instead of the keyboard, and
surpress the output.

Still, I agree with your general sentiment: I-F shouldn't be a tree to
explore at will, backwards and forwards. That creates too much
detachment from the characters. Why should I care if my character gets
killed, when I can just magically turn back time and do something else?
The I-F-like games which get me most involved in the character have
always been MUDs, where you spend a lot of time developing your
character, and if you get killed it's *at least* a serious setback.
There's no save/restore and no undo.

Now, this might be a little too harsh for a normal interactive-puzzle
game. But you should still limit the "undoability" quite a bit, I
think. This could be done in various ways:

1. Only allow SAVEs at certain places in the game.
2. Make a RESTORE take a while (as it would anyway if it's replaying the
entire game up to that point), so that you'd rather not have to do it.
3. Have no SAVE/RESTORE, but just QUIT/RESUME which always goes back to
the last position played. (This would be a little hard to enforce
nowadays, but play along...) Then:
a. Have no permanent bad endings such as deaths or unsolvable traps,
and have instead serious (but recoverable) setbacks.
b. Allow a limited number of deaths, which reset you to some point.

In fact, these are not new ideas -- (1) is used by "Doom"-like games and
many graphical adventure games; and (3b) is the old "three lives" of
video games. The point is to make it important to you not to do
something stupid; to make you feel anguish when your character dies, and
triumph when it succeeds.

If you have the godlike power to travel backwards and forwards through
time, then where's the anguish and triumph?

,------------------------------------------------------------------.
| Joseph J. Strout Department of Neuroscience, UCSD |
| jst...@ucsd.edu http://www-acs.ucsd.edu/~jstrout/ |
`------------------------------------------------------------------'


Mark J Tilford

unread,
May 16, 1996, 3:00:00 AM5/16/96
to

Mark Green (Ma...@antelope.demon.co.uk) wrote:

: In article <4mvvmg$i...@news.lth.se> m...@marvin.df.lth.se "Magnus Olsson" writes:
: >
: > Let's consider a scenario: in move 456, I find a pen. I use it to
: > draw mustaches on all portraits I see, including the big painting of
: > Dimwit Flathead the Excessive (move 788) and the Flathead portrait on
: > a ten-zorkmid banknote (move 898) which I then hand over to a shopkeeper
: > (move 1213) who is so amused by my vandalism that he gives me some candy
: > (move 1214).
: > However, in move 6712, I discover that the pen was an enchanted object and
: > that moving it has angered my ancestral spirits. So I decide to undo my
: > taking the pen on move 456.

: Plus, there's the old time-paradox problem:

: >GET PEN
: Taken.

: >DRAW MOUSTACHE ON PORTRAIT
: Done.

: >UNDO GET PEN
: Undoing core: "Get Pen."
: Undoing consequence: "Draw Moustache on Portrait."

Being type meta, UNDO GET PEN would not be affected by undoing.

: Undoing consequence: "Undo Get Pen."


: Command undone during execution, abandoning.

: >INVENTORY
: You have a pen.

: Mg
: --

--

Mark J. Tilford

mjti...@artsci.wustl.edu

Kevin Bracey

unread,
May 17, 1996, 3:00:00 AM5/17/96
to

>I suppose you could enhance this even more by letting the player indicate
>how many turns they'd like to undo ("UNDO 20" would be the equivalent of
>typing "UNDO" 20 times). I'd be more interested in getting Inform to

>support multiple undo in the first place, though. (This isn't in v.6 by
>any chance, is it?)

Multiple UNDO can be implemented purely in the interpreter - Zip 2000 and
Frotz support it. This works for the Infocom games, but unfortunately
the Inform library won't let you UNDO twice in succession. If this was
fixed it would work fine. (Frotz gets around this by having a hotkey - but
that allows you to undo in places where a game author might not want you
to, so I haven't implemented this in Zip 2000).

Just deleting a couple of lines from the Inform library would do the trick
nicely. (It says something like "if (just_undone) "You can't undo twice
in succession."").

Kevin
=====

Marnix Klooster

unread,
May 20, 1996, 3:00:00 AM5/20/96
to

In article <Pine.SGI.3.91.960515080457.11196B-100000@golgi>,

Joseph Strout <jst...@ucsd.edu> wrote:
>On 14 May 1996, PAZ SALGADO wrote:
>
>> Marnix Klooster (kloo...@dutiag.twi.tudelft.nl) wrote:
>> : can be viewed as a `decision tree'. At certain points, the user

>> : chooses a path by entering a command, or pressing a key. (Note that
>>
>> I'm really terrified because of the idea. I can't see an I-F as a
>> *decision tree*. This kind of adventures are very linear and bored, without
>> life.

Paz left out an essential part of the first sentence quoted: I said
that the _interaction_ with a work of I-F can be viewed as a decision
tree. I have said nothing about the structure of the game itself,
which can be highly non-linear.

>> In my adventures it may be easier to save the whole world state
>> than the player and computer decision, because of my dozens of NPCs
>> decision by each player decision.
>
>No, you could always completely reproduce the state of the game from the
>starting state (including random number seed) and the player's
>conditions. Just run the game exactly as you did before, but take the
>player's actions from the file (or whatever) instead of the keyboard, and
>surpress the output.

As I have tried to explain in my earlier post, these are
implementation issues. My main point was that it is _possible_ to
create an I-F reader program (i.e., an interpreter) that gives the
player much more freedom in exploring the game.

>Still, I agree with your general sentiment: I-F shouldn't be a tree to
>explore at will, backwards and forwards. That creates too much
>detachment from the characters. Why should I care if my character gets
>killed, when I can just magically turn back time and do something else?
>The I-F-like games which get me most involved in the character have
>always been MUDs, where you spend a lot of time developing your
>character, and if you get killed it's *at least* a serious setback.
>There's no save/restore and no undo.

This is a new argument in the discussion: Joseph basically says it is
*not right* to create an I-F reader as I proposed, because it would
create an artificial distance between player and character. If I
understand him correctly, he implies that going back in a story (using
e.g. SAVE/RESTORE) is generally not right, but that it is inevitable
if the player has run into a dead end (e.g. by getting killed).

Does going back in time really create `too much detachment'? I don't
know, and since an I-F reader as I proposed does not yet exist, nobody
knows. That is one of the reasons I would like to create one. Let me
make three more remarks.

In my experience, SAVE/RESTORE does indeed diminish the involvement,
but not because I go back in time. The problem is that for any game I
have a number of saved games, and if I continue to play a game after a
month's interruption, I forgot the details about these games: did I
press button X 45 moves ago in this saved game, or didn't I? Thus the
problem with SAVE/RESTORE is not going back in time, but all the
administration involved. By letting the interpreter manage the entire
decision tree, this problem can be solved.

Also, there are games with a high Zarfian cruelty rate: games where
every move could lead you into a dead end, and you would only notice
23 moves later. I would like to try out weather my proposed
interpreter would change the way I play such games. (Any comments,
Andrew?)

Finally, the general concensus is that one of features valued highly
in a work of I-F is replayability. My proposed interpreter would give
a player much more freedom in this respect. For instance, after
finishing a game I am told that there was a button hidden halfway; if
I had pressed it, the game would have proceeded quite differently.
But unfortunately, I have done no SAVE before reaching the button
location, so I have to replay all moves up to that point by hand. At
this point it would be nice to have an interpreter that allows me to
go back in time, and try out other decisions.

Summing up, I simply see my proposed interpreter as more convenient
than existing ones.

>Now, this might be a little too harsh for a normal interactive-puzzle
>game. But you should still limit the "undoability" quite a bit, I
>think. This could be done in various ways:
>
>1. Only allow SAVEs at certain places in the game.
>2. Make a RESTORE take a while (as it would anyway if it's replaying the
>entire game up to that point), so that you'd rather not have to do it.
>3. Have no SAVE/RESTORE, but just QUIT/RESUME which always goes back to
>the last position played. (This would be a little hard to enforce
>nowadays, but play along...) Then:
> a. Have no permanent bad endings such as deaths or unsolvable traps,
> and have instead serious (but recoverable) setbacks.
> b. Allow a limited number of deaths, which reset you to some point.
>
>In fact, these are not new ideas -- (1) is used by "Doom"-like games and
>many graphical adventure games; and (3b) is the old "three lives" of
>video games.

Some remarks:
1. It is of course possible to have the game tell the interpreter
to which points the user is allowed to go back.
2. This seems a bit silly to me. (Note that `replaying the entire
game' is what happens conceptually; an interpreter might have a
very efficient way to do it.)
3. It is not easy to create a game without dead ends.

> The point is to make it important to you not to do
>something stupid; to make you feel anguish when your character dies, and
>triumph when it succeeds.
>If you have the godlike power to travel backwards and forwards through
>time, then where's the anguish and triumph?

There is still anguish if it turns out I did something stupid 100
moves ago, but I feel yet more anguish if that forces me to another
100 moves to correct it. Especially if it didn't seem so stupid at
the time, as in the Trinity breadcrums example.

Basically, my position is this: give a player the freedom to explore
the game as she or he wishes.

>,------------------------------------------------------------------.
>| Joseph J. Strout Department of Neuroscience, UCSD |
>| jst...@ucsd.edu http://www-acs.ucsd.edu/~jstrout/ |
>`------------------------------------------------------------------'

Humbly opinionated,

Andrew C. Plotkin

unread,
May 20, 1996, 3:00:00 AM5/20/96
to

kloo...@dutiag.twi.tudelft.nl (Marnix Klooster) writes:
> In my experience, SAVE/RESTORE does indeed diminish the involvement,
> but not because I go back in time. The problem is that for any game I
> have a number of saved games, and if I continue to play a game after a
> month's interruption, I forgot the details about these games: did I
> press button X 45 moves ago in this saved game, or didn't I? Thus the
> problem with SAVE/RESTORE is not going back in time, but all the
> administration involved. By letting the interpreter manage the entire
> decision tree, this problem can be solved.
>
> Also, there are games with a high Zarfian cruelty rate: games where
> every move could lead you into a dead end, and you would only notice
> 23 moves later. I would like to try out weather my proposed
> interpreter would change the way I play such games. (Any comments,
> Andrew?)

My comment is "Sure." :-)

I like cruel games, or even just games where I have several branches
of plot to explore, with significant interactions. (Spiritwrak is an
example; it does make some difference which order you explore in,
although it's not nearly as critical and failure-prone as Weather.)
But, mentally, I treat it as a decision tree. I have lots of saved
games, mostly at root nodes, and I tend to explore various options
deeply, return to a root-node save, explore another option deeply...
etc. (An "option" may be a plot branch, or a particular order of
several plot branches, if there's lots of complicated interaction.)

Now, I'm good at keeping track of what's in what saved game, and I can
type fast. So effectively, I already have one of these flexible
interpreters. (And that's why I'm willing to write that kind of game.)
But it would be nice to let the machine take care of the paperwork.

Magnus Olsson

unread,
May 20, 1996, 3:00:00 AM5/20/96
to

In article <4npefc$n...@mo6.rc.tudelft.nl>,

Marnix Klooster <kloo...@dutiag.twi.tudelft.nl> wrote:
>In article <Pine.SGI.3.91.960515080457.11196B-100000@golgi>,
>Joseph Strout <jst...@ucsd.edu> wrote:
>>Still, I agree with your general sentiment: I-F shouldn't be a tree to
>>explore at will, backwards and forwards. That creates too much
>>detachment from the characters. Why should I care if my character gets
>>killed, when I can just magically turn back time and do something else?
>>The I-F-like games which get me most involved in the character have
>>always been MUDs, where you spend a lot of time developing your
>>character, and if you get killed it's *at least* a serious setback.
>>There's no save/restore and no undo.
>
>This is a new argument in the discussion: Joseph basically says it is
>*not right* to create an I-F reader as I proposed, because it would
>create an artificial distance between player and character. If I
>understand him correctly, he implies that going back in a story (using
>e.g. SAVE/RESTORE) is generally not right, but that it is inevitable
>if the player has run into a dead end (e.g. by getting killed).

It is obvious that SAVE/RESTORE, as well as UNDO, are crimes against
mimesis. Come to think of it, so is RESTART (albeit to a lesser
degree). In real life, you don't get the option to restart your life
if something goes wrong.

But these commands are very convenient. I think the vast majority of IF
players are prepared to sacrifice mimesis to that small extent when
the alternative is to have to play the entire game in one sitting,
with no possibility of correcting even a stupid typo. Imagine playing
"A Change in the Weather" without save/restore...

It is interesting that the very first piece of IF, "ADVENT", had
restricitions on SAVE/RESTORE: you were only allowed to have one save
file, and some versions imposed a time delay before you could restart
the game after a save (I imagine this was more to save system
resources than to achieve mimesis, though).

Very few works of IF indeed have followed this example.

Personally, I think not allowing SAVE/RESTORE because you won't allow
your readers to distance themselves from your work is an evil thing to
do. If you can't achieve mimesis with your writing, you can't do it by
forcing the reader to play the entire game in one sitting. You'd only
get a lot of frustrated users.

Of course, if the *user* thinks that SAVE/RESTORE/UNDO is undesirable,
he or she is free not to use those functions. However, I think that
this should be up to the user. Authors shouldn't force users to read
their works in any specific way.

Of course, there are exceptions, and they are more acceptable the more
limited they are. For example, I'd find it perfectly acceptable to
disallow saving in certain situations (like in the middle of a fight).
However, disallowing saving altogether would be akin to posting guards
in a theatre to prevent the audience from leaving before the play is
finished - if the audience likes the play they won't leave, and if
they don't, keeping them there by force won't make them like it.

--
Magnus Olsson (m...@df.lth.se)

Matthew Daly

unread,
May 20, 1996, 3:00:00 AM5/20/96
to

m...@marvin.df.lth.se (Magnus Olsson) writes:
>It is obvious that SAVE/RESTORE, as well as UNDO, are crimes against
>mimesis. Come to think of it, so is RESTART (albeit to a lesser
>degree). In real life, you don't get the option to restart your life
>if something goes wrong.

Coming soon to a store near you ... single-run IF! Nah, I don't
see it catching on.... ;-)

I always thought that it would be amusing to rewrite the prolog to
Enchanter to say something like "Belboz calls you and says 'You
don't know many spells, but you have one extraordinary power ...
the ability to always make the most fortuitous decision when
given a choice, as if you learn from the mistakes you make in
alternate realities!'"

>But these commands are very convenient. I think the vast majority of IF
>players are prepared to sacrifice mimesis to that small extent when
>the alternative is to have to play the entire game in one sitting,
>with no possibility of correcting even a stupid typo.

Well, if the stupid typo is "GRT TREASURE" then there should be
no problem. If it's "KILL FROG" when you meant to say "KISS FROG",
then your point is taken.

I don't know about an entire game. But I might be satisfied to
save before each "scene", if an author chose to define a work in
that way. (I'm thinking specifically of the scenes in Spellcasting
101 here.)

>Personally, I think not allowing SAVE/RESTORE because you won't allow
>your readers to distance themselves from your work is an evil thing to
>do. If you can't achieve mimesis with your writing, you can't do it by
>forcing the reader to play the entire game in one sitting. You'd only
>get a lot of frustrated users.

There is an example in the 3-D action game arena, for those of
you who are familiar with that. Perhaps the major difference between
Dark Forces and other games like Doom and Heretic is that you cannot
save your DF game in the middle of a mission. Instead, you are
given three lives and there are "extra life" tokens spread throughout
the levels. Opinions are varied and usually strong on both sides,
but I think it adheres more closely to an "action mimesis". When
I play Doom, for better or worse, I save the game after every two
steps or one shot, whichever comes first. It's all well and good
to say "Well, don't play it that way", but I think it was designed
to play that way. OTOH, in Dark Forces you really do have to hug the
walls and engage in sniper tactics more than Doom, because if you mess
up the previous 20 minutes of work will be for naught.

>Of course, if the *user* thinks that SAVE/RESTORE/UNDO is undesirable,
>he or she is free not to use those functions. However, I think that
>this should be up to the user. Authors shouldn't force users to read
>their works in any specific way.

Well, this also requires work on the author's part. To give an
example, you _cannot_ get past the glass maze puzzle in Sorcerer
without mapping it, and you cannot map it without the SAVE/RESTORE
feature. To be true to mimesis, I think that a puzzle has to be
solvable by someone with an unnatural sense of intuition but no
concrete knowledge aforehand.

>Of course, there are exceptions, and they are more acceptable the more
>limited they are. For example, I'd find it perfectly acceptable to
>disallow saving in certain situations (like in the middle of a fight).
>However, disallowing saving altogether would be akin to posting guards
>in a theatre to prevent the audience from leaving before the play is
>finished - if the audience likes the play they won't leave, and if
>they don't, keeping them there by force won't make them like it.

In general, I'd like to see a reduction of puzzles that require
knowledge that the character doesn't have, and a lessening of closely
timed puzzles in general. Furthermore, it's nice to see games like
Zork Nemesis where you have to work really hard to die or otherwise
paint yourself into a corner that you can't get out of. Not that
I don't enjoy games where my character is constantly risking his
life, but it's hard to get that far into them because there is
obviously no such risk that's going on in my part of the experience.

-Matthew


John Elliott

unread,
May 20, 1996, 3:00:00 AM5/20/96
to

In article <4npue7$5...@news.lth.se>, Magnus Olsson (m...@marvin.df.lth.se) wrote:
: It is interesting that the very first piece of IF, "ADVENT", had

: restricitions on SAVE/RESTORE: you were only allowed to have one save
: file, and some versions imposed a time delay before you could restart
: the game after a save (I imagine this was more to save system
: resources than to achieve mimesis, though).

The 550-point CP/M version of ADVENT deletes the save file after a RESTORE.
I can't imagine that's for the purposes of saving system resources. Of
course, all you have to do is make a copy of the save file.

Roger Giner-Sorolla

unread,
May 21, 1996, 3:00:00 AM5/21/96
to

Regarding Save/Undo/etc., as I pointed out in "Crimes" pt. 4, the ability
to restart the game and play it over from scratch is a necessary
departure from simulation, in any game. So, Save/Restore and Undo are
merely conveniences that spare the player having to do everything over
again in sequence.

Roger Giner-Sorolla
New York University
Department of Psychology (S/P)
6 Washington Place 7th floor
New York, NY 10003
tel. (212) 998-7833
fax (212) 995-4018


John Francis

unread,
May 21, 1996, 3:00:00 AM5/21/96
to

John Elliott wrote:
>
> In article <4npue7$5...@news.lth.se>, Magnus Olsson (m...@marvin.df.lth.se) wrote:
> : It is interesting that the very first piece of IF, "ADVENT", had
> : restricitions on SAVE/RESTORE: you were only allowed to have one save
> : file, and some versions imposed a time delay before you could restart
> : the game after a save (I imagine this was more to save system
> : resources than to achieve mimesis, though).
>
> The 550-point CP/M version of ADVENT deletes the save file after a RESTORE.
> I can't imagine that's for the purposes of saving system resources. Of
> course, all you have to do is make a copy of the save file.

Which, on the original (mainframe) version of much I-F, didn't work.
It was only when these games got ported to personal PCs that it
became possible to have multiple save files. Before then it
really was single-run IF (unless you had a kind game administrator).
Cracking the save copy-protection was a common diversion for many of us.

Greg Ewing

unread,
May 27, 1996, 3:00:00 AM5/27/96
to

John Francis wrote:
> Cracking the save copy-protection was a common diversion for many of us.

I remember once coming up with a rather hairy method of re-using
Rogue save files on a Unix system, which involved copying the
file, waiting for Rogue to delete the original file, and then
copying it back very quickly in the hope that the inode just
freed would be re-allocated to it. It actually worked, most
of the time!

Greg

Reply all
Reply to author
Forward
0 new messages