[MUD-Dev] Re: Leaving characters in play

[J C Lawrence]

On Sun, 17 May 1998 22:17:57 -0500 (CDT) 
Travis S Casey<efindel at io.com> wrote:

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

...deletia...

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

The problem is that it is still dependant on a "combat state".  I have
utterly failed to determine any sort of pattern which can be used to
determine when a combat state actually should be incepted, which
actions pertain to combat and which don't, and when a combat state
should be closed.  It gets even messier for multi-character and
multi-ranged (Bubba is firing arrows from the other side of the river,
Boffo is hacking with a sword, and Bernie is doing his thing with the
fireballs thru the magical portal) combats.  

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

It removes the possibility for a player to react to his attack as I
also don't pre-announce incoming attacks (its not possible to always
determine what is or is not an attack).

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

This is one of the very many reasons I don't like the current idea.
My rough idea is that a "first blow" is defined as "action which is
computed to be a direct attack, first of its type on the target within 
X time."

X is thought to be on the order of 2 RL minutes.

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

<ponder> 

I like this.  It removes the logic by adding a curve who far end (the
insta-kill) is almost asymptotic.  it would take little to make it
very nearly asymptotic to infinity.

Cute.  Adopted.  Thanks.

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

RL.  I'd go for shorter except that I want the chance for careful and
correct reactions to be able to be significant.  I don't want a
point-and-shoot combat style.  I also don't want a pure
chess-approach.  Something a bit in the middle, but closer to hack.

--
J C Lawrence                               Internet: claw at null.net
(Contractor)                               Internet: coder at ibm.net
---------(*)                     Internet: claw at under.engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...

--
MUD-Dev: Advancing an unrealised future.