Design Theory: Deconstructing Iteration

04 May

Iteration is one of the most fundamental practices in the videogame industry. It’s the core around which every major company and almost all the minor ones structure their development. It’s a powerful, reliable tool. It’s also a problem. Like many methodologies that arise in industry, developers adopt the model without critical analysis of where it is best used and where its flaws are. The result is that the universal adoption of iterative process has perhaps done harm as well as good.

For new readers, I adopt a somewhat… adversarial style. I think that the more valuable and awesome something is, the harder you should try and identify the problems with it. So take the pithy negativity with a grain of salt, I’m trying to make you look at something harder than you otherwise might



Iteration is the process of developing a product through incremental adjustment. A product is developed and then tested. Based upon feedback and impressions of the tested product, it is adjusted towards a more desirable state, tested again and so on. The operative words here are adjustment, feedback, impressions and desirable.

Adjustment: Iteration has difficulty changing or reversing directions sharply and nimbly. Once locked into iteration, it’s hard to change broad strokes.

Feedback: Iteration depends upon testing, which means that the more iterative a process, the more bumpy the flow of asset development must be.

Impressions: A given iteration rarely has the luxury of undergoing deep analysis. Adjustments are more often made based upon shallow impressions due to limited time.

Desirable: to iterate towards a desired state, that desired state must be known. The more detail about the desired state is known, the more powerfully and effectively iteration can be directed.




So iteration is fundamentally a polishing tool. It doesn’t reliably create great gameplay from nothing- it just takes what you have and smooths things out. It’s interestingly similar to genetic development* where occasionally some tweak that comes out of the iterative process proves so wildly successful it becomes a genre defining mechanic. Over a whole group of such projects, each adopting the iterative discoveries of their neighbors, you arrive at a kind of progress that is fundamentally quite random, but in practice slowly pushes towards the desired state.

The complications of this model are again similar to those with genetic development. It can’t really make any revolutionary changes, because it must develop in incremental steps from existing templates. A fundamentally flawed template will remain fundamentally flawed no matter how much it is iterated upon and any serious change in direction will require some messy improvisation based upon the existing template. It’s inefficient, since even with a developer directing ‘mutations’, the very premise of iteration acknowledges a lack of surety. The less certain of how to get the desirable outcome it is, the more inefficient iteration will be.

This creates a sort of paradox: the more you understand where you want to end up the less you’re inclined to iterate, but the more powerful iteration will be if you do use it because you can more efficiently make use of the feedback that iteration generates. The less you understand how to get to where you want to be, the more you’re inclined to use iteration but the less efficient and powerful that iteration will be.

This can be condensed into the following: the more solid design and potential in a product before iteration begins, the more it will benefit from the process. The less focus, direction and careful design in a product, the less it will benefit from iteration. It’s a multiplicative thing. To condense it even further, into the realms of profanity: No matter how much you polish a turd, it’s still a turd.



This is the main problem with the iterative model upon which the industry runs. Iteration is viewed as a catch-all method of fixing things up and ensuring a product is marketable. Problems with a basic concept are just assumed to get ironed out in iteration. While this may be the case, the amount of iteration that has to occur to get the product to the same level that a bit of forethought and analysis could achieve is massive. That means money and time wasted, game budgets expanding and general doom and gloom. Not only that, but solutions will more rarely be truly innovative and elegant, hacked together from re-purposed or rushed assets as they must be. The pressure to not go back to the drawing board is immense, particularly for studios working to publisher milestones or with announced release dates.

For all the flaws listed, iteration is supremely reliable. If you put a product through significant iteration it’s going to come out looking better than it did when it went in. This is great, but it can also be deceptive. Without a comparison, that improvement can deceive a developer as to the actual quality of their product. I often see playtest groups start with something utterly awful, get it to a point where it’s barely playable and hear things like ‘we feel like this is in a good spot right now’.

The promise of iteration to refine a game distracts from the need to set goals before development even begins. Specifying certain desired outcomes such as ‘we want players to spend no more than X time and no less than Y time completing this area’ or ‘we want 90% of our playtest group to report a 9 or 10 out of 10 satisfaction with this level’ give iteration something tangible to push towards and, importantly, something set in stone which performance can be measured against. I’m sure that this sort of practice does exist widely in more experienced studios to benchmark specific areas of the game, but I’m not sure that even the industry leaders establish these sorts of design-centered performance benchmarks from the get-go. I certainly know I don’t. To do so requires a significant amount of research and preparation, but on the whole I’ve found that every hour put into such work means ten less in the actual development cycle.


So what’s the alternative? Well, for the most part right now there isn’t one, and that in itself is a problem. This article is more about pointing out that iteration has very definite weaknesses and that it’s worth putting effort into figuring out other development methodologies which might avoid some of these. Iteration will always have a place, but it’s worth considering just where and when that is in the overall process. Too early and you cede your ability to refocus drastically in order to hit your goals. Too late and everything is already too rigid to benefit greatly from the feedback based tweaking iteration provides.

So have a look at your process. Do you really need to begin testing on day one? if so, what does that say about your understanding of what you’re making. Might your time be better invested in research, so you can figure out what you need to test more precisely? This is just one of the questions I ask myself before I begin iteration.

I hope y’all find this useful, or at least thought provoking.


*some will no doubt contest that genetic evolution is truly random and that design iteration is guided by conscious… well, design. This is true, but I’d contend that the goal to which we guide game design at the moment is so vague (Eg. ‘fun’ or ‘rewarding’) that this really only serves to limit truly awful mutations rather than creating significantly more powerful positive ones than random variation would.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: