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

[Emil Eifrem]

Sorry for the delayed comments. Holidays kept me out of touch with
computers for a good week and a half.


At 02:21 AM 12/24/98 , J C Lawrence wrote:
>[Emil Eifrem:]
>> 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.

K, I'll be sure to look it up on dejanews. I decided to not separate PCs
and NPCs early on in my design and didn't pay it much mind -- I never quite
managed to find any major advantages to having them separated.

I have a distinction between player and character that I think helps; where
player is an actual rl person connecting to the mud, while a character is
one of possibly many in-game entities that that player may control.


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

I use single inheritance for my world object hierarchy so multiple base
objects and other issues associated with multiple inheritance (I didn't
include the multiple-inheritance quote from your mail) won't be any
problem. The only immediate drawback I see about a global grammar is the
requirement to recompile your server in order to add a verb or command
instead of shoving that responsibility to the world scripting language.

That inflexibility may end up being tedious and restraining on the
builders, such as when JoeBuilder wants 8 new small commands for his new
cool area, but will have to wait for lazy coders and the next code update
instead of just adding it dynamically by script. It may or may not be a
problem, depending on the length of one's code-update cycle and how
soft-coded one's server is.

Keeping with my initial terms, I guess this boils down to trading
flexibility for consistency.


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

Aye, as I believe all administrative tasks tend to do. After some admin
restructuring and a series of (ehum) masterly crafted code-updates, our avg
playerbase increased with around 25%. With the result that our admin work
almost doubled. 

In fact, in my experience, the amount of admin work increases exponentially
to the growth of your player base. Hmmm.. that may even qualify as one of
Raph's laws. "The amount of administrative work increases exponentially to
the growth of your player base." I think player-driven rule enforcement may
help flatten the curve. On the other hand, maybe it won't -- it may only
serve to redistribute the effort to the players, which in the end will give
the problems to the admin staff anyway.



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

Seems like they're not listening. ;)


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

That counts out most of today's muds. Mine certainly. I am positive that
all muds I've played can be successfully automated, at least to a certain
extent. Wasn't there a Raph-law about that? Something like, "whatever
design decision you do, people *will* find ways to automate playing." I'll
have to look that up.

In role-playing environments, it's probably a very good goal though.


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

Yes. "cast my damagespell" was an ill-chosen example since it's normally
limited by both time and mana. Now, with the reservation that I don't know
anything about your combat system except for what I read in your post, it
seems to me that if two people were fighting with non-resource-limited
skills (such as 'kick'), *without* any player-command-lag the person with
the fastest client/connection would win. 

So I would assume that you've made sure that all your (combat-)commands are
limited by something other than time. Or am I thinking too narrow here?
-shrug-


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

Interesting. I can agree with you on the better part ('better' combat
automation can be translated into 'doing the right decisions at the right
time,' which in my dark-player-killing-youth used to be what I claimed
separated the true pkiller (me) from the wussies (everyone else)), but must
admit that I find the faster/luckier approach very peculiar.

I guess it's just that with my square diku-derivative background, I lack a
basic understand of your fighting system. Will have to try it out some day.

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

   > cast windshield
   You start weaving flows of Air.
   931 orcs come in through the northern door, wondering what the heck
you're doing in their temple and near their holy, stolen and oh-so-magic
stones.

   > get the gotdamn stones from the floor
   You pick up the three Stones.
   The 931 orcs all draw bows and nock arrows.
   > put the rotten stones in my bag
   You put the three Stones in your bag.
   A thin, translucent shield of Air surrounds you.
   The 931 orcs all fire at ya, but their arrows are caught in your
windshield. You run through the southern door with the stones in your bag
all thanx to the parallell command execution.

I like it!
   

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

Aye. Probably too much DIKU, pile-on-the-hps thinking on my part. Sorry.

-EE [emil at prophecy.lu]