mud grammar (was Re: Just a bit of musing)

[Nathan Yospe]

On Mon, 10 Mar 1997, Carter T Shock wrote:

:> From: coder at ibm.net
:> A good MUD grammar is incredibly context sensitive.  A simple example is
:> the case where the presence or proximity of an object adds verbs to the
:> players.  There is no need for this crap to wander thru the global
:> namespace, or even warp the general grammar.

Agreed. An object in someone's possesion (in one of their bags or pouches,
for example) might generate a certain set of new verbs for the owner, and
in hand, a new set of new verbs, ie a grenade might enable "prime" as a
verb, when held. I accomplish this by means of references in my internal
language attatchment scheme. Another example is: there is a horse in the
room. The new verb "mount" has been enabled. "mount", in my system, might
refer to a real function not normally accessed by the player, or to a
bytecode function written in my internal programming language.

<snipped>

:Lessee... in most mud worlds, the "nouns" are dynamic, but the verbs are
:not. I put nouns in quotes because often a noun/adjective pairing is
:required to uniquely identify an object (the long sword, the black sword,
:etc.). The verbs in the system are your commands. cast, throw, hit, etc. If
:we want to allow dynamic or generic verbs, now you're getting into natural
:language processing and I definitely don't want to go there. So there are
:some distinct sentence structures that emerge:

Hmmm. I, personally, am for dynamic verbs. Thus, my natural (command form
only, so far) language parser.

:<verb> <object>  "hit foo"
:<verb> <object> <object> "give gold foo" "cast fireball foo"
:
:So the first trick is to define your grammar... establish a mapping of
:verbs to appropriate objects. We'll start with "hit". In most codes if you
:"hit foo" the code first sees what the allowable targets are for foo, then
:tries to locate a foo somewhere in the world that satisfies the target
:rules (get_person_room_vis(), get_obj_room_vis() whatever). The basic flow
:doesn't change a whole lot. We still have classes of objects... people,
:things, places, etc. One solution is to write our lexical analyzer so it
:enforces target rules. Another is to write objects so they can respond to
:any command 

My objects respond with a boolean for recognized on a command, resulting
in a list of possible objects. The context engine then locates the proper
choice. shoot, for example:

<verb>       <object>       <meanskey>    <means>
<shoot> <the purple dinosaur> <with> <the rocket launcher>

<verb>        <object>     <lockey>  <location>
<shoot> <the purple dinosaur> <in> <the kitchen>

<verb>       <object>      <speckey> <specifier>
<shoot> <the purple dinosaur> <in> <its left eye>
<shoot> <the purple dinosaur> <'s> <left eye>

And these are the simple examples. Of course, unless there is a reason to
specify, and the time to specify (IE: set up a good shot) you usually type
"sho dino" and be done with it.

:(I've done sort of a mix here. Done in C++, the base generic
:object has a handler for all available commands, all of which respond "You
:can't do that" or somesuch. Real objects are derived from the base. For
:commands that make sense on the derived object, overload the virtual
:default handler, multiple levels of inheritence work nicely here).

Of course, this assumes preset commands, something I'd hate to have.
Instead, I have my String class parse things as above, and feed the
results to the verb and the various potential objects. An object will
respond if it recognizes a verb that _needs_ to be recognized (IE: prime),
but some verbs are universal, and never bother asking the object for
permission (IE: shoot).

:An example of where this works very nicely is with magic. Identify the verb
:"cast" as special in your lexical analyzer. Rather than
:<verb> <object> <object>
:it becomes
:<verb> <spell> <object>

Hmmm. Well, yes. But that functionality could just as easily be built into
cast with a good String parser.

:Now the question, why bother?
:Well, first off, it can make the mud more user-friendly. Rather than simply
:reporting "huh?" on bad commands, a true parser should be able to:
:	1) report the exact location of the error in the command
:	2) offer up suggestions (tab completion of commands)
:Now, we could do all of this without learning lex/yacc, but doing it in
:lex/yacc gives you a standard interface.. not to mention someone else has
:written most of the ugly code for you already. Btw, the newer flavors of
:the GNU lexer/parser software (glex and bison I think) offer up a C++
:version that encapsulates the parser as an object. Nifty side effect is
:that you can have more than one. So, if you really want to screw with the
:user's minds you could conceivably have different command sets in different
:parts of your world. (something along Zelazny's Amber... the physics are
:different in the place you've warped to so the commands, spells, etc are
:different). Wait, it gets better... if we want to link up muds, there are
:ways that one mud could export its parser object to another so, if you
:wanted, you could process commands for a user in the remote mud locally
:(not sure why you'd want to, but hey.... explore the possibiliteis :)

Now, that might be interesting. I wrote the whole thing in C++, didn't
find it very ugly, and thought it worked quite well, and fast enough for
my tastes. But that's just me. Incidentally, I used the keys as 
breakpoints. (in, at, on, over, etc) I find that I rarely need to parse an
unbroken set, though the parser will do so if required.

   __    _   __  _   _   ,  ,  , ,  
  /_  / / ) /_  /_) / ) /| /| / /\            First Light of a Nova Dawn
 /   / / \ /_  /_) / \ /-|/ |/ /_/            Final Night of a World Gone
Nathan F. Yospe - University of Hawaii Dept of Physics - yospe at hawaii.edu