What words to use and recognize

38 views
Skip to first unread message

Andrew D. Jewell

unread,
Dec 15, 1992, 1:57:29 PM12/15/92
to
I would like to hereby assert the Two Fundamental Laws of Parsing

The First Law of Parsing :

Any word displayed by the game should be recognized by the parser.

The Second Law of Parsing :

One should be able to "win" the game using only words displayed
by the game.

(Both of these could conceivably be checked at compile time.)

At first glance there is nothing new here. If the games says "there is a red
book here" you know to use the words "red" and "book" to refer to it, and if
a game follows the First Law of Parsing, you can even ask
>IS THERE A RED BOOK HERE
and get a reasonable response.

Any of you who agreed with the Second Law of Parsing should realize
that it does not limit the words to nouns and adjectives. Thus to comply
with the Second Law, the game must display all verbs and adverbs needed
to "win" the game. (Yes, I include adverbs. They increase the power and
flexibility of commands, and don't create any problems that verbs haven't
already created.)

I have no idea how to make this work well.

A good start might include :

>EXAMINE BOOK
It looks like a perfectly ordinary red book to me.

>WHAT CAN I DO WITH THE RED BOOK
One can read, open, close or throw a book.

>HOW CAN ONE OPEN A BOOK
One can open gently or strongly.

>LIST VERBS
>LIST ADVERBS
>LIST NOUNS
...

But these do nothing to help fulfill the Second Law

Here's a really bad attempt :

>EXAMINE BOOK
It looks like a perfectly ordinary red book to me, the kind that opens on
the right.

>OPEN BOOK
You gently open the book, as if starting to read. If you closed it more
strongly, it might rip.

So the question is :
How can we inform users WITHIN THE CONTEXT OF THE GAME of the verbs and
adverbs available to them. To force players to think about the right thing
to DO while freeing them from thoughts about the right thing to SAY.


Andy Jewell
avj...@cfar.umd.edu

John Francis

unread,
Dec 15, 1992, 5:27:09 PM12/15/92
to
In article <62...@mimsy.umd.edu> avjewe@.umd.edu (Andrew D. Jewell) writes:
>I would like to hereby assert the Two Fundamental Laws of Parsing
>
>The First Law of Parsing :
>
> Any word displayed by the game should be recognized by the parser.
>
>The Second Law of Parsing :
>
> One should be able to "win" the game using only words displayed
> by the game.

[ . . . . . .]

>So the question is :
>How can we inform users WITHIN THE CONTEXT OF THE GAME of the verbs and
>adverbs available to them. To force players to think about the right thing
>to DO while freeing them from thoughts about the right thing to SAY.
>

I agree with the first law as an ideal. Most of the complaints my wife has
about Infocom games boil down to the fact that the game does not let her use
adjectives (or even object names) contained in the long descriptions of the
locations and items she finds.

For your question, however: I don't think that letting the user know what
adverbs are available is a laudable goal. This is because I don't think
that adverbs are a desirable addition to game syntax. In my opinion, any
sentence requirements more complicated than

"Put coal, red book and firelighter in the large brass scuttle"

is going to turn playing the game into an extremely frustrating case of
"guess how the game programmer wants you to express the concept". It's
hard enough already to decide what to do - you don't need to add in the
extra complication of adverbs. Displaying a list of available words (as
is done in the Legend Spellcasting games) solves the problem presented
in your "Second Law", but this is not the major problem many of these
games exhibit. What is far more important is that any & all reasonable
paraphrasings of the desired concept will work. I wasted a lot of time
on one particular problem in "Spellcasting 201" because I thought I had
tried everything. My wife breezed through that particular problem with
no difficulty because she expressed basically the same idea, only using
slightly different wording. Her phrasing worked; mine didn't.

Finally, I would like to add one further suggestion. The solutions to
puzzles in the game should be suggested, however obliquely, by the game
itself. I gave up on Dave Baggett's UU2 because although the solutions
(given in the walkthrough) to several of the puzzles were each in and of
themselves reasonable [from the viewpoint of an omniscient observer],
there was no indication or hint in the game to steer you towards that
particular solution. I don't particularly like guessing games (be it
"guess the word" or "guess the concept"). In fact, for a long while I
felt that the "right" solution to the cyclops problem in mainframe Zork
was unfair because there was nothing in the game that suggested this as
a way of solving the problem, and there were hints steering you towards
the "wrong" solution of feeding him. (It was the "wrong" solution because
you wouldn't get the extra 25 points, but there would be no indication
that there was anything else you needed to do). Eventually somebody
showed me that there was, in fact, an obscure hint to the right solution.
--
John Francis jo...@apollo.hp.com
with 9 cats to feed, I don't have time to think up a clever .sig

Karen Silkwood's car

unread,
Dec 15, 1992, 5:48:05 PM12/15/92
to

avjewe@.umd.edu (Andrew D. Jewell) writes:
>The First Law of Parsing :
> Any word displayed by the game should be recognized by the parser.

until parsers make great strides i think this is going to remain fairly
impossible.

>The Second Law of Parsing :
> One should be able to "win" the game using only words displayed
> by the game.

this is just dumb. it means you have to give away the solution more or less
implicitly in every game you write. for example: suppose there's a rope
that you have to swing on to cross a ravine. why would you ever need to
mention the word "swing" in describing it? it just gives away the answer.
i'd prefer to let the player think of possible things that you can do with
ropes (tie stuff to them, swing on them, cut them off and use them to fasten
other stuff down...)

>(Yes, I include adverbs. They increase the power and
>flexibility of commands, and don't create any problems that verbs haven't
>already created.)

i think adverbs are a bad idea. this discussion has already been hashed out
pretty thoroughly on r.a.int-fiction. how are you going to know that you
have to enter "PULL HARD ON LEVER" instead of just "PULL ON LEVER"?

>>HOW CAN ONE OPEN A BOOK
>One can open gently or strongly.

to me, this just adds a completely unnecessary level of detail to the game.
you're going to be going around asking the game for every possible nuance of
every possible object. i think this would detract from the experience,
rather than enhance it.

>How can we inform users WITHIN THE CONTEXT OF THE GAME of the verbs and
>adverbs available to them. To force players to think about the right thing
>to DO while freeing them from thoughts about the right thing to SAY.

i say don't bother. it's already hard enough guessing which sentence
permutation is accepted without adding another variable to the equation.
i want "slide card through slot" to be enough. "slide card quickly through
slot" doesn't make for an enjoyable game in my book.

--
Jon Drukman (God's personal DJ) uunet!sco!jondr jo...@sco.com
-------------------------------------------------------------------------------
I was an infinitely hot and dense dot.

Russell L. Bryan

unread,
Dec 15, 1992, 6:48:07 PM12/15/92
to
I quote from Michael J. Robert's manual for TADS, the section "Writing
Better Adventures" :

A certain number of verbs will work on pretty much any object in an
adventure game; for example: take, drop, open, close, examine, put an
object in (or on) another object, give object to a character. All games
have these verbs. Now, imagine writing a game with only these verbs, plus
one more special verb: "use....."

.....It may appear that limiting your verbs in this manner makes puzzles
too
obvious, since the player doesn't have to think of the actual thing to do
with
an object, but can just "use" it and have the game figure out what to do.
In
fact, it encourages you, the designer, to choose objects that have exactly
one very obvious use; doing so means that the "use" verb detracts nothing
from the puzzle, since it's obvious that you push a button and turn a
knob,
and that you'd do nothing else with them. Hence, this forces you to avoid
obsucre verbs that apply to just one object as you choose your puzzles.

--

While I do not advocate limiting a parser to the verb "use," the article
does bring up a good point. Our job as designers is not to fool the
player.
You say you want to use adverbs, but do you want adverbs to be a necessary
part of the game? If so, then will the player always have to try to guess
in what MANNER he is supposed to do something? If not, then the parser
will
merely ignore the adverb anyway -- why bother?

The only possible use of an adverb would be if you were trying to do
something
which ran against the obvious way something is done. Say, perhaps, that
there was a monster in your game with poor eyesight who knows to attack
only
because something moves quickly across his field of vision. Then, "Go
west
slowly" might be appropriate.

I stress that ONLY in extreme cases such as this should adverbs be used.
If
you DO use adverbs, I strongly recommend that you include adverbs in your
example vocabulary list. In general, I'd say don't use them at all. If
the troll is keeping an eye on the chicken, I sure as hell am not going to
take the chicken "slowly," or "casually," or "daintily." I'm gonna grab
the damn thing and take off.

-- Russ

Andrew D. Jewell

unread,
Dec 16, 1992, 11:24:44 AM12/16/92
to
Before this gets any more out of hand, let me take back my "adverb"
comment. I will keep adverbs as my own private perversion, and renounce
them publicly.

I am still interested in opinions about how to let the player know what
words (especially verbs) are available without giving away the puzzles.
But, please, no more adverb bashing (or promoting for that matter).

The two primary problems I'm trying to solve are

a) I want to HANG from the rope, but the game doesn't know the word HANG.

b) The game wants me to DANGLE from the rope, but the word DANGLE
does not come to mind.

Andy Jewell
avj...@cfar.umd.edu

The Grim Reaper

unread,
Dec 16, 1992, 12:03:18 PM12/16/92
to


I'd still say the best way to do it is to give the verb in the item
description-

>LOOK AT ROPE
The rope is long and somewhat frayed at the ends.
>TIE ROPE TO HOOK
You tie the rope to the hook in the ceiling
>LOOK AT ROPE
The rope is long and somewhat frayed at the ends. It's tied to
a hook in the ceiling, reinding you of those Tarzan movies
where he goes around swinging and hanging from the vines to
rescue the girl.

David Whitten

unread,
Dec 16, 1992, 12:19:57 PM12/16/92
to
avj...@cfar.umd.edu (Andrew D. Jewell) writes:
>I am still interested in opinions about how to let the player know what
>words (especially verbs) are available without giving away the puzzles.
>
>The two primary problems I'm trying to solve are
>
>a) I want to HANG from the rope, but the game doesn't know the word HANG.
>
>b) The game wants me to DANGLE from the rope, but the word DANGLE
>does not come to mind.

This strikes me as another example of needing the game to provide subtle
hints. What immediately comes to mind is:

1] Common (among IF developers) agreement upon a dictionary - synonym list.
(This would help all of us to provide bigger vocabularies that are consistent
among the games we create)

2] Providing a description (in some nearby room possibly) that has something
dangling from a rope. Something like:

You're in a dank dark dungeon with an exceptionally high ceiling. Something
swinging slowly catches your eye deep in dark recesses of room.

>LOOK UP

You see a skeleton dangling from a rope, far out of your reach. Dust falls
from above, causing your eyes to blink with tears.

>GO NORTH

This option allows the reader to notice something that might give a subtle
hint, but isn't part of the description of the room, so they don't have to
see it when they enter, and have the AHA! experience later when they need
to use the rope.

Comments?
Dave (whi...@fwva.saic.com) US:(619)535-7764 [I don't speak as a company rep.]

Magnus Olsson

unread,
Dec 19, 1992, 8:23:52 AM12/19/92
to
In article <BzFA1...@world.std.com> t...@world.std.com (Tom O Breton) writes:
>Magnus:
>
>> What's the point of a puzzle where the solution is to find a new use for
>> some everyday object if you can just ask the game and get a complete list
>> of all possible ways to use the object in question.
>
>Hope you don't mind if I respond by quoting myself, but:
>
>"Where 'command CUP' would be a catchall for command words that you
>deliberately withheld from a player. (Presumably providing some clever way to
>discover them)"
>
>If you, say, wanted to make use of the cup to safely snuff a candle flame,
>and the player is supposed to cleverly realize this can happen, you might use
>this.

Yes, I suppose it might be a good idea to be able to say "USE CUP ON
CANDLE" in this situation. [Historical footnote: to save space, my
first adventure game (a re-creation of which is available as
pub/Misc/atomia.zoo from leif.thep.lu.se) actually only supported the
verbs TAKE, DROP, LOOK, WHERE (to describe one's surroundings),
INVENTORY and USE, as well as the movement commands.]

However, there's a disadvantage to this: suppose the player wants to
use the cup to collect some molten candlewax, types USE CUP ON CANDLE,
and to his/her surprise finds out that this snuffs the candle instead.
Personally, I *hate* it when you're trying to do one thing and the
game decides that it know better than you and does something
different...


>The idea is that
>
> 0: it only happens when the author *realizes* that they're putting forth a
> puzzle, not when the author didn't think of something.
>
> 1: The player knows that there's a puzzle there, thus distinguishing it
> from (unavoidable) similar-looking problems whose "solving" isn't part
> of the game.
>
> (IE, parser stupidity, unforeseen-and-unsupported actions, and
> unsupported vocabulary.)
>

Sorry, I didn't get that. I thought the reason for having these
"general-purpose verbs" was to provide a workaround for parser
stupidity.

>I picture a player coming up with half-a-dozen odd-but-plausible things to
>tell the cup before the parser understands "snuff candle with CUP". It's
>still mixing up "Can you solve my clever puzzle?" with "What have I supported
>in my stupid parser?", but at least it's fairer than blind guessing.

IMHO an adventure that requires bad guessing is badly written. If the
author wants the user to use the cup to snuff the candle, then it's
the author's responsibility to make the game recognize all resonable
semantics, like "PUT CUP OVER CANDLE" and things like that. Of course,
this requires *extensive* play testing, but so do many other aspects
of adventure games.

>> An adventure game should of course not be a "guess the correct verb" game,
>> but IMHO what every game designer should work _very hard_ to make all
>> puzzles so "intuitive" that it's possible for the player to express the
>> needed action in a very simple sentence, with everyday words (of course the
>> game should accept all reasonable synonyms and alternative wordings).
>
>Again quoting he-whom-I-admire-most:
>
>"there is no way an IF writer can truly support all the uses a player can
>think of (I can think of at least a hundred things a brick might be used
>for);"

Indeed; but please note that I wrote "all *needed* actions". You can
do a hundred things with a brick, and the game can't possibly support
all of them (we're talking about games, not real-world simulations)
but if the game requires you to do one thing and one thing only with
the brick, it should also understand all *reasonable* ways of
expressing this. If there are 769 ways of expressing or doing this,
then IMHO the puzzle needs some reconstruction to make the solution
more unique.


>However hard a designer works, I expect that within a *minute* I can find
>something I can do in real life that the game does not support (Barring
>extraordinary dodges such as a spartan setting to specifically defeat this)

Of course, but let me stress again that we're talking about *games*,
not artificial worlds (which seem to be an AI-complete problem).

>I would much rather play a game that used a 'sensible default' mechanism like
>this than one whose author worked "really really hard" to support synonyms.

And I wouldn't. De gustibus non est disputandum.

>> An adventure game should of course not be a "guess the correct verb" game,
>
>It goes beyond mere VERBS. All too often, it comes to a question not of
>solving the puzzle, but of guessing which way of solving it is *supported*.

Yes, but then the game is badly written.

>I recall someone describing a puzzle where one had to get past laser beams by
>clapping an eraser so that you could see the beams outlined in the dust.
>
>Clever? Yes, but you also have to *GUESS* that this functionality is
>implemented, whereas other functionalities such as
>
> sweeping dust instead up from the floor,
> improvising a mirror,
> improvising an ablative shield that would hold for the few seconds
> required,
> holding something disposable before you as you go as a 'mine detector',
> etc,
>
> are not. (Nor could one reasonably expect all such creative solutions to be
> supported)


I haven't played that game myself, but here's what I'd do if I were to
write such a puzzle:

1. Make sure the player gets the information that the erasers are
chalky (for example, when he/she examines them).

2. When the player manipulates the dusters in other ways, they should
give off a lot of chalk dust.

3. Sweeping dust up from the floor should work *if there is any dust
in the game*., but it needn't do that. BTW, you need quite a lot of
dust to create a cloud, and it's not unreasonable to assume that hte
rooms aren't *that* dusty.

4. Improvising a mirror requires reflective material. If there isn't
any in the game, there's no need to support such a solution.

5. If the laser beams are merely *detectors*, rather than death-rays
(again, I haven't palyed the game myself), ablative shields or
disposable objects won't help - the detectors will still be triggered.


*BUT* if a problem is such that there are scores of possible solutions
inside the game, then it's of course very bad only to allow one of
them.

An adventure writer simply needs to work so hard on the game's
internal consistency that there aren't any logical holes in it. And
the game must be play tested by people who have keen eyes for internal
logic.


Magnus Olsson | \e+ /_
Department of Theoretical Physics | \ Z / q
University of Lund, Sweden | >----<
mag...@thep.lu.se, the...@seldc52.bitnet | / \===== g
PGP key available via finger or on request | /e- \q

Karen Silkwood's car

unread,
Dec 16, 1992, 12:49:53 PM12/16/92
to

avjewe@.umd.edu (Andrew D. Jewell) writes:
>The two primary problems I'm trying to solve are
>a) I want to HANG from the rope, but the game doesn't know the word HANG.
>b) The game wants me to DANGLE from the rope, but the word DANGLE
>does not come to mind.

i think this is the sort of thing that should be caught in playtesting.
i've distributed a few copies of my adventure-in-progress with explicit
instructions to the testers - if you see something that you think you ought
to be able to do and the program doesn't understand the word - TELL ME! i
will fix it! really, you can't cover every possible base but hang should
definitely be a synonym for dangle in the game's vocabulary.

O.J.W. Betts

unread,
Dec 16, 1992, 1:31:23 PM12/16/92
to
In article <62...@mimsy.umd.edu>, avjewe@.umd.edu (Andrew D. Jewell) writes:
|> Before this gets any more out of hand, let me take back my "adverb"
|> comment. I will keep adverbs as my own private perversion, and renounce
|> them publicly.
|>
Personally, I'm against adverbs. If you must put them in, then I think the
message you get if you omit the adverb should give a strong hint as to what
you need to do.

There was a puzzle in Philosopher's Quest for the BBC Micro which had a sequence
of rooms with traps of spears and spikes which shot out of the wall at various
heights. So something like:

> N
A spear shoots out of the wall and hits you in the head. You die.

whereas:
> CRAWL N
A spear shoots out of the wall above you. It misses you.

I think there were four of these, two to cross to collect something and two
different ones coming back. I thought it was a fair puzzle, as the phrasing of
the messages provided a clue as to what to try.


|> I am still interested in opinions about how to let the player know what
|> words (especially verbs) are available without giving away the puzzles.
|> But, please, no more adverb bashing (or promoting for that matter).
|>
|> The two primary problems I'm trying to solve are
|>
|> a) I want to HANG from the rope, but the game doesn't know the word HANG.
|>
|> b) The game wants me to DANGLE from the rope, but the word DANGLE
|> does not come to mind.
|>

In my (mostly written but not finished) game, I used a thesaurus and put in all
the words that seemed appropriate. This means that dangle and hang would have
both gone in. Also, my approach when playing and the problem seems to be the
games vocabulary is to reach for the thesaurus - is this a common approach?

-- Olly Betts --

Tom O Breton

unread,
Dec 16, 1992, 5:36:18 PM12/16/92
to
I have one thing to add to the discussion:

Since it should generally be obvious to the character-in-the-fiction what
they can do with objects in the fictional world;

and since there is no way an IF writer can truly support all the uses a


player can think of (I can think of at least a hundred things a brick might
be used for);

I suggest that there be a standard verb (taking no game time) that describes
what things you can do with an object. Something like "WHAT_CAN_I_DO_WITH <X>"
(Anyone got a good 1-word synonym for 'what can I do with'?)

For example:

> WHAT CAN I DO WITH CUP?
You can use a CUP in these ways:
drop
pick up
give CUP to (X)
use
fill
drink from
command

Where 'command CUP' would be a catchall for command words that you
deliberately withheld from a player. (Presumably providing some clever way to
discover them)

BTW, please direct flames to the effect that "This takes away the mystery" to
/dev/null. A game where you don't know what you can do doesn't create
mystery, it creates boredom and gives text games a bad name. You can't create
mystery by default.

Tom

--
The Tom spreads its huge, scaly wings and soars into the wild sky...
up... up... out of sight... (t...@world.std.com)

Toby Paterson

unread,
Dec 16, 1992, 4:07:07 PM12/16/92
to
In article <1992Dec15....@starbase.trincoll.edu> Russell L. Bryan
<rbr...@Mail.trincoll.edu> writes:
> You say you want to use adverbs, but do you want adverbs to be a
necessary
> part of the game? If so, then will the player always have to try to
guess
> in what MANNER he is supposed to do something? If not, then the parser
> will
> merely ignore the adverb anyway -- why bother?
>
One of the elements I most enjoy about good IF adventures is the feel I
get from the game. It is possible, indeed, desirable for the game to
respond differently depending on how you perform an action; it all
contributes to the feel of the adventure. This is not to say that the
solution to an adventure should pivot around performing an action in one
particular manner. I agree that this is a bad thing for you are forcing
the player to try and second guess the author instead of participating in
an adventure. Of course, the game might have more than one solution, all
of which are equally valid, depending on how an action is performed at
some juncture in the game...

It would be nice to see more adventures get away from the "one solution
via one path (the author's path)" approach.

> If you DO use adverbs, I strongly recommend that you include adverbs in
your
> example vocabulary list. In general, I'd say don't use them at all. If
> the troll is keeping an eye on the chicken, I sure as hell am not going
to
> take the chicken "slowly," or "casually," or "daintily." I'm gonna grab
> the damn thing and take off.

Exactly. In situations like this, an appropriate adverb should be
"assumed" by the game unless explicitly overidden. For instance, grabbing
the chicken slowly might give the troll a chance to curse you and in so
doing provide a clue to a later puzzle in the adventure. Of course, you
would then have to fight the troll :-)

The game should also inform you of its choice of adverb - "You grab the
chicken quickly and beat a hasty retreat before the troll has a chance to
say anything."


> -- Russ
>

X

--
\\ / Who: Toby Paterson
\\/ How: tpat...@cs.ubc.ca, pate...@gdss.commerce.ubc.ca
//\ What: Grunt and NeXT hacker; GDSS Fellowship
// \ Where: University of British Columbia

Peter Weyhrauch

unread,
Dec 16, 1992, 5:53:54 PM12/16/92
to
Hi, all.

On the 15th of December, Jon Drukman comments on Andrew Jewell's post:

avjewe@.umd.edu (Andrew D. Jewell) writes:

>The First Law of Parsing :
> Any word displayed by the game should be recognized by the parser.

until parsers make great strides i think this is going to remain fairly
impossible.

I don't agree with this in the most general sense. There are a continuum
of options for the technologies of text generation and text understanding.
At one end you have human authors writing subtle and amusing prose that
no current computer can understand. I assume this is what Jon meant,
and I agree with him fully for that case. But, it leaves out the other
end of the spectrum. If you use a computer to generate your text, you
might be able to satisfy Andrew's First Law of Parsing.

A case in point is the Oz system. We currently generate all our
narrative text, and soon will generate character dialogue as well.
Since the same lexicon is used for generation and parsing, any word
used in generation is parseable. The grammars are currently
different, but encode (roughly) the same functionality. Notice that
you could use a more universal parser if you chose. The perhaps
unacceptable downside is that our output is uninspired for now. Part
of our research efforts are aimed at doing stylistic generation. For
your curiousity, I'll attach a fragment at the end of my post.

One of the issues we consider is whether our hard-line attitude is
warranted. Couldn't we rather do pre-canned text, enriching the
texture of the experience? We could, but I think the ultimate sense
of immersion in our worlds would then suffer. I have proposed, but
never implemented, though it would be simple, a concept of incidental
text, which is text that pops up on the screen at times, but is
considered officially outside the system. That way, at a climactic
moment, when the ordinary super-dry text just won't do, you can read a
rich description of the event. Perhaps with this you can get the best
of both worlds.

Peter Weyhrauch
Project Oz

Fragment of Oz output (Lyotard is a cat):

PLAYER> go to the bedrom

Correcting typos:
bedrom --> bedroom (deletion)

Tick 17...

You go to the east.
You are no longer located in the sunroom.
You are now located in the bedroom.

You are in the bedroom:

To the south, you see the closet door.
To the south, you see the closet.
To the west, you see the sunroom.
To the west, you see the red bedroom door.

Lyotard, the small liquor cabinet, the wicker trash basket, the
bed and the table are located in the bedroom. The small book and
the red superball are located in the under bed space. The white
brush and the black china cup are on the table.

Lyotard licks himself.

PLAYER> pet the cat

Tick 18...

You pet Lyotard.
Lyotard meows.
You hear a MEOW.

Neil K. Guy

unread,
Dec 17, 1992, 3:44:13 AM12/17/92
to
pw...@A.GP.CS.CMU.EDU (Peter Weyhrauch) writes:

>Correcting typos:
> bedrom --> bedroom (deletion)

This is an interesting touch. Handy, but might under some
circumstances lead to the game making assumptions that you don't want,
no?

>You go to the east.
>You are no longer located in the sunroom.
>You are now located in the bedroom.

>You are in the bedroom:
> To the south, you see the closet door.
> To the south, you see the closet.
> To the west, you see the sunroom.
> To the west, you see the red bedroom door.

I don't want to be rude, as I know nothing about the Oz project and
the state of your software development. (I don't doubt that it's very
innovative and ground-breaking.) But this is awful prose. I'm not
crazy about most text adventure prose to begin with, but I highly
doubt that I'd be willing to play a game that read like this. Any
pretenses toward literature are completely absent. Aren't there some
ways of making this repetitive, mechanical text a bit more human? Some
algorithm that can assemble options in a more readable fashion?

Again, I understand that this is a work in progress and that it's
probably somewhat limited now. Just my $0.02 worth.

>You pet Lyotard.
>Lyotard meows.
>You hear a MEOW.

Another thought. This is very redundant. I realize that it's
responding to an actor doing something (cat makes a meow sound) and
the game is also reporting an audible event. But shouldn't there be
filters so that only one event is reported? The way it's phrased makes
it sound like the cat meows, and then some disembodied voice says
"MEOW" in response...

- Neil K. (n_k...@sfu.ca)

(still totally in the dark as to what this Oz project is all about...)

Magnus Olsson

unread,
Dec 17, 1992, 11:39:44 AM12/17/92
to
In article <BzDIs...@world.std.com> t...@world.std.com (Tom O Breton) writes:
>I suggest that there be a standard verb (taking no game time) that describes
>what things you can do with an object. Something like "WHAT_CAN_I_DO_WITH <X>"
>(Anyone got a good 1-word synonym for 'what can I do with'?)
>
>For example:
>
>> WHAT CAN I DO WITH CUP?
>You can use a CUP in these ways:
> drop
> pick up
> give CUP to (X)
> use
> fill
> drink from
> command
>
>Where 'command CUP' would be a catchall for command words that you
>deliberately withheld from a player. (Presumably providing some clever way to
>discover them)
>
>BTW, please direct flames to the effect that "This takes away the mystery" to
>/dev/null.

This is not a flame, and I'm not going to argue that "this takes away
the mystery". I am going to argue that many puzzles will be spoiled by
this.

What's the point of a puzzle where the solution is to find a new use
for some everyday object if you can just ask the game and get a
complete list of all possible ways to use the object in question.


Actually, I'm getting a bit worried about the assumption in this
thread, that the game should actually list all possible actions. An


adventure game should of course not be a "guess the correct verb"
game, but IMHO what every game designer should work _very hard_ to
make all puzzles so "intuitive" that it's possible for the player to
express the needed action in a very simple sentence, with everyday
words (of course the game should accept all reasonable synonyms and
alternative wordings).

If the solution of a puzzle requires some very complicated commands,
with adverbs and whatever, then IMHO the puzzle is too complicated.
The way out of this problem is not to change the user interface, but
to re-think the puzzles.

>A game where you don't know what you can do doesn't create
>mystery, it creates boredom and gives text games a bad name. You can't create
>mystery by default.

I agree on this, though. Mystery is not the same thing as obscurity.

Tom O Breton

unread,
Dec 17, 1992, 4:22:14 PM12/17/92
to
Magnus:

> What's the point of a puzzle where the solution is to find a new use for
> some everyday object if you can just ask the game and get a complete list
> of all possible ways to use the object in question.

Hope you don't mind if I respond by quoting myself, but:

"Where 'command CUP' would be a catchall for command words that you


deliberately withheld from a player. (Presumably providing some clever way to
discover them)"

If you, say, wanted to make use of the cup to safely snuff a candle flame,


and the player is supposed to cleverly realize this can happen, you might use
this.

The idea is that

0: it only happens when the author *realizes* that they're putting forth a
puzzle, not when the author didn't think of something.

1: The player knows that there's a puzzle there, thus distinguishing it
from (unavoidable) similar-looking problems whose "solving" isn't part
of the game.

(IE, parser stupidity, unforeseen-and-unsupported actions, and
unsupported vocabulary.)

I picture a player coming up with half-a-dozen odd-but-plausible things to
tell the cup before the parser understands "snuff candle with CUP". It's
still mixing up "Can you solve my clever puzzle?" with "What have I supported
in my stupid parser?", but at least it's fairer than blind guessing.

> An adventure game should of course not be a "guess the correct verb" game,
> but IMHO what every game designer should work _very hard_ to make all
> puzzles so "intuitive" that it's possible for the player to express the
> needed action in a very simple sentence, with everyday words (of course the
> game should accept all reasonable synonyms and alternative wordings).

Again quoting he-whom-I-admire-most:

"there is no way an IF writer can truly support all the uses a player can
think of (I can think of at least a hundred things a brick might be used
for);"

However hard a designer works, I expect that within a *minute* I can find


something I can do in real life that the game does not support (Barring
extraordinary dodges such as a spartan setting to specifically defeat this)

I would much rather play a game that used a 'sensible default' mechanism like


this than one whose author worked "really really hard" to support synonyms.

> An adventure game should of course not be a "guess the correct verb" game,

It goes beyond mere VERBS. All too often, it comes to a question not of


solving the puzzle, but of guessing which way of solving it is *supported*.

I recall someone describing a puzzle where one had to get past laser beams by


clapping an eraser so that you could see the beams outlined in the dust.

Clever? Yes, but you also have to *GUESS* that this functionality is
implemented, whereas other functionalities such as

sweeping dust instead up from the floor,
improvising a mirror,
improvising an ablative shield that would hold for the few seconds
required,
holding something disposable before you as you go as a 'mine detector',
etc,

are not. (Nor could one reasonably expect all such creative solutions to be
supported)

Tom

David Whitten

unread,
Dec 17, 1992, 4:50:55 PM12/17/92
to
In message <1992Dec17.1...@pollux.lu.se> is written:

>In article <BzDIs...@world.std.com> t...@world.std.com (Tom O Breton) writes:
>>I suggest that there be a standard verb (taking no game time) that describes
>>what things you can do with an object. Something like "WHAT_CAN_I_DO_WITH <X>"
>>(Anyone got a good 1-word synonym for 'what can I do with'?)
>>
>>For example:
>>
>>> WHAT CAN I DO WITH CUP?
>>You can use a CUP in these ways:
>> drop
>> pick up
>> give CUP to (X)
>> use
>> fill
>> drink from
>> command
>>
>>Where 'command CUP' would be a catchall for command words that you
>>deliberately withheld from a player. (Presumably providing some clever way to
>>discover them)
>
>This is not a flame, and I'm not going to argue that "this takes away
>the mystery". I am going to argue that many puzzles will be spoiled by
>this.
>
>What's the point of a puzzle where the solution is to find a new use
>for some everyday object if you can just ask the game and get a
>complete list of all possible ways to use the object in question.
>
>Actually, I'm getting a bit worried about the assumption in this
>thread, that the game should actually list all possible actions. An
>adventure game should of course not be a "guess the correct verb"
>game, but IMHO what every game designer should work _very hard_ to
>make all puzzles so "intuitive" that it's possible for the player to
>express the needed action in a very simple sentence, with everyday
>words (of course the game should accept all reasonable synonyms and
>alternative wordings).

I'm not attempting to flame, but I think this is a important point.

Didn't Tom explicitly say you could hide some commands from the user by
saying "command" above ?

Lets say I have a rope.
I say "WHAT_CAN_I_DO_WITH ROPE"

The adventure comes back and says
You can get, put, and swing with a rope. There may be other commands available
in special circumstances.

Now lets say I want the player to lasso a jar of cookies to get them from a
shelf behind the ogre.

If I don't say LASSO in the list of verbs, the user may not even know that
I'll allow them to use the rope to Lasso.

I personally think that lasso should be listed in verbs for a rope.

What if I expect the user to Fray the rope, and use it as a replacement fuse
for a stick of dynamite?

I don't think you need to mention this in the list of verbs, since this is
an innovative use of a rope.

Lars J|dal

unread,
Dec 18, 1992, 4:13:49 AM12/18/92
to
t...@world.std.com (Tom O Breton) writes:

[Deleted: Discussion on whether or not to tell which words to use]

>I recall someone describing a puzzle where one had to get past laser beams by
>clapping an eraser so that you could see the beams outlined in the dust.

You realize this was a spoiler (not for me, but perhaps not everybody
reading this has played the game)?

>Clever? Yes, but you also have to *GUESS* that this functionality is
>implemented, whereas other functionalities such as
>
> sweeping dust instead up from the floor,
> improvising a mirror,
> improvising an ablative shield that would hold for the few seconds
> required,
> holding something disposable before you as you go as a 'mine detector',
> etc,
>
> are not. (Nor could one reasonably expect all such creative solutions to be
> supported)

Sorry that I'm straying from a general subject into commenting a
specific game, but I have to say this example is not as good as
it sounds.

The example is from David Baggett's Unnkulian Unventure II. The
laser beams are part of a security system with 'electric eyes'.
Thus we are not talking about high-powered lasers but about an
alarm system that goes off when you cross the beam.
The description of the room said the walls was full of holes and
if you examined the holes you were told they came in pairs, with
two holes at the same height on opposite walls. This is a fair
hint towards an 'electric eye' system. Hey, even I could guess
that.
Now you had to figure out to use the erasers to create dust. The
erasers was specifically described as "a pair of chalky erasers".
If the erasers was pounded a cloud of dust was produced. If this
was done at the laser system the beams was clearly seen that there
was "holes" between beams and thus you could sneak through.
I personally had a problem on finding out to use the erasers at
all, but once I got a hint in the right direction ("Have you been
in the Dudhist retreat?" where the erasers, among other things,
was found) I immediately saw the solution. I think my problems
more reflects that I'm a beginner on IF who thinks too little on
novel ways to use things.

Using dust from the floor? Fine idea if there had been anything,
but there wasn't. Perhaps the Acme Kleening Korps are doing a proper
job...
The rest of the suggestions would be fine for a high-power laser
obstacle, but they has little use for this puzzle.

> Tom
>--
>The Tom spreads its huge, scaly wings and soars into the wild sky...
>up... up... out of sight... (t...@world.std.com)

+--------------------------------------------------------------------------+
| Lars J|dal | Q: What's the difference between a quantum |
| email: prot...@daimi.aau.dk| mechanic and an auto mechanic? |
| or: joe...@dfi.aau.dk | A: A quantum mechanic can get his car into |
| University of Aarhus | the garage without opening the door. |
| Denmark | -- David Kra |
+--------------------------------------------------------------------------+

Karen Silkwood's car

unread,
Dec 18, 1992, 12:39:49 PM12/18/92
to

pw...@A.GP.CS.CMU.EDU (Peter Weyhrauch) writes:
>A case in point is the Oz system. We currently generate all our
>narrative text, and soon will generate character dialogue as well.
>Since the same lexicon is used for generation and parsing, any word
>used in generation is parseable. The grammars are currently
>different, but encode (roughly) the same functionality. Notice that
>you could use a more universal parser if you chose. The perhaps
>unacceptable downside is that our output is uninspired for now. Part
>of our research efforts are aimed at doing stylistic generation. For
>your curiousity, I'll attach a fragment at the end of my post.

interesting research and no doubt leading towards a satisfying conclusion
but i guess i'm a bit of a conservative when it comes to IF. i had many
many hours of entertainment playing infocom games as a teenager and i have
no problem with games coming out nowadays that live up to the standard set
by infocom. to wit: imaginative, interesting prose and a sometimes
frustrating parser. if that means i'll be pulling my hair out for a few
hours trying to figure out why PUSH SATCHEL IN FRONT OF PANEL doesn't work
while COVER PANEL WITH SATCHEL does, then so be it.

Tom O Breton

unread,
Dec 18, 1992, 5:27:20 PM12/18/92
to
Lars:

[...How you would keep me from using any of the electric eyes solutions
except the right one...]

But you see, your cleverness in defeating my cleverness does not address the
thing at hand. The author can't drop by and retro-fix for every creative
thing the player tries. Never be able to catch 'em all.

Which is why I suggest what I think is a fairly safe, easy, and flexible
mechanism for keeping the player informed of what they can do.

Tom

PS:

> You realize this was a spoiler (not for me, but perhaps not everybody
> reading this has played the game)?

No, since I was just repeating an earlier message on this newsgroup and
giving no new information. Anyhow, if anyone was really spoiled by it then I
apologize.

Tom O Breton

unread,
Dec 21, 1992, 4:56:36 PM12/21/92
to
Magnus: Well, this thread seems to be almost at the incineration point (If
that message about "SOLVE PROBLEM" "WIN GAME" wasn't already a flame), so I
won't dwell on it at length. I have a few things to clarify, and then I'm
done.

> Yes, I suppose it might be a good idea to be able to say "USE CUP ON
> CANDLE" in this situation.

I don't know where you're getting that from. It doesn't sound like anything I
said.

I have to take objection to this theme: (quotations from various parts)

> IMHO an adventure that requires bad guessing is badly written. If the
> author wants the user to use the cup to snuff the candle, then it's the
> author's responsibility to make the game recognize all resonable semantics,
> like "PUT CUP OVER CANDLE" and things like that. Of course, this requires
> *extensive* play testing, but so do many other aspects of adventure games.

> An adventure writer simply needs to work so hard on the game's internal


> consistency that there aren't any logical holes in it. And the game must be
> play tested by people who have keen eyes for internal logic.

> Yes, but then the game is badly written.

It is of course up to the individual authors, but I think here in this group
OF such authors, it will be clear to most that an efficient return on your
programming effort is desirable.

Same work, more game... looks good to me!


> I haven't played that game myself, but here's what I'd do if I were to
> write such a puzzle:

[ Rather a lot of effort, with the *foreknowledge* of what exact objections
would be raised, deleted ]

I think you missed my point.

0: Pretty much everyone agrees the game that included the example was
quite well-written. Telling me that this well-done game should have
been done *better* just makes my point for me.

Asking the author to manually make clear what functionality is
supported, discovering and covering even a good fraction of the
possible solutions, just is not a realistic request.

1: You are retrofixing problems *that you know about*.

2: You are spending an extraordinary amount of effort on "making sure" of
very tiny things. I'm suggesting an easier and more foolproof way.

Tom

--
The Tom spreads its huge, scaly wings and soars into the wild sky...

(t...@world.std.com)

Magnus Olsson

unread,
Dec 22, 1992, 6:12:19 AM12/22/92
to
In article <BzMqA...@world.std.com> t...@world.std.com (Tom O Breton) writes:
>Magnus: Well, this thread seems to be almost at the incineration point (If
>that message about "SOLVE PROBLEM" "WIN GAME" wasn't already a flame),

No, it wasn't a flame. I was being sarcastic, but my sarcasm was aimed
at the direction I feared this discussion was taking, and not directly
at you or anyone else in particular. Sorry if you felt offended.

BTW, I think the reason this debate is getting a bit inflamed is twofold:

a) Everybody seems to be slightly misunderstanding what the other
people say. This is certainly not due to malice, and probably not
entirely to lack of reading comprehension either... No flame intended,
but I think we could all (including me) have expressed ourselves more
clearly at points.

b) The discussion has been a lot about abstract principles, and
speculation about what things will be like if they're implemented.
This makes it very easy just to start shouting "is" and "is not" at
each other...

>so I
>won't dwell on it at length. I have a few things to clarify, and then I'm
>done.

I fear I'll have to be done as well, since I really must spend all
available time onb my thesis right now.

>> Yes, I suppose it might be a good idea to be able to say "USE CUP ON
>> CANDLE" in this situation.
>
>I don't know where you're getting that from. It doesn't sound like anything I
>said.

Well, it was I who said that. It was my suggestion on how to implement
something that somebody (maybe not you) suggested - or at least, I
interpreted that somebody as suggesting that.


>I have to take objection to this theme: (quotations from various parts)

Note: You shouldn't just concatenate unrelated quotations, since then
it looks as if I'd written something different from what I actually
did. Please insert ellipses "[...]" or something like that between the
distinct quotations to avoid misrepresenting my views. (It wasn't too
bad in that case, but falemwars have been started over less).

>> IMHO an adventure that requires bad guessing is badly written. If the
>> author wants the user to use the cup to snuff the candle, then it's the
>> author's responsibility to make the game recognize all resonable semantics,
>> like "PUT CUP OVER CANDLE" and things like that. Of course, this requires
>> *extensive* play testing, but so do many other aspects of adventure games.
>
>> An adventure writer simply needs to work so hard on the game's internal
>> consistency that there aren't any logical holes in it. And the game must be
>> play tested by people who have keen eyes for internal logic.
>
>> Yes, but then the game is badly written.
>
>It is of course up to the individual authors, but I think here in this group
>OF such authors, it will be clear to most that an efficient return on your
>programming effort is desirable.
>
>Same work, more game... looks good to me!

It looks good to you, since you're taking the author's point of view.
I'm taking the player's point of view, and I'm not sure I like what I
think you're suggesting.

Let me make it clear that I'd prefer a game like your proposal (or
what I think is your proposal) better than a badly designed one where
one has to guess at the author's intentions. But I'd still prefer a
well-designed, "traditional" one.

>> I haven't played that game myself, but here's what I'd do if I were to
>> write such a puzzle:
> [ Rather a lot of effort, with the *foreknowledge* of what exact objections
> would be raised, deleted ]

Foreknowledge? Well, I'd rather say afterthought in this case. But
foreknowledge *is* important - the author not only has to find puzzles
that make good sense to _him_ (her), but also has to try to put
himself/herself in the user's place, and think like the user.

This is hard indeed. But this is why it's of _vital_ importance that
all games be _thoroughly_ play-tested.

>I think you missed my point.
>
> 0: Pretty much everyone agrees the game that included the example was
> quite well-written. Telling me that this well-done game should have
> been done *better* just makes my point for me.

Should it really have been made better on this point? I don't know,
since I haven't played this game, but I saw at least one post that
disagreed with your views on ablative shileds and so on.

> Asking the author to manually make clear what functionality is
> supported, discovering and covering even a good fraction of the
> possible solutions, just is not a realistic request.

I'm afraid it is. But let me reiterate my point that the author should
design the problems in such a way as to minimize this task. If dust is
needed for a certain problem, then one shouldn't describe a lot of
rooms as "very dusty" just for the sake of atmosphere, because then
the user will want to get his dust from there, rather than from the
erasers.

> 1: You are retrofixing problems *that you know about*.

Of course. But even a rather small number of play-testers (2-3) will
find most of these problems, and let you retrofix them. And I
seriously doubt that your ideas will eliminate the need for play
testing.

> 2: You are spending an extraordinary amount of effort on "making sure" of
> very tiny things. I'm suggesting an easier and more foolproof way.

Easier? More foolproof? I'm not so sure of that.

But let's stop talking generalities: Why don't you write a game with
an implementation of your ideas? Then we can see

a) if it saved you much effort

b) if the users will like it more than a "conventional" game, and if
they won't feel that the game is "too helpful" (*)

And it's point b) that's the _really_ important thing, isn't it?


Footnote: (*) I've seen examples of games being too helpful; one
(unnamed, to save people from having their fun spoiled) game has a
helpful parser that supplies missing objects if there's only one
suitable object present. In one room, I thought I'd try to break
something I was carrying, but pressed return too early so my command
just became "break", upon which the parser decided I wanted to break
something else and proceeded to solve the entire puzzle for me.

This was of course a bug, but if you make your game very helpful and
forgiving towards the user, you may find that you have to spend your
time finding and correcting this sort of overly helpful behaviour
rather than finding alternative ways of solving problems...

Reply all
Reply to author
Forward
0 new messages