[MUD-Dev] re: Language Parsing for NPCs

[Robert Zubek]

[ with apologies for the delayed reply - this has been a busy week ]

Aaron Mulder writes: 

> First, I strongly agree that a repository of generic
> conversational logs would be really helpful.  But someone else
> pointed out that in many environments, players have been trained
> to use keywords, so the logs aren't as distinctive as they might
> be.
 
yes, that's very true. which is why there should probably be
emphasis on logs of players *talking among themselves* while trying
to accomplish some goals in the world, rather than logs of
conversations with npcs. and certainly, humans will use more complex
language while talking to other humans, but as you say, there won't
be as much information in logs of people just issuing keyword
commands to the npcs.

this of course presents the problem of privacy - so long as players
know their conversations could be recorded (with all the names
changed, of course), all will be fine. but they do need to realize
that.

 
> As for where I'm heading with all this, here's my theory so far:

   [my summary:] 
   1. parsing and disambiguation.  
   2, 3. extracting semantic structure from the parse tree
   4. doing something with the extracted semantic structure 

yes, i agree - and each of these steps by itself is a difficult
problem. even considering the disambiguation problem you mentioned:
"i ran a mud with a really smart npc" - there isn't a way to guide
the parsing of this sentence without already knowing what muds are,
what npcs are, that muds contain npcs, the word 'with' can be used
to express such containment, etc.  syntactic processing is amazingly
intertwined with semantic processing - sentence parsing builds on
the semantic knowledge of the world (and, i might also add, the
pragmatic understanding of what the other person is trying to
communicate), but also vice versa, knowledge of the world builds on
what gets extracted from the parsed sentence.

fortunately for us, we're not dealing with full-blown human
environment here. mud worlds limit the problem in interesting ways -
unlike in the real world, in muds there is a finite and small number
of discrete actions you can perform (take, hit, go, etc), a
reasonably limited set of stereotypical things to do in the world
(ie. go on a quest, practice skills, etc.), and if you impose a
grammar on emotes the way skotos does, for example, there will also
be a well-constrained set of ways to express emotions, gestures, and
postures.

on the plus side, this makes the problem of figuring out what's
going on in the mud much simpler than in real-world ai, which has to
deal with an irregular world where objects are fuzzy and loosely
defined (eg. the problems of visual recognition - how can a robot
tell if something is a table? what makes a table?), and humans who
talk about things like politics or favorite tv shows, which require
immense real-world knowledge.

however, even though the problem is made easier, it doesn't make it
at all easy. :) understanding a sentence and doing something with it
will require large amounts of explicitly encoded knowledge about
what life in a mud is like, from taxonomies of objects
(eg. blade-of-doom isa two-handed-sword isa sword isa weapon isa
object) to representing actions and consequences (eg. attack has two
outcomes, success or miss, where success results in injuring the
opponent, and the probability is a function of your strength and the
attack points of the weapon you're holding), to representing typical
actions that people can engage in (for instance,
kill-a-monster-quest script involves 1. acquiring necessary items
and skills, 2. traveling to the monster's lair, and 3. performing
the deed). but how to represent this knowledge? what kind of a
codification to use? (formal logic?  associative networks? frames? 
scripts?) there is no single best answer.

taxonomy (ie. class hierarchy) of objects can probably be extracted
directly from the mud engine, but the rest of the stuff will have to
be built from scratch, fitted to some particular mud, and probably
many times reevaluated, torn down, and rebuilt. but that's cool,
because knowledge engineering is really difficult, and it takes many
tries to get a useful representation of a new domain.

which is where we come in. :)


--
Robert Zubek 
rob at cs.northwestern.edu
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev