[MUD-Dev] Re: MUD Design doc (long)
efindel at io.com
Sat Jan 2 14:48:28 New Zealand Daylight Time 1999
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- ) )-,_..;\ ( `'-'
More information about the MUD-Dev