[MUD-Dev] Re: Leaving characters in play
J C Lawrence
claw at under.engr.sgi.com
Tue May 19 14:07:47 New Zealand Standard Time 1998
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.
> 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
>> 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 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.
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.
More information about the MUD-Dev