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

[Travis Casey]

On Saturday, January 02, 1999, Emil Eifrem wrote:

> At 04:06 AM 1/2/99 , Travis Casey wrote:

>>You could have a global grammar and still have verbs/commands be
>>implemented in the world scripting language.  Lima does this -- verbs
>>are LPC programs in the mud, but the driver handles parsing (verbs
>>have to register themselves with the driver).

> That's true. Unfortunately, my server is not that far to the soft side of
> things that the above would be possible. Our scripting lang is designed
> specifically for world manipulation and would be quite unsuitable for
> commands programming.

Without seeing your scripting language, I can't say for sure, but it
seems to me that a world-manipulation language should be suitable for
implementing at least some commands:  those that make the body affect
the world.  Thus, things like give, take, wield, wear, etc. ought to
be implementable in it.

Of course, the command parsing may have to be done elsewhere, but most
such commands have a fairly simple syntax.


A few other random thoughts on advantages of systems where builders
can't add new commands:

 - Easier quality control.  I already mentioned this with regards to
   the possibility of builders adding synonyms for verbs that already
   exist, but there are a lot of other ways that centralized verbs
   make it easier.  Take a "read" verb for example:  to really work
   right, a "read" verb ought to check whether there's enough light to
   read, whether the character understands the language (if your mud
   has languages), if there's any spell on the character or thing
   being read which might prevent it (e.g., AD&D's confuse languages
   spell, or a blindness spell).  With a centralized verb, all this
   only has to be coded once.  If each builder has to manually add a
   "read" action to each object that can be read, you can be sure that
   many of them won't think of some of these things.

 - Maintainability.  It's easier to change code in one place than in
   dozens or hundreds of different objects.  To use "read" as an
   example, let's say that X mud requires a light level of 6 or better
   in order for characters to see well enough to read.  So, all the
   good builders set up their "read" verbs so that they test that
   light >= 6.  Now, six months down the road, someone decides that
   they want to add a dark-dwelling race to the game, and that race
   should be able to see with less light -- specifically, they should
   be able to read with light >= 4.  Now, if builders have added
   "read" commands separately to objects, all of those objects have to
   be tracked down and updated to make this change.  With a
   centralized verb system, only the "read" verb has to be changed.

   (A side note:  on SWmud (an LP which used the add_action() system),
   we often ran across situations where there was a neat idea that
   would have made things better, but it would have required changing
   hundreds of objects throughout the game.  Naturally enough, none of
   those were ever implemented, because we simply didn't have the time
   to redo all those things.)

 - It can help prevent "guess the verb" situations.  I know -- some
   people like those.  Personally, though, I hate them.  Why?  Because
   if I were actually my character, I'd just *do* whatever it is, and
   it wouldn't matter what I *called* doing it.  Thus, to me, it
   discourages roleplaying by bringing the divide between the player
   and the character to the fore.

Personally, having played, built, and coded on a mud which used
add_action(), I wouldn't consider *not* making verbs global at this
point.  But, that's just me.  :-)

--
       |\      _,,,---,,_        Travis S. Casey  <efindel at io.com>
 ZZzz  /,`.-'`'    -.  ;-;;,_   No one agrees with me.  Not even me.
      |,4-  ) )-,_..;\ (  `'-'
     '---''(_/--'  `-'\_)