{"id":172,"date":"2009-08-25T07:40:09","date_gmt":"2009-08-24T21:40:09","guid":{"rendered":"http:\/\/www.doolwind.com\/blog\/?p=172"},"modified":"2009-08-25T07:40:09","modified_gmt":"2009-08-24T21:40:09","slug":"choice-driven-design","status":"publish","type":"post","link":"https:\/\/www.doolwind.com\/blog\/choice-driven-design\/","title":{"rendered":"Choice Driven Design"},"content":{"rendered":"

\"\"<\/a>Sid Meier once said \u201cA game is a series of interesting choices\u201d [1]<\/sup>.\u00a0 By focussing on the choices made by the player, we can create better games through Choice Driven Design<\/em>.\u00a0 This focus on player choice should happen both at design and implementation time for best results.\u00a0 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.<\/p>\n

Interesting Choices<\/strong><\/p>\n

If all games have choices, what makes Choice Driven\u00a0Design<\/em> so different?\u00a0 The main difference is that the developers should forget about all parts of the game that don\u2019t involve or affect a player choice.\u00a0 Rather than focussing on the features being added to the game, developers should focus on the choices they are adding.<\/p>\n

The reasoning behind this is that if the player isn\u2019t making a choice about a part of the game, it\u2019s only a secondary concern for the designer.\u00a0 That isn\u2019t 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.<\/p>\n

To give a concrete example of this, let\u2019s look at Spore, specifically the Civilization stage.\u00a0 The decisions that are made in this stage include:<\/p>\n

    \n
  1. Which of 3 types of units to build<\/li>\n
  2. Which buildings to build and where to place them<\/li>\n
  3. Where to move units<\/li>\n
  4. What to do if you attack an enemy base<\/li>\n<\/ol>\n

    That\u2019s it.\u00a0 Anything outside of this should be ignored when working on the core design of the game and implementing a prototype.\u00a0 There are two main advantages to this technique:<\/p>\n

      \n
    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<\/li>\n
    2. Prototype\u2019s can rapidly be created that ignore any part of the game that doesn\u2019t have a direct impact on the player\u2019s choices in the game.\u00a0 Leading to far smaller and more rapidly created prototypes to determine how fun the game is.<\/li>\n<\/ol>\n

      What is a Fun Choice<\/strong><\/p>\n

      Ultimately, we want the player to be making \u201cfun\u201d choices.\u00a0 Fun is quite a nebulous concept and there are many different ways for a choice to be fun.\u00a0 Below is a list of points that help to make a choice more fun.<\/p>\n

        \n
      • One that isn\u2019t obvious<\/li>\n
      • Something that requires some thought by the player<\/li>\n
      • Something the player must commit to<\/li>\n
      • Where there are many options to choose from<\/li>\n
      • Or there are no \u201cgood\u201d options and so it\u2019s choosing the best of a bad set of options<\/li>\n
      • Where different players will often choose different options<\/li>\n
      • Where the same options are presented in different situations, leading to a different choice<\/li>\n
      • Where there is no perfect choice<\/li>\n
      • Where one choice effects later choices<\/li>\n<\/ul>\n

        Choice Automation<\/strong><\/p>\n

        One key concept in Choice Driven\u00a0Design<\/em> is the automation of obvious or repetitive choices.\u00a0 If you find that the same choice is always being made for a given situation, or the same choice is occurring repeatedly then don\u2019t bother the player with it.\u00a0 These choices should be automated by the game as there\u2019s no reason for the player to make the choice.\u00a0 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.<\/p>\n

        A simple example of this in every day life is the \u201cDon\u2019t Ask Me Again\u201d message in Windows.\u00a0 It is extremely annoying to be asked the same thing over and over if you are always answering the same way.\u00a0 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.<\/p>\n

        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.\u00a0 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.<\/p>\n

        How to do it!<\/strong><\/p>\n

        Below is the recommended way of developing a game using Choice Driven Design<\/em>.<\/p>\n

        Break the game down into its various sections and complete the following:<\/p>\n

          \n
        1. Write down all the choices the player must make.<\/li>\n
        2. Sit and play through the game in your head.\u00a0 Step through the list of choices and think about how interesting and fun they are.<\/li>\n
        3. Sit around the table and \u201cplay out\u201d the game based solely on the choices.\n
            \n
          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.<\/li>\n
          2. This will give you an idea of how \u201cfun\u201d the choices they make are, how repetitive they are and whether there are enough.<\/li>\n<\/ol>\n<\/li>\n
          3. Once you have solidified the design, build a prototype which again only includes the choices the player makes.\u00a0 Ignore everything that doesn\u2019t involve a player choice.\u00a0 This prototype should basically be a computerized version of the game in steps 3.<\/li>\n
          4. Make small iterations of step 4 until you are happy with how fun the prototype feels. \u00a0If you are not successful look at moving back to step 1 and redesigning the set of choices from the ground up.<\/li>\n
          5. Complete the rest of the game to bring it up to an acceptable standard for release.<\/li>\n<\/ol>\n

            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.\u00a0 By focussing on choices only, it is far easier to get a picture of the whole game at an earlier stage in development.<\/p>\n

            Depending on the game type, these steps may become quite complex.\u00a0 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.\u00a0 During typical development it can be month\u2019s before a playable prototype is ready with only a small section of the game experience completed.\u00a0 Using Choice Driven Design<\/em>, the entire core gameplay can be developed in a far shorter time leading to more agility and freedom in making changes.<\/p>\n

            Conclusion<\/strong><\/p>\n

            This sums up a basic overview of Choice Driven Design<\/em> for games.\u00a0 It\u2019s still a work in progress so I encourage people’s comments and thoughts.\u00a0 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.<\/p>\n

            [1] Rollings & Morris 2000, p. 38<\/p>\n