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

Paolo Piselli ppiselli at yahoo.com
Sat Aug 14 10:05:20 CEST 2004


--- kennerly at finegamedesign.com wrote:

>>  - 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?

I would probably give them more time than one second. With network
latency that would require the HPBs to have near instantaneous
client-side reaction time. This affects things such as: what should
the minimum casting time on interruptable spells be?  Assuming that,
due to latency, the client sees his foe casting 0.5 sec after the
casting starts, he reacts in X amount of time, his interrupt command
takes 0.5 sec to reach the server, then the minimum casting time
should be 1 sec + upper bound for X (client-side
player-reaction-time).  My preference would be to set that lower
bound at 2 seconds to keep things from being too twitchy.  BTW - I
am all for move/counter-move as it requires player reactions during
combat, but there is no need to make it SuperStreetFighterOnline to
make it interesting.

>>  - 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?

Have you ever played the custom "Defense of the Ancients" style maps
that are popular with online Warcraft III?  The hero-vs-hero combat
has a very PvP flavor to it, with the intersting strategy coming in
the spatial posturing (analogus to the proposed "fighting stances"?)
and in the use of the abilities on timers (each hero usually has
several abilities each on 10-30 second timers).  I find that these
combats have a nice pacing that is exciting yet not 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.

>>  - 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

Hmm, I wasn't really thinking of the game-tree itself as a
working-memory element.  I was more referring to things pertinant to
decision-making that are not made explicit in the interface.  Stuff
like "this enemy can cast FOOBIE BLETCH" or "this enemy easily
blocks standard melee attacks" or "Chun Li's super combo goes like:
jump-in, kick-high, kick-medium, kick-high ..." Speaking of Street
Fighter, an elite player may know the precise timing of 40 super
moves, but during a match he will only need to actively remember the
few that belong to his opponent.

>>  - 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.

Thats ok, I just want to get people thinking about this stuff in the
context of their own project :)

> However, as soon as the player has an optimal strategy, meaning
> she has solved the game, then it's not fun any more.  The

For a fixed game tree this is possible, but this is where the
uncertainty of the opponent's move comes in.  If everyone is
constantly responding to their opponent, and there is a bit of
chance thrown in to boot, then you can't really "solve" combat in a
way that requires no decision making.  So long as the player has to
think and react, I would say the experience stays interesting.  If
the only time a player is reacting to a mob is by taunting every
20-or-so seconds when it makes a break for the healer, then of
course her game tree can be "solved".

> 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.

Good point, a user's motivations do play heavily into how much
something interestes them.  But I don't think there is any problem
with players being motivated to quest for fame, glory, and phat
lewt.

>> 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.

This sounds like a great method for adding interest - what do you
think are some good examples of non-linear skill advancement that
achieve this?

> 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.

It worked for Tetris ;) Seriously though, it is a tool in the
toolbox, but again it is ultimately limited by our constraints on
reaction-time and such. I much preferred the idea of increasing the
complexity of the mental model needed for combat.

> 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

But again, if there is a known optimal strategy for a given comabt
instance, it does not matter how many options you have.  Perhaps
discovering this strategy is fun, but discovery can only happen so
many times. I still think that making the combat process itself
inherently interesting is the way to go.

David, thanks for bouncing those ideas back at me.  I look forward
to continuing this discussion, but its getting damn late here on the
east coast!  -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



More information about the mud-dev-archive mailing list