Tuesday 6 January 2009

Learning Curves

I was talking to Jurie Horneman once about my Ph.D. in video game usability, and I think he said something like he wished there was more understanding of learning curves in game development.



I just noticed a discussion about learning curves and Eve Online over on SlashDot: "Setting a Learning Curve in MMOs",
'If you have a chance to watch the Portal "Director's Commentary", they explain precisely how the learning curve was developed for that game, and the rationale behind it based on feedback testing.'
Ooh! That reminds me to recommend the Left 4 Dead "Director's Commentary". In that they talk a lot about playtesting.

But back to learning curves...

The point I want to make is that we need to distinguish between multiple learning curves for the same game. I think this has a lot to do with what people like about games,

"I'm getting quite sick of games with small learning curves - the ones who's mechanics you can master in less than a month without any special instruction. The ones that become a game of who went deeper into the dungeon for the better armor, who buys the more expensive weapon, who can snap-aim better (which takes skill, but is not a particularly interesting one)."

This guy clearly isn't interested in physical interface mechanics. I think that is a relatively common reaction, particularly for casual players (who simply don't have time to invest in any long learning curve). There are clearly exceptions, eg hardcore FPS players for whom physical condition and diet are important in order to maintain peak performance.

Rather than learning curve, perhaps we can even go further and be more specific about what is being learnt. So we might have one curve to describe the kind of sensoriomotor skills our poster was complaining about. There might be another to show memory requirements (if there are lots of things to remember - maybe we could distinguish between navigational memory for menu systems, numerical memory if you need to recall stats on items, etc.)

I could imagine even differentiating between quantity and speed of recall and application.

Kind of like a fundamental GOMS for games.

What are the constituent components of playing a particular game (and how do they relate to the gameplay itself)?
  • Recognition (ms) - proportional to quantity
  • Recall (ms) - proportional to quantity
  • Cognition (ms - sec) - time to understand proportional to complexity of scenario
  • Application (ms - sec) - response proportional to time spent rehearsing
So in a racing game like Pure, we might talk about duration to read the "track language" (i.e., to process the visual data into an understanding of where the avatar is in relation to the track, and decide what action needs to be taken in order to achieve our current objective - probably race the fastest, which would often mean getting into the racing line), and duration required to execute the action (usually just holding down accelerate, but sometimes executing a series of button presses and stick pushes - each of which might have both cognition and application time costs).

Meanwhile we could also talk about the sort of number crunching some games require, the statistical analysis in Pro Evolution Soccer (Wii, 2008) where you try to balance your players by looking at their percentage stats across Attack, Defence, Strength, Stamina, Pace, Technique and Goal Keeping.

Or the strategic skills involved in the resource management of the Civilization (PC) series.

I'm sure we can have far more detailed and specific understanding of what players do when they play. And from that we should be able to describe the demands a game makes on the players, and how individuals play, and even describe our intentions for what the game should require from the player through the course of a game before the game has been made.

2 comments:

Anonymous said...

"Horneman" with ONE N! *shakes fist* :P Thanks for the link though.

Gareth R. White said...

Fixed.
Sorry about that!