Chapter 1. Designing Game Mechanics

Game mechanics are the rules, processes, and data at the heart of a game. They define how play progresses, what happens when, and what conditions determine victory or defeat. In this chapter, we’ll introduce five types of game mechanics and show how they’re used in some of the more common video game genres. We’ll also discuss at what stage during the game design process you should design and prototype mechanics, and we’ll describe three kinds of prototyping, addressing the strengths and weaknesses of each. By the end of the chapter, you should have a clear understanding of what game mechanics are for and how to think about designing them.

Rules Define Games

There are many different definitions of what a game is, but most of them agree that rules are an essential feature of games. For example, in Fundamentals of Game Design, Ernest Adams defines games as follows:

A game is a type of play activity, conducted in the context of a pretended reality, in which the participants try to achieve at least one arbitrary, nontrivial goal by acting in accordance with rules.

In Rules of Play, Katie Salen and Eric Zimmerman write the following:

A game is a system in which players engage in artificial conflict, defined by rules, that results in a quantifiable outcome.

In Half-Real, Jesper Juul says this:

A game is a rule-based system with a variable and quantifiable outcome, where different outcomes are assigned different values, the player exerts effort in order to influence the outcome, the player feels emotionally attached to the outcome, and the consequences of the activity are negotiable.

(Emphasis added in all cases.) We don’t intend to compare these different definitions or to claim that one of them is the best. The point is that they all refer to rules. In games, rules determine what players can do and how the game will react.

Games Are Unpredictable

A game’s outcome should not be clear from the start: To a certain extent, games should be unpredictable. A game that is predictable is usually not much fun. A simple way of creating unpredictable outcomes is to include an element of chance, such as a throw of the dice or the twirl of a spinner in a board game. Short games such as blackjack or Klondike (the most familiar form of solitaire played with cards) depend almost entirely on chance. In longer games, however, players want their skills and their strategic decisions to make more of a difference. When players feel that their decisions and game-playing skills do not matter, they quickly become frustrated. Pure games of chance have their place in a casino, but for most other games, skill should also contribute to victory. The longer the game is, the more true this is.

In addition to chance, there are two other, and more sophisticated, ways to make games unpredictable: choices made by players and complex gameplay created by the game’s rules.

A simple game such as rock-paper-scissors (or roshambo/rochambeau) is unpredictable because its outcome depends on the decisions made by the players. The rules do not favor one choice or another; they do not suggest a particular strategy. Trying to second-guess or influence the choice of your opponent might involve empathy or reverse psychology, but it remains largely outside the individual player’s control. The classic board game Diplomacy uses a similar mechanism. In this game, players control only a handful of armies and fleets. Victory in battle simply goes to the side that committed the largest number of units to a battle. However, because all the players write down their moves secretly and resolve their turns simultaneously, the players must use their social skills to find out where their opponent will strike and to convince their allies to support their offensive and defensive maneuvers.

When the rules of a game are complex, they can also make a game unpredictable, at least to human beings. Complex systems usually have many interacting parts. The behavior of individual parts might be easy to understand; their rules might be simple. However, the behavior of all the parts combined can be quite surprising and difficult to foresee. The game of chess is a classic example of this effect. The movement rules of the 16 chess pieces are simple, but those simple rules produce a game of great complexity. Whole libraries have been written about chess strategies. Expert players try to lure opponents into traps involving many pieces that might take multiple turns to execute. In this type of game, the ability to read a game’s current state and understand its strategic complexities is the most important game-playing skill.

Most games mix these three sources of unpredictability. They include an element of chance, player choices, and complex rules. Different players prefer different combinations of these techniques. Some like games that involve many random factors, while others prefer games where complexity and strategy are key. Of these three options, chance is the easiest to implement but not always the best source of unpredictability. On the other hand, complex rule systems that offer many player choices are difficult to design well. This book will help you with that task. We devote most of the chapters to designing rule systems that create, among other things, interesting choices for players. In Chapter 6, “Common Mechanisms,” we cover random number generators (the software equivalent of dice) and discuss them at several other points as well, but we feel that chance serves a supporting, rather than a central, role in mechanics design.

From Rules to Mechanics

The video game design community usually prefers the term game mechanics to game rules because rules are considered printed instructions that the player is aware of, while the mechanics of video games are hidden from the player, that is, implemented in software for which the player is given no direct user interface. Video game players don’t have to know what the game’s rules are when they begin; unlike board and card games, the video game teaches them as they play. Rules and mechanics are related concepts, but mechanics are more detailed and concrete. For example, the rules of Monopoly consist of only a few pages, but the mechanics of Monopoly include the prices of all the properties and the text of all the Chance and Community Chest cards—in other words, everything that affects the operation of the game. Mechanics need to be detailed enough for game programmers to turn them into code without confusion; mechanics specify all the required details.

The term core mechanics is often used to indicate mechanics that are the most influential, affecting many aspects of a game and interacting with mechanics of lesser importance, such as those that control only a single game element. For example, the mechanics that implement gravity in a platform game are core mechanics; they affect almost all moving objects in the game and interact with mechanics for jumping or the mechanics that control damage to falling characters. On the other hand, a mechanic that merely enables players to move items around in their inventories would not be a core mechanic. The artificial intelligence routines that control the behavior of autonomous non-player characters are also considered not core mechanics.

In video games, the core mechanics are mostly hidden, but players will learn to understand them while playing. Expert players will deduce what the core mechanics must be by watching the behavior of the game many times; they will learn how to use a game’s core mechanics to their advantage. The distinction between core mechanics and non-core mechanics is not clear-cut; even for the same game, interpretation of what is core and what is not can vary between designers or even between different contexts within the game.

Mechanics Are Media-Independent

The mechanics of a game can be implemented through many different media. In the case of a board game, the mechanics are implemented through the medium of the game’s paraphernalia: board, counters, playing pieces, spinners, and so on. The same game can also be published as a video game. In that case, the same mechanics will be implemented in software, which is a different medium.

Because mechanics are media-independent, most game scholars do not distinguish between video games, board games, and even physical games. The relationships between different entities in the game is much the same whether implemented on a board, with pieces you move by hand, or on a computer screen, with images moved for you by software. Not only can the same game be played in different media, sometimes a single game can use more than one medium. Today more and more games are hybrids: board games that include simple computers, or physical games facilitated by clever devices hooked up to remote computers.

In addition, the media independence of game mechanics allows designers to create mechanics for one game but then implement that game in several different media; this cuts down on development time, since the design work is done only once.

Using different media can help when creating prototypes. Programming software usually takes much more work than simply writing down mechanics as rules for a board game. If the same game can be played in a board game or physical game form, it’s a good idea to try the rules/mechanics in one of those forms before going to the trouble and expense of implementing them on a computer. As you’ll see in the next section, efficient prototyping techniques are important tools in the game designer’s toolbox.

Five Different Types of Mechanics

The term mechanics has come to indicate many different types of underlying relationships between entities in games. Here are five different types of mechanics that you might expect to find in a game:

• Physics. Game mechanics sometimes define physics—the science of motion and force—in the game world (which can be different from the physics of the real world). In games, characters commonly move from place to place, jump up and down, or drive vehicles. Computing a game element’s position, the direction in which it is moving, and whether it intersects or collides with other elements makes up the bulk of the calculations in many games. Physics plays a large role in many modern games, from ultrarealistic first-person shooters to the popular physics-puzzle games such as Angry Birds. The implementation is seldom strict; however, games with so-called cartoon physics use a modified version of Newtonian mechanics so that characters can do non-Newtonian things such as change direction while in midair. (We also consider such things as timing and rhythm challenges to be part of a game’s physics.)

• Internal economy. The mechanics of transactions involving game elements that are collected, consumed, and traded constitute a game’s internal economy. The internal economy of a game typically encompasses items easily identified as resources: money, energy, ammunition, and so on. However, a game’s economy is not limited to concrete, tangible items; it can also include abstractions such as health, popularity, and magical power. In any Zelda game, Link’s hearts—a visible measure of his life energy—are part of the internal economy. Skill points and other quantified abilities in many role-playing games also qualify; these games have very complex internal economies.

• Progression mechanisms. In many games, level design dictates how a player can move through the game world. Traditionally, the player’s avatar needs to get to a particular place to rescue someone or to defeat the main evil-doer and complete the level. In this type of game, the progress of the player is tightly controlled by a number of mechanisms that block or unlock access to certain areas. Levers, switches, and magical swords that allow you to destroy certain doors are typical examples of such progression mechanisms.

• Tactical maneuvering. Games can have mechanics that deal with the placement of game units on a map for offensive or defensive advantages. Tactical maneuvering is critical in most strategy games but also features in some role-playing and simulation games. The mechanics that govern tactical maneuvering typically specify what strategic advantages each type of unit may gain from being in each possible location. Many games restrict the location of units to discrete tiles, as is the case for a classic board game like chess. Even modern strategy games played on the computer often implement tiles, although they do a good job of hiding them behind a detailed visual layer. Tactical maneuvering appears in many board games such as chess and Go but also in computer strategy games such as StarCraft or Command & Conquer: Red Alert.

• Social interaction. Until recently, most video games did not govern social interaction among the players, apart from prohibiting collusion or requiring that players keep certain knowledge secret. Now, however, many online games include mechanics that reward giving gifts, inviting new friends to join, and participating in other social interactions. In addition, role-playing games might have rules that govern the play-acting of a character, and a strategy game might include rules that govern the forming and breaking of alliances between players. Board games and folk games played by children have a longer history of game mechanisms that guide the interactions among players.

Mechanics and Game Genres

The game industry categorizes games into genres based on the type of gameplay the game offers. Some games derive their gameplay mostly from their economy, others from physics, level progression, tactical maneuvering, or social dynamics. Because the gameplay is generated by the mechanics, it follows that the genre of a game has a significant effect on the kinds of rules it implements. Table 1.1 shows a typical game classification scheme and how these genres and their associated gameplay relate to different types of mechanics. The game genres in the table are taken from Fundamentals of Game Design, Second Edition and correlate to the five different types of game rules or structures. The thickness of the outlines indicates relative importance of those types of rules for most games in that genre.

Table 1.1. Game Mechanics and Game Genres

Discrete Mechanics vs. Continuous Mechanics

We’ve listed five types of mechanics, but there’s another important distinction to be made: Mechanics can be discrete or continuous. Modern games tend to simulate physics (including timing and rhythm) with precise mechanics that create a smooth, continuous flow of play. A game object might be positioned half a pixel more to the left or right, and this can have a huge effect on the result of a jump. For maximum accuracy, physical behaviors need to be computed with high-precision fractional values; this is what we mean by continuous mechanics. In contrast, the rules of an internal economy tend to be discrete and represented with integer (whole-number) values. In an internal economy, game elements and actions often belong to a finite set that does not allow any gradual transitions: In a game you usually cannot pick up half a power-up. These are discrete mechanics. This difference between game physics and game economies affects a game’s level of dependence on its medium, the nature of the player interaction, and even the designer’s opportunities for innovation.

Understanding the Mechanics of Physics

Accurate physics computations, especially in real time, require a lot of high-speed mathematical operations. This tends to mean that physics-based games must be implemented on a computer. Creating a board game for Super Mario Bros., in which the gameplay requires moving and jumping from platform to platform, would be difficult. In platform games, physical dexterity matters, just as it does in playing real-life football; those skills would be lost in a board game. Super Mario Bros. is probably better mediated as a physical course testing players’ real running and jumping abilities. The point is, a rule that states that you can jump twice as high after picking up a certain item can be easily translated between different media, but actually implementing that jump cannot. The continuous, physical mechanics of a game need computing power more than the discrete rules that govern a game’s economy.

Interestingly, when you look back at the early history of platform games and other early arcade games, the physics calculations were more discrete than they are today. The moves in Donkey Kong were much less continuous than they were in Super Mario Bros. In Boulder Dash, gravity is simulated by moving boulders down at a constant speed of one tile every frame. It might play slowly, but it is possible to create a board game for Boulder Dash. In those days, the rules that created the game’s physical mechanics were not that different from other types of game rules. The early game computers did not have any floating-point arithmetic instructions, so the game physics had to be simple. But times have changed. Today the physics in a platform game have grown so accurate and detailed that they have become impossible, or at least inconvenient, to represent with a board game.

Mixing Physical Mechanics with Strategic Gameplay

With discrete rules, it is possible to look ahead, to plan moves, and to create and execute complex strategies. Although this isn’t always easy, it is possible, and many players enjoy doing it. Players interact with discrete mechanics on a mental, strategic level. Once players grasp the physics of a game, they can intuitively predict movements and results, but with less certainty. Skill and dexterity become a more important aspect of the interaction. This difference is crucial for gameplay and can be seen in a comparison between Angry Birds and World of Goo, two games that mix physical mechanics with strategic gameplay.

In Angry Birds, players shoot birds from a catapult at defensive structures protecting pigs (Figure 1.2). The catapult is operated with a touch device, and because the physical simulation is so precise, a small difference in launch speed or angle can have a completely different effect on the structural damage the player causes. Catapulting the birds is mostly a matter of physical skill. The strategy in Angry Birds involves those aspects of the game that are governed by discrete rules. Players have to plan to attack the pigs’ defenses most effectively using the number and types of birds available in the level. This requires identifying weak spots and formulating a plan of attack, but the execution itself is based on hand-eye coordination, and the effects can never be foreseen in great detail.

Figure 1.2. Angry Birds

Compare the mix of strategy and skill in Angry Birds with a similar mix in World of Goo (Figure 1.3). In World of Goo, players build constructions from a limited supply of goo balls. The game includes a detailed physical simulation that controls the player-built constructions. Physical phenomena such as gravity, momentum, and center of mass play an important role in the mechanics of the game. Indeed, players can form an intuitive understanding of these notions from playing World of Goo. But more importantly, players learn how to manage their most important (and discrete) resource, goo balls, and use them to build successful constructions. The difference between Angry Birds and World of Goo becomes very clear when you consider the respective effects of both games’ continuous, pixel-precise physics. In Angry Birds, the difference of a single pixel can translate into a critical hit or complete miss. World of Goo is more forgiving. In that game, releasing a goo ball a little more to the left or right usually does not matter, because the resulting construction is the same, and spring forces push the ball into the same place. The game even shows what connections will be made before the player releases a ball (as shown in Figure 1.3). You can see that the gameplay is more strategic in World of Goo than it is in Angry Birds. World of Goo depends more on its discrete mechanics than on its continuous mechanics to create the player’s experience.

Figure 1.3. World of Goo

Innovating with Discrete Mechanics

Discrete mechanics offer more opportunities for innovation than many of the current forms of continuous mechanics do. As games and genres change, designers’ definitions of physical mechanics are all evolving into a handful of directions that correspond closely with game genres. Most of the time there is little point in completely changing the physics of a first-person shooter. In fact, as games increasingly use physics engine middleware to handle these mechanics, there is less room to innovate in that area. On the other hand, all designers want to offer unique content, and many first-person shooters do include a unique system of power-ups, or an economy of items to collect and consume, to make their gameplay different from their competitor’s. There is more room for creativity and innovation in the mechanics that govern these economies than in the physics of the game. This book concentrates on discrete mechanics.

Looking back at four decades of computer game history, it’s clear that game physics have evolved much faster than any other type of mechanics in games. Physics are comparatively easy to design because of the clarity of Newton’s laws and the increasing computing power to simulate them. The laws of economics are far more complex and difficult to work with. In this book, we hope to give you a solid theoretical framework for nonphysical, discrete mechanics to make it easier.

Mechanics and the Game Design Process

There are almost as many different ways to design a game as there are game companies. In Fundamentals of Game Design, Ernest Adams advocates an approach called player-centric game design, which concentrates on the players’ roles and the gameplay that they will experience. Adams defines gameplay as consisting of the challenges the game imposes on the player and the actions the game permits the player to perform. The mechanics create the gameplay. When Mario jumps across a canyon, the level design may define the shape of the canyon, but it is the game’s laws of physics—its physical mechanics—that determine how far he jumps, how gravity behaves, and whether he succeeds or fails.

Because the mechanics generate the gameplay, we encourage you to start designing the mechanics as soon as you know what gameplay you want to offer. The development process outlined in this section is player-centric game design with an extra emphasis on creating complex, but balanced, game mechanics.

Outlining the Game Design Process

Roughly speaking, the process of designing a game goes through three stages: the concept stage, the elaboration stage, and the tuning stage. These stages are discussed next, but you can find more details about these stages in Fundamentals of Game Design.

Concept Stage

During the concept stage, the design team will decide on the game’s general idea, the target audience, and the player’s role. The results of this phase will be documented in a vision document or a game treatment. Once you have made these key decisions, you should not change them throughout the remainder of the design process.

In the concept stage, you might create a very quick, experimental version of the game’s basic mechanics just to see if it produces fun gameplay, if you are not certain what kind of game you want to make. These proof-of-concept prototypes can also help you pitch your design vision to the rest of the team or to a funding agency, or playtest key assumptions. However, you should assume that you will throw this work away and do it again from scratch in the elaboration stage. This will enable you to work faster in the concept stage, without worrying if you create something buggy. You should not start to design the real, final mechanics until this stage is over, because your plans may change and it would be wasted effort.

Elaboration Stage

During the elaboration stage—which usually begins once the project has been funded—the development of the game goes into full swing. During this phase, you will create game mechanics and levels, draft the story, create art assets, and so on. It is vital that during this phase the development team works in short, iterative cycles. Each cycle will produce some playable product or prototype that must be tested and evaluated before the design can move on. Do not expect to get everything right the first time. You will have to redesign many features during this stage. It’s a good idea to get players representative of the audience from outside your team to playtest parts of your game during this stage, too. When a prototype is playtested only by members of the development team, you will not get a good idea of how real players will eventually play and approach the game. Your development team may fall outside the game’s target audience, and they generally know the game too well to be good test subjects.

Tuning Stage

The tuning stage starts with a feature freeze. At this point, you will decide as a team that you are happy with the game’s feature set and you are not going to add any more features. Instead, you focus on polishing what you have. Enforcing a feature freeze can be difficult: You are still working on the game, and you will invariably come up with some new clever ideas you did not think of during earlier stages. However, at this late stage of development, even small changes can have devastating unseen effects on the game and add significantly to the debugging and tuning process—so don’t do it! If anything, the tuning stage is a subtractive process: You should take out anything that does not work, or has little value for the game, and focus the design on the things that do work to make it really shine. In addition, when planning a game project, it is easy to underestimate how much work tuning actually is. In our experience, polishing and tuning can take anywhere between one-third and half of the entire development time.

Designing Mechanics Early On

Game mechanics are not easy to create. We advise that you start working on your game’s mechanics early in the elaboration phase. There are two reasons for this:

• Gameplay emerges from game mechanics. It is difficult, if not impossible, to tell whether your gameplay will be fun simply by looking at the rules. The only way to find out whether your mechanics work is by playing them or, even better, by having somebody else play them for you. To make this possible, you may need to create a number of prototypes. We will go into this in more detail in later chapters.

• The game mechanics that we focus on in this book are complex systems; gameplay relies on a delicate balance within this system. Once you have mechanics that work, it is easy to destroy that balance by adding new features late in the development process or by making changes to existing mechanisms.

Once you have the core mechanics working and you are sure they are balanced and fun, you can start working on levels and art assets to go with them.

Getting It Right

As mentioned, to get game mechanics right, you must build them. The methods and theory described in this book will help you understand how mechanics work, and they will include new, efficient tools to create early prototypes, but they can never be a substitute for the real thing. You must build prototypes and iterate as much as you can to create games with balanced, novel mechanics.

Prototyping Techniques

A prototype is a preliminary, usually incomplete, model of a product or process created to test its usability before building the real thing. Because prototypes don’t have to be as polished as the final product, they are (usually) quicker and cheaper to construct and modify. Game designers create prototypes of games to test their mechanics and gameplay. Some of the more common prototyping techniques that game designers use are software prototypes, paper prototypes, and physical prototypes.

A Few Terms

Over the years, software developers have devised a number of terms to describe different types of prototypes. A high-fidelity prototype resembles the intended product closely in many ways. In some cases, a high-fidelity prototype ends up being refined into the final product. A high-fidelity prototype is relatively time-consuming to build.

In contrast, a low-fidelity prototype is quicker to build and does not need to resemble the end product as closely. A low-fidelity prototype typically uses a different technology from that used in the end product. You might use a 2D Flash game to prototype a 3D console game, or you could even use PowerPoint to create an interactive storyboard for a game. Developers build low-fidelity prototypes to test ideas quickly, and these prototypes tend to be focused on one particular aspect of the game.

Developers also create a vertical slice of the intended product with their prototype. The term comes from a visual representation of a software project, as shown in Figure 1.4. A vertical slice is a prototype that includes all the elements (code, art, audio, and anything else) required to implement one or a small number of features of a game. Vertical slices are useful for testing the moment-by-moment gameplay of a game and to give people an impression of your game while not showing the complete product. A horizontal slice is a prototype that includes all the parts of some aspect of the game but none of the others. For example, a horizontal slice might include a complete user interface but no functioning mechanics.

Figure 1.4. Vertical and horizontal slices of a game project

Software Prototyping

If you want to get a sense of how your video game will feel to your players, the best way is to create a software prototype that approximates your designs, as quickly as possible. To speed the prototyping process, it sometimes is a good idea to use open-source game engines or game development environments such as GameMaker or Unity, even if your target platform will be something completely different.

The advantage of using software prototypes is that you can get a good indication of the gameplay of your game, even if the art is only temporary and the features might be buggy or incomplete. However, the disadvantage is that creating software prototypes takes longer than creating the other kinds. Depending on the available options and the skills of your development team, it might take almost as long as making the real game. Still, it is a good idea to build software prototypes, even if you end up throwing away all the art and code that was produced for them. Having an early software prototype will help keep the project on course. Programmers will know what type of game elements are needed, level designers will have an idea of the direction the design takes, and game designers will have an environment to play around in and test ideas. Software prototypes function almost as design documents: The development team can refer to the prototype when building the real thing. The prototype can illustrate some aspects of a game, such as interactive features, better than a description in words can.

One critical factor of a successful software prototype is easy customization of the game within the prototype. When a game’s gravity is vital for the gameplay of your 3D platformer, make sure designers can change the setting easily during play in order to get a feel for what works best. If you have a factory producing resources for a real-time strategy game, make sure you can change the production rate easily in order to find the right balance quickly. Don’t waste time creating a fancy user interface for this; store key initial values in a text file that the program reads when it starts up. This way, the designers can play with the values simply by editing the file and rerunning the program. Or even better, include a simple, off-the-shelf console in your game that allows you to make changes while playing the game. This will speed up your development-test cycle even more.

Paper Prototyping

Because software prototypes are relatively slow and expensive to create, more and more game studios are using paper prototyping techniques. A paper prototype is a noncomputerized, tabletop game that resembles your game. Some game mechanics are media-independent. If your game does not rely too heavily on precise timing, physics, or other computation-intensive mechanics, you should be able to create a board game from your video game concept. If your game does rely heavily on computation-intensive mechanics, it can still be worth your time and effort to create a paper prototype for those aspects of the game that don’t. Remember, a prototype typically zooms in on a particular aspect of the game, and you just might want to zoom in on the internal economy of a game that otherwise derives most of its gameplay from its extended physics simulation. It’s important to know what aspect you want to explore before you start designing a paper prototype.

Paper prototyping is not trivial. Designing good board games is an art in itself, at least as difficult as designing a good video game. It helps if you are familiar with a wide variety of board games yourself. There are many more board game mechanics than “role a die and move that many spaces.”

Paper prototyping has two important advantages: It is fast, and a paper prototype is inherently customizable. Paper prototypes are quick to make because they do not need to be programmed. When creating a paper prototype, you should not waste time on creating nice art for cards or boards; instead, you should spend your time drafting rules and testing them. With some skill and experience, you can put together a decent paper prototype for any game in a matter of hours. That leaves you a lot of time to start playtesting and balancing the mechanics.

With a paper prototype, it is easy to change the rules. You can even do this on the fly. If during play you notice something does not work as intended, change it immediately. This way, you can almost create the game as you play. Iteration cycles do not get shorter than this.

Paper prototyping has two disadvantages: It is more difficult to involve test players, and not all mechanics translate to board games easily. If you are going to test a paper prototype with new players, you will need to explain the rules to them yourself—it’s not worth the time to write them down, because you’ll be changing them all the time. In addition, test players, especially if they have little testing or board game experience, might find it difficult to see how your paper prototype is related to a video game.

More problematic is that not all mechanics translate to paper prototypes easily. As we mentioned, mechanics that deal with a game’s physics are difficult to translate. Continuous mechanics, which are computationally intensive, really need to be implemented on a computer. This is something to take into account when creating a paper prototype: It is best used to test discrete mechanics. Paper prototyping is more suited to designing mechanics that govern a game’s economy or progression.

Physical Prototyping

Prototyping is not restricted to creating software or paper games; simply drafting rules and playing the game out in real life can be just as effective. This is especially true when a game has many continuous, physical mechanics. Running around an office building armed with laser-tag guns can give you a fairly good idea of what a first-person shooter game might feel like. Most of the time, this requires even less preparation than paper prototyping. As with paper prototyping, physical prototyping is fast and adaptable. Some game designers mix physical and paper prototyping techniques to great effect. However, again as with paper prototyping, physical prototyping is not easy: Getting it right requires some skill and expertise from both designers and players.

Prototype Focus

Apart from choosing the appropriate medium for your prototype, another critical aspect of effective prototyping is finding the right focus. Before you start building a prototype, you must ask yourself what you intend to learn from the exercise. If you are trying to find out something about the balance of the economy, you will need a different prototype from one intended to test a new user interface. Look at the prototypes of Spore (www.spore.com/comm/prototypes). Each was created for a specific reason.

Choosing a single focus should help you create prototypes faster. If you are focusing on one aspect, you do not have to prototype the entire game. A tight focus should also help you get the right feedback from test players: They will be less distracted by features (or bugs) that are unrelated to the issue you are studying.

A prototype’s focus affects the choice of prototype technique. If you are trying to design a balanced economy of power-ups in a physical platform game, a paper prototype can work even though physics are hard to reproduce as a board game. However, if you are trying control schemes with a new input device, you will need a high-fidelity, software prototype that is close to the real game.

The following aspects of game design are typical focuses for prototyping, loosely ordered from early to later prototypes:

• Tech demos. It is always a good idea to make sure you or the team of programmers can actually deal with the technology involved. For a tech demo, you should try to tackle the most difficult and most novel aspect of the game technology and prove to yourself, and ideally a publisher too, that you can build the game. Tech demos should be built early to prevent surprises during later stages of development. While building a tech demo, keep an eye out for interesting gameplay opportunities. Especially when you are working with novel technology, quickly building something simple can lead to deeper insights later.

• Game economy. A game’s economy revolves around a number of vital resources. You can prototype a game economy with low-fidelity, paper prototyping techniques; this is best done early during the design process. The following are typical playtest questions: Is the game balanced? Is there a dominant strategy that wins all the time? Do the players have interesting choices? Can they sufficiently forsee the consequences of their choices? Getting the right players for a game economy playtest is important. You and your team are good test subjects, although you will be handicapped because you have an idea of how the game is intended to be played. In general, the ideal test player for this type of prototype is an experienced power gamer who can quickly grasp the mechanics and has experience in finding and using exploits. Make sure you ask them to try to break the game. If it can be broken, you should know.

• Interface and control scheme. To find out whether players can control your game, you must have a software prototype of your game. The prototype does not need to have much content or complete levels; rather, it is a playground where players can try most of the game’s elements and interactions. These are typical playtest questions: Can players perform the actions you offer them correctly? Are there other actions they want or need? Are you giving them the information they need to make correct decisions? Is the control scheme intuitive? Do the players have the information they need to play? Do they notice they are taking damage or that a vital game state has changed?

• Tutorials. To build a good tutorial, the game must be in its later stage of development. After all, nobody wants to waste time and resources to build a tutorial for game mechanics that still might change. When testing a tutorial, it is important your test players have not seen your game before. In many ways, developing a game is like a long and detailed tutorial: Developers spend many hours tweaking mechanics, and during this time, they play a lot. It is easy to forget how skilled you have become at your own game. Therefore, you cannot trust your own judgment of the game’s initial difficulty and learning curve. You really need new players for that, and while they play, do not interfere with their learning process. The most important question for a tutorial prototype is this: Do my players understand the game and how it should be played?

Summary

Game mechanics are the precisely specified rules of a game, including not only the entities and processes at the heart of the game but also the data necessary to execute those processes. Mechanics may be categorized as continuous or discrete. Continuous mechanics are usually implemented in real time, with many floating-point calculations every second, and are most often used to implement physics in a game. Discrete mechanics may or may not operate in real time, and they use integer values to implement a game’s internal economy. It is imperative to begin designing game mechanics early, so you can create prototypes to playtest.

Particular structures exist in game mechanics that contribute strongly to emergent gameplay. In the following two chapters, we will explore this structural perspective on game mechanics in more detail, and we will use that perspective to create a practical method and design tool to help design game mechanics.

Exercises

1. Practice your prototype skills. Translate an existing video game to a paper prototype.

2. Find a relevant reference game for a game that you want to build. Explain what aspect of the reference game is useful in illustrating the kind of game you have in mind.

3. Find examples of discrete mechanisms and continuous mechanisms in a published game for each of the five types of game mechanism described in this chapter (physics, internal economy, progression, tactical maneuvering, and social interaction). Don’t use any of the examples given in this chapter.