[MUD-Dev] [Theory?] Parsing of knowledge to allow for more interactive NPCs

[holding99 at mindspring.com]

At 11:45 AM 12/22/2001 -0600, Robert Zubek wrote:

> First, parsing out the object of a command may be more tricky than
> you describe. While it's simple to parse simple second-person
> action-target commands ('hit the monster', 'take the apple' etc.),
> more complex commands will introduce ambiguity that will somehow
> have to be dealt with. Consider a command such as 'hit the man
> with the broom' - does it mean 'hit with the broom' or 'the man
> with the broom'? That is, how do you know how to parse out the
> object - does the prepositional phrase apply to the action, or to
> the object?
 
> There's no good structural way of dealing with this, so you will
> either have to establish usage rules (which as an engine designer
> you can always do), or the parser will have to include some kind
> of a semantic module to disambiguate. For example, it may have to
> look at both the agent's and the target's possessions, and parse
> the sentence in a way that best accounts for the extraneous
> broom. This now ties the parser into the knowledge base, and will
> have to be implemented with care, because the parser's behavior
> may end up communicating world knowledge that the player shouldn't
> have access to (such as who owns what).

<snipped>

Addressing this issue actually requires I give some information both
on the inventory system I plan to use and on the way I would like
command parsing to work.

First, there would be no general inventory. While I do plan to keep
wear locations (in a somewhat general way), using and handling a
thing requires a free hand (or sometimes, two free hands). Anything
you want to carry must be put into something else, such as a pouch
on your belt or a pack on your back. Therefore, "hit (the man) (with
the broom)" would elicit a parser error if you did not have a broom
in your hand.

Secondly, the parser will find all objects referenced in the command
when it is input, as seen by the player issuing the command. So,
"hit (the man with the broom)" will also elicit a parser error, if
there is no one visible to me who has a broom. For example, if Bubba
is carrying a large box with a lid, the mud will not allow me to
"hit the man with the broom", since even if I think there's a broom
in that box, I can't see it.

However, there are two problems with this approach. The first, and
more obvious one, shows up in the above example. If Boffo sees Bubba
put a broom in his box and close the lid, he should be able to "hit
the man with the broom", even though he can't currently see the
broom in the box. In other words, he should remember it's there. I
personally don't have too much of a problem with that; while it
would be nice to have the character remember such information it
opens a can of worms in terms of what happens when Boffo see Bubba
and his box two days later. Is the broom still there or not? In this
case, checking the current status of the broom-in-box system could
give unnecessary world knowledge. I prefer that the parser return
"You don't see a broom here", and leave it up to Boffo's player to
connect the dots between the broom and the box.

The second, and more insidious, is the use of the word "with" in
terms of the knowledge chunks I posted before. It's actually not
just "with" that causes a problem; "of" is equally problematic, and
I am sure I could think up others if I were more
motivated. Prepositional phrases of this sort basically act as extra
long adjectives, in that they describe more fully the noun of
interest. I'll call them prepositional adjectives, to distinguish
them from the normal, one word variety. When I described the noun
chunk, I assumed that any adjectives would be one word or hyphenated
(which is a way of treating two words like one). That way a single
string could contain several adjectives, each of which could be
(fairly) easily separated and used for identification
purposes. Prepositional adjectives, on the other hand, can sometimes
be simplified into one word, and sometimes cannot. For example,
"ball of wax" can be simplified into "wax ball", but "ball of Bubba"
might be "Bubba ball" (a Pokemon-type ball that somehow produces a
Pokemon-type Bubba), or it might be "Bubba's ball" (in that Bubba
made it or somehow caused it to become famous). I am not quite sure
how to handle that, especially considering how often such constructs
are used in the English language (thus, I don't feel comfortable
just ignoring it). I am quite open to suggestions.

<more snipped>

> However, similar ambiguities surface here, especially when there
> is more than one good binding for the pronoun. Consider:
 
>      "take the apple from the box and lock it"
> vs.
>      "take the apple from the box and eat it"
 
> Again, structurally they're the same, and there's more than one
> good binding for the ambiguous pronoun. What lets us understand
> one command one way, and the other a different way, is the
> common-sense knowledge of the world: we know that apples are not
> very lockable, and boxes not very edible. This could again be
> implemented by requiring the parser to examine the functions that
> each object can perform, and parsing the sentence in a way that
> makes most sense. Even though it won't work as an approach to
> general natural language understanding, it should do quite well in
> a MUD. And when the human requests something completely vague,
> such as "lock the box with the key and drop it", the engine should
> probably just give up and double-check with the user (eg. "Do you
> mean drop the box or the key?"), because even a human would have a
> trouble with a command like that.

An excellent example, and one I had not considered. In fact, I am
tempted to disallow compound commands (two commands linked with the
word "and") just to eliminate that possibility. I will probably just
have the parser give up in such a situation and ask. While I
wouldn't mind making some assumptions as to the player's intentions
(such as eating an apple as opposed to a box), I am not sure how I
will implement the assumption-making process. Perhaps flag each item
with an "intended use".

> So much for my rant on ambiguity. Oh, and the final note on
> professional NLP literature - don't be discouraged, it's meant to
> be overpowered. The research on NLP attempts to capture language
> usage in most intricate detail, so it will inevitably lead to
> tools that are extraordinarily complex. For the purposes of
> command-parsing in MUDs most of this research probably won't be
> useful, since it deals with phenomena that are much more
> complex. Instead, I too would be curious to hear what actual MUD
> developers have successfully used in their systems.

I have completely given up on the professional literature. While it
seems they've come up with some incredibly powerful tools, I have
decided that they're trying to solve a different problem. I am also
interested in what success others have had in writing NLPs for use
in muds. I know that Infocom had developed what seemed to be an
incredibly sophisticated text parser, but I do not know how it
worked (I got lost in the details of the Z-machine - I am not good
at deciphering the code of others), nor do I know how well it would
perform in a multiplayer game where the world state is not as well
defined. I am fairly sure that actual implementation issues of a NLP
has not been discussed previously (at least, I did not turn up
anything tangible in the archives).

T.H. Cooke

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev