Sid Meier once said “A game is a series of interesting choices” ^[1].  By focussing on the choices made by the player, we can create better games through Choice Driven Design.  This focus on player choice should happen both at design and implementation time for best results.  I will discuss why the focus on choices is so important, how this fits in with agile game development and give some practical ways of mapping out the choices made by the player.

Interesting Choices

If all games have choices, what makes Choice Driven Design so different?  The main difference is that the developers should forget about all parts of the game that don’t involve or affect a player choice.  Rather than focussing on the features being added to the game, developers should focus on the choices they are adding.

The reasoning behind this is that if the player isn’t making a choice about a part of the game, it’s only a secondary concern for the designer.  That isn’t to say that these other parts are unimportant, they simply have a lower importance than (and serve as a distraction from) the core game play that should be focussed on first.

To give a concrete example of this, let’s look at Spore, specifically the Civilization stage.  The decisions that are made in this stage include:

1. Which of 3 types of units to build
2. Which buildings to build and where to place them
3. Where to move units
4. What to do if you attack an enemy base

That’s it.  Anything outside of this should be ignored when working on the core design of the game and implementing a prototype.  There are two main advantages to this technique:

1. Less design time is wasted on the extraneous parts of the design focussing the designers time to the most important parts of the game
2. Prototype’s can rapidly be created that ignore any part of the game that doesn’t have a direct impact on the player’s choices in the game.  Leading to far smaller and more rapidly created prototypes to determine how fun the game is.

What is a Fun Choice

Ultimately, we want the player to be making “fun” choices.  Fun is quite a nebulous concept and there are many different ways for a choice to be fun.  Below is a list of points that help to make a choice more fun.

• One that isn’t obvious
• Something that requires some thought by the player
• Something the player must commit to
• Where there are many options to choose from
• Or there are no “good” options and so it’s choosing the best of a bad set of options
• Where different players will often choose different options
• Where the same options are presented in different situations, leading to a different choice
• Where there is no perfect choice
• Where one choice effects later choices

Choice Automation

One key concept in Choice Driven Design is the automation of obvious or repetitive choices.  If you find that the same choice is always being made for a given situation, or the same choice is occurring repeatedly then don’t bother the player with it.  These choices should be automated by the game as there’s no reason for the player to make the choice.  You can inform the user that the choice has been made so in the rare case that they want to make a different choice they can.

A simple example of this in every day life is the “Don’t Ask Me Again” message in Windows.  It is extremely annoying to be asked the same thing over and over if you are always answering the same way.  You can always go into the options and turn this automated answer off, but 99% of the time you will want it to perform the action for you.

During this critical analysis of the choices in a game you need to be bold and be prepared to remove or automate obvious and repetitive choices.  By removing or automating the choice, you will quickly see a gap forming and then have the option to replace it with a more interesting choice.

How to do it!

Below is the recommended way of developing a game using Choice Driven Design.

Break the game down into its various sections and complete the following:

1. Write down all the choices the player must make.
2. Sit and play through the game in your head.  Step through the list of choices and think about how interesting and fun they are.
3. Sit around the table and “play out” the game based solely on the choices.
   1. Ask the player questions based on the choices they must make and act as if they are playing the game, continuing to ask questions based on their previous ones.
   2. This will give you an idea of how “fun” the choices they make are, how repetitive they are and whether there are enough.
4. Once you have solidified the design, build a prototype which again only includes the choices the player makes.  Ignore everything that doesn’t involve a player choice.  This prototype should basically be a computerized version of the game in steps 3.
5. Make small iterations of step 4 until you are happy with how fun the prototype feels.  If you are not successful look at moving back to step 1 and redesigning the set of choices from the ground up.
6. Complete the rest of the game to bring it up to an acceptable standard for release.

Once all sections are complete you can look at the game as a whole and determine if there is any part of the game that is weaker than the others.  By focussing on choices only, it is far easier to get a picture of the whole game at an earlier stage in development.

Depending on the game type, these steps may become quite complex.  It may seem like a waste of time to perform these actions, however finding any problems before step 6 will greatly reduce the time required to make changes.  During typical development it can be month’s before a playable prototype is ready with only a small section of the game experience completed.  Using Choice Driven Design, the entire core gameplay can be developed in a far shorter time leading to more agility and freedom in making changes.

Conclusion

This sums up a basic overview of Choice Driven Design for games.  It’s still a work in progress so I encourage people’s comments and thoughts.  By focussing on the key choices made by a player we should begin to see deeper and more enjoyable games while minimizing risk in the development.

[1] Rollings & Morris 2000, p. 38