From: magnus@thep.lu.se (Magnus Olsson)
Newsgroups: rec.arts.int-fiction
Subject: Re: What words to use and recognize
Date: 19 Dec 92 13:23:52 GMT
Organization: Theoretical Physics, Lund University, Sweden

In article <BzFA13.Hro@world.std.com> tob@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         |   >----<           
 magnus@thep.lu.se, thepmo@seldc52.bitnet  |  /      \===== g
PGP key available via finger or on request | /e-      \q
Newsgroups: rec.arts.int-fiction