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

[J C Lawrence]

On Thu, 17 Dec 1998 11:57:36 +0100 
Emil Eifrem<emil at prophecy.lu> wrote:

> At 04:31 AM 12/17/98 , J C Lawrence wrote:

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

The usual argument is simplicity and performance.  By making them
the same you remove the possibility of using short-circuit logic in
your NPC's or their AI's, thus imposing extra logic which is really
only needed for players and their typoes, command goofs,
guess-the-verb-games etc.  By devolving NPC's to a simpler form you
can bypass that and present a much simpler and in many ways more
elegant API to the NPC AI's.

George Reese IIRC has written articulately on this in
rec.games.mud.*, but I'm unable to find the reference right now.

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

No.  It has the advantage of simplicity on the server side, and the
disadvantages of fostering bad-reuse, guess-the-verb games, and
logical vocabulary inconsistancies.

Both *can* be done equally well.  The problem is the everlastingly
fallable maintenance, area, and user programmers.

> It may be too game specific a problem for a generic solution, I
> guess.

Quite.

> 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!?".

Ditto.  My current approach is a global vocabulary and grammar, and
local overloaded definitions.

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

Bingo.

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

Allowing vocabulary to be part of the inheritance tree (cf Cold)
such that objects inherit their verbs from the parents can go a long
way.  There are ugly problems with multiple inheritance and verbs of
course, as well as multiple base objects, but that's another
crusade.

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

<nod>

Making a useful set of base verbs on your base classes and then
inheriting them into the instanced children *can* do a lot to handle 
this.  It can't do it all, but it helps.

> One could also have a head builder that walks through all areas to
> check the dynamic vocabulary but that does tend to hamper
> productivity.  

And such administration scales wonderfully.

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

It took me a lot of brain beating, but I finally game up on
per-object vocabularies (I was a big proponent for its simplicity
effects).  Using a global vocabulary with default (crude)
definitions and well defined and dynamic contextual overloading of
those base definitions current seems the way to go for me.  I
haven't cut code there *yet*, but the design seems basically sound
once I get a decent context analyser mapped out.

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

Uhh huh,  

  > l
  There is a flower and shot cow pies here.
  > smell
  The cow manure smells something horrid.
  > get flower
  You pick up the flower, kneeling in the manure in the process.
  > drop flower
  > n
  > smell
  You don't have the flower any more.
    
>> 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...

Bingo.  See Cold/ColdX for a working example.

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

I'll bow out here to the various Cold people on the list.

> [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?

Yes.  Its not necessarily a problem with untimed combat.  One of my
pet criteria is that any game which can be usefully automated has
demonstrated the failure of its design.

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

Not quite.  Wiggins has already given simple cases where this is not
the case.

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

Aside: One of the reasons I'm not concerned about
inter-client/lag_balance wars is that I actively encourage and
support free user programming.  As such, players are free to program
their own combat code/scripts/packages to automate whatever they may
wish.  The result?  Yes, many combats will derive to who has the
better/faster/luckier combat automation. I don't see this as a
problem.

As for timing of individual acts, no I don't control this, and I do
assume that similar actions performed by two characters are likely
(this is not true BTW, but I assume it anyway as the exceptions are
either generally realisitic or prone to amusing and interesting
abuse by players) to execute in similar lengths of time.  Further,
while a player's commands normally execure serially, they can
execute in parallel (player character doing multiple things at the
same time).  I do very little to restrict this other than factoring
it into the luck and sloppiness fields (a parallelly executed
command suffers runtime penalties).

The result?  Yes, from one viewpoint the question is who can enter
the most commands most rapidly.  However that's a false viewpoint as
the combat structure is heavily predisposed to tactical reactions
(ie very interactive and supportive of prior preparation) as versus
a simple pile-on-the-hp's.  A player character coming in swinging a
broadsword as fast as he can might get a couple whacks in -- until
his opponent freezes him and then disects him at leisure while the
attacker's command buffer empties.  Even if the attacker notices the
freeze, by the time he cancels his command buffer and usefully
reacts it is likely to be too late as his opponent now has the
timeing advantage.

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

There are two main differences:

  1) Nobody logged off in the above example.
  2) I don't remove characters from the game when their players logout.

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

Quite.  For me time is one of the things a player can causitively
affect in his game environment, both for himself and for other
characters.  Temporal inconsistencies are the expected norm.

--
J C Lawrence                              Internet: claw at kanga.nu
(Contractor)                             Internet: coder at kanga.nu
---------(*)                    Internet: claw at under.engr.sgi.com
...Honorary Member of Clan McFud -- Teamer's Avenging Monolith...