- How Do You Even Start?
- Designing Systemic Games
- Analyzing Games from a Systems View
- Prototyping and Playtesting
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Prototyping and Playtesting
A final important part of working as a systemic game designer is iteratively getting feedback. Game design is necessarily a process of repeatedly testing and refining game design ideas in the service of an overall vision for the game. Game ideas will not make it from your mind to their final form in front of the player without having gone through many changes first. It’s common for almost everything about a game except for its single unifying vision to change multiple times during development.
As an example from a related creative field, making movies, Ed Catmull, president of Pixar, has been open about the many gyrations that films at his studios go through. “All of our movies suck at first,” he said when speaking to aspiring movie animators. He clarified that statement by adding, “A lot of people don’t believe me when I say that. They think I’m being self-effacing or modest, but I don’t mean it in that sense. I mean it in the way that the film sucks.” He went on to discuss the many story changes that the movie Up went through during its development: it started with a story about a kingdom in the sky with two princes who didn’t like each other, who fall to earth and end up meeting a giant bird named Kevin. That version went through a huge number of changes. By the time they completed the movie, he said, “All that was left was the bird and the word ‘up’” (Lane 2015).
The same sort of thing happens in games. While your game may not change as drastically as a movie like Up, you must be prepared for many iterations—many cycles through the creative process. This means you have to be willing to test your ideas over and over again, learning and changing them as you go. And it means you have to be humble enough to change an idea or throw it out if it isn’t working. Iterating and “finding the fun” inevitably means throwing away a lot of work—drawings, animations, programming, design documents, and so on. You cannot cling to something you have worked on just because you put a lot of time into it. If you do, you will be settling for an idea that is okay (or mediocre) when with a little more work and polish it could have been great.
To iterate effectively on game designs, you need to make them real. The only way to do this is to make early versions—prototypes—and test them. You may start with drawings on a whiteboard or pieces of paper and coins being pushed around on a table—anything to start actually playing with the idea you have. Most of your prototypes will be varying degrees of ugly or unfinished, converging on the full, finished, and polished product at the end. The point is to take your game design out of the realm of ideas and into real implementations that can be played and tested—and to do so as quickly and often as possible.
Playtesting is how you validate your prototypes—or, more often, how you find out where your game design is broken. Developing a game designer’s intuition for what will work or not is important, but even for the most experienced designers, it is never a substitute for testing the gameplay on players who have never seen it before. As Daniel Cook has said, without implementation and playtesting a game design remains an “ineffectual paper fantasy” (Cook, 2011b). You will need to test your design ideas with other people early and often to keep your game on track.
We will return to the topics of prototyping and playtesting often in the following chapters, particularly in Chapter 12. For now, understand that a core aspect of working as a game designer is having the humility and creative flexibility to test and refine your game design ideas based on what others think of them. You will need to make fast, often ugly prototypes, and you will need to test them with potential players repeatedly during design and development. The bright shining idea you have in your head will never survive contact with reality without change—most likely a lot of change.