Chapter 10. Integrating Level Design and Mechanics

In this chapter and the next, we shift our focus from purely emergent game mechanics to mechanics as a tool for progression design. We look at the ways that game levels organize their challenges into missions and how they interweave a story with the player’s progress. Although people often think of level design as creating spaces or using software level design tools, game mechanics play an equally important role in defining how a level provides challenges to the player.

In this chapter, we investigate how to integrate level design with the design of game mechanics. We look at different kinds of progress that take place in games and address how levels structure play. We also discuss ways that you can use levels to introduce game mechanics in such a way that players can get into the game easily.

From Toys to Playgrounds

A game’s mechanics should provide players with enjoyable gameplay, and most games offer players a structured environment and an orderly progression of goals as part of the experience. Creating the environment and the goals is part of the level designer’s job. Level design also introduces the players to the game’s mechanics a little at a time. In this chapter, we will focus on the role that levels play in structuring the gameplay experience. In the terminology of Kyle Gabbler (see the sidebar “Make the Toy First” in Chapter 1, “Designing Game Mechanics”), thus far we have been focusing on using mechanics to construct a toy. Now it is time to use that toy to create a playground.

Structuring Play

We generally think of toys as enablers for free-form play, in which players can set their own goals or play without any goals at all. Games come with a predefined goal that specifies exactly under what conditions you beat the game or your opponent; this is also called the game’s victory condition. Victory conditions can be very simple, such as to destroy all enemy ships or collect a certain number of points. Some goals are unachievable in practice: No matter how many aliens you destroy in Space Invaders, the game continues to throw fresh waves at you until you lose your last life and the game is over. In this case, the real goal of the game is not to defeat all the alien invaders but to survive and score as many points as you can before the game is over. The high-score table that Space Invaders displays after each session supports this goal and serves as a reward if you do well enough to enter your own initials.

Games of emergence typically establish simple goals such as collecting the most points or defeating enemy units. In these kinds of games it takes skill, strategy, and experience to play the game’s mechanisms and get the game into the state that the victory condition is met. This works well for short games in which the mechanics produce emergent gameplay but are not too complex. This way, players can develop their game-playing skills and strategies over multiple short sessions. For games of emergence, the exact definition of the goal can make a big difference (see the “Goals in Machinations Diagrams” sidebar).

In games of progression, goals also tend to be simple: find the treasure, rescue Princess Peach (again), or defeat the evil wizard. However, in progression games, achieving the victory condition requires the player to achieve many subgoals first. Players progress from goal to goal until they can try to complete the final goal. Compared with games of emergence, performing the action necessary to win the game might not be all that difficult, but there are many more things the player must do before she can even attempt that final action.

As we explained in Chapter 2, “Emergence and Progression,” emergence and progression are not mutually exclusive categories. Many games have elements of both. The player’s experience benefits from game mechanics structures that create emergent gameplay, but very long games also need progression features to create a sense of purpose for the player and variety in the gameplay.

Structuring Progress

Players can get a sense of progress in a game in a variety of ways. In the next few sections, we explore different kinds of progress.

Progress Through Completing Tasks

As designers, we can define progress in a game in terms of the number of tasks the player has completed. This assumes that the game has a victory condition and that it is something a player can actually achieve. This type of progress is often represented as a percentage: “You have completed 75% of the game.” Many games also offer optional tasks that players don’t have to perform to win the game. In those cases, the percentage of progress can be relative to the total number of tasks available, but the victory condition is set at less than 100% or is defined in terms of specific tasks rather than numbers. For example, Grand Theft Auto III measures progress in terms of many optional stunts and challenges, and the game lets you continue to work on them even after you have nominally achieved victory. Many classic adventure games such as the Kings Quest or Leisure Suit Larry series measure progress in terms of a number of points earned by performing particular actions. Again, most of these games could be finished without scoring all the points, and players would replay them with a goal of completing the game with all possible points.

In games in which progress comes through performing tasks, you must offer players enough variety to keep them engaged; you can’t simply string together a sequence of identical tasks. You must also pace them correctly and create a suitable difficulty curve to keep the player both interested and challenged.

Progress as Distance to Target

In games of emergence, progress is more difficult to measure in terms of numbers of completed tasks, because the tasks in such games are seldom discrete subgoals on the way to the main goal. Yet, because these games often have a victory condition that is stated in numeric terms, we can measure completion on that basis rather than in terms of tasks. For example, in Caesar III (see the discussion in Chapter 9, “Building Economies”), the goal of a certain level might be to build a city’s population up to a certain size. No specific sequence of actions leads to that target, but we can still tell players how close they are to the goal. However, in these cases, the completion percentage doesn’t always guarantee that the player will achieve the victory condition in a fixed amount of time. A player might have built a city that hosts 90% of the target population, but if she also ran out of building space or has no access to the food supplies needed to grow the city any further, she might still be a long way from obtaining the remaining 10%.

A crucial difference between this type of progress toward goals through emergent gameplay and more classical progress through completing tasks is that the player can experience setbacks. In the Caesar III example, players might lose citizens and buildings to invading barbarians, thus increasing the distance between their current achievements and the target. By contrast, once a task is finished in an adventure game, it can never be undone; the player never loses the benefit of achievements already obtained.

Another difference is that progress toward completing tasks typically follows a predesigned trajectory that takes no account of the player’s level of skill. (Puzzle-based adventure games normally have no difficulty settings the player can adjust.) Progress in emergent systems adapts to the player’s performance naturally—or it can if you set up your mechanics correctly. For example, you can use the escalating challenge and escalating complexity patterns (see Chapter 7, “Design Patterns,” and Appendix B) to adapt quickly to a player’s level of skill. In an emergent game, variation in the gameplay has to come from different phases that the game goes through as a natural part of its mechanics (see the section “The Shape of a Game of Chess” in Chapter 4, “Internal Economy”). You can use the slow cycle pattern (Chapter 7 and Appendix B) to cause gameplay phases to emerge.

Progress as Character Growth

A third way you can measure progress is through the avatar character’s own growth in strength or abilities. Role-playing games typically use this type of progress, especially table-top role-playing games and massively multiplayer online role-playing games (MMORPGs) that lack a goal that ends the game. Progress in these games is measured in numeric character levels, which are obtained by collecting numeric experience points. This type of progress tends to be open-ended: there may be no limit to the level a character can achieve. It also has the potential to offer branching growth paths, if players have to choose between different ways to advance their characters, especially when these options are mutually exclusive. A good example of this type of development is found in Deus Ex. In this game, players can find augmentation canisters that increase a character’s abilities. Each canister offers a choice among several cybernetic enhancements. Every choice is offered only once, and the players have to decide between options that support different playing styles.

As with all types of progress, character development is used to structure gameplay. For example, a player character must have a particular score for a strength ability before being able to progress to certain areas. However, because the game designers don’t have direct control over how the player chooses to develop a character, the game may need to support many different approaches to get to the same point in the game. In some cases, the game offers different possible endings based on the way the player character developed.

Progress as Player Growth

You can measure the player’s progress through the game in yet another way: through the player’s own growth in skill. Compared with role-playing games, the avatar characters in action-adventures such as The Legend of Zelda, Super Mario Bros., or Metroid Prime don’t progress much. They unlock new abilities and gain more life points over the course of play but possess nothing like the fine granularity offered by the character attributes in role-playing games. In action-adventure games, the game trains the player to use his avatar’s abilities through increasingly difficult and complex challenges.

In many action-adventure games, abilities unlock new areas for the player to explore, but often it is the player’s level of skill that determines whether he is able to reach a certain location in the game world. Use the environment to measure your player’s ability. Children do this all time in the real world, trying to walk on low walls, jump over fences, or set themselves challenges such as not stepping on cracks in the pavement. Many games use this learning instinct to great effect. When players see a collectable coin in an odd location in a platform game, most will immediately assume the designer intended it to be reachable and will try to find out how to use their avatar’s abilities and their own game-playing skills to get there. You’ll find that this instinctive and playful approach to the environment is a useful design tool for creating compelling game worlds.

Focusing on Different Structures in Your Mechanics

Large games structure their gameplay into multiple distinct levels because their mechanics are simply to complex to throw at the player at once, especially in the early stages when the player doesn’t know the game well. By creating different levels or areas in the game that focus on different mechanisms, the game breaks down its complex machinery into easier-to-manage segments. At the same time, it creates more variety in the gameplay and can require the player to explore different strategies for playing a particular game.

In some games, each level focuses on a different aspect of the game mechanics. This requires a mechanics core that is large enough to include multiple structures that generate their own gameplay—enough gameplay to carry a level. Early levels in the game highlight different subsets of the mechanics, while later levels might include all the mechanics. Figure 10.1 illustrates this. It shows how different subsets of the mechanics from the basic Lunar Colony game economy (Chapter 9) can be used to create different levels. Because the core set of mechanisms of Lunar Colony is not very large, each of these different versions will probably feel like a new introduction to the game’s mechanics.

Figure 10.1. Different subsets of the core mechanics create different levels for Lunar Colony.

StarCraft II uses this technique to great effect. As with most real-time strategy games, the economy of StarCraft II is extensive and includes resource harvesting, base building, and technology researching to create an effective strike force. The first level doesn’t involve any building. It simply lets you learn to manage your combat units and focuses on movement and combat. The second level introduces the base and resource-harvesting mechanics, but only a handful of buildings are available at this time. Only after completing particular levels do more buildings and unit upgrade options become available. After the first three levels, players get to choose which level they would like to do next, allowing them to pursue specific goals.

A big difference between the original StarCraft and StarCraft II is that many missions in the later game introduce mission-specific mechanics (we already mentioned and discussed a few of these effects in Chapter 2). For example, in the level “The Devil’s Playground,” minerals can be harvested only from low areas that are periodically flooded with hot lava (Figure 2.6). This requires players to move their units to safety from time to time. In effect, it adds a powerful slow cycle pattern to the internal economy of StarCraft II. A different slow cycle appears in the “Outbreak” level, when mutants attack the players base en masse during the night and the player goes out to destroy infested structures during the day (Figure 10.2). Other levels force players to keep moving their bases across the map to protect or attack periodic convoys or to quickly capture specific targets.

Figure 10.2. During the night cycle in the “Outbreak” level of StarCraft II, you must defend your base against hordes of mutants.

StarCraft II is a great example of how to build varying levels from the same core of game mechanics. By changing goals, disabling certain mechanisms, or adding a novel mechanism that works in a level only, you can get a lot of gameplay out of the same core. These changes to the circumstances of individual levels will require players to explore a wider variety of strategies—they can’t use the same approach to every level.

Storytelling

As we discussed in Chapter 2, games of progression often tell stories as part of their entertainment. Storytelling helps to structure levels and guide players. Stories give players a motive for achieving goals that otherwise would remain abstract or meaningless. Killing orcs in a fantasy game obtains emotional significance when the game’s story frames it as an act of vengeance or self-defense.

Stories in games work best when the mechanics, the level structure, and the dramatic arc interconnect seamlessly. The typical dungeon structure in The Legend of Zelda works because it creates synergy between story, level layout, and game mechanics. Link nearly always fights a mini-boss halfway through the level to obtain a special weapon that he’ll need to defeat the dungeon’s end boss. This structure gives the player ample opportunity to explore the new mechanics associated with the special weapon. It creates variety by introducing the new mechanics partway through the dungeon and enables progression by unlocking previously unreachable areas. In addition, it uses the familiar dramatic arc associated with adventure stories where the hero fights his way through a series of tough challenges to gain that vital edge and come out victorious.

Most storytelling in video games is either linear (the story is the same every time the player plays the game) or branching (the player makes decisions that influence the direction of the plot line in a large-scale way). Emergent storytelling, in which a story emerges entirely from the game’s mechanics and the player’s actions, has long been a holy grail of game designers. It has proven to be a particularly intractable problem because it requires designers to characterize dramatic situations and human behavior in numeric and algorithmic terms. This is far more difficult than creating the economy of even a very complex game world like that of Civilization.

Because this book concentrates on game economies, we don’t have room to discuss the various efforts that people have made toward emergent storytelling. For the moment, it remains a research topic for academics and is seldom attempted in commercial video games.

Missions and Game Spaces

When we design levels, we usually do so working from one of two perspectives on the task. One perspective focuses on the challenges that players must overcome (or tasks they must perform) to complete the level. The other perspective focuses on the layout of the game world—the simulated space in which it takes place.

In Chapter 9 of Fundamentals of Game Design, Ernest Adams explains that challenges in video games form a hierarchy, with groups of short-duration challenges combining to form larger challenges. The lowest level challenges are called atomic challenges because they cannot be further subdivided. For example, successfully landing a punch on an opponent in a boxing game is an atomic challenge, while winning the fight is a mission made up of many such challenges, and it may be necessary to win many fights to finish the game. From the challenges perspective on level design, we concentrate on defining this hierarchy.

Viewing level design from the second perspective, that of layout, we define the architecture of the level itself. In Chapter 12 of Fundamentals of Game Design, Adams describes several common spatial layouts found across different games. Some games, such as side-scrolling games or Half-Life, provide nearly linear levels. Track-based car racing games use ring-shaped layouts. Spaces in first-person shooter games designed for multiplayer combat are often quite sophisticated, with open and protected areas, doors to guard, high vantage points, and so on.

Each of these two different perspectives has its own strengths when considering different design issues. For example, it’s easier to think about pacing and difficulty curves when you view the level as a series of tasks or challenges. But storytelling and atmosphere are better understood in terms of the spatial layout of the level, at least if the story concerns a journey.

In our analyses of game levels in this book, we find it important to keep the two perspectives separate when trying to discuss them (although of course in the final product they must work together to form a harmonious whole). We refer to the mission of a level when we focus on the sequence of tasks or challenges in a level, and we use the term game space when we focus on the spatial layout of a level.

Separating these two aspects of level design helps us see how they relate to emergent gameplay. In some games, the mission of the level maps directly to its space (see the “The Dungeon Is the Mission?” sidebar). However, this is not always the case. Games can reuse the same space for different missions, as in the Grand Theft Auto games. They demonstrate that the same space can accommodate many missions if the designer makes imaginative use of it. This saves the developers time and money, because they don’t have to create a new space for every level in the game. It has gameplay benefits as well. For example, players can use previous knowledge of the space to their advantage, adding to their player’s sense of control with each mission that reuses the space.

A level’s mission and game space do depend on each other, even though we discuss them separately. A space must accommodate the mission, while the mission should ideally guide the player in her exploration of the space. In the next chapter, we’ll explore in more detail how progression mechanisms, and lock and key mechanisms in particular, serve to connect missions and spaces.

When designing a level, it often makes sense to start by designing its mission rather than its space. A mission is easier to write down and organize; its structure is usually quite simple. However, this isn’t an absolute rule. There is a risk to beginning with the mission: Designers sometimes create a very linear space to fit the mission, leaving out any opportunities for the player to explore or enjoy the space for its own sake. For some levels, it might be more interesting to start with designing an engaging space (such as a castle, space station, or famous nonfictional location) and design a mission to fit that space.

Mapping Mechanics to Missions

Game mechanics interact with missions and game spaces differently. We’ll deal with missions first and address game spaces in “Mapping Mechanics to Game Spaces” later in this chapter. The interaction with missions is often straightforward. The game mechanics dictate what actions are available in the game, and these actions suggest tasks that can be used to build missions. For example, if the game allows the player to collect flowers, a simple mission could be to collect ten flowers. In this section, we’ll explore some variations on the flower-collecting mission to make it more enjoyable.

Adding Challenges to Improve the Experience

When mapping mechanics to missions, it is important to be sure that the tasks are not too trivial or repetitive. If collecting a flower only requires the player to navigate to a location and press a button, it offers no challenge. You can use Machinations diagrams to document the challenges that a mission offers and to help you think of design strategies that avoid trivial and repetitive tasks. The mission to collect ten flowers might look like Figure 10.3. From the diagram, you can see that the mission is both trivial and repetitive. The way to complete this game is simply to click the source ten times to win. There is no choice, and the game involves no player skill. (Remember, at this point we’re discussing missions independently of the space they take place in.)

Figure 10.3. Repetitive and trivial mechanics create poor missions.

The mission can be improved by adding enemies that the player must avoid. The new mechanics are represented by Figure 10.4. In this case, the player needs to choose whether to focus on avoiding enemies or collecting flowers (if you built the diagram yourself, make sure you put the diagram in synchronous time mode so that the player can activate each element only once every second). The effect of avoiding is randomized a little: The player removes one to three threat tokens when avoiding. This randomness models variation in player skill.

Figure 10.4. Adding enemies to create choice

Playing this diagram is already tricky, mostly because of its high pace (see the sidebar “Speed vs. Cognitive Effort”). However, once you find the right balance, it is not too difficult. We can further change this by adding an interaction between the two mechanisms. In Figure 10.5, we added a mechanism that increases the rate at which threat is produced for every flower the player collects. This means that the player must spend more and more time avoiding the enemies while progressing toward the goal. This creates a nice difficulty curve for the mission. It starts out relatively easy but gets more difficult quickly.

Figure 10.5. Interaction between progress and difficulty

Adding Subtasks

Another way you can make the mechanics for the flower-collecting mission more interesting is by adding subtasks that must be completed to achieve the goal. In Figure 10.6, the goal is still the same: collect ten flowers. However, in this example, the player must perform three subtasks to unlock all the flowers to be able to achieve the goal. In this case, every subtask is represented as a simple gate but can be replaced by a more complex mechanism. For example, you can use the enemy-avoiding mechanism to create a subtask. To create variation in the game, it is best to create subtasks that offer the player different gameplay experiences, perhaps because they have unique mechanics or because they emphasize different structures in the general mechanics of the game.

Figure 10.6. Performing subtasks necessary to collect all the flowers

Many games that use subtasks do not make all the tasks available at once. They create dependencies among the tasks. We can easily add dependencies to the flower collection example (Figure 10.7). The advantage of these dependencies is that they allow the designer to control the pacing of the tasks and create a nice difficulty curve by making the more difficult tasks dependent on the easier ones. Sometimes, this leads to completely linear missions, in which the order of all the subtasks is fixed. You shouldn’t always choose this approach, however, because players appreciate some freedom of action. If your game has a fixed sequence of subtasks, you should at least make sure that the actions required to complete a subtask allow some options—otherwise, the gameplay amounts to checking off boxes. When evaluating the quality of your mission design, you should always ask yourself how many options are available to the player at a time. More is generally better than fewer, as long as you don’t overwhelm the player with options and no data about how to choose one.

Figure 10.7. Dependencies among subtasks

Exploring Advanced Techniques: Optional and Mutually Exclusive Tasks

In this book we cannot go into too much detail about the fine art of creating missions and game spaces. However, we do encourage you to experiment with the way you order the tasks and subtasks in a mission. Here we offer two advanced techniques to make missions less linear (but be warned that it also makes designing them harder): optional tasks and mutually exclusive tasks.

If you give the player an entirely optional task, be sure to think about the rewards that performing the task brings. Does the reward have an effect on the game mechanics? (For example, it might give the player a more powerful weapon.) Or is the reward just some extra eye-candy or badge of honor? Optional tasks that do affect the gameplay make the game richer, but you have to be careful that the impact is not so great that the task actually becomes a requirement to finish the game.

Many games create alternative sequences of tasks to achieve a mission goal. (For example, players might sneak past a guard and steal a key, or they might fight or bribe the guard to the same effect.) When you create alternatives like this, you can make certain tasks mutually exclusive. If the player tries to bribe the guard, it becomes impossible to sneak past him (he is aware the player is there), and if the player tries to sneak past him, bribing him no longer is an option (the guard’s suspicions are now aroused). If you set up mutually exclusive tasks, you have to be careful not to create a situation in which the game is no longer solvable. In this example, the option to fight the guard serves as a backup strategy that is always available.

Mapping Mechanics to Game Spaces

Machinations diagrams can be used to represent game spaces. To explore that idea further, we start with a diagram representing a trivial game where the objective is to make your way from a starting point to finish (Figure 10.8). A series of pools represent different locations in the game, and a single resource representing the player can be moved between these locations simply by clicking them. In this case, the player can move in only one direction. (Remember that pools pull by default. To move the player you must click an empty pool to pull him in.)

Figure 10.8. Using Machinations to represent a simple, linear game space

You can use this type of diagram to represent more open or maze like structures. For example, Figure 10.9 represents a space for a simple version of the flower-collecting game discussed in the previous section. The player is represented as a blue resource element, while the flowers are red ones. The presence of the player at a certain location makes it possible to transfer the flower to the player’s inventory by clicking an adjacent gate. Acquiring five flowers unlocks the place the player needs to reach to win.

Figure 10.9. A simple space for the flower-collecting game

In this case, the presence of the player in a certain location unlocks particular actions. This is a common use of space in a game and works equally well with one resource to represent a single-player character or multiple resources to represent a number of units under the player’s control. In fact, we can take into account the location of resources in a real-time strategy game space by allowing production units to be moved across the map. Figure 10.10 represents the mechanics of mineral harvesting in the level “The Devil’s Playground” in StarCraft II, including the periodic destruction of all SCV units in low-lying areas. Note that the distances between the pools in the diagram do not indicate the physical distance to the resources on the map. Rather, the lowered effect of SCV units on the production rate for the resources on the right represents the real distance to the base.

Figure 10.10. Resource harvesting on several locations in StarCraft II

You can use the player’s location in the game to activate certain mechanisms, and you can also use it the other way around to use the state of the mechanics to make certain locations accessible. Figure 10.9 illustrates this idea. The goal location is activated only when the player has collected five or more flowers. Mechanisms that control the accessibility of certain locations in the game space are typically lock-and-key mechanisms. In its simplest form, a lock-and-key mechanism depends on one binary state: whether or not the player has acquired the correct key. Figure 10.11 adds such a lock-and-key mechanism to the flower-collecting game.

Figure 10.11. A key mechanism (green) unlocks access to extra flowers.

Learning to Play

Part of the level designer’s job is to train the player in the required gameplay skills necessary to complete the game. Nowadays, players don’t want to read manuals to play a game; they expect to learn the mechanics as a natural part of playing the game. This is especially true of casual gamers playing games online or on mobile devices. This means that you must structure your levels in such a way that they introduce the mechanics to the players in an incremental, comprehensible progression. In this section, we will discuss two slightly different but compatible approaches to teaching the mechanics while the player plays the game.

Skill Atoms

In an article entitled “The Chemistry of Game Design” published on the Gamasutra website, designer Daniel Cook analyzed the way that players learn skills to play games (2007). He broke his hypothetical game into multiple skill atoms. Each atom constitutes a step in the learning process and consists of four events:

1. Action. This is the action the player performs, such as pressing a button or moving a mouse cursor.

2. Simulation. The game responds by applying mechanics and changing its state.

3. Feedback. This is the way the game communicates its state change via output devices. (Note that this is not positive or negative feedback within the mechanics but information “fed back” to the player.)

4. Modeling. The player then updates her mental model of the game.

Cook gives an example of these steps in the skill atom that governs jumping in Super Mario Bros.:

1. Action. The player presses the A button.

2. Simulation. The game moves the player character within its internal model of the world by applying a jumping force and gravity.

3. Feedback. The player character moves, its animation changes, and the game plays a jumping sound.

4. Modeling. The player learns that pressing A allows her to jump.

Skill atoms can depend on previously learned skills. Continuing the Super Mario Bros. example, the player needs to learn how to jump before she can learn that she can jump onto platforms or that jumping into a certain block will reveal hidden objects. Linked skill atoms form chains and trees of related skills that can be represented as graphs. For example, a small part of the skill tree for Super Mario Bros. is depicted in Figure 10.12.

Figure 10.12. A partial skill tree for Super Mario Bros.

Two important characteristics of a skill tree are its relative width and depth. If a skill tree is wide, the player must learn many new skills independently of one another. If a skill tree is deep, it has long chains of skills that depend on each other. In general, it is better to have skill trees that are relatively deep instead of relatively wide, at least to teach the skills required early in the game. The reason is that the player can pick up secondary skills (skills that build on other skills in the game) comparatively easily as an addition to something she already knows, whereas primary skills (skills at the beginning of the chain) must be learned explicitly without the benefit of any prior experience. For example, when encountering a new and unfamiliar type of game, the player has two ways of finding out what the primary skills are: She can look for in-game instructions, or she can simply try random buttons or other available input devices. When she has learned a few primary skills, she will use them to play the game and will very likely either deduce combinations that work as secondary skills or stumble on those combinations by accident. However, if she missed a primary skill (for example, she never pressed the button to shoot), she might never realize that shooting was an option and miss out on an entire branch of the skill tree.

The skill atoms work very well with dexterity-based action games in which each skill atom maps to mastering the controls to play the game. However, it can be applied just as easily to more strategic games whose challenges don’t depend on mastery of the controls. For example, in a turn-based strategy game, skill atoms might include the player understanding that a cavalry unit is very effective at fighting units of archers. The steps to learn this skill are similar to any action-based skill atom. The player needs to perform an action (order cavalry to attack archers), and the game runs a simulation (decides how effective the attack is) and provides feedback (animations and visual effects to indicate the effectiveness of the attack) that allows the player to update her mental model (attacking archers with cavalry is effective).

Martial Arts Learning Principles

Our first approach to learning in games was to define skill atoms and organize them into skill trees. Our second approach draws on the methods used in karate (and various other Japanese martial arts) training. Students must train in four different stages to complete every “level” (properly called belts or, in Japanese, dan). These stages, which build upon one another, are as follows:

• Kihon (fundamentals). The student learns to perform an individual technique. The focus is on getting the technique right.

• Kihon-kata. The student repeats the new technique endlessly to master it and perform it without thinking. If you never received martial arts training, you might recognize this stage from the endless chores the main character in the movie Karate Kid had to go through (“wax on, wax off”).

• Kata (form). The student learns how to combine different techniques in a fixed, choreographed sequence of moves called a kata.

• Kumite (sparring). To prove his mastery, the student fights his master in a free fight. For the first few levels, the master will use only a subset of simple and predictable moves, but as the student advances, the master will draw from a wider range of attacks and use them less predictably.

You might recognize these stages in many games. For example, you can apply these learning stages to Super Mario Bros. and Crash Bandicoot as well:

• Kihon. The player gets to practice a new move (such as jump) in a fairly safe environment. Once she has learned to jump, she is able to move on.

• Kihon-kata. The move is then repeated several times: The player needs to perform a series of jumps, often with increasing difficulty. Before long, the player doesn’t need to think about how to perform a jump or what button to push; she simply jumps when she needs to jump.

• Kata. During the level the player encounters a series of challenges that require combinations of moves to overcome. For example, the player needs to jump and shoot at the same time. At this stage, the movement patterns of enemies tend to be deterministic and predictable. Once the player finds the right combination of moves, that combination will work every time (during this stage).

• Kumite. The learning process is completed with a boss encounter. Boss encounters require the player to use combinations of moves in a free fight. Especially toward the end of the game, boss behavior gets more and more difficult to predict, requiring a greater and greater mastery of the moves by the player.

Games that use these learning principles often integrate them closely with their mission structure. Every stage of learning becomes a subtask, or a series of subtasks, that the player must complete to proceed. This also means that these games put more emphasis on testing the abilities of the player. To advance past the kihon stage, the player must prove that she is able to jump. These tests are easy to set up: Simply create a challenge that the player cannot avoid and that requires her to use the right skill. During the initial stages, it’s best to keep the levels simple and safe to build player confidence. During later stages you can increase the risk. These learning principles work best with fairly linear missions, or at least missions in which you have made sure that the player can face only tasks from later stages after she has completed the tasks of the early stages.

You can find this type of learning structure in the Forest Temple level in The Legend of Zelda: Twilight Princess. (We also discussed this level in Chapter 2.) In the Forest Temple level, Link has to overcome many challenges. In the early stages of the level, he encounters bomblings, small creatures that explode a few seconds after Link picks them up. His first task (kihon) with the bombling is to use it to destroy a large carnivorous plant that prevents him from reaching the next dungeon room. After that, he needs to repeat similar moves a couple of times (kihon-kata) to blast walls. When Link gains the Gale Boomerang, he learns to use the boomerang to flip special switches and pick up distant items over a series of simple tests (kihon and kihon-kata). These tests require that the player demonstrate that he is able to direct the boomerang toward a particular sequence of targets. Near the end of the level, Link must use the boomerang to pick up distant bomblings and deliver them to another carnivorous plant (kata). This prepares Link to use the same technique to fight and defeat the level boss (kumite). Figure 10.13 illustrates the structure of the mission and the locations of the learning stages within it. In this figure, the boxes represent tasks, and arrows indicate dependencies between tasks: A task is available only when the player has completed all the tasks that lead into it. Note that it omits many details to concentrate on the mission’s structure. (You can see a map of the spatial layout of the level in Figure 2.3.)

Figure 10.13. Structure of the “Forest Temple” mission

You can find a similar structure in the second dungeon of the game, the Goron Mines. To gain access to this dungeon, Link must acquire the Iron Boots, an item that he can equip to make himself very heavy, and must demonstrate how to use it (kihon). The dungeon trains the player in the various applications of this item: to sink to the bottom of bodies of water, to walk on vertical or upside-down stretches of magnetic rock, and to fight heavy and strong creatures (kihon-kata). Halfway through the dungeon, Link acquires the hero’s bow and has to use it to open several pathways by shooting at targets (kihon, kihon-kata). During this stage, he engages in several fights in which the player must switch in and out of his boots quickly and combine it with archery and sword fighting (kata). Finally, the player must combine all three skills to defeat the level boss (kumite). In fact, this structure is repeated for all dungeons in Twilight Princess. Figure 10.14 shows an overview of the mechanisms that are introduced during each dungeon and each intermission between dungeons. It shows that the game slowly introduces new mechanisms over its entire course and focuses on a different combination of mechanisms for each level. It is a very fine example of using levels to structure a smooth learning curve and create prolonged and varied gameplay. You can use such a chart to plan the learning stages of your own games as well as to analyze published games.

Figure 10.14. The introduction and focus of mechanisms in The Legend of Zelda: The Twilight Princess

Summary

In this chapter, we examined the ways that game mechanics interact with level design. We noted four different ways of measuring progress through a game: through completed tasks, through advancement toward a numerical goal, through character growth, and through growth in the player’s own abilities. We showed how it is possible to use a subset of all your core mechanics to create a specific level, using our Lunar Colony game as an example. In the section “Missions and Game Spaces,” we introduced an important distinction between the structure of a level’s mission, or sequence of tasks to be performed, and its physical layout. You can use Machinations diagrams to help you design both. The chapter ended with a discussion of the ways in which players learn to play games and how cleverly designed games always prepare a player well for what is to come. The Legend of Zelda: Twilight Princess serves as an ideal example.

In the next chapter, we will study progression mechanisms in games, especially the lock-and-key mechanism, in more detail.

Exercises

1. Review the Machination diagrams you made for earlier designs. Look for a diagram that allows you to focus on different structures that can serve as a starting point for different levels. Create a sequence of at least three different levels of ascending difficulty, simply by leaving out certain parts and changing the end conditions.

2. Examine either of the following games: Knytt Stories (http://nifflas.ni2.se/?page=Knytt+Stories) or Robot Wants Kitty (www.maxgames.com/play/robot-wants-kitty.html). Analyze how these games have structured their levels and how they train the players in playing the game. What are the differences between the structure of these games’ mission and game space? What are the skills the player learns while playing, and how are these skills linked and combined?