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

kennerly at finegamedesign.com kennerly at finegamedesign.com
Sat Aug 14 03:12:48 CEST 2004


Hey Paolo, that was a great overview of the goals that we've been
pursuing.  I appreciate the top-down perspective.  Although, I'm not
sure how I miscommunicated as to suggest that I (or anyone else) was
fishing for complexity, randomness, or chess.

Paolo Piselli wrote:

> It seems to me that the discussion of "better combat" is diving
> depth-first into tangents on chess, randomness and game mechanics

.... and UI, and downtime, and community.

> I don't think any one of "make it like chess", "make it more
> random", or "make it more mechanically complex" are good
> general-case solutions.

I don't think anyone here has said they are.  Those are tangents,
explorations, or in Paul Schwanz's case of speed chess, only an
analogy.

> To me this cries "cognitive task analysis" - not "search trees" or
> "game mechanics"

The humane side of human-computer interaction is a welcome inclusion
into the discussion.

> (I guess those with hammers will always see nails).

  (One could equally well guess that those without hammers will
  avoid nails.  :) )

I'd be in bliss if I could entertain players without applying
discrete mathematics.  I avoid it at every possibility.  But since
players aren't blissful in a broken game, such math must be done.

Of course cognitive psychology applies wonderfully to combat design.
So I'm happy to listen to your insight on CTA and combat.

> In my estimation, Puzzle Pirates has you all beat for this one
> reason: "combat" via those puzzles is far more cognitively
> interesting than "debuff, stun, nuke, nuke, nuke" or whatever
> variation thereof is the optimal combat procedure for class X in
> game Y.

You all?  Super Puzzle Fighter II Turbo (from which Puzzle Pirates
Swordfighting is derived), is fun, and YPP ship versus ship
swordfighting is even more fun.  Yet, I didn't want to insert a
tangent into the thread.  :)

> IMO the question we need to answer is:

I don't know the answers to your questions.

Perhaps you can encourage the knowledgeable reader by providing an
example CTA for YPP swordfighting.  Until then I'll make some up to
encourage a knowledgeable reader to post.  Pulling numbers out of my
ass:

>  - what kind of mastery of the keyboard and mouse should the
>  player have?

How about a lower-bound of 10 wpm typing speed and 5 pixel
click-radius on 800x600 monitor?  No upper bound constraint
required.

>  - how fast of a reaction time will the player be required to
>  have?

No faster than the roundtrip lag of the network, so about 1 second
lower-bound is safe in the US on 56 kbps modem?  Upper-bound depends
on desired pace...

>  - how frequently will the player have to make decisions?

John Buehler proposed no more often than once each 3 seconds.  But
that's just one pacing preference.  How about a range from 1 second
to 15 seconds?

>  - how much time will the player have to make strategic decisions?

No less than reaction time; e.g., 1 second.  No more than 15
seconds?

>  - how much information will the player have to remember during
>  combat?

Depends on the desired combat.  To continue my magic number trick:
between 0 and 3 preceding game states?  Let's say each state has no
more than 10 bits of essential information?  (After any algebraic or
other human data-compression techniques.)

>  - how many cognitive structures (production rules, decision-tree
>  nodes, or whatever model you prefer) will the player need to
>  maintain in order to be successful at combat?

I can't estimate combinatorics without first designing the combat.

However, as soon as the player has an optimal strategy, meaning she
has solved the game, then it's not fun any more.  The obvious
examples are tictactoe and nim.  Therefore, while the novice game
can be trivial, the master game should have a lower-bound no less
than a few thousand unique, asymmetric game states.  Just an
estimate.  It also depends on how much essential information is in
each game state and the frequency of decision- making, which you
queried above.

> ...and a thought to lead off discussion on changes that will
> increase interest: - Wether its RPS fighting-stances or alpha-beta
> decision-trees, I see these things simply as ways of increasing
> cognitive-load, and evaluating their effectiveness at improving
> combat amounts to evaluating how they impact the cognitive tasks
> involved.

Not all equal cognitive loads are equally entertaining.  Both a D&D
3.5e character and a 1040EZ tax form require an equal amount of
paperwork.  Both reading a cereal box's ingredients and a sonnet
impose an equal cognitive load.

> ...and a thought to lead off discussion on player learning: -
> well, since IMO its all about cognitive-load, then the natural
> conclusion is to increase cognitive-load over time.

Which a decent MMP does: Over time a player gains new items and new
skills that require new and more complicated tactics.

Again, however, it would silly to only increase cognitive-load over
time. For example, a simple method is just to speed up the rate.  To
double the cognitive-load, cut the decision making time from 2
seconds per cycle to one second.  This works for some training, but
it's not panacea for games.

> However, our constraints put a limit on this in order to keep the
> game accessible.  I'd propose to allow players of all capacities
> to be successful at combat, yet give benefits to those capable at
> performing at a higher level (less downtime, more XP, whatever).

Or increase combinations over time, which an MMP does (and many
non-MMPs do).  A player doesn't start out in Lineage, EverQuest, or
any of the other MMP with all the abilities or access to every
tactic.  I thought CoH was remarkable in how accessible it is, due
to the small number of combinations at security level 1.

Despite the last cautionary comments, I look forward to reading your
perspective on cognitive task analysis applied to combat design.
Since CTA has been applied to military teams, and since most MMP
combat is more interesting in teams, its application here has me
.... cognitively interested.

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



More information about the mud-dev-archive mailing list