Once you have a solid concept for a game, you can start working out how you’ll turn it into a playable experience. But development can be a risky venture. Games are inherently negotiated experiences; the designer normally just defines the parameters of play, within which the players bring the game to life. Part of the experience is created in advance, but the rest exists only in the moment of play. This means that it can be very difficult—if not impossible—to tell how well a game will play, short of actually playing it. You have to assume that the design of any game will go through a lot of revisions between conceptualization and launch.
It can also be very hard to think through all the fine points of a game’s design right from the start. In particular, games that offer great depth of play and very involving experiences are necessarily complex undertakings. Game designers need reliable tools to help them refine an idea thoroughly and efficiently.
Prototyping meets both of these needs. It minimizes risk by exposing design problems early in the process. Designers can then focus on solutions that will improve the design. Prototyping also allows designers to flesh out and refine a game at a detailed level. It brings the gaps in the design into focus, and it’s a cost-effective means by which designers can experiment with different ideas.
In this chapter I discuss two types of prototyping that will be familiar to UX designers, each of which has unique considerations in the context of game design. There’s a natural progression between the methods, moving from lower to higher fidelity and ultimately to the final form of the game.
Practice with applying these methods to game design may even yield insight into better practices for the design of conventional user interfaces. I’ve often found that the shift in thinking that is required for designing games can crack open new approaches to UX design.
Paper prototyping is beloved in the UX design community for its ability to support highly informative appraisals of early design concepts without the overhead of lengthy, expensive development cycles. But at first glance, this method we know so well might seem ill suited to many video games. Can you really represent the experience of a game like Asteroids on paper? It’s difficult enough to get a paper prototype of a Web form to reflect the way it will behave in the real world. How then can you re-create the mechanic of flying through open space and firing wildly at giant boulders that crumble into smaller pieces shooting out in different directions, all while following Newtonian physics?
Stone Librande, creative director at Maxis, advocates using paper prototypes broadly in the design of video games. He challenges participants in his workshops to create paper versions of real games they’ve played in the past, and as it happens, one session actually produced an entirely offline version of Asteroids (Figure 7-1).
Figure 7-1. The classic arcade game Asteroids, re-created as a fully playable paper prototype. A probability matrix (bottom right) determines, from a die roll, whether a shot hit or missed.
In this simulation, players chose one of four directions in which to point their spaceship, from which asteroids approached one step on each turn. Players then rolled a die to fire, and a probability matrix based on the size of the asteroid and their distance from it determined whether they were successful. This prototype successfully reduced the game to its most basic interaction.
So at least some elements of video games are suited to paper prototyping. Even if some parts of a game you’re working on don’t translate, chances are that other parts do. That’s okay; you don’t have to re-create the game as a whole faithfully. But wherever an opportunity exists to answer a design question on paper, the expediency and affordability of the paper method make it worthwhile.
While paper prototypes usually can’t offer a precise representation of an entire game experience, there are some common aspects of a game’s design that they are especially good at evaluating.
Paper is a great tool for efficiently figuring out which values to assign to elements in the game so that they balance well against one another. See the sidebar for an example of how Stone Librande applied paper prototypes toward this end in the design of Spore.
Paper-Prototyping Spore
The video game Spore (EA/Maxis, 2008) is an epic spanning the evolution of life on a planet. The player begins the game controlling a primitive organism in a small tide pool. Over time the organism evolves into a sentient race of creatures that, if successful, will conquer the planet and eventually colonize the galaxy.
I was the lead designer on the first portion of Spore, called the “Cell Game.” In this stage of the game the player starts out as a weak tadpole-like creature. The player’s goal is to navigate through increasingly hostile waters and crawl up onto land. To accomplish this, the player must make the creature evolve by growing new parts in response to environmental challenges.
One of my first tasks on this project was to determine what these parts were and how they affected the player’s experience. It was easy to generate long lists of interesting animal parts, but this was the beginning of the game and we did not want to overwhelm the player. My design challenge was to efficiently pick the smallest number of parts while still providing the greatest amount of gameplay variance. Instead of jumping right in and building an electronic prototype (which would have required the assistance of a programmer and an artist), I decided to test the initial ideas by making a simple board game. This was not intended to be an exact representation of the PC game experience, but only a quick way to determine how many parts we needed, what the special abilities were going to be, and how the different parts should relate to one another in terms of power.
Figure 7-2. A simple model for cell creatures allowing different body parts to be snapped on. Each part had its own attributes and abilities, and the prototype helped balance them against one another.
Using index cards, scissors, tape, and paper clips, I mocked up a crude collection of creature parts (Figure 7-2). Players could make different creatures by choosing which of these parts they wanted to attach to its central body. Did you want to try a speed strategy? Add more fins. Or maybe you wanted to concentrate on offensive abilities? Add powerful jaws. How about taking it slow and steady with lots of armor? Add some spikes. By simply hooking together different parts in different combinations, a player could make hundreds of unique creatures.
Next I printed out a large hex grid for the board. The goal of this game was to move your creature around the grid and collect colored beads (“food”) that were placed randomly in the hexes. Players would “swim” around the board in an attempt to gather the most food without dying.
Using the prototype, I was able to do most of the early testing by myself. I would have my mutant creatures fight each other to determine which “build” would be the best (Figure 7-3). If a particular strategy dominated the tide pool, then the corresponding parts were weakened (or removed from the game entirely), while other parts were strengthened. After a few play sessions I had generated a list of potential parts, the associated abilities (electric zap, poison spray, blood-sucking proboscis, and so on), and the tuning parameters that could be tweaked to make each part weaker or stronger.
Figure 7-3. The cell game prototype developed for Spore was so robust that it could be run as its own fully playable board game.
By working out the design as a paper prototype, I was able to save weeks of programming and art time. The final list contained just nine parts but covered the most important aspects of gameplay (movement, combat, and eating) while giving the player freedom to experiment and customize. Although there was still a lot of work to do to turn these ideas into a playable real-time PC game, the part list in the final shipping product is the same as the one that was determined while working on the paper prototype.
Stone Librande is the creative director at EA/Maxis and teaches game design at Cogswell College in Sunnyvale, California. He is a regular speaker at the annual Game Developers Conference, where he runs a workshop on paper-prototyping game ideas.
You can think of a game as a system in which events play themselves out according to the set of rules you create. Different rules result in different player behaviors, outcomes, and durations of play. How many moves should a player be able to make in one turn? How often should players be allowed to execute a special move? Should two players be allowed to occupy the same space at one time? You can use paper prototyping to experiment with different rule sets and see what effects they have. Run the prototype game repeatedly, altering the rules in each iteration while keeping all other factors the same.
Some puzzles, such as the pattern-matching mechanic of Bejeweled, can be directly translated to a paper prototype. Other puzzles can be abstracted to a point where their basic challenge is fully represented on paper. For example, one challenge in Myst involves pumping water from one flooded area to another to allow access to different puzzle elements (Figure 7-4). Players need to figure out the correct sequence in which to open up a room and make use of its components. At one point, the player must drain water from a chest and then seal it shut so that it will float when the room is flooded again.
Although the full game involves traversing an elaborately detailed ship several times and operating realistically rusty machinery, the puzzle underlying that graphical presentation is just a set of on/off conditions. This basic mechanic can be modeled using index cards to describe the state of each component, and a flowchart to determine which outcomes follow particular conditions (Figure 7-5). Creating a puzzle like this on paper is a great way to develop the basic puzzle design and discover how people respond to it.
The environment in which the game is played can also often be prototyped on paper. Paper-prototyping the environment can help to establish how different spaces are related, how far players need to travel, what strategies the environmental constraints allow, and so on. Suppose you’re developing a role-playing game in which players periodically have battlefield encounters. The progress of each battle may be heavily influenced by different elements in the environment. It may, for example, contain rivers that can be crossed only by winged characters, or rocks that allow characters to attack with projectiles from behind cover. Running the game on a paper prototype can help you design maps that produce better gameplay. You can even model 3D environments by breaking out the Legos.
It’s natural to think of video games as rich experiences full of audiovisual splendor. But at their core, they consist of fundamental conflicts that players are trying to resolve. For the sake of a paper prototype, you want to disregard all of the accoutrements of the interface and focus on the underlying mechanic of play. Pennies work well as character tokens, and index cards can be used for character properties, actions, or objects. This is about all you need to prototype the battle system of a role-playing game like Final Fantasy VII sufficiently to build a basic set of attacks, defenses, magic spells, and summoned monsters and test them against different enemies.
Don’t try to model the actual experience of the finished game in a paper prototype. Complete video games, with their real-time action and manifold interactions, are usually too complex to translate onto paper. Instead, focus each prototype on an elemental piece of the game for which it’s important to get the design right. Notice that the Asteroids prototype I described earlier didn’t have the spaceship actually flying through space; it didn’t need to, because it was just good enough to provide useful insight into the shooting mechanic. Focus on what will be sufficient to answer your design question, and don’t worry too much about other aspects of how the game will work. If needed, you can always create additional prototypes to examine other aspects of the gameplay.
The more fluidly a paper prototype executes, the more insight you can get out of it in a given period of time. You don’t want to get bogged down in excessive bookkeeping to continually note the condition of each spaceship in a fleet, or in excessive computation to calculate the amount of fuel each ship consumes, given its mass. Those may be great elements to have in the finished game, but don’t overcomplicate the prototype by trying to model them on paper.
Instead, group things that have related attributes into a single entity in the prototype, and then act on their aggregated value. For example, instead of calculating the mass of individual spaceships, you could use coins to represent each cargo item a ship holds, so that the data is easy to visualize and maintain. Eliminate as much math as you can from the prototype.
Clearly, jumping, shooting, and dodging attacks can’t work the same way on paper as they do on-screen. But they don’t necessarily need to. Instead, you can substitute probability for many of the skill-based components of games.
Suppose you’re modeling a battle sequence in Halo on paper. In the actual game, players have a greater probability of getting a kill using the sniper rifle than they do with a low-precision weapon like the plasma pistol. Equivalently, players expend more ammunition using the pistol. To prototype the battle, first invest $5 in a set of polyhedral dice. Then create an index card for each enemy, assign a die to each weapon, and note the number that players need to roll to score a kill. To kill a grunt, one of the weaker enemies, players may need to roll a 1 or 2 on a 6-sided die using the sniper rifle (a 66 percent chance) or a 5 or lower on a 20-sided die using the pistol (a 25 percent chance); otherwise the enemy scores a hit on the player. If the player gets the kill, then the number rolled could represent the amount of ammunition used in the effort. This setup would allow you to experiment with factors like the number and types of enemies that players face, the number of those enemies that are behind cover, and the amount of ammunition and health available to the player.
If you want to get a feel for how this works in practice, pick up a set of Strat-O-Matic baseball cards online or at a hobby shop (Figure 7-6). Together with a set of dice, these cards allow you to build fantasy teams of real-life players and simulate baseball games using their real-world statistics from a specific season. While Strat-O-Matic games may be very low tech, they effectively represent the rules and basic gameplay that lie at the core of baseball.
A prototype works especially well when it has a set of objectives, environmental constraints, and formal constraints that make it a complete (if small) game unto itself. Consider making it a game in which two people face off as opponents, even if you’re developing a one-player game. Playing the prototype as a real game helps generate insights because it focuses attention on the game’s fundamental conflict. It enables the people testing the game to more accurately assess whether it’s too easy or too difficult, because they’re really trying to outdo one another. Used in this way, a paper prototype stands a better chance of exposing holes in the design.
In the best circumstances you might even find that the paper game itself is pretty fun to play. A good game is a good game, regardless of the medium on which it’s played.
Finally, treat the prototype as a generative design tool and iterate it several times. This is the best time to do it, since paper is so cheap and easy to work with. Get together with a group to test-drive the prototype. Once you begin playing, people will start to come up with new ideas. Keep plenty of pens and index cards handy to capture their ideas, and then experiment with adding those suggestions to the design. Discard anything that isn’t working, and continue refining the flow until it feels appropriately challenging and fun.
Working on paper can get you only so far. At some point you need to investigate aspects of the design that can’t be sufficiently represented on paper, such as the pace of gameplay, the way online players will interact with one another, or whether people will feel comfortable with the control scheme. To get a sense of what it actually feels like to play it, you need to introduce the complexity that the computational and data-intensive elements will bring to the live game. At this point, it’s time to start developing electronic prototypes of the game.
Prototypes fulfill specific purposes in the development of a game. The more questions that a single prototype can address, the more useful it will be. In the process of documenting the idea for a game, periodically take a step back and think about areas where you’re not precisely sure how the gameplay should work, concepts that feel like they might be on the wrong track, or things that could potentially go wrong if your assumptions don’t hold up. Be critical (remember, this is all for the sake of reducing risk), and write your questions down so that you’ll have them when you’re building the prototypes. Here are some examples of questions you might prepare:
How quickly should enemy characters move?
How should the targeting system work?
Will people get through the challenges too quickly?
Is the process of creating a new character too cumbersome and time-consuming?
Can players complete this challenge in any way that bypasses the intended solution?
With these research questions in hand, you’ll be better able to decide what should go into the prototype. You may well be coding something that represents several disjointed parts from the overall game. That’s okay as long as you’re learning something valuable from each part.
Don’t prototype anything more than you need to. It’s easy to bite off too much and spend too much time developing prototypes. Remember that prototyping should be done rapidly, so that you can implement the necessary changes and make a new prototype.
Start with the elements that represent the core mechanic of the game to see how well they’re working. Such an element might be just a character jumping from one ledge to another, a farm with only one plant for you to grow, or a single set of turns taken by each player. It’s important to get the low-level elements of the design right first, because they generalize to the game experience as a whole. If they work in the prototype, you’ll be more confident that they’ll work in their proper context.
As in UX design, a good set of well-annotated wireframes can save a lot of time in the design of games by clearly specifying what needs to be prototyped and ensuring that the coded delivery is faithful to the intended vision (Figure 7-7). With a reliable set of wireframes, developers can concentrate on building the prototype and work more independently, without having to worry about having to revise the code again and again. All of this helps to keep cycle times short and development costs low.
Wireframes are also a great tool for talking about the design with other members of the team. Graphic designers have a basis for creating image assets. Developers can generate estimates of work. Business sponsors get a sense of the game’s direction. Everyone starts to develop a shared vocabulary for critically discussing the game.
Especially in the early stages, your prototypes can be as ugly as they need to be. Visual design is an important element of games, but artwork can’t sustain the experience without a foundation of high-quality gameplay. First and foremost, you should be concerned with whether the game itself is inherently interesting, challenging, and fun. Cut out excessive animations. Cut out backgrounds. Cut out lighting effects. Cut out color. Cut out sound. Cut, cut, cut. There will be time to add all of this later. Focus instead on the things that make the game worth playing.
Because electronic prototypes are relatively costly to build, you want to get every bit of life out of them that you can. As you improve the prototype and gain confidence in its design, continue building off of it. Keep making incremental enhancements as you go, incorporating progressively larger parts of the game experience. Bring the prototype into playtesting (described in the next chapter) and solicit player feedback on the design. Move gradually toward greater fidelity, incorporating image assets and sounds as they become available. In the best case, you’ll be able to reuse much of this code in developing the game itself.
Don’t let the act of creating a prototype overcommit you to a design that isn’t working. Games don’t always work as well in practice as they do in theory. You may discover that the vision you had for the gameplay experience just doesn’t materialize, and the prototype may reveal that the game isn’t any fun to play. You don’t have to give up; you may find ways to make the design work by iterating the prototype. But you also might need to go back and pursue a radically different design. If you’ve been following the advice in this chapter, then this realization should come at the earliest possible moment and with the fewest downsides. Go ahead and ball it up, take a breath, and then give it another go.
When you’ve got a solid idea and feel really excited about it, prototyping can seem like a waste of time. It can be very tempting to jump as quickly as possible from concept to all-out development. But doing so is ultimately self-defeating, because it will inevitably lead to more revisions to the finished code—when such changes are most expensive. Adopting a disciplined process that moves from low-fidelity prototypes to higher-fidelity ones over the course of the design cycle will result in better games produced at lower cost.
Prototyping is a great way to minimize the risk inherent in a game design project of any complexity. To get the most out of prototypes, you need reliable methods of assessing the quality of the gameplay experience. In the next chapter I’ll discuss how to test your designs.