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

Niklas Elmqvist d97elm at dtek.chalmers.se
Tue Oct 27 17:28:58 New Zealand Daylight Time 1998


On Mon, 26 Oct 1998, Jon Leonard wrote:

> 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.

Hmm, I don't know if I understand you correctly, but this sounds pretty
good. This has led me to realize that we need to provide a facility to
pass information from native code modules to MUD-language softcode. Hmm,
maybe we want native code and MUD language softcode to be used
interchangably? (Yes, I am not original in proposing this and has in fact
opposed it before, but now I see that it may be necessary.) 
 
The differences in inter-module communication and loading/unloading
between native code modules and softcode modules would have to be hidden
by an abstraction layer. This way, people could decide to do different
stuff on different tech levels; some would do routines in native code
(sort of hard-coded) at the module level, while others do this at lib
level. It *still* is not hard-coded, since modules can easily be reloaded 
with new behavior.

As for the parser example above, the lib builders would just build command
handlers in the MUD language. I think parsing (or at least lexing) is
better left to the native code modules for efficiency reasons (not
necessarily though, hence no distinction -- at least from the viewpoint of
the module and lib programmers -- between native and soft code should be
made). The root game object in the lib would get command handler methods
such as "get", "drop", "throw", etc and specific object classes would
inherit from these and redefine the behavior. This way, a new object could
either go with the old handlers, redefine existing handlers or create
new handlers (all via verb binding or something). 

Of course, I realize that this is probably what LP and other softcoded
MUDs do, but the difference is that we would support native code command
handlers on the module level as well. In other words, our scheme would not
limit the developers to a specific convention or paradigm.

> Jon Leonard

-- Niklas Elmqvist (d97elm at dtek.chalmers.se) ----------------------
  "The trouble with being a god is that you've got no one to 
   pray to."
		-- Terry Pratchett, Small Gods





More information about the MUD-Dev mailing list