[MUD-Dev] Re: MUD verb handling (Was: DevMUD - thoughts.1)

[Jon Leonard]

On Sun, Oct 25, 1998 at 12:54:34PM +0100, The Arrow wrote:
> On Sat, 24 Oct 1998, Chris Gray wrote:

[stuff about parsing, like LPC's individual objects parsing user commands,
and his (Chris Gray's) grammar system]

> Hmm, reminds me of the system I have thought of for my mud.  However, I
> haven't got anything else than some random thoughts and a yacc grammar for
> my mud-language (based on a mix of C and the IF languages Hugo and Inform)
> for the definition of the verbs.  Verb handlers exists either as functions
> in the mud language, or not at all (a "Huh?!?" type message gets written),
> and all mud-objects may have one or more (or none) after and before handlers
> wich gets called after and before the verb default function.  The after and
> before handlers can return false to stop the verb parser from searching for
> more handlers and not execute the default verb function.
> For example, assume Bubba the human tries to pick up a rock, the rock object
> have a a before handler for the OnGet verb that checks the strength of the
> actor and prints "The rock is to heavy for you." message and returns false
> if the actors strength is to small, making the rock ungetable for Bubba.

I implemented something like this back when I ran an LPmud.

In the scheme I used, verb handlers had a string and a priority.  When
a player typed a command, the handlers were run through in priority order
until one returned success.  Handlers that failed also had the option of
setting the error message, so that if no handler matched, an error message
more meaningful than the default "What?" could be displayed.

For example, if there were two rocks in a room, one of which was just
scenery, the scenery rock would define a get function, but it's only
behaviour was to fail and set an error message saying that it was too
heavy to pick up.  The other rock would have normal get behavior.

That way, "get rock" the first time would pick up the movable rock even
if it got checked second, and subsequent attempts would print the
appropriate error message.

This worked reasonably well for commands that succeeded, since it ran
down the list of functions in priority order, and usually picked the most
sensible result if more than one could succeed.  If there were multiple
failure messages (and no successes), then it would print the error message
for the least likely one, which wasn't always so sensible.

I eventually concluded that the proper way to do things was not to have
verb handlers defined by objects at all, because there isn't a good way
to find the most useful error message to print if a given command has
several interpretations, none of which work.   I favor systems where each
potential action (verb in this context) has a handler, and it then queries
objects to see what's the best way to proceed.  Localizing the error
handling makes it easier to do a good job with it.  (The side effect of
avoiding guess the verb games was a bigger motivation.)

I think that a mud configuration using object-defined verbs should get
implemented in DevMUD, but my ideal remains the system where the parser
(whichever one is appropriate for the natural language the user typed)
translates into an internal command language, and is then executed.  The 
internal language would consist of parse trees of verbs, objects and so
on, and would exist in order to allow uniform responses to commands
across the whole MUD.

Jon Leonard