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

[Koster]

> -----Original Message-----
> From: J C Lawrence [mailto:claw at under.engr.sgi.com]
> Sent: Wednesday, December 16, 1998 9:31 PM
> To: mud-dev at kanga.nu
> Subject: [MUD-Dev] Re: MUD Design doc (long) 
> 
> Combat for me is still largely an untimed system.[snip]
> Roughly the common models break down to:
> 
>   1) Timed action 
>   2) Timed rounds with action limits per round
>   3) No time controls 
> 
> 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.[snip]
> 
> #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.

On LegendMUD we had what I think you are referring to for #3. For each
weapon, there was a rate of swing, defined in pulses and affected by the
player's skill. Differing actions also had differing pulse intervals
they took to execute (I believe these took the form of delays
post-action, with the action being executed instantly, for simplicity's
sake). Output was immediate, and all sense of "rounds" was lost as the
regular periodic actions of differing players engaged in melee with one
another could be completely asynchronous. For readability, actions
occurring in the same pulse were grouped together and issued
simultaneously.

We removed it, however. Not because of balance. Not because of problems
with the implementation.

No, we yanked it because it was too spammy. Players suffered from
information overload when engaging in combat with multiple opponents.
You could reach cases where groups of event messages were issued every
pulse (eg, every 1/4 second).

Since we removed it, we have added additional controls over the system
for combat messages--players can finetune the style of the text & its
length. We've discussed allowing bystanders to completely ignore
"details" in a fight unless they are participants, etc. And of course,
we've discussed adding in coordinate-based combat within our room-based
system, which would once again "up the volume" on messages and also make
combat more tactical--and would probably require slowing down the pulse
rate, in order to avoid this problem.

BTW, what happens now is that all those intervals & the like remain as
they are, but they are arbitrarily chopped up into rounds at 18 pulses.
The output is staged, and the calculations are staged--more like #2.

-Raph