[MUD-Dev] A new combat system

J C Lawrence claw at kanga.nu
Wed Jul 12 23:56:35 CEST 2000


On Wed, 12 Jul 2000 14:14:01 -0700 
Ian  <Hess> wrote:

> I'm curious how your system deals with a maximum number of speed
> points allowed at any one point, or lag experienced during a
> fight.  

It struck me while considering this area that the basic problem in
the handling of rate of time and of the rate of time in combat in
particular in games is the fact that as players we insist on it
being non-linear and in particular to being proportional to the
vagarious of our input and display device manipulations.  Most(?)
players are lousey typists, thus we slow down time for those factors
which are "typing sensitive".  Our graphics and posing capability
don't show muscle tension and the finer aspects of body systems (and 
are resolution-incapable of showing), so we slow down time and event 
granularity again to single step thru the event:

  Imagine a one second pause between lines:

  >
  Bubba looks at you and seems angry.
  > (want to do something?)
  Bubba draws his sword!  
  > (want to do something?)
  Bubba begins to raise his sowrd over his head.  
  > (want to do something?)
  Bubba tenses, ready to deliver a crushing blow with his sword.  
  > (want to do something?)
  Bubba begins to swing his sword at your head
  > (want to do something?)
 
The interface to communicating intent and physical action and
reaction is sufficiently bandwidth intensive in both directions that
it makes physical combat reaction/counter-reactions a moot point.
So instead we simply granularise the interface (cruder controls more
generic presentation) until it is manageable and pretend it hasn't
lost all flavour.

The apparent base goal is to present the player with a consistent
event rate.  Things never happen too fast, or too slow, thus the
player can maintain a comfortable level of attention on the game and
maintain enjoyment.  Raise the event rate too high and he burns out
or is confused and overwhelmed.  Too low and he's bored.  Expertise
and familiarity raises the tolerable and expected event rates.
Variation in rate is required so some events are "more exciting"
than others, outside of their internal content.  Where it gets
interesting is in the communication of intent and player control,
their effect on realised time rates, and the impact of this on the
rest of the world once you have a variable time rate in your world.

Further, players want localised variable time rates, especially for
actions relating to combat or other detailed physical activities.
They want to see their opponent attacking them, to have fair
warning, to be able to react suitably, to be able to react to their
opponent's reactions suitably, and in general to be able to attempt
realtime tactices during combat.

  eg They want a chance to see that Bubba is going to attack them
(boffo), that he is going to use a sword (versus some other wepon or
means), that they have a chance to defend or counter-attack (parry
or perhaps stab with a dagger), and that Bubba has a (small) chance
to counter-react (swing harder/faster, suck in gut).

And all this on a congested unpredictable latency unreliable link.

So you have an even rate for walking about the world, an event rate
for riding a horse, an event rate for smithying a sword, and event
rate for picking a lock, and an event rate for combat.  In essence
you have variable time rates.  Time can flow at different speeds,
tho its normally presented as all being the same speed.

However once you introduce variable time rates, there are logical
consistancy problems due to the fact that the other players are now
(comparitively) in fast time and some players are in slow time and
yet they can affect each other as if their times rates synched.

If Bubba and Boffo engage in combat (sample action that might
require a slower time rate), and subjective time for the two of them
slows to a crawl, what is the impact of that on other's perception
of them, and theithose other's ability to communicate to them or to
effect either individual or their combat?

The problem is in the magnitude of the disjoint.

I hit this pretty hard with Murkle a while back where I explicitly
slowed time for combatants (perceived factor of almost 20:1),
offering a specialised command interface for combat, scripted combat
rounds, and the ability to dyamically define and customise combat
strategies and scripted reactions during the combat.  (Search the
archives for the threads on the area -- it was a set of utterly
impractical and lunatic ideas I had some fun with)

  Note: The combat interface just exagerated a bad problem to the
point of invalidating the entire system.  It didn't create the
problem.  The time differential created the problem.

It failed abysmally on the inconsistancy between two points:

  The disjoint in time rates between combat participants and other
  uninvolved players was large.  

  Determining who was a combatant (ie who was in fasttime or
slowtime) was impossible to make logically correct in all cases.

Slowtime offers significant advantages in a number of game
activities, let alone during combat (or even harmless staged combats
put on soley to achieve the benefits of slowtime).  But entering
slowtime put those people at a severe disadvantage in regard to
fasttime players should those players do actions that affected the
slowtime players.

Consider:

  Bubba attacks Boffo.

  Bubba and Boffo both enter slowtime.

  Bernie does something that materially affects Bubba without being
  restricted by slowtime.

What Bernie does really doesn't matter.  The problem was that he was
in fastime and they were in slowtime and the two could still
communicate and affect each other in the game world.  What the
effect was didn't matter -- the disjoint, and the fact that
cooperation or attack across the disjoint was possible created the
problem.  Bernie for instance could fell a tree such that it fell on
Boffo (sample action impossible to pre-determine as an attack).
Meanwhile Boffo is stuck in slowtime, unable to move (or moving in
my case at 1/20th speed) or externally react at full speed and is
toast.

  But why does he have to move at 1/20th speed?  Because if he moved
at full speed, then Bubba could at full peed and then neither would
have any foreknowledge or reaction time ability for the import of
their motion.  Ergo, subjective time slowed and so did their motion.

A simple reaction is to remove combatants from the game world and
thus put them in some abstracted "fight" world or stadium pending
resolution of the conflict at which point they are returned to the
"real world".  But that has large expenses on the ability to
surprise, to overwhelm, to engage in and create melees, and much
more simply requires that:

  Players must explicitly consent before hand to enter combat

or,

  Every single action be classified explicitly as combat-related or
non-combat-related so as to determine mechanicslly when to enter
combat-state.

Which in the first case violates many popular non-consensual game
models, and in the latter case, given the indirect nature of the
effects of many actions in a mechanicslly complex world (eg cutting
down a tree which hits a rock which starts an avalanch which kills
Bernie) is near impossible.

You also can't slow down the external non-fighting world to match (I
have to walk super-slow just because some people I don't know over
there are fighting?) and we' started the slowtime/fasttime disjoint
to get away from the problems of pretending to use a unified time
rate.

Which "pretend it just doesn't happen" is of course the one
overwhelmingly taken; you just decrease the magnitude of the
differential to such a level that you can ignore the fact of the
problem and then hide under the fact that some things just don't
match and you have to deal with it 'coz its a game (which is a
pretty fair reason).

I'm not keen on that.  I want detailed, multually reactive and
intelligent behaviour to be possible.  I want realtime tactics to be
both possible and rewarding, which is a site different than just
speed-clicking "stab/slash/kick/bash".  I want to be able to have
the results and progress of a slowtime activity to be directly
dependant on my human (or scriptd) capabilities.

Note: I prefer binding much of the ability of a character to his
human player rather than attempting to calculate and emulate them
via locally stored statistics and weights.  Thus you don't get so
much get "high level characters" as "high level players", or to
dramatise my view:

  A newbie character played by an expert should be able to best most
high level characters played by merely competent humans (combat,
running, game challenges, whatever).  Ditto for competent
human/newbie character versus nerbie human/high level character.

Providing explicit and dramatic support for slowtime/fastime just
seems one route to provide this.  It just has problems.

--
J C Lawrence                                 Home: claw at kanga.nu
---------(*)                               Other: coder at kanga.nu
http://www.kanga/nu/~claw/        Keys etc: finger claw at kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev



More information about the mud-dev-archive mailing list