[MUD-Dev] Re: MUD Design doc (long)

[Mik Clarke]

Emil Eifrem wrote:
> 
> At 04:31 AM 12/17/98 , J C Lawrence wrote:
> >Thinus Barnard<thinus_barnard at bigfoot.com> wrote:
> >> Should NPCs and players have different command sets?
> >
> >Should there actually be *ANY* distinguishing features between NPC's
> >and players other than the source of their actions?  There are good
> >reasons for both approaches and reasonable design methods to salve
> >most of each other's problems.
> 
> What good reasons are there for separating NPCs and PCs?

A lot of a Muds work is done with smoke and mirrors.  To acheive the
desired effect with a Mob it is quite often necessary to have it perform
some 'slight of mud' that the players cannot.  Examples might be mobs
that create items, mobs that need to update control variables and mobs
that need to either relocate the player or summon other mobs.  Other
than the special effects and game control commands, there shouldn't be
any difference.
 
> >A well defined inheritance model can do wonders as can a good
> >grammar, which brings up the questions:
> >
> >  Central grammar and vocabulary?
> >
> >  Standardised grammar at all?
> >
> >  Per-object dynamic vocabulary?
> 
> Per-object dynamic vocabulary was quite extensively discussed in an earlier
> thread that I read up on in the archives. Did you guys reach a conclusion
> on a reasonable design? It may be too game specific a problem for a generic
> solution, I guess.
>
> What solutions are there for #1? I had some thoughts along the line of
> instead of removing the verb from vocabulary, just cancel the action and
> replace it with a can't-find-it message. So typing smell in the other room
> (w/o a flower in it) would give you a "But you've dropped your flower!" or
> whatever message.
> 
> Or maybe just for every character (/mobile/etc) object keep track of the
> item last associated with a dynamically added verb. So "smell" with an
> absent flower would give a "You don't see a flower here." message.
> 
> Any other ideas?

I think the only way to do it properly is to have a defined (fixed) set
of commands that the player can execute (the players capabilities, a
limited subset of what they should be capable of) and to be able to
interrorgate each object to ask it if it supports each particular
command.  For example, the code flow for smell might be...

  if target object not specified, 
    emote is in dire need of a bath
  else
    locate target object
    if not found,
      send_to_char "Sorry, can't find one of those."
    else
      if (!object->can_you_be(CMD_SNIFFED)) 
        send_to_char "It smells of nothing in particular."
      else
        object->you_are(CMD_SNIFFED, char)
 
This lets the object decide how to handle the command while giving
central (and consistent) command parsing and handling.  Any command can
be used on any object and will give a sensible response.  It also
support inheritance (so your food class might response with "It smells
delicious" which would apply to all food items unless they overwrote it
and a mob class might response with "slaps you!" by default.

My challange for 1999 is to persuade a son of a ROM to work this way (ie
rewriting 90% of the command processing)...

Mik
--
http://www.geocities.com/SoHo/Cafe/2260