“We practice iterative design”  You hear it in virtually every studio profile, every GDC design lecture, and it’s a buzzword game journalists equate with exceptional game design and a high level of polish.  Apparently there is a magic formula for making good games, and it goes something like this.

1. Start with a fun game
2. Make a tiny change (usually after exhaustive debate)
3. Playtest extensively to see if those changes made the game better
4. If they did, keep them; if not, change them back
5. Repeat until your publisher makes you ship

It’s a pretty straightforward process, anyone can understand it and imagine executing on it.  Acceptance of this model leads to some pretty obvious ways to improve your design skills, too.  Make smarter changes.  Iterate faster.  Find better test metrics.  Take more time.  And now we know why Valve and Blizzard make better games than anyone else, right?  They take more time discussing changes, they have better tools for iteration, they playtest more than anyone, and of course, they ship when they are ready.  And it’s true, to some extent; a game that went through several rounds of polish will be better than one that didn’t.  But if you adopt iterative design as your primary design philosophy you will be doomed to making mediocre clones of better games…

First, let’s examine iterative design applied to other creative forms.  Want to write the next great novel?  Start with a book you really enjoy, like “The Count of Monte Cristo” and start iterating!  Pick a random chapter, change a crucial detail, and then read the whole book again and see if it is better.  Clowns are funny – let’s make Dantès a traveling circus performer instead of a sailor.  Over the course of 1400 pages, assessing that change is virtually impossible, except that the occasional clown-lover might comment on it.  Although no one change will be measurably worse, by the time enough alterations are made to create a substantively different novel, it will be an incomprehensible mess.

Pourquoi cet air si sérieux?

Let’s take a look at a concrete example of how iterative design can fail, specifically in determining the number of weapons the player can carry in a shooter.  In Wolfenstein 3d, the player could carry 6 weapons.  In order to improve this, an iterative designer would try playing through with 5 weapons and with 7 weapons.  Clearly, 7 weapons is better than 5 because the player has more choices.  So then the designer would try 8 weapons, which would also test better because “more” always tests better.  At some point, the designer would probably decide the gains from adding an additional weapon no longer justified the expense, and the game would ship with the player carrying 25 weapons at all times.  The iterative designer would never arrive at the solution introduced in Halo and adopted by virtually every shooter since, of reducing the number of weapons the player can carry, because the benefits of that system are not apparent until you reach 2-3.  In mathematics, this technique is known as hill climbing and it can only be used to find a local maximum because it cannot cross gaps to reliably find the global maximum.  Every designer knows that a game is never fun at first, so it is likely that even a good change is going to feel like a bad one for a short period of time, and an iterative process will reverse course too early.

You can't get there from here...

The main reason that the iterative process is a siren song is implicit in Step One, “Start with a fun game.”  How can anything dramatically new be created if you are only allowed to start with something that is already successful?  If you something is already fun, stop iterating on it and work on the parts that aren’t fun.  And if something isn’t fun, the iterative process won’t get you there.  In the end, iteration is a polishing technique, not a generative one.