[MUD-Dev] Better Combat (long)

[Paul Schwanz]

David Kennerly wrote:
> Paul Schwanz wrote:

> My comments could be summarized as: Where is your knight?

My comments are not so easily summarized.  I'm afraid you'll have to
read them all inline. ;)

>> How does chess manage this?  It seems to me that, although the
>> rules of chess are simple enough to be summed up in one page of
>> text, the complexity comes from every move being predicated upon
>> all the preceding moves, both yours and your opponent's.

> There are no numbers in Chess.  Only spatial relationships.  Okay,
> one could put numbers into chess, and use numerical analysis.  But
> it's estimated there are about 10^100 vertices on the Chess game
> tree.  So get back to me when you solve Chess.  :)

It is precisely the unsolvability of Chess that makes its principles
so worthy of emulation.  But I obviously laid out too many rabbit
trails detracting from my main point, which was precisely that I'd
like to see MMORPG combat with emphasis on "spatial relationships."

[snippage]

> So, one thing unposted and much more important than the number of
> stances and reaches, is the interaction of these.  If they are all
> tradeoffs of efficiencies on scales of offense/defense, then they
> are reducible.  For examples:

Good point!

[more snippage of reducible examples]

> To echo your Chess allusion, to create a non-reducible, and
> therefore potentially strategic, option you need a "knight."
> Something that operates on a data structure with a pattern instead
> of a simple repetition of a constant direction.  The bitch is that
> it must be carefully chosen in the context of the entire system in
> order to prune the game tree to bonsai-perfection that a player's
> sophisticated intelligence demands.

Based on current combat models, it doesn't seem that players are
quite as demanding as you make them out to be.  :)

I don't know about "bonsai-perfection," but let's talk about a
knight, a pawn, and a bishop in my combat model.

Let's run through a possible scenario.  In order to score a hit on
my opponent, let's say that I need to execute a specific form.
Let's call that my "checkmate" form.  Now, when the duel begins, I
don't know which form is my checkmate form any more than a chess
player knows, when executing his opening, exactly which move will
end up checkmating his opponent.

But I have a strategy.  I just learned a new form last week that is
difficult to defend against.  However, in order to execute this form
(for the moment, we won't even consider the other factors describing
a position from which to successfully execute the form: hand
location, sword-tip location, orientation, opponent's stance, etc.),
my feet must be arrayed like this (looking down from above,
character facing top of screen):

  L**
  **R
  ***

But we open the duel in an /en garde/ position, with my feet arrayed
like this:

  *R*
  ***
  *L*

So here's where our chess rules come in.  We'll make them rather
arbitrary (i.e. not based on any sort of real-life combat
principles) for the purposes of illustration.

  1 - only one foot can be moved when executing a form

  2 - when executing an attacking form, one of my feet can move like
  a pawn

  3 - when executing a defensive form, one of my feet can move
  backward like a knight or a rook

  4 - when executing a riposte, one of my feet can move like a
  bishop

My five move strategy is to
defend...riposte...attack...attack...checkmate, using forms that
cause the following stance changes:

  *R* | *** | *** | *** | L** |
  *** | *** | L** | L*R | **R |  ...checkmate move
  *L* | *LR | **R | *** | *** |

But, of course, it is unlikely that my opponent will be so
accomodating (any more than a chess player will accomodate me while
I get my bishop in position and hop my knight down the board to take
his pawn and fork his rook and king).  Perhps he'll take a defensive
posture himself.  Perhaps he'll use quick darting attack forms that
do not give me enough time to execute a form that makes the knight
stance change, instead calling for me to make quick sword movements
to block while maintaining the /en garde/ stance. Maybe I should
present him with an opening to try to coax him into a more agressive
attack.  Or maybe he'll attack with forms that require me to respond
with rook stance change defensive forms.  Maybe I should think about
what sort of checkmate form he's trying to execute.  I'll need to
constantly adapt my strategy as the positions change.  In any case,
though we are not playing chess, it seems to me that the combat
described has moved in that direction.  Add back in rules for how
hands and weapons move, how the torso or head shifts with various
forms, how an opponent's stance and orientation dictate whether a
hit location is present for a specific attacking form, etc. and
things could get pretty interesting.

> Despite this being text-only, I imagined all the lucid
> descriptions, except one:

>>    Weapon Reach: But what if we move out of 2D and into 3D?
>>    Imagine using a 3x3x3 grid instead to describe both your
>>    character's and his opponent's stances.

> Did I miss something?  Your crouch/upright qualifier already
> transformed the 3x3 grid into a 3x3x2 grid.  Just a minor comment;
> I still understand the conceptual design.

I was speaking more of moving into 3 dimensions for target location.
Initially, even though stance takes depth into account, you would
just attack a square on the 2d grid (3 high and 3 wide) between you
and your opponent.  If they are in the /en garde/ position, the
head, torso, and right leg would present targets withing the central
column of the 2d grid.  When you add in the concept of weapon reach,
you can add a 3rd (depth) dimension to the target locations.  Now, a
dagger might not reach the head, but a sword would.  Whereas before,
either dagger or sword could attack the headh in the 2d grid.

> At the current leaps and bounds of graphics, could the techonology
> support real-time rendering about 1000 animation poses with
> several times as many transition animations sometime this decade?
> I don't know the state of the art of graphics programming.

Me neither.  As someone else pointed out, the AI could be
problematic as well.

> The way you defined weapon reach, it sounded like a weapon that
> was longer penetrated both shallower and deeper into the personal
> space of the target.  Since it thus threatens more cubes in the
> 3-grid, a longer weapon dominates a shorter one.  that Did I
> overlook some qualitative or quantitative countermeasure?

Assuming that a successful defensive form intercepts the attacking
form at any cube along the attacking weapon's length, it seems to me
there would be more opportunity to block a longer weapon.  Whereas
to successfully block a dagger, one would have to execute a form
targetted to intercept at one and only one cube, to block a staff,
one can select any form that would intercept at any of the three
cubes describing the weapon's length.  In other words, using a staff
could triple the number of defensive or riposte forms availabe to
your opponent, giving him more options for moving into a checkmate
position.

> A gentle (continous, monotonic, strictly increasing) fitness slope
> is trivial for any evolutionary algorithm to climb.  Likewise,
> such fitness slopes are reducible to the old binary search
> guessing (pick a number between 1 and 100...).  Thus, dull for a
> sophisticated player, after discovering this property.  In
> addition to collision detection, are there other /qualtitative/
> differences?  This would, analogous to a knight's move, is neither
> forward nor aside, nor continuously through, but a discrete leap.
> In any case, thank you for the tour.

I don't have your knowledge of game theory, so I often feel like I
think I know what you are saying, but am not quite sure.  I hope the
above gave you a better idea about what I'm getting at, but if not,
please keep asking questions.  I'm bound to understand eventually.
:)

--Paul "Phinehas" Schwanz
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev