[MUD-Dev] Cognitively Interesting Combat (was Better Combat)

[Paolo Piselli]

--- David Kennerly <kennerly at finegamedesign.com>
wrote:

>> Have you ever played the custom "Defense of the Ancients" style
>> maps that are popular with online Warcraft III?

<snip>

>> twitchy.  As a player you constantly monitor the combat state,
>> evaluating wether to advance or retreat or burn some mana on an
>> ability.  I'm pretty sure the pacing of ability usage or "posture
>> change" falls in your suggested range.

> "Spatial posturing" as in a formation of units?

By "spatial posturing" I mean the dynamic process of managing the
distance between yourself and the opponent - closing distance,
retreating, sneaking around, etc.  When a player start to close
distance, are the merely goading the other play on with a feint, or
are they moving in for an attack?  Will they stay outside of casting
range, pbaeo range, or will they intentionally try to get the
opponent to burn some mana.  Space management can be an interesting
addition to the complexity of the combat task - consider the use of
positional attacks in MMOG combat.  Positional attacks seem like a
good start, but can this aspect of combat be made even more
interesting than "try to get behind opponent, then backstab
repeatedly"?

> There is an additional problem: A competent player must search the
> game tree (which is, for our purposes, isomorphic to the decision
> tree and can be derived from a problem space).  A necessary
> strategy

Yes, game trees and and decision trees are the same, and represent
the problem space, but I do not think that they model human
cognition very well.

> to success in Puzzle Fighter is the ability to anticipate
> potential game states.  The whole notion of breaking a block is
> the simplest and shortest search of a game tree.  Yet more complex
> versions include looking five or ten moves ahead.

>>From what I know of human game playing, they do not even generate
most nodes of the tree, let alone evaluate them.  Players will
consider only a few possible future game-states, not even bothing to
think of irrelevant moves.  Better players will consider more future
states, but still no where near the thousands of states that a
chess-playing algorithm might have to evaluate.  To the human
player, it does not matter if there are 100 possible moves if there
is one obvious move - in this case the 99 other moves do not even
come to mind and the player effectively has no choice, where a
computer algorithm would have to examine all 100 options and compare
their heuristics.

> These are not the way a human searches the game tree, but a human
> does search the game tree.  The structure of the tree (or the set
> of rules for its generation) is necessary to even construct the
> WME of Puzzle Fighter.  Break block has no meaning without
> understanding the rules of the game.  Break block has no strategic
> value without understanding what the subtree from one's current
> vertex (AKA node) in the game tree is.

Strategy and high-level goal-setting are not part of a
tree-searching algorithm.  A tree search algorithm needs no
conceptual understanding of the domain it is operating in - it
merely needs to know what node to start with, how to generate nodes
from the current node, and a function for evaluating which nodes to
expand next.

A human mind is much more likely to just consider the chess-moves
that come to mind.  A human would not consider separately what
moving each piece on the board might do, and then choose to stop
thinking about moving pawn from queen's-rook-2 to queen's-rook-3
because doing something about the opposing knight that is
threatening both the queen and a bishop has a higher heuristic
value.  A human would more likely start with the *fact* that a
knight is threatening his queen and bishop, then make a *goal* of
getting out of that situation, then consider *strategies* for
achieving that goal (such as sacrificing the bishop to save the
queen, applying a threat elsewhere, etc.), and then evaluate the
fitness of these different strategies.

> But a player can solve it.  Game theorists call such a solution a
> mixed strategy.  It is a set of pure strategies, each with a
> probability assigned to it.  Optimization of a mixed strategy is
> no more cognitively interesting than a pure strategy, once it has
> been optimized. For example: Rock Paper Scissors has a solution.
> As a tuple, it is (1/3, 1/3, 1/3).  Randomly select one of R, P,
> or S.  Game theorists call a mixed strategy over all elements with
> a uniform distribution a pure random strategy.  In the case of
> RPS, it is the solution.  Having solved it, it's no more
> interesting than another solved game, such as tictactoe.

I would argue that Tic-Tac-Toe is still more cognitively interesting
than RPS because the production-model for generating a random move
from [rock,paper,scissors] is far simpler than the production-model
for playing tic-tac-toe.

Assuming that, given multiple matching rules of equal salience, one
rule is picked at random, here is a production model of the pure
random RPS strategy:

  USE-ROCK:
    if playing RPS
      then use ROCK

  USE-PAPER:
    if playing RPS
      then use PAPER

  USE-SCISSSORS:
    if playing RPS
      then use SCISSORS

where a produciton model for tic-tac-toe is much more complicated,
in fact I just happen to have some tic-tac-toe rules lying around:
http://users.wpi.edu/~ppiselli/ppiselli-TTT12.clp You don't have to
be able to understand the code - just look at the number of rules
there are and the comments.

> A solved game, for a rational player, is just a chore.  By chore,
> I mean a procedure without interesting decisions.  By a

I definitly agree with you there, anything that can be
proceduralized can be reduced to one rule: execute the procedure,
and is incredibly boring unless there is something interesting about
the skill involved in executing the procedure.

-Paolo

=====
Paolo Piselli
ppiselli at yahoo.com
www.piselli.com , www.bestcoastswing.com
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev