How I Teach Game Design. 
Lesson 1: The Game Design Process

how and why to iterate + a game modification exercise

Iterative design

In the syllabus I shared in my last How I Teach Game Design post, graded assignments are given out on one week, and then one or two or three weeks later, they are due. So what happens in-between, during the actual work time? The answer is: the iterative design process.

Iterative design means a process focused on playtesting. You produce a playable prototype of a game as quickly as possible, then playtest the prototype, and you decide how to evolve the game based on the experience of the playtest. One way of understanding iterative design would be its opposite: a designer who works out all of the details of a game in advance, and creates a final set of rules and other materials without ever actually playing the game.

Of course, this caricature is absurd: no game designer I know has ever released a game without playtesting it. But I do have a particularly strong emphasis on iterative design in my teaching and my creative practice as a designer. The game designer Kevin Cancienne once called me a “playtesting fundamentalist’ – and perhaps he’s right. (So much for my stance against fundamentalism.)

What’s the big deal about iteration? The behavior of complex, interactive systems – like games – is incredibly difficult to predict. You generally cannot know exactly what players are going to do once they start playing your game. The only way to find out is to actually build some primitive version of your game, have people play it, and see what happens. Each time you playtest, you find out what does and doesn’t work, make some adjustments, and then play again. That’s why it is called the iterative process – you create successive versions, or iterations, of your game as you go.

The process of iteration consists of these steps:

1. design a prototype
2. playtest your prototype
3. analyze what happened 
    (then it’s back to step 1 - modifying your game to create a new prototype)

In a game design class, most of the playtesting will be done by the designers themselves, especially for short assignments. But of course it is always good for other people to play the games and give feedback – such as designers playing each others’ games in a class. For commercial game development, of course, a more rigorous playtesting process is highly recommended. (More details about playtesting methodology are coming in future posts.)

Principles of iteration

Below are a few ideas to keep in mind about the iterative process.

Ideas are cheap. People often romanticize the creative process, assuming that the hardest part of doing anything is to come up with a “good idea.” I could not disagree more. Ideas in and of themselves – by which I mean a concept you might have for a game – are not that important. Game design ideas gain value, sophistication, and meaning only when they are playtested. The hard work of the process, the actual game design itself, happens during the iterative process, not the concepting process that proceeds it.

Stop brainstorming and start prototyping. When a group begins discussing a game project, the tendency is for everyone to discuss their ideas ad infinitum. Whose idea is better or more interesting? Whose idea will make a better game? The truth is that it doesn’t really matter – any place is a good starting point for a design process. The challenge of iteration is to get a playable prototype happening as soon as possible. The art of iteration is to decisively pick one idea – any idea – that can quickly be playtested.

Embrace failure. One of the hardest things about iteration is seeing your ideas fail. But it’s really important to experience failure – most ideas will not work the way you expected them to play out. That’s why it is important to iterate like mad, trying out ideas, seeing what works and doesn’t work, evolving your design forward as you learn from your mistakes. Failure is like spicy food – it hurts at first... but then you acquire a taste for it – and soon you just can’t get enough. You never completely lose the hurt, but you also learn to enjoy the pain.

Be critical. As we iterate, we practice our ability to be rigorously critical with each other and with ourselves. The study of game design can provide a language and set of concepts to help designers see why a game design might or might not be working. But ultimately it is up to you to learn how to be critical with your own design.

More experimental? More iteration. The more weird or unusual an idea is, the more important it is to iterate. If you are doing an exact copy of an existing game, just changing a few superficial elements, you probably don’t need to playtest as much. But if you are doing anything at all original or experimental then you absolutely need to playtest throughout the entire process.

Keep it ugly. As a game design prototype, you should not worry if your game has gorgeous visual aesthetics. Initial prototypes should be down-and-dirty, skeletal versions of a game. Don’t design beautiful illustrated playing cards – just grab some index cards and handwrite what you need. Perhaps later on you’ll end up with a beautiful looking game, but at first, keep things fast and loose so that you can quickly try out different ideas.

Sidebar: the pitfalls of playtesting

Just so that I don’t come off as too fundamentalist about playtesting and iteration, I want to be sure and acknowledge that iteration is not a cure-all for every designer and every game, and that it can be dangerous to playtest your design uncritically.

At the Different Games conference in New York City last year, I saw a great talk by game designer Mattie Brice who presented a corrective to the idea of playtesting. Her point was that playtesting can sometimes dilute the personal, expressive quirkiness of a game design – that if you playtest with outsiders, and create a game to please them instead of yourself, you could end up killing what is most unique about your game.

This is a very valid point. It’s important to be critical of playtesting, and of the reactions your playtesters might have to your game. Like any design concept or methodological tool, playtesting is not universally valid or true, and there are many ways to playtest well or poorly.

New rules for an old game

I like to get my students making something as quickly as possible – even during the first class. Because creating a game from scratch is often a daunting challenge, one way to kickstart the design process is to give designers an exercise where they are modifying an existing game, rather than making a new one.

The Tic-Tac-Toe exercise usually takes place during the very first class meeting. It serves as a good introduction to understanding game rules, as well as an “icebreaker” design activity.

MODIFYING TIC-TAC-TOE
in-class exercise

Summary
Analyze Tic-Tac-Toe and then redesign the game by changing a few rules.

Goals
• understanding how changing game rules changes the system of a game
• introduction to the iterative process
• icebreaker game design exercise

Before the exercise
Through class discussion, make a general list of the rules of Tic-Tac-Toe. For example:

1. play takes places on a 3x3 grid
2. two players alternate turns placing an X or an O in an empty square
3. three of the same symbols in a row wins
4. if no one can play, the game ends in a draw

Then discuss why Tic-Tac-Toe always ends in a draw for most players. Have the class brainstorm what they might modify in order to change the game: the grid size and shape, the number of players, the winning conditions, the things you can do on a turn, etc.

Modify!
Pairs of students try to redesign the game in order to increase the space of possibility of the game – to make it more interesting to play than the “solved problem” of classic Tic-Tac-Toe.

As they design, have them change as little as possible – one, two, or three rules at the most. They should follow the iterative process of making small changes, playing their modified version, analyzing how they affected the game, and then redesigning again.

Finally, groups can share their modifications with the class, and what did and didn’t work. If there are too many groups for everyone to share, then pairs of groups can play each others’ games and discuss.

At this point, I’ve seen my students create hundreds of variations of Tic-Tac-Toe. My favorite was an exceptionally elegant variation where nothing was changed – except the winning condition. If you got 3-in-a-row, you lost. Playing this version of Tic-Tac-Toe means trying to force your opponent to make what we normally consider a “winning move.” As a minimal rule-change that turns the “solved” game of Tic-Tac-Toe into a brain-twisting puzzle, I loved that modification.

Further Reading

For a great case study on iterative design, I often have my students read The Design Evolution of Magic: The Gathering, an essay by Richard Garfield that appears in The Rules of Play Reader, an anthology I co-edited with Katie Salen.

I also wrote a chapter in Brenda Laurel’s book Design Research about the iterative design process called Play as Research: The Iterative Design Process which is available to read at ericzimmerman.com.

The Tic-Tac-Toe exercise is directly inspired by one of my game design heroes, Bernie DeKoven. In his classic game design book The Well-Played Game, there is a whole chapter devoted to modifying games, including Tic-Tac-Toe. MIT Press just published a new edition of the book. (Full disclosure: the new edition’s *awesomely brilliant* foreword was written by me.)

This series is dedicated to my co-teaching collaborators and other game design instructors who have taught me so much, including Frank Lantz, Katie Salen, Nathalie Pozzi, Naomi Clark, Colleen Macklin, John Sharp, Tracy Fullerton, Jesper Juul, Nick Fortugno, Marc LeBlanc, Stone Librande, and Steve Swink.

I also want to thank some of the many many teachers that have inspired me throughout my life, including Gilbert Clark, Enid Zimmerman, Weezie Smith, Susan Leites, Gwynn Roberts, Pat Gleeson, Janice Bizarri, Sensei Robert Hodes, and Sifu Shi Yan Ming.

Special thanks to Frank Lantz, Nathalie Pozzi, John Sharp, and Gamasutra editor Christian Nutt for their input on this essay series.