[MUD-Dev] Re: Leaving characters in play

[Travis S. Casey]

On Friday, 15 May 98, J C Lawrence wrote:

> It is this point which ghas persuaded me to almost entirely move away
> from round based combat.  I refuse to place the entire game and all
> players on a pacing clock (humans shall not wait for machines), but
> not using a global clock while using usably long combat rounds opens
> the combat system for all sorts of interesting abuse due to the
> inconsistant time scales.

In true round-based combat, as used in the paper RPGs which created
the term, there is no pacing clock.  Humans aren't waiting for
machines -- they're waiting for other humans.

I'd call what most muds use timer-based combat -- there's a timer
which determines how often automatic combat routines are performed,
and which thereby places limits on how slow someone can be and still
get their action in this turn, and sometimes on how often one can
enter a command.

A true round-based combat system is difficult to implement on a mud
for one reason:  there's no easy way to tell if a player is still
there or not.  In a paper RPG, if a player has to get up and go to the
bathroom, the other players and the GM will definitely notice that
the player is leaving, and can then either choose to wait or to have
someone else decide what that PC will do while the player is gone.  On
a mud, it's not that simple.

It would be easy to add an "auto" command for players who have to go
for a few minutes but want to stay in the fight -- "auto" would tell
the game to autopilot your character.  When you returned, entering any
command would take your character off autopilot.

The problem then becomes one with careless players or players who are
suffering extreme lag or lose their connection.  A lost connection isn't
too hard to handle -- many muds already have methods for handling
them.  However, to handle the other two cases, there needs to be some
kind of timeout -- if a reasonably long time goes by without a certain
player entering a command, then the mud would need to either put that
character on autopilot or handle it like a lost connection.

This eliminates (or at least seriously reduces) the advantage to "fast
twitch" players, those who use scripting, and those who can type fast.

> Opening the combat to being entirely untimed conversely allows spam
> attacks and tends to guarantee that the fastest twitch will win.  Not
> good.  Further, as discussed earlier, I can't distinguish between
> combat and non-combat commands as even utterly innocuous commands will
> be used heavily in combat ("drop mana consumers"), and very
> combat-centric commands will be used peacibly (cf UggUgg's fight)..

> I don't have a good design.  The best I can think of so far is:

>   -- No first blows are fatal.  

Why not?  I can see why you'd want first blows to be rarely fatal, but
why never?

Also, how do you define a first blow?  The first blow since the
character entered the room?  A blow suffered when the character is
uninjured?  A blow delivered by someone who hasn't attacked you since
you logged on?

There may be easier ways to do this... for example, how about a damage
system which works like this:

Every character has three stats related to damage:  Resilience, Size,
and Accumulated Damage.  When a blow is suffered, the character makes a
check on Resilience against the amount of Accumulated Damage he/she had
*before* the blow landed.  If the check is failed, the character dies.
If the check succeeds, the character adds the amount of damage taken
to his/her Accumulated Damage.  However, each character has a limit to
how much Accumulated Damage he/she can take:  Resilience multiplied by
Size.  If Accumulated Damage passes this point, the character dies,
even if he/she did not fail a check.

The linchpin of this system is the Resilience check against
Accumulated Damage.  You can set this up to provide many different
possibilities:  for example, you might choose to set it up so that a
character who had no Accumulated Damage can't fail the check.  In that
case, the only way to kill an undamaged character with one blow would be
to do more than his/her Resilience * Size in a single blow.

Features of this system:
  - The chance of death, barring massive amounts of damage, depends on
    what Accumulated Damage was *before* the blow.  Hence, you can
    better control how likely someone is to die from a first blow.

  - Beyond a possible initial "safe zone", where the character can't
    die except from a massive amount of damage, there is always a
    possibility of death, however small it may be.  This would help
    discourage "tanking" and similar tactics.

  - Instead of simply having death, you could create a table of
    different effects which could happen on a failed Resilience check,
    with worse failures giving worse results.  This gives a simple way
    to add stuns, wounds, and similar results to the system.

Possible bug:
  - Weapons which do less damage will force more Resilience checks in
    the course of bringing Accumulated Damage up to a certain point.
    Hence, a character is more likely to die from a series of knife
    blows which bring him/her up to 50 points of damage than from a
    series of sword blows which do the same total damage.  It should
    be noted, though, that this effect isn't likely to make too much
    of a difference in practice -- if you start from X Accumulated
    Damage, you'll be more likely to die from Y blows delivered by a
    sword than from the same number of blows delivered by a knife.

>   -- Arrange these probabilities appropriately to force most combats
> to the 15 - 20 seconds point.

Is that 15-20 seconds of game time or real time?

>   -- The game dynamically defines a "combat state" which is hidden
> from the player and is used only for event process control.

>   -- Combat state is initiated upon a definitely combat-oriented
> command from any party (kill, fight, hit, damaging spell, etc).

>   -- Combat state is declared for both target and source.

>   -- Combat state's only effect is to enforce timings of actions.  It
> takes XXX time to swing a sword, YYY time to cast a spell etc.

If using a round-based system, this could be done via action points,
or, if using short rounds, by making some actions take more than one
round to do (possibly with an option to abort in the middle of an
action).

--
       |\      _,,,---,,_        Travis S. Casey  <efindel at io.com>
 ZZzz  /,`.-'`'    -.  ;-;;,_   No one agrees with me.  Not even me.
      |,4-  ) )-,_..;\ (  `'-'
     '---''(_/--'  `-'\_)


--
MUD-Dev: Advancing an unrealised future.