Introduction to Game Design, Prototyping, and Development (2015)

Part I: Game Design and Paper Prototyping

Chapter 7. Acting Like a Designer

Now that you’ve learned something about how to take a designer’s approach to thinking about and analyzing games, it’s time to look at the way that game designers go about crafting interactive experiences.

As mentioned in previous chapters, game design is a practice, and therefore, the more design you do, the better you will get at it. However, you also need to make sure that you’re starting with the kinds of actions that will yield you the greatest gains over time. That is the purpose of this chapter.

Iterative Design

“Game design is 1% inspiration and 99% iteration.” —Chris Swain

Remember this saying from the first chapter? In this section, we explore it further.

The number one key to good design—the most important thing that you can learn from this book—is the process of iterative design shown in Figure 7.1. I have seen iterative design take some games that were initially terrible and make them great, and I’ve seen it at work across all forms of design from furniture to illustration to game design.

Figure 7.1 The iterative process of design¹

¹ Based on: Tracy Fullerton, Christopher Swain, and Steven Hoffman, Game Design Workshop: A Playcentric Approach to Creating Innovative Games (Burlington, MA: Morgan Kaufmann Publishers, 2008), 36.

The four phases of the iterative process of design are:

Analysis: The analysis phase is all about understanding where you are and what you want to accomplish. Understand the problem that you’re trying to solve (or opportunity that you’re trying to take advantage of) with your design. Understand the resources that you can bring to bear on the project. Understand the amount of time you have.

Design: Now that you have a clear idea where you are and what you’re trying to accomplish with your design, create a design that will solve the problem/opportunity with the resources you have available to you. This phase starts with brainstorming and ends with a concrete plan for implementation.

Implementation: You have the design in hand; now execute it. There’s an old adage: “It’s not a game until people are playing it.” The implementation phase is about getting from game design idea to playable prototype as quickly as possible. As you’ll see in the digital game tutorials later in this book, the earliest implementations are sometimes just moving a character around the screen—with no enemies or objectives—and seeing if the movement feels responsive and natural. It’s perfectly fine to implement just a small part of the game before testing; a test of just a portion of the game can often be more focused than a large-scale implementation could be. At the end of implementation, you’re ready to run a playtest.

Testing: Put people in front of your game and get their reactions. As your experience as a designer grows, you will get better at knowing how the various game mechanics you design will play out once the game is being tested, but even with years of experience, you will never know for sure. Testing will tell you. You always need to test early, when it’s still possible to make changes to the game and get it on the right track. Testing must also be done very frequently so that you can best understand the causes of the changes in player feedback that you witness.

Let’s look at each phase in more detail.

Analysis

Every design seeks to solve a problem or take advantage of an opportunity, and before you can start to design, you need to have a clear idea of what that problem or opportunity is. You may be saying to yourself “I just want to make a great game,” which is true of most of us, but even with that as your initial statement, you can dig deeper and analyze your problem further.

To start, try asking yourself these questions:

1. For whom am I designing the game? Knowledge of your target audience can dictate many other elements of design. If you’re creating a game for children, it is more likely that their parents would let them use a mobile device than a computer connected to the Internet. If you’re designing a game for people who like strategy games, they will most likely be used to playing on a PC. If you’re designing a game for men, you should be aware that nearly 10% of Caucasian men are colorblind.

One thing that you should always be aware of is the danger of designing a game for yourself. If you just make a game for you, there’s a legitimate possibility that only you will want to play it. Researching your intended audience and understanding what makes them tick can tell you a tremendous amount about where your game design should go and help you to make your game better.

It’s also important to realize that what players think they want and what they will actually enjoy are sometimes two different things. In your research, it’s important to try to differentiate between your audience’s stated desires and the things that actually motivate and engage them.

2. What are my resources? Most of us don’t have a budget of tens of millions of dollars with which to employ a studio of 200 people to make a game over the span of two years. But you do have some time and talent and maybe even a group of talented friends as well. Being honest with yourself about your resources, strengths, and weaknesses can help shape your design. As an independent developer, your primary resources are talent and time. Money can help you purchase either of these through hiring contractors or purchasing assets, but especially if you’re working on a small indie game team, you want to make sure that the game you’re developing makes the best use of the resources on your team. When working on a game, you should treat your time and that of your team members as a precious resource; be sure to not waste it.

3. What prior art exists? This is the single question that is most often ignored by my students (often to their detriment). Prior art is the term used to describe existing games and other media that are related to yours in some way. No game comes from a vacuum, and as a designer, it is up to you to know not only the other games that have inspired you (which, of course, you know), but also what other games exist in the same space that came before or after your primary inspirations.

For instance, if you were to design a first-person shooter for console, of course you’d look at Titanfall and the Call of Duty: Modern Warfare series, but you would also need to be familiar with Halo (the first game that made the first-person shooter [FPS] genre work on a console when conventional wisdom held that it was impossible to do so), Marathon (Bungie’s game prior to Halo, which forms the basis for a lot of the design decisions and mythology in Halo), and the other FPSs that were precursors for Marathon.

You must research prior art because you need to be sure to know everything you can about the ways that other people have tried to approach the design problem that you’re tackling. Even if someone else had the exact same idea as you, it’s almost certain that they approached it in a different way, and from their successes and mistakes, you can learn to make your game better.

4. What is the fastest path to a playable game that demonstrates what I want to test? Though often-overlooked, this question is critical for obvious reasons. You only have 24 hours available to you each day, and if you’re at all like me, only a small fraction can be devoted to game development. Knowing this, it is critical that your time is used as efficiently as possible if you want to get your game made. Think about the core mechanic of the game you want to create—the thing that the player does most throughout the game (for example, in Super Mario Bros., the core mechanic is jumping)—and make sure that you design and test that first. From that, you’ll know whether it’s worth it to make more of the game. Art, music, and all other aesthetic elements are of course critical to your final game, but at this point, you must focus on the mechanics—on gameplay—and get that working first. That is your goal as a game designer.

Of course, you’ll have many more questions of your own to add to these, but regardless of the game you’re making, these four are critical to keep in mind during the analysis phase.

Design

A large portion of this book is about design, but in this section, I’m going to focus on the attitude of a professional designer. (Chapter 14, “The Digital Game Industry,” covers this in more detail.)

Design isn’t about getting your way, it’s not about being a great genius or auteur who is followed by everyone else on the team, and it’s not even about doing a great job of communicating your vision to the rest of the team. Design isn’t about you; it is about the project. Working as a game designer is about collaborating with the rest of the team, compromising, and above all listening.

In the first few pages of his book The Art of Game Design, Jesse Schell states that listening is the most important skill that a game designer can have, and I emphatically agree. Schell lists five kinds of listening that you need to develop:²

² Jesse Schell, The Art of Game Design: A Book of Lenses (Boca Raton, FL: CRC Press, 2008), 4-6.

Listen to your audience: Whom do you want to play your game? Whom do you want to buy your game? As mentioned previously, these are questions that you must answer, and after you have answered them, you need to listen to the kinds of experiences that your audience wants to have. The whole purpose of the iterative process of design is to make something, throw it out to playtesters, and get their feedback. Make sure you’re listening to that feedback when they give it, even (especially!) if it’s not what you expected or what you want to hear.

Listen to your team: On most game projects, you’ll be working with a team of other talented people. Your job as the designer is to listen to all of their thoughts and ideas and work with them to unearth the ideas that will create the best game for your audience. If you surround yourself with people who are willing to speak up when they disagree with you, you will have a better game. Your team should not be contentious; rather, it should be a team of creative individuals who all care passionately about the game.

Listen to your client: A lot of the time, as a professional game designer, you’ll be working for a client (boss, committee, etc.), and you’re going to need to take their input. They aren’t usually going to be expert game designers—that’s why they hired you—but they will have specific needs that you must meet. At the end of the day, it will be your job to listen to them at several levels: what they tell you they want, what they think they want but don’t say out loud, and even what they really want deep down but might not even admit to themselves. With clients, you need to listen very carefully in order to leave them with an excellent impression of working with you and an excellent game.

Listen to your game: Sometimes certain elements of a game design fit together like a hand in a glove, and sometimes, it’s more like a wolverine in a Christmas stocking (p.s.: bad idea). As the designer, you’ll be closest to the gameplay, and it will be up to you to understand the game from a gestalt (holistic) perspective. Even if a certain aspect of a game is brilliant design, it might not fit well with the rest. Don’t worry; if it is a great bit of design, there’s a good chance you can find a place for it in another game... you’ll make a lot of games in your career.

Listen to yourself: There are several important aspects of listening to yourself:

Listen to your gut: Sometimes you’ll get a gut feeling about something, and sometimes these will be wrong, but other times they’ll be very right. When your gut tells you something about a design, give it a try. It may be that some part of your mind figured out the answer before your conscious mind had a chance to.

Listen to your health: Take care of yourself and stay healthy. Seriously. There is a tremendous amount of research out there showing that pulling all-nighters, being stressed, and not exercising have a tremendously negative effect on your ability to do creative work. To be the best designer you can be, you need to be healthy and well rested. Don’t let yourself get caught in a cycle of one crisis after another that you try to solve by working crazy hours into the night.

Listen to how you sound to other people: When you say things to your colleagues, peers, friends, family, and acquaintances, take a moment every once in a while to really listen to how you sound. I don’t want you to get a complex about it or anything, but I do want you to listen to yourself and ask these questions: Do I sound respectful? Do I sound like I care about the other person? Do I sound like I care about the project? All other things being equal, the people who do best in life are those who consistently demonstrate respect and care for others. I’ve known some really talented people who didn’t get this; they did all right initially, but without fail, their careers sputtered and failed as fewer and fewer people wanted to work with them. Game design is a community of shared respect.

There are, of course, many more aspects to acting like a professional designer than just listening, but Schell and I agree that it is one of the most important. The rest of this book covers more nuts-and-bolts aspects of being a designer, but all of it must be approached with the humble, healthy, collaborative, and creative attitude I’ve outlined here.

Implementation

The latter two-thirds of this book are about digital implementation, but it’s important to realize that the key to effective implementation in the process of iterative design is to get from design to playtest in the most efficient way possible. If you’re testing the jump of a character in a platform game like Super Mario Bros. or Mega Man, you will need to make a digital prototype. However, if you’re testing a graphical user interface (GUI) menu system, you don’t need to build a fully working digital version; it’s perfectly fine to print out images of the various states of the menu and ask testers to navigate through them with you acting as the computer (and swapping the printed images by hand).

For instance, the diagram in Figure 7.2 shows some different screens from a GUI mockup of an options menu. Each playtester would only be shown one screen at a time, starting with #1, the Options Menu. While shown screen #1, the playtester would be instructed to “Press the selections you would make to turn the subtitles on.” (You would encourage the playtesters to actually touch the paper as if they were touching a touchscreen.)

Figure 7.2 A simple paper GUI prototype.

Some playtesters might press the Video button, whereas others might press Audio (and a few might press Game). Once the user made a selection, the #1 sheet of paper would be replaced with the menu of their selection (for example, #2 Video Options). Then, presumably, the playtester would press the Subtitles: on / OFF button to switch the subtitles on, which would cause #2 to be replaced with #4 Video Options.

One important thing to note here is that subtitles are available to be changed on both the video and sound options screens. For testing this works well because regardless of which of the two options are chosen by the player (Video or Audio), you can then subsequently test whether the “on / OFF” capitalization clearly conveys that the subtitles are currently turned off.

Paper prototyping is covered further in Chapter 9, “Paper Prototyping.”

Testing

As you’ve just seen, paper prototyping can be the fastest way to get to playtesting when you’re in the early phases of a project. Chapter 10, “Game Testing,” covers several different aspects of testing. The key thing to keep in mind now is that regardless of what you think about your game, you won’t really know anything until a player (who is not you) has tested it and given you feedback. The more people who play your game, the more legitimate that feedback will be.

In my Game Design Workshop class at the University of Southern California, each of our board game projects took place over four weeks of labs. In the first lab, the students were placed in teams and given time to brainstorm their game ideas. Every subsequent lab was devoted entirely to playtesting the current version of their game. By the end of a 4-week project, each student team had completed nearly 6 hours of in-class playtesting and had drastically improved their designs as a result. The best thing you can do for your designs is to have people playing them and giving you feedback as often as possible. And, for the sake of all that is good, please write down what your playtesters tell you. If you forget their feedback, the playtest is a waste.

It is also important to make sure that your playtesters are giving you honest feedback. Sometimes, playtesters will give you overly positive feedback because they don’t want to hurt your feelings. In The Art of Game Design, Jesse Schell recommends telling your testers something like “I need your help. This game has some real problems, but we’re not sure what they are. Please, if there is anything at all you don’t like about this game, it will be a great help to me if you let me know”³ to encourage them to be honest with you about flaws they see in the game.

³ Jesse Schell, The Art of Game Design: A Book of Lenses (Boca Raton, FL: CRC Press, 2008), 401.

Analysis/Design/Implementation/Testing/Repeat!

After you have run your playtest, you should have a lot of feedback written down from your testers. Now it’s time to analyze again. What did the players like? What didn’t they like? Were there places in the game that were overly easy or difficult? Was it interesting and engaging?

From all of these questions, you will be able to determine a new problem to solve with your design. For instance, you might decide that you need to make the second half of the first level more exciting, or you may decide that the game has too much randomness.

After each playtest session, I review the feedback from my players and fill out the chart shown in Figure 7.3 with a line for each issue on which players have given feedback.

Figure 7.3 One line from a playtest analysis chart

This is only a single sample line from the chart that could be dozens or hundreds of lines long. The first thing I do when creating this chart is to collect similar feedback together. You need to make sure that all testers are talking about the same part of the game, so you should have some sort of system for marking where they were in the game when they made the comment (e.g., Boss1). Then, place all similar comments in the same Feedback cell. Next, analyze these comments as a whole and attempt to understand what is causing the players to feel this way. Then decide how serious you think this underlying issue is and if it is an issue of Medium or High severity, propose a solution that might fix the problem. After you have all of your proposed solutions it’s time to take them into the design phase and continue the cycle of iterative design. Each subsequent iteration of the design should include some changes, but not all of those you have proposed. The most important thing is to get to the next playtest quickly and determine whether the solutions that you have implemented solved the problems they were meant to solve.

Innovation

In his book The Medici Effect,⁴ author Frans Johansson writes about two kinds of innovation: incremental and intersectional. Incremental innovation is making something a little better in a predictable way. The progressive improvement of Pentium processors by Intel throughout the 1990s was incremental innovation; each year, a new Pentium processor was released that was larger and had more transistors than the previous generation. Incremental innovation is reliable and predictable, and if you’re looking for investment capital, it’s easy to convince investors that it will work. However, as its name would suggest, incremental innovation can never make great leaps forward precisely because it is exactly what everyone expects.

⁴ Frans Johansson, The Medici Effect: What Elephants and Epidemics Can Teach Us about Innovation (Boston, MA: Harvard Business School Press, 2006).

The other kind of innovation is intersectional innovation. Intersectional innovation occurs at the collision of two disparate ideas, and it is where a lot of the greatest ideas can come from. However, because the results of intersectional innovation are novel and often unpredictable, it is more difficult to convince others of the merit of the ideas generated through intersectional innovation.

In 1991, Richard Garfield was trying to find a publisher for his game RoboRally. One of the people he approached was Peter Adkison, founder and CEO of Wizards of the Coast. Though Adkison liked the game, he didn’t feel that Wizards had enough resources to publish a game likeRoboRally that had so many different pieces, but he mentioned to Richard that they had been looking for a new game that could be played with very little equipment and resolve in 15 minutes.

Richard intersected this idea of a fast-play, low-equipment card game with another idea that had been kicking around in his head for a while of playing a card game with cards that were collected like baseball cards, and in 1993, Wizards of the Coast released Magic: The Gathering, which started the entire genre of collectible card games (CCGs).

Though Garfield had been thinking about a card game that was collectible for a little while before his meeting with Adkison, it was the intersection of that idea with Adkison’s specific needs for a fast-play game that gave birth to the collectible card game genre, and nearly all CCGs that have come since have the same basic formula: a basic rule set, cards that have rules on them which override the basic rules, deck construction, and fast play.

The brainstorming procedure described in the next section takes advantage of both kinds of innovation to help you create better ideas.

Brainstorming and Ideation

“The best way to have a good idea is to have a lot of ideas and throw out all the bad ones.” —Linus Pauling, sole winner of both the Nobel Prize in Chemistry and the Nobel Peace Prize

Just like anyone else, not all of your ideas are going to be great ones, so the best you can do is to generate a lot of ideas and then sift through them later to find the good ones. This is the whole concept behind brainstorming. This section covers a specific brainstorming process that I have seen work very well for many people, especially in groups of creative individuals.

For this process, you will need: a whiteboard, a stack of 3x5 note cards (or just a bunch of slips of paper), a notebook for jotting down ideas, and various whiteboard markers, pens, pencils, and so on. The process works best with five to ten people, but you can alter it to work for fewer people by repeating tasks, and I’ve modified it in the past to work for a classroom of 65 students. (For instance, if you’re by yourself, and it says that each person should do something once, just do it a few times until you’re satisfied.)

Step 1: Expansion Phase

Let’s say that you are just starting a 48-hour game jam with a few friends. The theme of the game jam is uroboros (the symbol of a snake eating its own tail symbol). This was the theme of the Global Game Jam in 2012. Not much to go on, right? So, you start with the kind of brainstorming that you learned in grade school. Draw an uroboros in the middle of a white board, draw a circle around it, and start free associating. Don’t worry about what you’re writing at this point—don’t censor anything—just write whatever comes to mind as you go. Figure 7.4 shows an example.

Figure 7.4 The expansion phase of brainstorming a game for uroboros