[MUD-Dev] Re: Leaving characters in play

[J C Lawrence]

On Sat, 16 May 1998 02:49:20 -0700 
John Bertoglio<alexb at internetcds.com> wrote:

> From: J C Lawrence <claw at under.engr.sgi.com> To: mud-dev at kanga.nu
> <mud-dev at kanga.nu> Date: Friday, May 15, 1998 6:11 PM

>> On Thu, 14 May 1998 11:21:17 -0700 (PDT) Adam
>> Wiggins<adam at angel.com> wrote:

>>> On Tue, 12 May 1998, John Bertoglio wrote:

>> It is this point which has 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.

> Minor point with confusion. Do you mean time scale as in real time
> (seconds ticking on a clock) or another concept I am (obiously)
> unfamilier with.  

There are two basic approaches:

  Events in game require a definite amount of time to execute.

  Events in game are executed as fast as they can be received and
processed.

I tend to the later.  Attempting to mix that with combat rounds, which 
ar necessarily of the former type, doesn't work well.

> If you issue a command, drink jug and the connection is quick, the
> screen quickly returns something like "The jug is now empty". Now I
> know some of you out there could drain a jug in a few
> miliseconds...but most of us can't. Most of us cannot work our way
> up to the top of a 10,000 ft mountain in the time it takes to type
> "CLIMB" or "UP" five times.

Ahh.  For me you can (pending resource limitations).  Then again a key 
part of this is that the commands to climb could originate from the
player, from his client, or from in-game user programs.  As such
typing rate is not relevant.

> Some quick questions. I guess most would consider round-based combat
> to be similar to a boxing match where the rounds are discrete chunks
> of time. I think more like a wargamer...a combat round is a period
> in which a certain number of actions are executed by the combatants
> and then resolved.

I'm using the latter definition for "rounds".  What I used to have was
a "combat object" (search the archives for that term, lotsa good
discussion) which was created at the inception of combat, and which
mediated the combat rounds from then on.  Players then input intended
actions for each round to the combat object, and at the end of each
round the combat object resolved the various attempted actions,
derived a sequence of the actual effected actions, applied the actions
and the result damages and side-effects, and then started the next
round.

My current concept for combat at a user interface level is to have no
implicit interface.  Commands are entered for each blow, or a command
may be entered to repetitively attempt a blow or sequence of blows.
Thus there is no combat state outside of the client, and the combat
lasts as long as any participant continues to originate actions that
other participants consider combative.

>> I don't have a good design.  The best I can think of so far is:
>> 
>> -- No first blows are fatal.

> Why? You hit a bunny with a halbred and you either miss or have a
> binary bunny.

Then you'll tend to either miss all first blows to bunnies, or merely
graze/injure the bunny (assuming that the bunny is player
controlled).  The idea is not to ensure that a player can necessarily
__escape__ any attack.  The idea is that a player has the opportunity, 
if fleeting, to causitively react to an attack.  Single-blow
insta-death attacks prevent that.  Having first blows fore-shadowed to
the player:

  You see something whirr towards you!
  > duck
  You hit the dirt.  An arrow flies by overhead.

doesn't work well for bullets, missiles, earthquakes, planetary
collisions (esp if on the far side) etc.

> Now when our system is finished, I guarantee that no player will
> score a one hit kill on another player...but that is a different
> story.

>> -- First blows may be nearly fatal.

> Of course.

>> -- Second blows can be fatal, but its very very unlikely,
>> especially if the first blow was nearly fatal.

> Sounds like you are considering manipulating fate (luck) in combat
> fortunes. I see this a partial solution to PK...Operant
> conditioning..."I got womped by a newbie with a dagger! Bummer. He
> took all my stuff."

Yup.  Essentially I am attempting to install extra time to allow for
intelligent reactions.  I want the newbie with the bodkin to still
kill the hero, but I want the hero to have a chance to see what's
happening first.

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

> I disagree here. Let combat spin off on its own. I (barely) recall a
> movie which had Sean Connery in single combat with a bad guy. Both
> were in full armor fighting in the middle of a hot, grassy
> field. Neither could get the better of the other. The fight took
> quite a while. At the end, both were so exausted the could not
> stand. A similar fight could happen in our system with carefully
> matched opponents. Fatigue happens even if damage doesn't.  Fighters
> could dance around each other for five minutes (RT) using defensive
> attack profiles until one was taunted into launching a real attack
> or they fell into a heap and were killed by a nasty bunny.

Nahh.  Its a stylistic thing.  I'm not interested in defensive battles 
(much tho I like them in cricket or snooker).  Combat is deliberately
intended to be both unstable and unpredictable.  I don't want
artificial (if obvious) balances interjected into that otherwise

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

> We just create an entry in a data table for each combat, attacker
> and defender. We create as separate entry for each combat so if
> BUBBA fights three hobbits, three events are spawned. If Hobbit 1
> decides to flee, that event is closed out. If #1 decides to join
> BUBBA and attack his former buddies, cool. Their combat event is
> closed and new ones created.

This gets *really* messy for melees.  What happens when 5,000
screaming Orcs boil out of the ground and engage your 500 typo-matic
players?

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

> Because I can't control time (stateless, you know), we use action
> points.  (BTW, an action can take so many points it takes three (or
> more) rounds to fire.) This frees the players from the twitch
> factor. It also creates a more leisurely (some would say slow)
> combat feel.

<ponder>


> (I have a huge, somewhat incoherent post on a combat system started
> on my workstation at work. I should be able to poach enough time to
> post it next week sometime. It could even be coherent by then...It
> references a lot of past posts and might even be interesting.)

Excellant!

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