English command parsing (long!)

[David Graves]

Thanks, Phil, for your extensive outline of your parser's design. I thought
I should respond with a posting contrasting your design with mine. Hopefully,
some of this will be interesting to readers of this group.

Like Phil's parser, I use a large dictionary, with attributes attached to
entries for each word type (verb, noun, adjective, etc). Many words have
multiple attributes. For example, "water" may be used as a verb ("Water
the plant") as a noun ("Drink the water") or as an adjective ("Take the
water glass"). Unlike Phils, my lexical analizer does not remove articles
(a, the), demonstratives (those, these) or intensifiers (very, extremely).
(These words are optional, though, so the user may omit them).

My parser is also an ATN, where each node in the network is represented by
a function. Phil indicated some of the difficulties of implementing his
ATN in assembly language -- I didn't have to deal with these problems since
I used a high level language.

It seems that in Phil's design, the parser contains enough knowledge to
resolve all ambiguity in the command, and thus correctly fill certain slots
for the command handlers. I opted for having the parser do only syntactic
analysis, moving all semantics out to the command routines. The command
routines do semantic validation, fill in any slots which are only implied
by the player's command, and determine any implied actions which are
prerequisites to this action. For example, if there is a beer on the table
and the player says "Drink", the drink command handler can determine that
you must mean the beer, so it fills the direct object slot with the object
ID for the beer. (The parser could not have done this unless it had
knowledge of the semantics of all the verbs -- quite a large rule base).
Besides knowing to look for the implied edible liquid, the Drink routine
knows that containers must be open to allow drinking, and that the beer
should be in hand. Rather than giving error messages such as "You aren't
holding the beer", or "The beer isn't open", the Drink routine pushes the
goals "Get the beer" and "Open the beer" onto the player's goal stack.
(Each character, including the player, has his own goal stack). Some goals
may give rise to other goals, but eventually all prerequisites are met and
the Drink routine gets to do it's thing. Text is generated to describe the
action, something like: "You take the beer from the table, open it, and
drink from it."

Sometimes a command routine finds that the command means something different
than simple syntax would imply. For example, "Remove" is a verb allowing
you to take off a garment, but "Remove the cork" is really a request to
open a bottle. The Remove routine modifies the command slots a bit, then
passes control to the Open routine. Thus, the command routines form a
loose semantic network, depending on each other to resolve prerequisite
actions, and "referring customers" to each other when they discover that
a command is outside of their own domain of knowledge.

For a more complete description of my parsing and semantic processing, see
"Second Generation Adventure Games" in Vol 1, number 2 of the Journal of
Computer Game Design. (Address of the Journal is currently posted in
rec.games.programmer).

David Graves d...@hpsemc.hp.com

[Ian Farquhar]

>For a more complete description of my parsing and semantic processing, see
>"Second Generation Adventure Games" in Vol 1, number 2 of the Journal of
>Computer Game Design. (Address of the Journal is currently posted in
>rec.games.programmer).

Rec.games.programmer is not received at this site, so would somebody
mind sending me the address of this Journal? My e-mail addresses are
below, though ifar...@macuni.mqcc.mq.oz.au address is preferable.

Thanks.

"AI is also an acronym for Artificial Ignorance"

Ian Farquhar Phone : (612) 805-7420
Office of Computing Services Fax : (612) 805-7433
Macquarie University NSW 2109 Also : (612) 805-7205
Australia Telex : AA122377

ACSNet ifar...@macuni.mqcc.mq.oz.au ifar...@suna.mqcc.mq.oz.au
D

[Miles Gillham]

In article <2...@macuni.mqcc.mq.oz> ifar...@mqccsunc.mq.oz (Ian Farquhar) writes:
>>For a more complete description of my parsing and semantic processing, see
>>"Second Generation Adventure Games" in Vol 1, number 2 of the Journal of
>>Computer Game Design. (Address of the Journal is currently posted in
>>rec.games.programmer).

>Rec.games.programmer is not received at this site, so would somebody
>mind sending me the address of this Journal? My e-mail addresses are
>below, though ifar...@macuni.mqcc.mq.oz.au address is preferable.

[ What a tongue-twister! :-) ]

In fact, rec.games.programmer is probably not received anywhere in Australia
yet... Could you please post the address to this group for all the many
attentive oz gamers? (If any :-) Or at least cc me too, please.

Thanks,

Miles Gillham, m...@lance.oz.au
Yinkel, n.:
A person who combs his hair over his bald spot, hoping no one
will notice.
-- Rich Hall, "Sniglets"

[David Graves]

The Journal of Computer Game Design's target audience is professional
game designers. Subscriptions are $30 for a year (which gives you six
issues). You can send your order to The Journal of Computer Game Design,
5251 Sierra Road, San Jose, CA 95132. Each issue is about 16 pages, with
small type.