FUNDAMENTALS OF GAME DESIGN, SECOND EDITION
. Actions for Gameplay
Most of the actions that a player takes in a game are intended to meet the challenges that she faces. This book cannot possibly provide a list of all the kinds of
gameplay-related actions that players can perform in game worlds; they vary from the simple and concrete, such as fire weapon, to those as complex and abstract as send covert operatives to arouse antigovernment sentiment in a hostile nation—which the player could do in Balance of Power by choosing a single item on a menu. Study other games in the genre you have chosen to see what actions they support.
The interaction model that you have chosen for a particular gameplay mode determines a lot about the kinds of actions available in that mode. If you use an avatar-based interaction model, then the actions available to the player, for the most part, consist of influencing the game world through the avatar. In games using a multipresent model, the player acts indirectly by issuing commands to units, which themselves act within the game world (as in real-time strategy games), or acts directly on features of the world itself (as in construction and management simulations and god games).
Don't expect a one-to-one mapping between actions and challenges; many games include a large number of types of challenges but only a small number of actions, leaving the player to figure out how to use the actions in various combinations to surmount each challenge. Puzzles frequently do this. Faced with a scrambled Rubik's Cube, the player can take only one action: She can rotate one face of the cube 90 degrees. The solution to the puzzle consists entirely of making similar rotations.
Games offer many challenges but limited numbers of actions for two reasons. First, if you give the player a large number of actions to choose from, you must also provide a large user interface, which can be confusing to the player and increase the difficulty of learning the game. (If you implement a context-sensitive interface that chooses the correct action for the user based on context, you don't give the player the freedom to try interesting combinations.) Second, a large number of actions usually requires a large number of animations to display them all. This makes the game expensive to develop.
Many great games implement only a small number of actions but still let the player use them to overcome a wide variety of challenges. If you are imaginative enough, the challenges will be so interesting that the player will never notice.
To define the actions that you'll implement, begin by thinking about the player's role in the game. At the concept stage of your project, you asked, "What is the player going to do?" You should have some general answers to that question. Now it's time to go into detail for each gameplay mode. Begin with the primary mode.
If you wrote, "In the primary gameplay mode, the player will drive a car," think about exactly what actions driving entails. Pressing the accelerator, turning the steering wheel, and braking, of course, but what else? Shifting the gears? Turning on the lights? Using the handbrake? Some of the actions you decide on may have to do with challenges; others will simply be another part of the role.
Next, look at the challenges you designed for the primary gameplay mode. Begin with the atomic challenges you plan to offer; for each atomic challenge, write down how you expect the player to overcome it. Your answers will probably consist of individual actions or small combinations of actions. Ben Cousins has argued that game designers should spend most of their effort defining and refining the way that actions overcome atomic challenges because the player spends most of his time performing those actions (Cousins, 2004); this is excellent advice.
After you define the actions that will meet the atomic challenges, consider the intermediate and higher-level challenges in the gameplay mode. Can they all be met with the actions you've defined, or will they require additional ones? Add those to the list.
Finally, consider actions unrelated to gameplay that you may want to make available to the player. You may already have some that come with the player's role, but you may want to include others for other reasons. See the list in the next section for some ideas.
Once you have been through this process for the primary gameplay mode, do it all again for each of the other modes. When you believe you have comprehensive lists of all the actions that you want to include in each mode, you're ready to start defining the user interfaces for the different modes: assigning actions to control mechanisms. (See Chapter 8.)
