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

[Emil Eifrem]

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

I'm pretty ambivalent on this issue. It's a 'flexibility vs consistency'
matter for me: I want the flexibility of letting a builder add the verb
"smell" to a mob's (or character or any Living) vocabulary when the mob
picks up a flower. But I strongly dislike the fact that if I drop the
flower and walk into another room, "smell" would give a "Huh!?".

The other consistency problem (which that thread opened my eyes to) is the
case when you have a zillion buttons in the world which all add the verb
"push" to your vocabulary and respond accordingly, except one tiny little
one built by NewbieJoeBuilder, which responds to "press." No fun.

The last problem can be solved administratively. One approach is to
maintain a list (a physical document, not a data structures list) of
different types of objects and the verbs they shall use for different
actions. (Such as "buttons: if a character push it, add the 'push' word to
its vocab".) 

That approach would soon get unreasonable -- both for the NewbieJoeBuilder
who needs to look through a monstrous file for every lil object he builds
and for ExperiencedJackMaintainerOfTheList who has to maintain the dang
thing and update it as new object types come along in the game.
One could also have a head builder that walks through all areas to check
the dynamic vocabulary but that does tend to hamper productivity.
Admittedly, quality assurance of areas is something that needs to be done
no matter what, but I believe checking the standard stuff (correnct
englihs, appropriate setting and theme, etc) is way different from checking
the dynamic vocabulary as it's easy to have the standard check done by a
staff of 4-5 experienced builders, but vocabulary review would have to be
done by one person per se.

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?

>
>  Rules for genating precedence and grammar rules with dynamic
>vocabularies?
>
>  Is grammar a dynamically inherited structure across objects?

So Sword would inherit the grammar of Weapon? Hmmm...

I'm not even sure how, and why, having dynamic grammar attached to objects
would work. Pros and cons, anyone? And how?


[timing in combat:]
>In #1 each player action (eg "bash buffa") takes a preset length of
>time, and prevents the player character's motions/actions during
>that time.
>
>#2 is a little different.  Players submit the actions that their
>characters are going to perform in the next "round", where a round
>is a known and predefined length of time.  At the end of the round
>all the various actions by the various players are resolved against
>each other (the action and round resolution logic can be quite
>complex -- see the combat package threads in the list archives) and
>the final results computed and reported before the next round starts
>and the players again submit their intended actions.  It is common
>with round systems for player characters to operate under a quota
>system, where each of their proposed actions has a quota value and
>their total must not exceed some maximum.  See Jon Lambert's posts
>on his (IIRC) round based combat system for some interesting design
>notes on this area.
>
>#3 is where I've been heading, while mixing in generous dollops of
>#1 and #2.  Loosely, each character does whatever he can as fast as
>he can with the limiting factor being the execution time of his
>various actions and the speed with which he can submit them.
>Arguments about fairness are of course rife with this approach.

Ack. Haven't your players heard of tintin?

Surely you must have some way to delay a player's queing commands while
they're busy doing something else. For example, say you have a spell that
causes damage. According to the above, a fight between two people with this
spell would basically be a fight between their clients and connections --
whomever gets through most "cast my damagespell" messages would win.

This doesn't sound feasible, so I assume that you do have individual delays
after commands. I think that's what you mean with the limiting factor being
the execution time of various actions. So the execution time for cast
damagespell would be pretty high and thus not unbalance the game. I don't
see how that's different from 1?


[independent time ratio:]
>  > stats
>  You are 10 days old.
>  > stats bubba
>  Bubba is 10 days old.
>  > stats boffo
>  Boffo is 10 days old.
>  ...play the game for a while...
>  > stats
>  You are 50 days old.
>  > stats bubba
>  Bubba is 30 days old.
>  > stats boffo
>  Boffo is 168 days old.
>
>I don't however see this as a problem

This is the approach used by most DIKU-derivatives. Your character's age is
dependant on how many hours you have played him or her. This works out
sortta well, but if you want to create a consistent and realistic game
environment then it will disrupt player's perception of acting in a
semi-real world. In my experience, players will acccept unrealistic things
as long as they are consistent and at least somewhat logical. Most of our
wacky magical systems being a good example.


Actually, as I think of it, the above *does* provide consistency, if not
realism. I guess it just wouldn't fit my setting. My mud's based on a
fantasy book series, and I want a player to be able to say that they were
born that-and-that date before the legendary battle-of-this-and-that and
hear stories from an old experienced player whose char was actually in the
legendary battle. Time's running short and that wasn't a great example, but
you get my point.

-EE [emil at prophecy.lu]