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

[Paolo Piselli]

--- kennerly at finegamedesign.com wrote:

> Perhaps you can encourage the knowledgeable reader by providing an
> example CTA for YPP swordfighting.  Until then I'll make

Although I don't have an active character on Puzzle Pirates, I did
dig out my Playstation and Puzzle Fighter for some quick analysis :)
Here is my quick impression of the "Puzzle Fighter task":

Memory load is kept very small because the entire game state is
visible on the screen.  At a novice level of play, this is
sufficient, but at a higher level a player will benefit from
maintaining the opponent's block-drop pattern in working memory.
Even so, maintaining one working-memory-element is a very light
load, considering that humans can handle somewhere between three and
seven WMEs in their heads at once.

ASIDE: For those unfamiliar with this stuff, a
working-memory-element, or WME, is a "chunk" of abstracted
information.  A WME can contain a whole sub-network of information,
but it remains unexpanded while in working memory (aka: what you are
actively thinking about).  Over time, a person chunks together
related mental constructs into simpler ones, which reduces the load
on their working memory.  Eventually we can "proceduralize"
information to the point that it is used reflexively.  For instance,
as I type this message I do not need to actively remember where any
of the keys are on the keyboard are - their positions never enter my
conscious brain, having been internalized to the point where my
fingers find whole sequences of them reflexively, and the load on my
working memory is much less inhibited than it was when I was first
learning to type.

I'm going to abbreviate here, and forego explicit goal-setting and
WME-matching, but a model of the Puzzle Fighter "task" at a novice
level might be something like: the player repeats the following
sequence of sub-goals until the match is over:

  1. Identify the next block to be placed
  2. Find a good place to put the block
  3. Move the block into position

Where goal 1 is fairly trivial (but still takes a non-zero amount of
time), step 2 is the really interesting part (discussed below), and
step 3 requires the manual dexterity of manipulating the controller
within a limited amount of time.

Note that just because we have a repeating sequence of the same
three goals does not mean that Puzzle Fighter is "solved" or boring.
Most games will play out in a unique way due to the constant
presence of unknowns: what block will come next for each player, and
what each player will decide to do with it.  Thus each run-through
of the simple three steps will be different - no specific sequence
can be memorized and repeated.  The player must maintain their
attention and actively think about what is going on.

And now some abbreviated production-rules for a novice player.
These are not meant to be an exact model, just a rough estimate to
give us an idea of how complex the game might be.  The saliences
would probably be dependant upon how strongly the preconditions
match.  An intermediate player would have more rules governing
big-block formation and positioning falling blocks for multiple
reasons, and an player would have even more rules governing a
higher-level strategy such as setting up multipe-breaks ans such.

  DROP-BLOCK: (salience: very low, kind of like a default)
    if we are trying to place a block
      then position it over the lowest column on the board

  BREAK-BLOCK: (salience: low)
    if part of the block to be placed is a "breaker" block, and if
    there is an exposed block of the same color on our board
      then position the "breaker" block over the exposed block

  GROUP-BLOCKS: (salience: medium)
    if part of the block to be placed is a regular block, and if
    there is an exposed block of the same color on our board
      then position the block so that the regular block will land
      adjacent to the exposed block

  BREAK-BLOCKS: (salience: high)
    if part of the block to be placed is a "breaker" block, and if
    there is an exposed block of the same color on our board that is
    connected to several other blocks of the same color
      then position the "breaker" block over the exposed group of
      connected blocks

  BREAK-BIG-BLOCKS: (salience: very high, note that "big" blocks are
  blocks that have been arranged in a rectangular shape and have
  merged - breaking them gives extra attack power against the
  opponent)
    if part of the block to be placed is a "breaker" block, and if
    there is an exposed block of the same color on our board that is
    connected to several other blocks of the same color, some of
    which are "big" blocks
      then position the "breaker" block over the exposed group of
      blocks containing the "big" block

Even from this quick-and-dirty-and-incomplete analysis of Puzzle
Fighter, we can see that it has quite a number of conditional rules
that may be applied at any given time, even at a novice level.
These decisions need to be made over and over again during the
course of one "combat" because the conditions have changed for each
iteration of the high-level goal-loop.  The combination of
uncertainty and decision-making means that Puzzle Fighter can never
be "solved" by a discovering a single, optimal procedure, even
though the game has incredibly simple mechanics and memory
footprint.

-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