Upcoming Events
Unite 2010
11/10 - 11/12 @ Montréal, Canada

GDC China
12/5 - 12/7 @ Shanghai, China

Asia Game Show 2010
12/24 - 12/27  

GDC 2011
2/28 - 3/4 @ San Francisco, CA

More events...
Quick Stats
84 people currently visiting GDNet.
2406 articles in the reference section.

Help us fight cancer!
Join SETI Team GDNet!
Link to us Events 4 Gamers
Intel sponsors gamedev.net search:

Contents
 Page 1
 Page 2
 Page 3
 Page 4
 Page 5
 Page 6

 Printable version
 Discuss this article

Step 1: Focus on a fundamental activity

Giants and Castles is a game about stacking items.  Some of the actions in the game include:

  • Pick up a room: Remove token from a castle stack and add to your giant stack

  • Drop an item: Remove a token from your giant stack and place it on an adjacent stack

  • Jump on top of another giant: stacking one giant stack on top of another giant stack.

There is spell casting, inventory management, exploration, and a half dozen other meta-game activities that occur.  Everything revolves around stacking.

Think of other games that have simple easy to understand rules that describe what you do 90% of the time you play.  Super Mario Brothers is primarily a game about jumping.  Quake is about moving and shooting.  Populous is about flattening land.  The Diablo II post mortem has this comment; "First, we make the game playable as soon as possible in the development process. Our initial priority was to get a guy moving around on the screen and hacking monsters. This is what players would be doing most of the time, and it had to be fun."

There are some impressive benefits to this design strategy

  • Ease of learning: Most fundamental activities are so simple they can be taught in under a minute.  This means the player is able to jump into the game immediately.

  • Focuses game balancing: If the designer can make the core activity enjoyable, then 90% of the game is enjoyable.

  • Provides a solid foundation for additional rules: Every spell in Giants and Castles is based of variations on stacking.  By subtle expansions of a fundamental activity a rich and complex set of rules can emerge.  Look at your activity and map out the various permutations of player actions.  In Super Mario Brothers, the player could jump on top of something.  The designer extended the rule set so that this natural permutation of the core activity became "Attack enemy".

Step 2: Play the Game

After every set of rule changes, play the game.  The most common error I hear designers make is that they do heavy design at the beginning of the project and fail to test until the last month or two.  The result is a confused tangle of rules that confuse the player.   Those designers who attempt to correctly balance the game end up spending massive amounts of development resources fixing the system's underlying flaws.  Perhaps if they had started testing when the game was young, the problems would be much easier to fix.

After each iteration on the game's rules, I would get together a group of people and play Giants and Castles.  Before I began playing, I was convinced that my shiny new set of rules would work perfectly.  The sin of Grand Vision struck.  The first time I played and the next 20 iterations after that proved me wrong.

There are a couple styles to playing the game and both have their benefits.

  • Let other people play the game and then observe them.
  • Play the game yourself

Letting other people play the game results in an objective overview of how people are reacting. However the outside observer tends to miss many of the social details.  Games involve a player acting and reacting emotionally to the environment created by the game rules. Many of the trends and undercurrents are completely invisible unless you are in the game interacting with the rules and feeling your psychological responses to the situations that emerge.

Step 3: Observe the Game

Observing is the act of collecting data about player reactions to game play.

I used a crude yet remarkably effective method of observing the game.  While playing the game, I watched my fellow players.  Whenever there was frustration or boredom, I asked why.  I also asked people to make suggestions if they noticed something that felt odd or could be improved.

Every single time someone mentioned something no matter how trivial, I wrote it down.  I never argued and told them 'the way it was supposed to work.'  Such 'expert' behavior merely confused the issue and damaged their trust in me as an impartial observer.   The more I wrote things down and publicly showed I was listening, the more intelligent responses I received.

I also would ask clarifying questions.  "Could you give me an example?"  "What do you mean by that comment?"   Often a vague feeling of discomfort would rapidly crystallize into a specific issue with one of the game rules.

I wrote down my own thoughts and feelings as well.  Given the temporal nature of any psychological response, it was important to capture observations immediately.   When I waited to record my observation later, they were not as useful in determining issues because I had already let my expectations bias the data.

Admittedly, Giants and Castles is a 60-minute long multiplayer game where personal testing is logistically trivial.  However, I have great faith that a variation on this technique is possible with in-house testing of game sections.  The use of web forums, open and closed betas can glean valuable knowledge from outside testers.





Next : Page 4

© 2002 Daniel Cook. All rights are reserved.