Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
October 23, 2014
arrowPress Releases
October 23, 2014
PR Newswire
View All
View All     Submit Event

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

How I Teach Game Design. (Lesson 1: The Game Design Process)
by Eric Zimmerman on 10/19/13 08:51:00 pm   Expert Blogs   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.


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.


in-class exercise

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

• 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.

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

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.

Related Jobs

DeNA Studios Canada
DeNA Studios Canada — Vancouver, British Columbia, Canada

Analytical Game Designer
University of Texas at Dallas
University of Texas at Dallas — Richardson, Texas, United States

Assistant/Associate Prof of Game Studies
Avalanche Studios
Avalanche Studios — New York, New York, United States

UI Artist/Designer
Bohemia Interactive Simulations
Bohemia Interactive Simulations — ORLANDO, Florida, United States

Game Designer


Trevor Cuthbertson
profile image
Iterative design is paramount in any gaming project. Unfortunately, there’s too much of what you say of “people often romanticizing the creative process” and don’t understand that the game needs to be designed through the playtest. It’s like the analogy of someone buying an electric guitar, when someone thinks they’re Eric Clapton or Dave Mustaine just because they bought an electric guitar, but not thinking or understanding that these guys are guitar masters and write songs through their guitar playing. You gotta playtest your game. Iterative design is not something you can buy at a store. It means getting out of your comfort zone and breaking from your inner circle of friends. Then you might have a game that’s a lot of fun that you’ll remember for years.

Peter Eisenmann
profile image
Actually there is a stage between idea/brainstorming and prototyping stages, I'd call it "sit on your ass and think really HARD". Many dead ends can be avoided just by really analyzing your gameplay ideas. Often you can see quite clearly that something will or will not work even without having to prototype it. I guess that needs a little experience though.

Actually, my last game (admittedly a simple one) did not need any prototyping at all; the final game was in my head and/or on paper before coding a single line. And, most user reviews praise its gameplay. (Negative reviews are 95% about technical issues.) The funny thing is that it exactly fits your 'New rules for an old game' (Battleship in my case).

TC Weidner
profile image
Totally agree. Play the game in your head over and over well before you even start your first line of code.

Alexander Jhin
profile image
I was about to comment the same thing myself! The amazing thing about the human brain is that it can run simulations of "what might happen if I do this." Simulating a game in your brain is a little bit harder, as you're simulating "what might a player do given these rules" but it's still well worth doing. It's cheap, albeit often inaccurate. It forces you to make assumptions which are later challenged by players, which makes you wrong more often, which teaches you more.

Douglas Scheinberg
profile image
There's a two-rule modification of Tic-Tac-Toe that produces an entertaining game, sometimes called Gomoku:

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

Nils Pihl
profile image
You mean both players can place either an X or an O? That's... interesting. Will try!

Luis Guimaraes
profile image
By reading the exercise I came up with something similar but as overtime rule, you start 3x3 then add one row each time there's a draw. Still I don't think there's much room of option for the second player beyond just defending all the time.

If you just add lots of rows it gets closer to Go an further from TicTacToe, so that no-match-3 rule seems very interesting.

TC Weidner
profile image
We all know tic tac toe was a flawed and poorly designed game. Why it endured I'll never know. Connect 4 was probably the most popular and best re-imagined version of that game.

Kujel s
profile image
@TC: It probably endured buecause you can play it with just some dirt and your finger.

Damion Murray
profile image
I like the Ultimate Tic-Tac-Toe version. Basically you have a 3x3 grid where each cell has a nested 3x3 grid inside it. Check it out:

Marius Holstad
profile image
Playtesting: test to see if your system is working as you envisioned, and understand that your system cannot cover everyone.

TC Weidner
profile image
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
I dont agree with this. Yes, testing and the iterative process help shape, focus, and refine your idea and game, but if it doesnt all start from a good place, your going nowhere quick. The idea, the inspiration, the vision is the VITAL step, all the rest is just work in order to realize that vision.

Anyone can make code work for the most part, the art of game design is being able to bring a vision to life. Too often what we find in this industry is the problems associated with games is the ability to be able to do this. Either through monetary constraints, technical constraints, skill, and/or often simply communication problems among the team.

So yes I agree that play testing and being flexible to "happy accidents" is essential to creating a playable game, its the initial vision that will separate it from all the rest. The art is in the vision, the rest is how one brings that vision to life. I tend to think the problem with many game is the first step, the Idea, is either not good, not original, or not feasible that dooms a project before it even starts.

The ol phrase- Cant polish a turd comes to mind.

PS. I should however add, that in the subject matter of teaching game design, I can agree that the initial idea may not be a big deal, after all learning is the goal, not so much final product. For to be honest game designers are lucky to have a even a few really good game ideas over the course of our whole lives, so to think one would just pop in someones head in a course of a week is asking too much and as pointed out, not relevant if learning the process is the goal

Alexander Jhin
profile image
We can apply the concept of hill climbing algorithms to brainstorming and play testing. The game designer comes up with an idea, which is the initial point on the graph. The play testers reveal flaws/good parts of the game which moves the point locally on the graph. Play testing may help the game reach a local maximum. But it's only a talented game designer who can then make a daring leap to another, similar but different idea and reach a higher maximum.

In other words, play testing will help you reach a local maximum, but it won't put you on the highest peak.

Nick Harris
profile image
I broadly agree with this article, but think it applies best to simple games and teaching. For it to have relevance for large-scale development I feel it would be better to split the game into three, which can be termed Controller, Model and View. Iterative development then takes place in that order. The Controller can be visualized with the aid of an input device (like a gamepad), so that an appropriately kinaesthetic, ergonomic and articulate interface is devised. Even if many of the features of this control scheme never get implemented due to restrictions of scope by deadlines, you know where the frequently used essential stuff goes and there is no awkward packing in of unanticipated actions that results in a clumsy, hard to remember, interface. No programming has taken place yet, but the aspect that has the biggest impact on a game's accessibility, expressivity and immersion has been inexpensively defined. Because controls constrain what you can do with a game (or in many genres what your avatar can do in some simulated world), it is vital to define this aspect first and let later aspects be forced to compromise.

The Model takes input from the Controller, but the whole complexity of the Controller need not be implemented early on - it just helps to have a "Road Map" for future feature expansion. It helps to play the game as early as possible, so the Model needs to be able to output to the View which takes care of all presentational aspects including audio and vibration. As this article says this can be quite 'ugly' and lacking in aesthetics - actually, what you need is a way to debug behaviour, so it may be easiest to initially present a first-person game from a top-down point-of-view if there is little impact on its 'landlubber' AI and then come back and explore its dynamics from a floating first-person spectator camera when you need to explore the relative vertical movement of flying, climbing, jumping and falling entities. The bulk of the iteration happens with the implementation of the Model which can be regarded as a simulation that defines an interesting possibility space, with all "happy accidents" constrained by the fixed feature set of the Controller. If play testing suggests that the game would be better if the control scheme were to allow X, then the complex ramifications of including X (usually at the expense of relocating or removing a pre-existing W), will tend to dissuade you from this kind of innovation unless the gamepad is underutilised, or you have the luxury of a (arguably less ergonomic and therefore less immersive), keyboard interface.

The View should only be iterated beyond the barest real-time visual debugging aid when all work has been completed on the Model. Too much emphasis is placed on presentation in todays games and it is unsurprising that Retro gaming is popular, not merely for the sake of nostalgia, but due to some titles having richer dynamics than state of the art 'interactive Cinema'. Many indie games capitalize on the fact that they don't need to afford AAA production values if they can put decent dynamics (and often original mechanics), into an aesthetic that leverages a charming pixel art, or voxel aesthetic. Procedural generation and user content generation also avoid you needing a staff the size of Ubisoft, or Rockstar, providing you can accept its stylized results. Later, when the core gameplay is becoming polished the quality of the presentation can be iterated and subtleties put into the Model to take account of such aspects as AI being able to spot targets despite vegetation and smoke being in their line of sight and their vision adapting to sudden changes of brightness, whether that be a transition from an explosion, flare, or interior to outdoors, or vice versa.

All I am saying is that it is inefficient to keep going back to the foundation aspects of a game in the hopes that some reconfiguration of the control scheme will improve its dynamics. Of course, it may well do... but on a large project the cost of this experimentation is prohibitively expensive, as is the cost of throwing away whole graphics engines as new one's appear that seem to be a bit more capable, by which I merely recommend that large projects try to avoid copying this:

Curtiss Murphy
profile image
"Embrace failure. One of the hardest things about iteration is seeing your ideas fail."

^ This is tied directly to Carol Dweck's work on Mindset which was one of the most powerful influences in my evolution as both game designer and developer. Stated succinctly, success could be written this way: Try; Fail; Improve; until too good to ignore.

Jason Drysdale
profile image
Thanks, Eric--this is really insightful; looking forward to reading the texts and excerpts you suggest. Great instructional design as well!

David Verney
profile image
Interesting and helpful. Thanks for writing this one.

David Verney
Games Design Student