[MUD-Dev] Object Representations?

[Robert Zubek]

KevinL writes:
 > What I'm doing at the moment is just packaging up all the text outbound as 
 > basic data packets - clumps of text.  What I'd _like_ to do is somehow 
 > indicate, within that, which bits are important - give the client a leg-up
 > on parsing this stuff.  Bearing in mind here that the client need not be a 
 > player-run program, it could be an NPC's AI, so distinguishing objects from 
 > text is very useful...

i've only limited experience with this - i worked on a lisp-based ai
mud agent with an inference engine to reason about what it had to do
in the world - but i think i can help by illustrating some of the 
world-interface problems that we encountered in the process.

distinguishing object information from description turns out to be 
*absolutely necessary* for any sort of ai npcs. we quickly realized
that parsing salient information out of a text description was not
only tedious, but very error-prone. the solution was of course to add
another display mode to the engine. the new display mode included all
of the publicly-available object information (along with description)
in a machine-readable format.(*)

for instance, when the output of a look command would originally 
be something like:

      The city center temple
      You see:
        The temple chaplain
        A newbie handbook

our output would be:

      <LISP (ROOM (ROOM-NUMBER 1) (DESC "The city center temple"))>
 
      <LISP (CRITTER (ID 92)
            (DESC "The temple chaplain")
            (COMPARE 3042)
	    (NAMES "chaplain" "priest"))>

      <LISP (ITEM-IN-THE-ROOM (ID 103)
            (DESC "A newbie handbook")
            (NAMES "handbook" "book"))>

by the way, the representation we settled on was lisp alists
(that is, key-value lists, as in: "((key1 value1) (key2 value2)
...)"), just because it simplified parsing on the lisp end. :)  
any syntax that supports key-value pairs would've done fine.

the representation included first the type of data (room, mob, item,
action, etc.) and then whatever additional information was
appropriate - such as object keywords and unique ids. the former were
included to once again eliminate the need for language processing
(ie. why can i refer to 'the big book' as 'book' but not as 'big'?),
and the latter to solve issues of continuity (ie. is the broken sword
i have now the same object as the good sword i had before i fought the
great dragon?) which would've been more than we wanted to handle. :)
for monsters we also included traits like relative strength (easily
obtainable via 'examine' command) and whatever else was visible to the
user.

in addition to object descriptions, pretty much every event that could
happen in the engine was also represented in machine readable way - so
witnessing someone attack the priest would look something like:
  <LISP (ACT (ATTACK (SUBJECT 205) (OBJECT 92)))>
the particular ontology of actions (ie. hit, buy, sell, go, etc.) was
based directly off of what the engine supported. 

and so, what ended up happening was that we made a machine-readable
representation of *everything* in the world (objects, actions, emotes,
expressions, etc.) as simple alists, and if the user turned on the
"lisp display mode", these lists would get displayed along with
regular text descriptions. it worked quite well, especially since our
agent could then simply ignore everything except for lisp forms. :) 

rob


(*) ps. if the item descriptions look familiar, it's for a good reason -
since we concentrated on an intelligent agent, we thought it would be
best to run it in an existing mud engine rather that build a new one -
and the engine we picked was scrymud. it turned out to be quite a nice
engine, especially in terms of OO design and multilingual support.
kudos to the authors! 


--
Robert Zubek 
rob at cs.northwestern.edu



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