Parsers
Duane Morin
As a matter of fact, probably the only reason I follow IF is because its
one of the few places left in the world that appreciates natural language.
But, anyway. I'm wondering what people like in a parser, and whether or not
ANY parser would be "good enough"? That is, won't you be able to find
things that just won't work, regardless of how good the parser is?
Sometimes, ambiguity sets in. Where it doesn't, things should be easy.
I mean:
>plant pot plant in plant pot // Or SOMETHING like that
Should be easy, because it's essentially unambiguous:
plant ::= <COMMAND> | <ADJ> | NOUN
pot ::= <ADJ> | <NOUN>
in ::= <PREP>
<VERB_PHRASE> ::= <COMMAND> <OBJECT> <PREP> <OBJECT>
<OBJECT> ::= <ADJ> <NOUN> | <NOUN>
However, how about something like this:
You enter a room. There is a chest on the floor, and one on a table.
>examine chest on floor
You find a picture.
>put picture in chest on table
Now, this is ambiguous. Is it "picture in chest" or is it "chest on table"?
Granted, a typical parser would take it as the second meaning, because
you don't have to describe the picture as being in the chest. But,
say there was another picture, hanging on the wall? If <OBJECT> is
defined as something like this:
OBJECT ::= <NOUN> | <ADJ> <NOUN> | <OBJECT> <RELATION> <OBJECT>
RELATION ::= in | on | under
Then there's a problem. Parser would have to assume that you meant
"picture in chest", because that fits. Heck, I just realized that if I
had this:
>examine chest on table
You find a picture.
>examine picture in chest on table
Then that works, too. :) I suppose we'd have to have something in there
to verify whether or not the case of <OBJECT><RELATION><OBJECT> was an
appropriate description, to help knock out some ambiguity.
Back to the original idea. I'm not familiar with IF parser technology
very much. Does your standard parser handle things like the above
examples? If not, should it? If so, what wouldn't it handle?
Duane, writing a parser, if no one had guessed
Duane D Morin
Steve Dunham <dun...@cl-next4.cl.msu.edu> wrote:
[on the subject of ambiguity and parser interpretation]
> 1. If there are no semantic interpretations consistent with the game
>world, then complain to the user (``I don't understand'' or ``there is
>no box on the table'').
Easy enough.
> 2. If there is one interpretation, act on it.
Again, goes without saying.
> 3. If there is more than one interpretation, any of the following
>actions could be taken:
>
> (iii) Give a `unlikeliness' score to each of the possible
> semantic interpretations (mark unusual interpretations or
> rarely used constructs as being more unlikely, add them up for
> each interpretation), and if any one interpretation stands out
> as being much more likely than the others, act on it.
Fuzzy? Wow. Problem with it is that, to be robust, you'd still have
to verify with the user that you'd guessed correctly. Well, you
wouldn't HAVE to, but in my day job I write medical software and
there's no guessing allowed, everything has to be verified by the user. :(
>unlock the door
[unlocking the big door]
...
>unlock the door
You mean the big door?
>Steve Dunham
>dun...@gdl.msu.edu
Duane
Steve Dunham
: In article <2l2jq2$17...@msuinfo.cl.msu.edu>,
: Steve Dunham <dun...@cl-next4.cl.msu.edu> wrote:
: [on the subject of ambiguity and parser interpretation]
: [...]
: > 3. If there is more than one interpretation, any of the following
: >actions could be taken:
: > [...]
: > (iii) Give a `unlikeliness' score to each of the possible
: > semantic interpretations (mark unusual interpretations or
: > rarely used constructs as being more unlikely, add them up for
: > each interpretation), and if any one interpretation stands out
: > as being much more likely than the others, act on it.
: Fuzzy? Wow. Problem with it is that, to be robust, you'd still have
: to verify with the user that you'd guessed correctly. Well, you
: wouldn't HAVE to, but in my day job I write medical software and
: there's no guessing allowed, everything has to be verified by the user. :(
The game is only to act on it if the other options are very unlikely
(d.h. very bizarre interpretations of the original sentence).
I only presented this idea, because it came to me as I was typing and
it is very .. convoluted. As I think more about it, I think that it
would be a very rare case indeed that
(a) the sentence makes sense in more than one way in our game
world,
and
(b) all but one of the interpretations is a really odd use of
the language
would both hold; so it would not be worth it in implement the scoring.
(It works very well in TeX's line breaking algorythms though.)
: >unlock the door
: [unlocking the big door]
: ...
: >unlock the door
: You mean the big door?
>unlock the door
Which one?
>the big one
but we would either have to accept:
>unlock the door
Which one?
>drop the cat <-- This violates Pragmatics anyways...
...
or come up with a suitable responce:
>unlock the door
Which one?
>drop the cat
First tell me which door to unlock.
> never mind the door. Drop the cat
You drop the cat. The cat (landing feet down of course) turns,
scratches your leg and runs off.
__
Steve Dunham
dun...@gdl.msu.edu
Duane D Morin
Steve Dunham <dun...@cl-next4.cl.msu.edu> wrote:
>>unlock the door
>Which one?
>>the big one
This is a classic inconsistency with text adventure parsers. Many (most?)
of them will approach ambiguity with a question:
>unlock the door
Which door do you mean, the big door or the little door?
But then fail to accept:
>the big door
As a result. Yet, a classic example of where this was not the case, from
the original Adventure:
>kill the dragon
With what, your bare hands?
>yes
Amazingly enough, you kill the dragon...
I mean, typing "yes" at that point, for most people, would just be frustration,
because experience tells them that what they should be typing is:
>kill the dragon with bare hands
>Steve Dunham
>dun...@gdl.msu.edu
Duane
Carl de Marcken
Some comments on parsers:
I do research in parsing natural language, and know a lot about building
parsers, from simple adventure-game templatic stuff to real ones built around
complex linguistic theories. Let me suggest that as far as adventure games go,
stick with the simple stuff and don't get sidetracked by the misconception that
a better parser would significantly improve a game.
You see, the problem is that the more capable the language interface is, the
more likely it is that people are going to be fooled into believing your game
is smart. This is a classic problem- it comes up all the time in natural
language interfaces, especially in speech interfaces. The advantage of a
primitive TADS-like parser is that its capabilities can be described succinctly
to a game player. After they learn what the 3 or 4 simple templates they can
type in are, that's all they try. So they don't get disappointed and confused
by typing "Walk south but just far enough south that I'm in the doorway." and
finding out that the game's world just isn't complex enough for that to be
a reasonable command.
Think about some of the advertisements companies like Apple have been printing
for their speech recognition software. They show people saying "Open my
favorite word processor." It's a mistake they're making. The reality is that
the underlying technology is only capable of executing predefined macros when
cued by a specific word sequence. So, a person who sees one of these ads and
says "Open my SECOND-FAVORITE word processor" is going to be sadly disappointed
and may not understand why it didn't work. If this sort of confusion happens
in your game, it will leave a naive player with a far worse impression than if
they had merely been told that the game understands only VERB NOUN.
So while you may feel that it would be really cool to be able to type in
real sentences, or have the parser disambiguate complex prepositional-phrase
and relative clause adjunction phenomena, the reality is that it is very
unlikely your underlying world representation will be capable of supporting
this level of language understanding, and the result will be confusing for
most players.
Carl de Marcken
Phil Goetz
In article <CM2o4...@world.std.com>,
Duane D Morin <dmo...@world.std.com> wrote:
>Yet, a classic example of where this was not the case, from
>the original Adventure:
>
>>kill the dragon
>With what, your bare hands?
>
>>yes
>Amazingly enough, you kill the dragon...
>
>I mean, typing "yes" at that point, for most people, would just be frustration,
>because experience tells them that what they should be typing is:
>>kill the dragon with bare hands
But experience didn't tell them that, because Adventure was
a two-word parser. You couldn't type "kill the dragon" either,
just "kill dragon". How was this puzzle implemented in the
TADS version?
Phil
David Baggett
Phil Goetz <go...@cs.buffalo.edu> wrote:
>WARNING: COLOSSAL CAVERNS ADVENTURE SPOILER!
>>>kill the dragon with bare hands
>...
>How was this puzzle implemented in the TADS version?
The game accepts either
>kill dragon
With what, your bare hands?
>yes
or
>kill dragon with [bare] hands
This was one of the more interesting problems with retrofitting a sentence
parser onto Crowther & Woods' classic. I suspect this puzzle is much
harder (for the uninitiated) in the TADS version because of this.
Dave Baggett
__
d...@ai.mit.edu Boot up, log in, drop out. MIT AI Lab
ADVENTIONS: We make Kuul text adventures! Email for a catalog of releases.
PO Box 851 Columbia, MD 21044 USA / CIS: 76440,2671 / GEnie: ADVENTIONS
Duane D Morin
Carl de Marcken <cgde...@ai.mit.edu> wrote:
>I do research in parsing natural language, and know a lot about building
>parsers, from simple adventure-game templatic stuff to real ones built around
>complex linguistic theories. Let me suggest that as far as adventure games go,
>stick with the simple stuff and don't get sidetracked by the misconception that
>a better parser would significantly improve a game.
The question I'd prefer is, "What would it hurt?" I don't want to write a
full blown IF game. I'd much rather write a good parser and give it to someone
else to use in their game. I'm not wasting any time "reinventing the wheel",
because the currently available wheels don't really roll the way I'd like.
Besides, I've always wanted to visit a Wheel Making plant.
>You see, the problem is that the more capable the language interface is, the
>more likely it is that people are going to be fooled into believing your game
>is smart. This is a classic problem- it comes up all the time in natural
>language interfaces,
Eliza syndrome? In a way, what's wrong with it?
>especially in speech interfaces. The advantage of a
>primitive TADS-like parser is that its capabilities can be described succinctly
>to a game player. After they learn what the 3 or 4 simple templates they can
>type in are, that's all they try. So they don't get disappointed and confused
>by typing "Walk south but just far enough south that I'm in the doorway." and
>finding out that the game's world just isn't complex enough for that to be
>a reasonable command.
I'll claim that many of the people that try such a statement will already
have been so Wow'd by the game in the first place that they won't pause
for a second before trying something else. They'll think that it's their
fault that they've done something the computer doesn't understand, and
try something else.
Typical example. Way back when, I wrote a simple Eliza type program (Hey,
who didn't?) I thought it sucked, because I could break it by typing in
the right things, making it produce garbage. Time came for a computer
show (I was working at the local high school) and the computer teacher said
"How to we make a demo out of your program?" I told them no, I wouldn't
show it off, I didn't think it was good enough. But, sure enough, they
demo'd it without me, and I found a roomful of people crowded around
a computer that was basically spitting out gibberish, to me, but absolute
magic to them.
When I write a natural language database query, I don't want to trick my
user into thinking that the computer is smarter than it really is. They
should know how every word of "LIST ALL THE RECORDS WHERE THE ZIPCODE IS
BETWEEN 01604 and 02184 AND THE LAST NAME STARTS WITH S" breaks down
into a request, so that they can efficiently use the program. But,
right now, we're talking about games. There's no need for efficiency.
There's just a need for fun. Ideally, I suppose, a good parser should
give you the feeling that you're talking to someone, instead of the
typical:
<verb> [<object>] [<direct object>...]
I mean, granted, there's no real sense to experimenting if you don't
stop thinking "I'm just telling the computer what to do." I don't have
a particularly good solution that doesn't involve this, though, but
I'm working on it.
>Think about some of the advertisements companies like Apple have been printing
>for their speech recognition software. They show people saying "Open my
>favorite word processor." It's a mistake they're making. The reality is that
>the underlying technology is only capable of executing predefined macros when
>cued by a specific word sequence. So, a person who sees one of these ads and
>says "Open my SECOND-FAVORITE word processor" is going to be sadly disappointed
>and may not understand why it didn't work. If this sort of confusion happens
>in your game, it will leave a naive player with a far worse impression than if
>they had merely been told that the game understands only VERB NOUN.
I disagree first that people will be so quick to experiment like that.
Users, in many cases, are frightened of what they're doing. They don't
want to do what they haven't been told to do. If no one tells them that
they can say "second-favorite word processor", then odds are that most
of them never will. The few that will are the ones that know enough
about the technology to say, "Hey, I wonder if it will understand this..."
"Oops, I guess not." But now we're talking about games, not applications.
The most that's going to happen in a game is your character dies. People
will tend to experiment more. The trick is to push them i the right
direction (by supplying some examples) without letting them fall into
that template trap.
>So while you may feel that it would be really cool to be able to type in
>real sentences, or have the parser disambiguate complex prepositional-phrase
>and relative clause adjunction phenomena,
I was willing to take you at your word that you know parsers. Thanks for
the proof. :)
>the reality is that it is very
>unlikely your underlying world representation will be capable of supporting
>this level of language understanding, and the result will be confusing for
>most players.
<shrug> I say they'd be confused until they learn what does work, and then
they'd stick with that. You don't keep trying to same things over and over
if you've already been given an error message.
>
>Carl de Marcken
>
Duane
David Baggett
Duane D Morin <dmo...@world.std.com> wrote:
>>So while you may feel that it would be really cool to be able to type in
>>real sentences, or have the parser disambiguate complex prepositional-phrase
>>and relative clause adjunction phenomena,
>
>I was willing to take you at your word that you know parsers. Thanks for
>the proof. :)
Oh, that's nothing. Ask him about Molecular Phonology and Spectral Syntax
sometime.
Seriously: I think you're missing the point of Carl's post. If you want to
advance the state of the art in interactive fiction, work on knowledge
representation or a radically new very-high-level IF programming language.
Come up with a reasonably terse way of expressing the knowledge the game
has to have to really make use of a more sophisticated parser, or make
something that learns about its environment as it goes.
There's no point in having a sophisticated parser that you can't make use
of, and as Carl said, it would very likely be a source of confusion. We've
discussed the "adverb anathema" ("give the troll the book *nicely*") at
length here already, and that's just the tip of this iceberg.
If you want to work on making better parsers just for the sake of making
better parsers, more power to you. But I don't think that better parsers
alone will help interactive fiction right now.
Your point about leaving the actual game-writing to others is a bit
distressing. There aren't enough people making real use of the tools that
we have *right now* for us to be worrying so much about better tools.
Given how simple it is to write a basic treasure hunt (which is, I'll
happily admit, what UU2 is) from a technical standpoint, it's surprising
how few games are released. If we are worried about interactive fiction as
a new medium, just getting people to write more ought to be our priority,
in my opinion.
Jon Drukman
>Your point about leaving the actual game-writing to others is a bit
>distressing. There aren't enough people making real use of the tools that
>we have *right now* for us to be worrying so much about better tools.
Although I basically agree with you, I think you are sort of confusing
the issue. The person you are responding to was discussing *playing*
tools, not designing tools. The designing tools are pretty much at
the stage where anybody with enough motivation and a basic knowledge
of programming issues could write a fairly complicated game without
too much difficulty. And there seems to be enough people out there
willing to play a text game with the parsers that are currently
available.
>Given how simple it is to write a basic treasure hunt (which is, I'll
>happily admit, what UU2 is) from a technical standpoint, it's surprising
>how few games are released. If we are worried about interactive fiction as
>a new medium, just getting people to write more ought to be our priority,
>in my opinion.
Well, I've been moving very slowly in the game development area
precisely because of what you mentioned above - it IS ridiculously
easy to write another "find the treasures" game. And I really don't
want to do that. I'm trying to think of something original, but it's
so difficult! (I like to think that my one and only released game
"Busted!" is at least slightly innovative.) I was working on a game
for a while, then Enhanced came out and I found many of its ideas to
bear a striking resemblance to my work-in-progress, so I've had to gut
a large amount of the game. This is actually a blessing in disguise,
because the similarities arose from both of us plagiarising ideas from
the "cyberpunk" genre. What's left of my game is taking on a far
stranger cast. I hope it will be more involving and compelling than
"yet another treasure hunt" and more original than a "genre game"
(where you are transplanted into a well-known literary genre).
"Rylvania" looked good but (as usual with Adventions games) I got
stuck very early on and found the frustration level so unbearable that
I just deleted the binary in a fit of pique. :)
Similarly, I find the continued discussion of how to create more
realistic NPCs to be pretty annoying because I don't think too many
people are thinking about what kind of brilliant scenarios they are
going to put their advanced NPCs *into*. The genius of Infocom (well,
one of the facets of their genius) was the sheer originality of many
of their scenarios. To take an example, A Mind Forever Voyaging was
*fascinating* and I don't think the relatively narrow scope of the NPC
behavior in it weakened the story at all.
There have been some great threads in this group about story design
and how to break the mold, and I've been soaking them all up.
Hopefully something nice will result from it.
Meanwhile, if anybody out there has The World's Greatest Unwritten
Adventure Game Idea but doesn't feel like coding it, talk to me!
Jon Drukman jdrukman%dls...@oracle.com
-------------------------------------------------------------------------------
This calls for a very special blend of psychology and extreme violence.
David Baggett
>These two statements go together. I consider myself a programmer, not a
>writer. This might very well put me in a minority, at least in this
>group. But, at least for me, I always shudder when I hear someone say
>something like "_____ is the best thing in the world! You don't have to
>do hardly any programming at all!"
I certainly agree that in many circumstances, programming is interesting
and enjoyable in its own right. But I'd personally like to see IF tools
advance to the point where the "programming" is really more scripting than
bit-twiddling and list manipulation. As programming tasks go, IF hacking
is really mundane -- thousands of boring cases to handle, each basically an
"if ... then ..." statement. Thirty-thousand lines of this will drive evan
the most steadfast hacker insane, and evey r.a.i-f reader who's written a
full-length IF game seems to have expressed frustration with this at least
once in this very forum. It's *easy* to program these games, but
*tedious*. (I realize I'm not directly addressing your programming bent,
which is towards programming IF *systems* and not IF itself, but this has
been on my mind lately so I thought I'd share it.)
Carl and I once discussed using a system of global constaints to eliminate
some of the tedium. You, the programmer/scripter, would give the system
general statements like
if the pot is on the burner, the contents are heated
if the egg is heated, it will explode
etc.
Here you're still forced to enumerate constraints, but you don't have to
worry about handling, in tedious detail, each *set of circumstances* that
could create the environment for a constraint above. To be more clear:
There are many ways an egg could end up in a pot, and the pot on the hot
burner -- you could do any of the atomic actions
turn on burner
put egg in pot
pot pot on stove
in any order. Current IF systems force you to handle any order of events
explicitly, and this complexity is where the tedium (and potential for
mistakes) comes in.
Imagine, however, a system like Carl envisioned, but augmented
with the notion of classes. You could then say things like
if a fooditem is heated, it will get burned
where "get burned" is some standard method, which could be by default
inherited as-is from the fooditem class. Perhaps all fooditems would
automatically inherit the constraint too.
One difficulty with this approach is that it may prove tricky to make a
system that maintains all these global constraints without slowing to a
crawl. Unlike current IF programming paradigms, this constraint approach
does not scale well -- the larger and more complex your game, the slower it
will be.
RoboZapp
>These two statements go together. I consider myself a programmer, not a
>writer. This might very well put me in a minority, at least in this
>group. But, at least for me, I always shudder when I hear someone say
>something like "_____ is the best thing in the world! You don't have to
>do hardly any programming at all!" I *like* programming. Far more,
>in fact, than filling in the game around it. If I ever do produce a
>game of this genre, it's literary merit will be weak. But it will have
>a few things that I hope are innovative enough to get people to notice
>it. THEN I can worry about using the new tools to write a great game.
I will have to agree with you here. I do have a much stronger
background in programming than in writing well, but I do dabble a little
in IF. (If I didn't, I wouldn't be reading this group. <g>). One of
the reasons that I am a TADS fan is because it allows me to do
programming, but already has a good base. Any time I have a chance to
choose between something that allows me to code, or ot choose between a
list of menu items, I will pick the one that allows me to code. As an
example, I ran a BBS in my day. I was a big fan of Telegard, because I
figured that the menu editor was the next best thing to being able to
actually program extentions to the software, although it was very
limited. It just feels like I have more power when I am actively
programming something, rather than clicking on dialogue boxes.
Gerry Kevin Wilson
file in Avalon called NPC.T which is basically a set of switch statements.
The code is long, ugly, and frequently confusing even to me, and I wrote it!
While I like programming, I think it should be reserved for things like
making Trinity-style poem boxes pop up in the middle of the screen. When I'm
doing something repetitious, I want it as abbreviated as possible.
--
<~~~~~E~~~G~~~~~~~~~~~HEINLEIN~~~~~~~~~~~DOYLE~~~~~~~~~~~~~SPAM~~|~~~~~~~>
< V R I O Software. We bring words to life! | ~~\ >
< T | /~\ | >
<_WATCH for Avalon in early MAY!____wh...@uclink.berkeley.edu_|_\__/__>
Mike Roberts
> The advantage of a primitive TADS-like parser
So much for my claims of having a sophisticated parser (and so much
for my ego :) :).
> typing "Walk south but just far enough south that I'm in the doorway." and
> finding out that the game's world just isn't complex enough for that to be
> a reasonable command.
> ...
> If this sort of confusion happens in your game, it will leave a naive
> player with a far worse impression than if they had merely been told
> that the game understands only VERB NOUN.
I totally agree. This is exactly why I've been encouraging game
authors to think in terms of a minimal vocabulary set rather than
getting too carried away with parsing. I think the LucasArts games,
with their 12 (or so) verbs and totally regular sentence structure,
have the least intrusive "parsers" I've seen. It's really nice as a
player to know exactly what the constraints of the underlying system
are. Lots of people complain that its frustrating not to be able to
type "KICK IN THE DOOR" when they feel like it, but I think it's much
better to be able to see that something's obviously not an option, by
having all options clearly laid out for you, than to have to type it
in to find out that it's not an option -- I don't see that "You can't
kick in the door" is any better than not being able to express it in
the first place.
--
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
Erik Max Francis
> >examine picture in chest on table
>
> Then that works, too. :) I suppose we'd have to have something in there
> to verify whether or not the case of <OBJECT><RELATION><OBJECT> was an
> appropriate description, to help knock out some ambiguity.
Interesting post. I should point out, though, that in this case,
you'd implement the delimiter "which":
>examine the picture in the chest, which is on the table
After all, all you have to do is think about how you'd say it in
English. If you have to explain to the player how such constructs are
made when they're not English, then you've missed the point of
parsing.
I don't think many (if any) "standard" parsers handle a third level of
indirection. Most of the time indirection is ignored.
Erik Max Francis, &tSftDotIotE ...!uuwest!alcyone!max m...@alcyone.darkside.com
USMail: 1070 Oakmont Dr. #1 San Jose, CA 95117 ICBM: 37 20 N 121 53 W __
AGCTACTGTACGTACGTTTGCACGTATGCTGTGCAXTGCATACTGACATCGTGACTGATCTGCATGACTTGCA / \
"Omnia quia sunt, lumina sunt." (All things that are, are lights.) \__/
Erik Max Francis
> This is a classic inconsistency with text adventure parsers. Many (most?)
> of them will approach ambiguity with a question:
>
> >unlock the door
> Which door do you mean, the big door or the little door?
>
> But then fail to accept:
> >the big door
It strikes me, in passing, that it should accept "the former" and "the
latter" as answers to this question when there are exactly two
choices.
This is something that I've wondered about on and off for some time
now. Should the cursor change when the computer is asking you a
question (to confirm, or to clarify)? I think it should:
>unlock the door
Which door do you mean, the big door or the little door?
:the big one
Unlocked.
Also, how far should these synonyms extend? For example, if I type
SHOOT THE GIRL, should the parser ask me
Which girl do you mean, Shirley Temple or the hardened prostitute?
Erik Max Francis
> But experience didn't tell them that, because Adventure was
> a two-word parser. You couldn't type "kill the dragon" either,
> just "kill dragon". How was this puzzle implemented in the
> TADS version?
Huh? The Adventure that I played when ported to the IBM PC (and boy,
was it an old version) understood direct objects and to ignore
articles; i.e., THROW AXE AT TROLL or KILL TROLL WITH AXE.
Matthew Amster
Max Francis) writes:
>This is something that I've wondered about on and off for some time
>now. Should the cursor change when the computer is asking you a
>question (to confirm, or to clarify)? I think it should:
>
> >unlock the door
> Which door do you mean, the big door or the little door?
>
> :the big one
> Unlocked.
This can be done easily in TADS 2.1. Check your docs; I don't have them
handy.
-----------------------------------------------------------------------------
Matthew Amster Pomona College mam...@pomona.claremont.edu
"The master's tools will never dismantle the master's house." -Audre Lorde
David Baggett
Erik Max Francis <m...@alcyone.darkside.com> wrote:
>
>Huh? The Adventure that I played when ported to the IBM PC (and boy,
>was it an old version) understood direct objects and to ignore
>articles; i.e., THROW AXE AT TROLL or KILL TROLL WITH AXE.
Don't know what version you were playing, but the original DEC-10 sources
indeed handle only two word commands. I think the Microsoft version (which
is what most PC owners probably played) was also limited to two word
commands.
Duane Morin
>This is something that I've wondered about on and off for some time
>now. Should the cursor change when the computer is asking you a
>question (to confirm, or to clarify)? I think it should:
>
> >unlock the door
> Which door do you mean, the big door or the little door?
>
> :the big one
> Unlocked.
I like it.
>Also, how far should these synonyms extend? For example, if I type
>SHOOT THE GIRL, should the parser ask me
>
> Which girl do you mean, Shirley Temple or the hardened prostitute?
Might depend on how you're introduced to each character. I mean, do
you originally get:
There is a young girl here.
>ask girl about name
"Shirley Temple."
You should still be able to refer to her as "girl". But:
Shirley Temple is here.
THen it might become optional. Anybody gonna write a politically correct
adventure game?
There is a woman here, doing her husband's taxes.
>ask girl about taxes
"Girl?! GIRL!! DO I LOOK LIKE A GIRL??"
:)
>Erik Max Francis, &tSftDotIotE ...!uuwest!alcyone!max m...@alcyone.darkside.com
Duane
R. Alan Monroe
> >unlock the door
> You mean the big door?
Personally I don't like this type of screen prompt (note I'm not flaming
the orginal intent of the thread, which was good)
You're never quite sure whether you're supposed to type
:Yes
or start over and type
:unlock the big door
Becuase you don't know if "you mean the big door?" is rhetorical or not...
How about "You mean the big door? [Y/N]"
My 2 cents...
--
Have fun
Alan
Yeah, my doctor told me I have Attention Deficit Dis... Hey what's for lunch?
Jon Drukman
>now. Should the cursor change when the computer is asking you a
>question (to confirm, or to clarify)? I think it should:
> >unlock the door
> Which door do you mean, the big door or the little door?
> :the big one
> Unlocked.
i don't like this model because a good parser should let you change
your mind.
>unlock door
which door do you mean, the big one or the little one?
>east
(new room description)
the other way doesn't give you an out.
>Also, how far should these synonyms extend? For example, if I type
>SHOOT THE GIRL, should the parser ask me
> Which girl do you mean, Shirley Temple or the hardened prostitute?
why not? as long as "girl" is an acceptable way to refer to either of
the two items, the ambiguity should be resolved. if you're asking if
"Shirley Temple" and "hardened prostitute" should both have "girl" as
a descriptor, i probably wouldn't program it that way but others
might.
Ross Cunniff
> m...@alcyone.darkside.com (Erik Max Francis) writes:
> >This is something that I've wondered about on and off for some time
> >now. Should the cursor change when the computer is asking you a
> >question (to confirm, or to clarify)? I think it should:
> > >unlock the door
> > Which door do you mean, the big door or the little door?
> > :the big one
> > Unlocked.
> i don't like this model because a good parser should let you change
> your mind.
> >unlock door
> which door do you mean, the big one or the little one?
> >east
> (new room description)
> the other way doesn't give you an out.
Well, I hate to boast, but ADL handles this correctly; here's an example:
Museum entrance You are standing outside the north entrance of a
large brick building. Inscribed above the doorway, appear the
text: 'AARDVARK'S MUSEUM -- GATEWAY TO ADVENTURELAND'.
There is a coil of rope here.
There is a shovel here.
There is a carbide-flame lamp here.
There is a copy of a newspaper here.
> take
You must tell me what to take.
> south
Museum rotunda
You are in a large rotunda of an old museum. Doors lead to the
north, south, east, and west, and a narrow stairway in the
north-east corner of the room leads down.
There is a ball-point pen here.
There is a slip of paper here.
> north
Museum entrance
You can see:
a rope
a shovel
a lamp
a newspaper
> take
You must tell me what to take.
> rope
rope - taken
Note that the player initially decided not to take anything, and leave
the room. Later, they do take the rope. The mechanism for this
involves a partial parsing of the sentence, and recognizing that no verb
is present. If no verb is present, then the system verb NOVERB is used
instead. NOVERB knows, in this case, that the previous verb was 'take',
so it uses 'take' as the verb. The exact same thing can be done in
reverse; e.g.:
Museum entrance You are standing outside the north entrance of a
large brick building. Inscribed above the doorway, appear the
text: 'AARDVARK'S MUSEUM -- GATEWAY TO ADVENTURELAND'.
There is a coil of rope here.
There is a shovel here.
There is a carbide-flame lamp here.
There is a copy of a newspaper here.
> rope
What do you want to do with the rope?
> take
rope - taken
It's all mostly built into ADL, with a little help in the standard.adl
file. Sigh. Someday I'll get around to improving ADL to make it more
competitive with TADS... Too many projects, too little time...
Ross Cunniff
Hewlett-Packard Graphics Software Lab
cun...@fc.hp.com
Memo to myself: do the dumb things I gotta do. Touch the puppet head.
Jamieson Norrish
Alan Monroe) writes:
> >unlock the door
> You mean the big door?
Personally I don't like this type of screen prompt (note I'm not
flaming the orginal intent of the thread, which was good)
You're never quite sure whether you're supposed to type
:Yes
or start over and type
:unlock the big door
Becuase you don't know if "you mean the big door?" is rhetorical or
not...
How about "You mean the big door? [Y/N]"
This looks ugly, IMHO. I think again that the problem can be solved if
the author states at the beginning a little of how the game works. By
telling the player that such questions can always be answered by a
"yes/no" or not, the problem is removed.
Jamie