Text Adventures
B. Douglas Wake
> >Why did you decide on only 2 word phrases,as it would make the game more
> >playable if you had multi-word sentences. just a point question,but one I
> >always wanted to ask:)
> >
> >Signed The Shadow
> Well, the sci fi theme is sort of a combination War of the Wars/Planets of
> the apes/aftermath
>
> The reason for the 2 words is related to my programing ability.
Nothing wrong with a limited parser, in my opinion, if it's done right.
Many of the multi-word parsers are limiting in that they want the user
to find the right combinations of words to allow the user to do a simple
task.
Besides your basic Push, Pull, Get, Give ... to ..., and other kinds
of commands, there's really only one other command we use:
Use ... with ...
"Use" can replace a lot of verbs, making the computer smart enough
to figure out what it is that the user wants.
Use key with lock replaces "Put key in lock. Turn key."
Use sword with troll replaces "Hit troll with sword."
There's really not much you need to do that the basic commands, and
"Use," can't do for you.
Monkey Island was a complex enough adventure game that only used 12
(I think) keywords, which you selected by mouse. I found it to be quite
playable.
I'm crossposting this to rec.arts.int-fiction.
Doug Wake
dw...@uhunix.uhcc.hawaii.edu
The FASS Theatre Company
>Nothing wrong with a limited parser, in my opinion, if it's done right.
>Many of the multi-word parsers are limiting in that they want the user
>to find the right combinations of words to allow the user to do a simple
>task.
I've had the opposite experience; that is, limited parsers tend
to turn an adventure into a word guessing game. I remember a game
called The Hobbit that I gave up after four rooms because the synonym
support was non-existant. One room was featureless except for a curtain
on one wall; naturally I wanted to look behind it. So I type:
LOOK BEHIND CURTAIN
EXAMINE CURTAIN
SEARCH CURTAIN
MOVE CURTAIN
PUSH CURTAIN
LOOK CURTAIN
PULL CURTAIN
until finally, OPEN CURTAIN did the trick.
>Besides your basic Push, Pull, Get, Give ... to ..., and other kinds
>of commands, there's really only one other command we use:
>Use ... with ...
>
>"Use" can replace a lot of verbs, making the computer smart enough
>to figure out what it is that the user wants.
>Use key with lock replaces "Put key in lock. Turn key."
>Use sword with troll replaces "Hit troll with sword."
Ugh. Well, actually, that's not too bad *if* the game is polite
enough to either
1) display all possible actions (as verbs to type,
or buttons/icons to click) at all times in the game, or
2) list all possible verbs in the documentation with the game.
That would make very limited parsers acceptable, to me at least.
As for the idea that two-word commands are all we use (or need),
I can't agree. Limited parsers result in a limitation of the puzzles
possible. Without adjectives, for example, you can't have any puzzle
involving similar or look-alike objects, such as a red book and a green book.
You'd be limited to only one book in the entire game. Unless, of course,
one is a "dictionary" and the other is an "encyclopaedia", and
the player will never be able to type in "book" instead.
That takes us back to the word guessing game.
Synonyms! Implement synonyms!
>I'm crossposting this to rec.arts.int-fiction.
>
>Doug Wake
>dw...@uhunix.uhcc.hawaii.edu
>
David Welbourn (fa...@math.uwaterloo.ca)
Mike Marcelais
|> In article <CCJEx...@news.Hawaii.Edu> dw...@uhunix.uhcc.Hawaii.Edu (B. Douglas Wake) writes:
|> >Nothing wrong with a limited parser, in my opinion, if it's done right.
|> >Many of the multi-word parsers are limiting in that they want the user
|> >to find the right combinations of words to allow the user to do a simple
|> >task.
|>
|> I've had the opposite experience; that is, limited parsers tend
|> to turn an adventure into a word guessing game. I remember a game
|> called The Hobbit that I gave up after four rooms because the synonym
|> support was non-existant. One room was featureless except for a curtain
|> on one wall; naturally I wanted to look behind it. So I type:
|> LOOK BEHIND CURTAIN
|> EXAMINE CURTAIN
|> SEARCH CURTAIN
|> MOVE CURTAIN
|> PUSH CURTAIN
|> LOOK CURTAIN
|> PULL CURTAIN
|> until finally, OPEN CURTAIN did the trick.
No! There is a difference. Your problem was with a limited vocabulary.
Is there really a difference in playability between a two word parser:
> LOOK CURTAIN
and a full infocom style parser
> LOOK BEHIND THE PURPLE AND GOLD CURTAIN ON THE NORTH WALL
as long as there is enough vocabulary to that you don't guess for words. (I
don't think so...)
--
+-------------------------------------+---------------------------+
| Mike Marcelais (Perm Address) | mrma...@eos.ncsu.edu |
| 4109 Livingstone Place | Fourth Bryan Productions |
| Durham, NC 27707 | #include <disclaim.h> |
+-------------------------------------+---------------------------+
| if the above address bounces, then try the address below: |
| mrmarcel%eos.nc...@ncsuvx.ncsu.edu |
+-----------------------------Signature-Virus-Shield-v1.0-enabled-+
B. Douglas Wake
|>
|> I've had the opposite experience; that is, limited parsers tend
|> to turn an adventure into a word guessing game. I remember a game
|> called The Hobbit that I gave up after four rooms because the synonym
|> support was non-existant. One room was featureless except for a curtain
|> on one wall; naturally I wanted to look behind it. So I type:
|> LOOK BEHIND CURTAIN
|> EXAMINE CURTAIN
|> SEARCH CURTAIN
|> MOVE CURTAIN
|> PUSH CURTAIN
|> LOOK CURTAIN
|> PULL CURTAIN
|> until finally, OPEN CURTAIN did the trick.
Yeah, this is the kind of parser I advocate doing away with--limited
vocabulary or not. With my suggestion (limiting verbs), you could only
have done "push," "pull," "examine," and "use" the curtain. Pushing
the curtain is probably fairly meaningless when it's closed, but I
feel that Pull and Use should both produce results, where Examine
or Look (but only one implemented) should at least give some kind
of clue. I guess Open would be implemented as well. My point is that
any word of the limited vocabulary of verbs that makes sense should
do something.
I think parsers should be invisible. If the verbs are limited, it
can actually make the parser MORE invisible to the user. The user
can forget about it because he/she knows what's available. In the
game you referenced, I think the problem was more with a non-intuitive
parser than with a limited vocab. Why didn't Move or Pull work?
This is just something I've been dwelling on lately, and maybe
haven't sorted out fully yet, but I don't think the bigger parsers
do more than a 12-verb limited parser. I'm thinking about writing
an adventure in that style, so any input positive or negative is
appreciated....
>>"Use" can replace a lot of verbs, making the computer smart enough
>>to figure out what it is that the user wants.
>>Use key with lock replaces "Put key in lock. Turn key."
>>Use sword with troll replaces "Hit troll with sword."
>>
>Ugh. Well, actually, that's not too bad *if* the game is polite
>enough to either
> 1) display all possible actions (as verbs to type,
> or buttons/icons to click) at all times in the game, or
> 2) list all possible verbs in the documentation with the game.
>That would make very limited parsers acceptable, to me at least.
I agree with both (1) and (2). The idea is to free the user--no
guessing!
What do you all think?
Doug
dw...@uhunix.uhcc.hawaii.edu
Jonathan R. Ferro
> haven't sorted out fully yet, but I don't think the bigger parsers
> do more than a 12-verb limited parser. I'm thinking about writing
> an adventure in that style, so any input positive or negative is
> appreciated....
I have difficulty picturing the kinds of puzzles that would be available
under such a system. In what way would this prevent a stupid strategy
of "Huh, there's a curtain here. I guess it's a game object so I should
try to do something with it. Where did I put my list of verbs? Oh,
here it is. PUSH CURTAIN <RET> PULL CURTAIN <RET> EXAMINE CURTAIN <RET>
USE CURTAIN <RET>. OK, what did I make happen/what is the next game
object that I now have access to?"
This concept of having a limited set of actions has been used to design
pseudo-text-adventures for the Nintendo system. (The actions are
selected from a menu at the bottom of the screen.) I found these to be
among the most stultifying examples of the genre, and I don't see how I
am incorrect in thinking that _Loom_ is the highest this concept can
aspire to. I will be very interested if your sample adventure proves me
wrong.
-- Jon Ferro Einsprachigkeit ist heilbar
Sussman, Michael J
>I think parsers should be invisible. If the verbs are limited, it
>can actually make the parser MORE invisible to the user. The user
>can forget about it because he/she knows what's available. In the
>game you referenced, I think the problem was more with a non-intuitive
>parser than with a limited vocab. Why didn't Move or Pull work?
To allow the user to enjoy a text adventure game more, however, it would be
better not to limit the game's vocabulary to a given list of words.
Instead, consider all of the puzzles and situations that the user will
experience while playing the game, and develop a list of words (as
comprehensive as possible) which the user may possibly consider using in
each situation. Even if certain words are not even involved in helping the
user solve any puzzles in a game, allowing the user to type in these words
and receive appropriate responses will make the game much more enjoyable
(and more "user-friendly!")
For example, pretend you are playing a text adventure game, and you find
yourself in front of a small shack in the middle of a dark forest. The
entrance to the shack is a closed wooden door, and to the left of the door
is a barred window.
For this simple scenario, the following commands would be obvious to most
players: OPEN DOOR, LOOK WINDOW, LOOK SHACK, ENTER SHACK.
Ignoring directional commands (i.e., S, W, etc.), why confine the player to
this list of commands? This would allow no flexibility for imaginative
players who might come up with commands like: KNOCK DOOR, BREAK DOOR, KICK
DOOR, BREAK WINDOW, or even CLIMB TREES. Receiving a response of "What?"
to these commands would only frustrate and bore them.
Naturally, you would need to provide a list of synonyms for words that need
them: GO might be a synonym for ENTER, and SEARCH, CHECK, and EXAMINE
might be synonyms for LOOK. A good way to determine new words which should
be added to the game's vocabulary is to watch other people play your game!
An undefined list of words also allows the player to think more. As
mentioned in a different posting, what's to prevent the player from running
down the list of actions and trying each one on a given object until
something happens? Maybe the only way to get into the shack is to break
the window, and thinking of this option is what text adventures are all
about! Clues are important to making the game enjoyable as well: BREAK
DOOR may produce the following response: "The wooden door is MUCH too
sturdy to break down!" LOOK BARS may produce: "Some of the wooden bars
covering the window are broken, and other look very worn. Not exactly
ideal protection!"
>>>"Use" can replace a lot of verbs, making the computer smart enough
>>>to figure out what it is that the user wants.
>>>Use key with lock replaces "Put key in lock. Turn key."
>>>Use sword with troll replaces "Hit troll with sword."
>>>
>>Ugh. Well, actually, that's not too bad *if* the game is polite
>>enough to either
>> 1) display all possible actions (as verbs to type,
>> or buttons/icons to click) at all times in the game, or
>> 2) list all possible verbs in the documentation with the game.
>>That would make very limited parsers acceptable, to me at least.
>
>I agree with both (1) and (2). The idea is to free the user--no
>guessing!
I also agree that the idea is to free the user, but another way to do this
(without explicitly listing all valid actions) is to provide a larger
vocabulary.
To allow the PROGRAMMER more flexibility in addition to making the game
more "user-friendly," you might even want to consider making a 4-word
parser instead. Accepting commands of the form <verb><noun><prep><noun>
(for example: PUT BOOK ON SHELF, GET VIAL FROM BAG) will make it easy for
the player to perform actions with multiple objects. If your parser is
only limited to accepting 2 words, how would you allow the player to give a
crown to a king? Naturally, it would be a two-step process: the player
types in GIVE CROWN, is prompted with "To whom?", and replies with KING.
Wouldn't typing in GIVE CROWN TO KING be easier?
Besides increasing your dictionary further, the 4-word parser does
introduce a few other problems, and you would have to make a few decisions.
Would typing in GIVE CROWN KING be acceptable? Or what about GIVE KING
CROWN? Since it's obvious what the player means by these commands, a good
game would execute them as expected. Other games might respond with "You
must specify how to 'give crown': to, at, on, etc." or "You don't have the
king."
Advantages of a 4-word parser definitely outweigh the disadvantages,
though. The programmer would have the ability to include actions such as
PUT, USE, GIVE, THROW, and many others, without having to worry about
asking the user for the rest of the information.
Implementation of the parser is a different subject...maybe some other
time! :)
- Mike
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Wise man say:
"A fool and his money are soon partying."
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The FASS Theatre Company
> This is just something I've been dwelling on lately, and maybe
> haven't sorted out fully yet, but I don't think the bigger parsers
> do more than a 12-verb limited parser. I'm thinking about writing
> an adventure in that style, so any input positive or negative is
> appreciated....
Mmm. I've put together a list of "reduced verbs" that I think are
more-or-less either essential or very common in the 'bigger parser' games.
By "reduced verbs", I'm referring to the distinct action type
that is invoked, not the verbs typed in.
That is, all these phrases:
>PUT COAT ON
>PUT ON COAT
>WEAR COAT
all reduce down to "WEAR COAT".
By contrast,
>PUT COAT ON TABLE
reduces down to "PUT-ON-TOP COAT TABLE".
With this sort of reasoning, I believe there are slightly more than
12 verbs involved.
Essential "Reduced Verbs":
--------------------------
Bookkeeping: INVENTORY, RESTORE, SAVE, QUIT
Self Movement: D, E, N, NE, NW, S, SE, SW, U, W
Obj. Movement: DISROBE, DROP, INSERT, MOVE, PUSH, PULL, TAKE, WEAR
Obj. Assert: ATTACH, BREAK, CLOSE, CONSUME, CUT, DETACH,
LOCK, OPEN, UNLOCK
Viewing: EXAMINE, LOOK-AT-ROOM*, LOOK-BEHIND, LOOK-IN,
LOOK-UNDER, READ
*LOOK-AT-ROOM is such a major subset of EXAMINE that
it is almost certainly handled as a different verb.
Very Common "Reduced Verbs" that ought
to be Standard in all Text Adventures:
--------------------------------------
Bookkeeping: BRIEF, CREDITS, HELP, RESTART, TIME, VERBOSE, VERSION, WAIT
Self Movement: CLIMB, CROSS, ENTER, EXIT, HIDE, JUMP, SIT, SLEEP,
STAND, SWIM
Obj. Movement: FILL, LIFT, PUT-ON-TOP, ROLL, SHAKE, TURN
Obj. Assert: BURN, DIG, EXTINGUISH, KICK, KNOCK, TURN-ON, TURN-OFF, WAVE
Viewing: LOOK-THROUGH, SMELL, TOUCH
With "People": ASK, ATTACK, FEED, GIVE, GREET, KISS, FUCK, SHOW, TELL
Miscellaneous: FIND, NO, YELL, YES
There are other common verbs, such as CLEAN or TYPE or SAY or FIX, but they
probably only need to be implemented as needed. Any good text adventure
should implement at least 80% of the above "reduced verbs".
IMHO, of course. :)
--------------------------------------------------------------
David Welbourn
Jon Thackray
In article <CCJEx...@news.Hawaii.Edu> dw...@uhunix.uhcc.Hawaii.Edu (B. Douglas Wake) writes:
>Nothing wrong with a limited parser, in my opinion, if it's done right.
>Many of the multi-word parsers are limiting in that they want the user
>to find the right combinations of words to allow the user to do a simple
>task.
I've had the opposite experience; that is, limited parsers tend
to turn an adventure into a word guessing game. I remember a game
called The Hobbit that I gave up after four rooms because the synonym
support was non-existant. One room was featureless except for a curtain
on one wall; naturally I wanted to look behind it. So I type:
LOOK BEHIND CURTAIN
EXAMINE CURTAIN
SEARCH CURTAIN
MOVE CURTAIN
PUSH CURTAIN
LOOK CURTAIN
PULL CURTAIN
until finally, OPEN CURTAIN did the trick.
Well I disagree. This has nothing to do with parsing complexity, it
only refers to synonyms. The more complex your parser, the more
synonymous phrases you have to supply to achieve the same single
effect. A reasonable implementation would have implemented all the
above two letter alternatives to give what was required, without
requiring longer phrases. The number of three or four or more letter
phrases to achieve the same effect will be much greater, and therefore
the chance that the implementor has omitted the one the player wants
to use is much greater. Also, you can always prompt the player if you
think he's on the right lines.
>Besides your basic Push, Pull, Get, Give ... to ..., and other kinds
>of commands, there's really only one other command we use:
>Use ... with ...
>
>"Use" can replace a lot of verbs, making the computer smart enough
>to figure out what it is that the user wants.
>Use key with lock replaces "Put key in lock. Turn key."
>Use sword with troll replaces "Hit troll with sword."
Ugh. Well, actually, that's not too bad *if* the game is polite
enough to either
1) display all possible actions (as verbs to type,
or buttons/icons to click) at all times in the game, or
2) list all possible verbs in the documentation with the game.
That would make very limited parsers acceptable, to me at least.
I object also to universally applicable verbs, especially if there are
lots of possible meanings. eg
use sword with troll
You knight the troll, who immediately becomes your loyal vassal.
or
use sword with troll
You throw the sword on the ground and you and the troll perform a
square dance over it. Eventually the troll becomes tired and goes to
sleep.
or
use sword with troll
You attack the troll with your sword. The troll's hide is so thick
he doesn't notice more than an irritating tickle, and attempts to swat
the cause. You die...
As for the idea that two-word commands are all we use (or need),
I can't agree. Limited parsers result in a limitation of the puzzles
possible. Without adjectives, for example, you can't have any puzzle
involving similar or look-alike objects, such as a red book and a green book.
You'd be limited to only one book in the entire game. Unless, of course,
one is a "dictionary" and the other is an "encyclopaedia", and
the player will never be able to type in "book" instead.
That takes us back to the word guessing game.
Not true again. I seem to remember a very nice puzzle in Zork to do
with an "eatme" cake. You couldn't refer to it directly, but if you
removed all the other cakes first, then you could acquire it by simply
saying "Take cake". Provided "Take cake" will always take a cake when
there's one there, you don't need the adjectives, and in any case they
don't solve the problem. This of course doesn't solve the fixed
object problem, such as press red button vs press green button, but
again you can prompt or offer a menu.
I think the essence is to implement complex parsing only when really
necessary, because if you insist on it when it isn't necessary you'll
only frustrate the player.
Synonyms! Implement synonyms!
Agreed!
--
Jon Thackray jo...@harlqn.co.uk 44 223 872522 (voice)
Harlequin Ltd. 44 223 872519 (fax)
Barrington Hall
Barrington
Cambridge CB2 5RG
England
Pat Shepard
I find this discussion of two word parsers and intentionally limited
vocabularies to be somewhat disturbing. I already *know* English, I
do *not* know the limited subset programmed into the adventure, unless
I sit down and memorize it, which sounds quite unpleasant.
Maybe I'm the odd one, but *I* want to be able to instruct the computer
to "get the red ball out from under the covers of the bed." Admittedly
even if that were allowed I would also like to be able to tell the
computer to "get ball" and get "(from under the covers) Taken." as a
response (assuming I had reason to know the ball was there, of course).
The reduced verb idea *does*, IMHO, have some merit however. All
adventure games should have these verbs available to the players *and*
(probably more important) should be *very* careful to ensure that all
verbs required to do something come from this list.
If I agree that all required verbs should come from a relatively small
well described list why do I want other verbs? Because a text adventure
should *feel* as much like natural language interaction as is
possible. If I feel that text adventures should feel as much like
natural languages as possible, why do I think it is important to
have a relatively standard set of verbs that cover all significant
actions in the game? Because it helps lessen the problems that arise
from the fact that all adventures are in fact written by imperfect
people with a limited amount of time. Were we all perfect then every
word in every adventure would have several thousand synonyms. Since
we're not (and hence adventures don't) a guarantee that "guess the verb"
will at least be an easy game sounds like a good idea to me.
The Shadow
to guess what a programmer wants me to do to something---like enter shack,
break down door with hammer....with a multi-word adventures,it seems to
me to be a lot easier(not in playabilty)----even if break door just gives
you a response of "you break your hand when you try to break down the door"
It kind of makes me,as a gameplayer,believe that the programmer took some
time in developing the adventure.
With a two-word parser,its sort of a guess as to what I'm suppossed--but
then again so is a multi-word. One post talked about some game and a curtain--
My reaction would be the same---open curtain,look curtain---so my
stand stays the same Multi-word parser are the best....but two-word can work
if the programmer takes a little time in deciding how those two word go
together.
Signed The Shadow
Adam Justin Thornton
/if-archive/programming/tads and look at the verbs it implements in std.t?
They're a really good start.
--
ad...@rice.edu | These? Rice's opinions? Yeah, right. | "Might there have
been fewer crimes in the name of Jesus, and more mercy in the name of Judas
Iscariot?"--Thomas Pynchon | Overheard in Waco: "This is not an assault."
Save the Choad! | Win/NT: Yesterday's technology tomorrow. | 64,928 | Fnord
The Shadow
>Why don't you guys grab TADS from ftp.gmd.de in
>/if-archive/programming/tads and look at the verbs it implements in std.t?
>They're a really good start.
I did,what's your point? TADS actually lets you use either the mult-word or
two word sentence. In my opinion,this is an excellent developing tool for
text adventure.
Signed The Shadow(I'm not a programmer,just a bad actor)
Jason D Corley
>In article <CCM1p...@news.Hawaii.Edu>, dw...@uhunix.uhcc.Hawaii.Edu (B. Douglas Wake) writes...
>>I think parsers should be invisible. If the verbs are limited, it
>>can actually make the parser MORE invisible to the user. The user
>>can forget about it because he/she knows what's available. In the
>>game you referenced, I think the problem was more with a non-intuitive
>>parser than with a limited vocab. Why didn't Move or Pull work?
>
>To allow the user to enjoy a text adventure game more, however, it would be
>better not to limit the game's vocabulary to a given list of words.
>Instead, consider all of the puzzles and situations that the user will
>experience while playing the game, and develop a list of words (as
>comprehensive as possible) which the user may possibly consider using in
>each situation. Even if certain words are not even involved in helping the
>user solve any puzzles in a game, allowing the user to type in these words
>and receive appropriate responses will make the game much more enjoyable
However, if you don't have the skill or the time to make up a tremendously
large parser containing every word the person could conceivably use,
I as a player would much rather have a verb list that I could consult
when I had to do something. If I didn't have to wonder whether or not
I was on the right track ("Hm....there's no entry for SHAKE so I guess
SHAKE BEER is out...") then I would enjoy the game a lot more. That
doesn't necessarily mean you should intentionally have a short list
of commands or that there shouldn't be tons of red herrings, but I like
knowing pretty much what the computer is "thinking" at all times.
--
******************************************************************************
"Every normal man must be tempted at times to spit upon his hands, hoist the
black flag and begin slitting throats."---------H. L. Mencken
Jason D. "cor...@gas.uug.arizona.edu" Corley Claims Full Responsibility
The FASS Theatre Company
summarize...
1) Synonyms are a GOOD thing. We all seem to agree on this -- yes?
2) There are major differences of opinion on whether a limited parser
is _sufficient_ to implement all the puzzles we'd like to implement.
In other words, are limited parsers robust enough?
3) Maybe I should look at TADS, or some other adventure writing program.
4) There are major differences of opinion on whether a limited parser
gives the player a _sufficient clarity of intent_. That is, will the
user have enough confidence that his/her actions will have the desired
or expected effect? You know, cause and effect?
I'll briefly start with (3) to get it out of the way.
No, I haven't seen TADS or any other public domain adventure-creating
software, and maybe I should. Unfortunately, it wouldn't do me much good
because of the way I'm signed on here, which I won't go into.
I have played Unnkulian Unadventures I and II, to conclusion, and enjoyed
both, but there were a few minor stumbing blocks in the implementation,
some of which is, I'm sure, a limitation of the TADS parser. So I'm
quietly writing my own adventure-creating software all by my lonesome.
I'm sorry, but the Infocom parser spoiled me rotten. If I can develop
a parser at least as good as what they had, why settle for less? :)
As for (2), are limited parsers robust enough, I can only offer
my personal conviction that no, they aren't. Not for me. You can still
write a good game with them, a game that is challenging and fun,
but it isn't as likely.
Someone else here said [sorry, accidently deleted who]:
>[with larger parsers]
>the chance that the implementor has omitted the [verb] the player wants
>to use is much greater. Also, you can always prompt the player if you
>think he's on the right lines.
>
Do I understand this right? Do you want dialogue like
>KILL TROLL
With what you want to kill the troll?
>AXE
to be the ONLY way to have two objects interact? You're joking, right?
>... I seem to remember a very nice puzzle in Zork to do
>with an "eatme" cake. You couldn't refer to it directly, but if you
>removed all the other cakes first, then you could acquire it by simply
>saying "Take cake".
That sounds like not a legitimate puzzle, but an implementation error.
That is, they forgot an adjective. Or you missed one. I played both
mainframe Zork and the I-II-III trilogy and don't remember this problem.
It does remind me of the difficulties of referring to carried water
whenever you're near a water source.
>DRINK WATER
Which water do you mean -- the well water or the water?
In this case, the program should be extra clever to realize that the
carried water is the default water. Maybe someday we'll see a parser that
can understand DRINK WATER IN CANTEEN or DRINK CANTEEN WATER.
In the meantime, drink water away from wells, lakes and puddles.
>
>I think the essence is to implement complex parsing only when really
>necessary, because if you insist on it when it isn't necessary you'll
>only frustrate the player.
IMHO, a statement like "PUT COIN IN VENDING MACHINE" is not that complex.
It really isn't. The clever author and parser should also permit
"INSERT COIN" and have the program behave the same way. Implement both.
We can both be happy.
>
> Synonyms! Implement synonyms!
>Agreed!
>Jon Thackray jo...@harlqn.co.uk 44 223 872522 (voice)
Not to beat this to death [too late! ;) ] but adventure writers should
pay as much attention to *SYNONYMOUS SYNTAXES* as well as word synonyms.
If you peek at my so-called "reduced verbs" in an earlier post,
(and I forgot THROW, please forgive me), the author should make a real
effort to think up all the synonymous syntaxes that belong to each
"reduced verb". For example, the "reduced verb" EXAMINE has the
syntaxes: LOOK <obj>. LOOK AT <obj>. LOOK ON <obj>. EXAMINE <obj>.
Add synonym support for the individual words:
L=LOOK=GAZE=VIEW=SPY, SEARCH=EXAMINE, ON=UPON
and you end up supporting all of this:
L <obj>. LOOK <obj>. GAZE <obj>. VIEW <obj>. SPY <obj>.
L AT <obj>. LOOK AT <obj>. GAZE AT <obj>. VIEW AT <obj>.
SPY AT <obj>. L ON <obj>. LOOK ON <obj>. GAZE ON <obj>.
VIEW ON <obj>. SPY ON <obj>. L UPON <obj>. LOOK UPON <obj>.
GAZE UPON <obj>. VIEW UPON <obj>. SPY UPON <obj>.
EXAMINE <obj>. SEARCH <obj>.
Do that for each and every "reduced verb". Why is that so hard?
Devil's advocate time. I remember one abuse of large parsers from
Enchanter, where you had to give a list of commands all at once,
something like:
TURTLE, "GO SE. PICK UP SCROLL. GO NW."
Yet, still, awful as this is, how could you possibly prompt for this
with a limited parser? The puzzle was structured so you COULDN'T
tell the commands individually, because once the turtle had gone southeast,
it could no longer hear you for the next command. And you couldn't survive
the trip yourself. If this example doesn't convince everyone that
limited parsers aren't robust enough to handle all puzzles, I give up.
I've yakked enough for one post; my convictions on (4) (can limited
parsers guarantee clarity of intent) aren't etched in stone.
I'll let the rest of you argue on that one. My only comment is, yes,
the verb "use" isn't clear at all, but should be implemented anyway,
if only to have the program come back with
How do you wish to use the <object>?
And yet, I'd still cut to the chase when the player has a beard
and types in USE SHAVER, should s/he have an electric shaver as well.
--------------------------------------------------------------------
David Welbourn (getting rather opinionated, isn't he?).
Adam Justin Thornton
>In article <CCoM...@rice.edu>, ad...@owlnet.rice.edu (Adam Justin Thornton) writes:
>>Why don't you guys grab TADS from ftp.gmd.de in
>>/if-archive/programming/tads and look at the verbs it implements in std.t?
>>They're a really good start.
>
>I did,what's your point?
No need to be rude. My point was that TADS defines a whole bunch of what
most people would consider the standard adventure verbs and phrases, and
that looking at how the code is structured is very useful for thinking
about what verbs a parser needs to know about.
>TADS actually lets you use either the mult-word or
>two word sentence. In my opinion,this is an excellent developing tool for
>text adventure.
Which is more or less what I was trying to say. Look at how Mike Roberts
does it. Even if you don't agree with his implementation of std.t, it's a
good place to start from.
Adam
Mike Roberts
may be surprising to find me defending the 12-verb style, but here
it is:
"Jonathan R. Ferro" <jf...@andrew.cmu.edu> writes:
> [ regarding a parser with a small, enumerated list of verbs ]
>
> I have difficulty picturing the kinds of puzzles that would be available
> under such a system.
Ironically, I recommend to people designing regular text adventure
game puzzles to pretend they're designing for a severely limited
command set, such as with a graphical game. It is more challenging
to design puzzles this way, but I've found that better puzzles usually
result -- specifically because they don't rely on anything but easily-
expressed commands.
> In what way would this prevent a stupid strategy
> of "Huh, there's a curtain here....PUSH CURTAIN <RET> PULL CURTAIN <RET>
> EXAMINE CURTAIN <RET> USE CURTAIN <RET>.
There's nothing to stop you in theory, but then again a regular text
adventure is finite as well (that seemingly unconstrained '>' prompt
notwithstanding), so the same strategy could apply. I think the thing
that stops you in practice (in both types of games) is that it's just
no fun.
> I don't see how I am incorrect in thinking that _Loom_ is the highest
> this concept can aspire to.
I'm not sure what you mean, but I'll assume you didn't like Loom.
Try Monkey Island I. It's much better than Loom, thus the concept
empirically can not only aspire to, but also achieve, more than Loom.
MI1 is among my favorite computer games to date.
It is one of the most pernicious misconceptions about text adventure
games that the seemingly (I emphasize: *seemingly*) unconstrained
command format is an advantage. Sure, you can type CAREFULLY PULL
BACK THE CURTAIN JUST SLIGHTLY AND PEEK AROUND IT TO SEE WHAT'S OUT
THE WINDOW, or anything else that will fit on an 80-character line,
but I believe it is worse to fail to accept a command that is offered
than not to offer a command at all. Text adventures implicitly offer
you all of English and then fail to accept almost all of it. (In text
adventures I've written, at least, I've always provided in the
documentation a complete list of all verbs and phrasings that are needed
to complete the game, but this information is in the documentation and
not in the '>' prompt.)
Yes, fighting with the parser increases the challenge of the game,
but not in a good way. Simply making the game unwinnable would also
increase the challenge. At best, a parser is invisible. Until AI
improves substantially, I think the only way to hide the parser
better is to expose its limitations, such as through verb enumeration,
as in the LucasArts games.
The only thing that really matters in a game is that it's fun. In
an adventure game, all of the fun is in the story and the wacky
interactions between the player and the game's things and people.
The user interface (maybe a parser, maybe some verb buttons) exists
solely to facilitate this interaction. If the interface is powerful
enough to express all of the possible interactions, it is adequate.
--
Mike Roberts mrob...@hinrg.starconn.com
High Energy Software 415 493 2430 (Voice)
PO Box 50422, Palo Alto, CA 94303 415 493 2420 (BBS)
Paradise is a place exactly like where you are right now, only
much, much better.
--- Laurie Anderson
The Shadow
>No need to be rude. My point was that TADS defines a whole bunch of what
>most people would consider the standard adventure verbs and phrases, and
>that looking at how the code is structured is very useful for thinking
>about what verbs a parser needs to know about.
I wasn't being rude,I didn't understand your post. I agree on your point about
TADS,its actually one of the better developement tools I have seen in the term
of use of verbs,interaction between NPC(although limited---but hey isn't life
in general that way?) and so forth and so on.
----Sorry if my post sounded rude----
Signed The Shadow(Still on an adventure,please forward all my mail to the Home
for the criminally insane,Fargo,North Dakota)
---Sig,we don't need no stinkin' sig............
Neil K. Guy
>I'm sorry, but the Infocom parser spoiled me rotten. If I can develop
>a parser at least as good as what they had, why settle for less? :)
Actually, I'm not sure if the this is really the case. TADS has a
very good parser, and you can extend the capabilities of the system
tremendously. I think it's possible to create a game with a much
richer vocabulary than most Infocom games using TADS if you're willing
to put in the time. True, if all you use is a slightly modified adv.t
you're going to have something along the lines of an early Infocom
game in terms of vocabulary, but nobody said you couldn't add your own
stuff. I see no real need to have to write another adventure game
system unless, of course, you're up for the intellectual challenge of
it all. :) Or if you object to the fact that the TADS source
is not freely available or whatever.
Me, I'm a lousy programmer, so I'll happily use someone else's game
system because I'm more interested in designing games than designing
parsers.
>It does remind me of the difficulties of referring to carried water
>whenever you're near a water source.
> >DRINK WATER
> Which water do you mean -- the well water or the water?
>In this case, the program should be extra clever to realize that the
>carried water is the default water. Maybe someday we'll see a parser that
>can understand DRINK WATER IN CANTEEN or DRINK CANTEEN WATER.
Not to harp on about TADS again, but this is all quite possible.
DRINK WATER IN CANTEEN has certain grammatical ambiguities as a
command and is therefore undesirable (IMHO) but you can easily assign
an adjective (in this case the noun "canteen") to an object. Heck, you
could even assign adjectives like "nice" and "clean" and "potable" to
the canteen water and adjectives like "dirty" or "muddy" to pond water
if you wanted to. Of course this doesn't deal with the traditional
text adventure problem of modelling infinitely divisible stuff like
water or flour or whatever, but that's another story...
TADS also provides a mechanism for avoiding the "Which blah blah do
you mean?" problem, through use of the mysterious verb verify
function. If trying to verb an object brings up an error message ("You
can't reach the water" or "The canteen lid is closed" or whatever)
then that object won't be included in the default list. You could,
therefore, write a TADS game that was intelligent enough to ignore
murky ponds of brackish water or muddy puddles and assume that you
mean your tasty canteen water when you say DRINK WATER.
- Neil K. (n_k...@sfu.ca)
Mike Threepoint
> Devil's advocate time. I remember one abuse of large parsers from
> Enchanter, where you had to give a list of commands all at once,
> something like:
> TURTLE, "GO SE. PICK UP SCROLL. GO NW."
> Yet, still, awful as this is, how could you possibly prompt for this
> with a limited parser?
POINT AT SCROLL.
Or for Lucasfilm parsers, "Use turtle with scroll". :-)
> If this example doesn't convince everyone that limited parsers aren't
> robust enough to handle all puzzles, I give up.
We accept your resignation. :-)
Ville Lavonius
standard of text adventure parsers. I've played a few lately, and
they're really not particularly excellent parsers -- the later Unnkulian
games recognize lots more synonyms and decoration items. It could be
I replayed Seastalker and Cutthroats, and came to exactly same conclusion -
Unnkulians have a better parser.
games were an early implementation of a limited parser! In fact, they
were visibly constrained, in that the documentation for an Infocom game
always includes a complete list of verbs needed to complete the game.
Huh ?
I bought my first infocoms in proper boxes back in '85 and none have had
a list of verbs... Some list the special commands (script, brief etc),
but NOT a complete verbal dump.
Hmm, perhaps the CBM-versions did have a verb-list, but they were raped
versions anyhow.
--
Mike Roberts mrob...@hinrg.starconn.com
High Energy Software 415 493 2430 (Voice)
PO Box 50422, Palo Alto, CA 94303 415 493 2420 (BBS)
--
Ville Lavonius : Mankind may never reach Mars,
lavo...@cc.helsinki.fi : but there will always be elves in Middle-Earth
GCS d-- -p+ c++ l m++/-- s+/+ g+/- w+ t- r+ : Terry Pratchett
Mike Roberts
> I already *know* English, I do *not* know the limited subset
> programmed into the adventure, unless I sit down and memorize it ...
> *I* want to be able to instruct the computer
> to "get the red ball out from under the covers of the bed."
This is actually the argument in favor of small parsers. The choice
between traditional text adventure parsers and visibly constrained
parsers (such as those used in most graphical adventures) is *not*
a choice between full English and some subset. It is actually a
choice between a small subset of English and a somewhat smaller subset.
The whole point of a visibly constrained parser is to show the player
exactly what subset is available. A traditional text adventure
pretends it understands English, then rejects most of it. (The
really bad parsers don't even tell you why they reject a sentence.
Back when the Sierra games had parsers, they were among the worst
offenders; type in random gibberish, and they'd respond with "You
can't do that--yet!".)
> A text adventure should *feel* as much like natural language
> interaction as is possible.
Why? It's certainly traditional to attempt to achieve this, but I
don't agree that it's a universal truth of adventure gaming. If you
remove the assumption that there is a command line, you also remove
the need for a parser. Although a verbal command is an excellent
way for a person to express intent, it is a very bad way for a computer
to interpret that expression. The trick is to find a medium of
expression that is easy for people to use and for computers to interpret.
Visibly constrained parsers are certainly easy for the computer, and
I've found them to be very pleasant to use with some games.
One interesting thing I've noticed about this discussion is that lots
of people continue to hold up the old Infocom games as the reference
standard of text adventure parsers. I've played a few lately, and
they're really not particularly excellent parsers -- the later Unnkulian
games recognize lots more synonyms and decoration items. It could be
that some people have idealized recollections, but I think it's really
something else going on: I think the highly standardized command set
in the Infocom games lets you get accustomed to "Infocom English" --
that very small subset of English imperative sentence structures that
Infocom games generally accept. In this sense, perhaps the Infocom
games were an early implementation of a limited parser! In fact, they
were visibly constrained, in that the documentation for an Infocom game
always includes a complete list of verbs needed to complete the game.
--
Mike Roberts mrob...@hinrg.starconn.com
High Energy Software 415 493 2430 (Voice)
PO Box 50422, Palo Alto, CA 94303 415 493 2420 (BBS)
Paradise is a place exactly like where you are right now, only
Torbj|rn Andersson
> standard of text adventure parsers. I've played a few lately, and
> they're really not particularly excellent parsers -- the later Unnkulian
> games recognize lots more synonyms and decoration items. It could be
It seems to me as if the Unnkulian games are designed in a system which
doesn't have the constraints of game size as Infocom had. At least, I haven't
been able to run any of the Unnkulian games in a stable fashion on my old
Macintosh with 512 Kb memory -- usually crashes after x screenfulls of
text (where x << what you would really want it to be :-), whereas most
Infocom games ran on 128 Kb, or perhaps even less. But perhaps I did
something wrong -- I haven't tried for some time, now.
Torbj|rn Andersson
Mike Roberts
> I haven't been able to run any of the Unnkulian games in a stable
> fashion on my old Macintosh with 512 Kb memory -- usually crashes
> after x screenfulls of text.
TADS probably won't run in 128k, but it should run without problems
in 512k -- DOS users do it all the time. What version of the TADS
runtime are you're using? (It will announce itself on the first line
of text displayed when you run the game.)
Clark Quinn
>something else going on: I think the highly standardized command set
>in the Infocom games lets you get accustomed to "Infocom English" --
>that very small subset of English imperative sentence structures that
>Infocom games generally accept. In this sense, perhaps the Infocom
>games were an early implementation of a limited parser! In fact, they
>were visibly constrained, in that the documentation for an Infocom game
>always includes a complete list of verbs needed to complete the game.
It's clear that people negotiate meaning and grammar, and it's been
posited that a way to help a user understand what is appropriate
language is for an interface to use the language appropriate for
interactions. If players want rich textual descriptions, but this is
misleading for the capabilities of the parser, then it can be proposed
that the best interface is two windows, one with rich textual
descriptions, and one that interacts with the user in the pidgin
language that both will understand.
Personally, I find the "text is the only form of fiction" view to be
narrow, and develop (in conjunction with talented students) graphic
environments, *supplemented* with text descriptions (I'm all for
multi-media as a way to engage the full panoply of experience in the
entertaining business of on-line problem-solving that constitutes the
major component of the challenge in adventures). I will qualify that
statement to say that my goals are cognitive and instructional rather
than primarily entertainment.
-- Clark
---------------------------------------------------------------------------
_--_|\ Clark N. Quinn
/ \ School of Computer Science and Engineering +61-2-697-3985
\_.--._* The University of New South Wales Fax +61-2-313-7987
v PO Box 1 cnq...@cse.unsw.edu.au
Kensington, NSW C.Q...@unsw.edu.au
AUSTRALIA 2033
"A California Yankee in the Land of Oz"
David Baggett
>> I haven't been able to run any of the Unnkulian games in a stable
>> fashion on my old Macintosh with 512 Kb memory -- usually crashes
>> after x screenfulls of text.
>
>TADS probably won't run in 128k, but it should run without problems
>in 512k -- DOS users do it all the time.
Another data point: the Atari version runs Unnkulia Zero (a much bigger
game than UU1 or UU2) in about 380K. Maybe it was one of the early 2.0
run-times that had problems on 68000 macs?
Dave Baggett
__
d...@ai.mit.edu Boot up, log in, drop out. MIT AI Lab
ADVENTIONS: We make Kuul text adventures! Ask about Unnkulian 1, 2, 0, 1/2
PO Box 851 Columbia, MD 21044 USA / CIS: 76440,2671 / GEnie: ADVENTIONS
Torbj|rn Andersson
> TADS probably won't run in 128k, but it should run without problems
> in 512k -- DOS users do it all the time. What version of the TADS
> runtime are you're using? (It will announce itself on the first line
> of text displayed when you run the game.)
Hmm ... embarrasing thing is, I can't remember -- I removed the files,
since I needed the space better for other things :-)
It was the version (of UU1 and UU2), I think, which was uploaded to
ftp.gmd.de at the same time the demo version of Unnkulia Zero was
uploaded. They both had a difficulty rating (which I don't think the
older version had).
Perhaps it's time to try it again ... I just assumed it was some out of
memory error -- the font would change to something unreadable, the game
would slow down considerably ... and things went downhill quickly after
that.
Torbj|rn Andersson
Philip Stephens
>most Infocom games ran on 128 Kb, or perhaps even less.
Actually, most infocom games ran in 48 Kb or less...they were pretty much
the first to use a kind of virtual memory system on such platforms as the
Apple //. But the game files themselves were never much larger than 128 Kb
(otherwise they couldn't have fitted on the Apple //'s whopping 140 Kb floppy
disks :-) ).
--
| Philip Stephens, Systems Programmer. | "Many views yield the truth. |
| Address: 43 Malcolm Road, Braeside, | Therefore, be not alone." |
| Victoria, 3195, AUSTRALIA. | |
| Internet: phi...@labtam.labtam.oz.au | -- Prime Song of the Viggies |
Nathaniel D. Daw
Philip Stephens <phi...@labtam.labtam.oz.au> wrote:
>Torbj|rn Andersson writes:
>
>>most Infocom games ran on 128 Kb, or perhaps even less.
>
> Actually, most infocom games ran in 48 Kb or less...they were pretty much
>the first to use a kind of virtual memory system on such platforms as the
>Apple //. But the game files themselves were never much larger than 128 Kb
>(otherwise they couldn't have fitted on the Apple //'s whopping 140 Kb floppy
>disks :-) ).
The last few Apple // ones (i.e. AMFV) came on double sided disks, with the
runtime on one side and the game file on the other. And I think they required
128k. But the first few (Enchanter, I know) required only 32k memory; they
would run on Atari 800s.
Of course, then there were Zork Zero and Shogun, which both required two
floppy drives on the Apple, and came on at least 4 disk sides as I remember ...
nd