Iterative Development

Ok... I have finaly got around to posting the second part of the Software Engineering Best Practices in Game Development. This part focuses on maybe the most important part of modern sofware development; developing iteratively.

Iterative Development

Developing iteratively can be viewed conceptually as splitting up the development of the software into several miniature projects, called iterations. Central to this style of development is that the iterations continuously deliver a working executable that allows for proper assessment of current quality and progress. Each iteration is a micro version of the project as a whole, with each area of the final product represented at some level of abstraction, and as iterations progress, the quality of each aspect of the product increases. Each iteration incorporates the natural flow of working with requirements through analysis, design, implementation, test and final delivery of the product, as working software is the product of each and every iteration. This flow repeats not only on an iteration basis but also on a project basis; the focus of the earliest iterations being more towards nailing down the fun of the game working heavily with focus groups and requirements while in later iterations requirements are more of detailing features of the product. This work flow can also be found on a daily basis, starting the day a developer accepts a task, needing to investigate the requirements of the task, maybe do some small analysis/design sketches, implement, test and integrate the feature into the product.

The key driver behind iterative development is to reduce as much risk as possible as early as possible. In game development a major risk is that the gameplay is simply not entertaining enough. Iterative development enables the developer to discover such fundamental problems early in the project instead of towards the end, as a working executable (albeit at a very high level of abstraction) is available as soon as the first iteration is completed. The developer is thus able to change the design or even abandoning the project before a huge part of the budget is spent.

As mentioned, a central aspect of each iteration is that it should result in a stable, testable software system that should be delivered to the end user. In game development this could mean delivering the product to key stakeholders and focus groups.

The output of one iteration becomes the input of the next, triggering the most important changes to flaws in the game. This way the developer has a chance to steer the project in the most appropriate direction, reacting to real experiences from a real working system. One key effect of this procedure is that the game design and the understanding of the game design evolve with the project. In essence there is no longer need for a complete design document before starting the project; indeed, creating such a document would most definitely be a waste of resources since the elusive property of fun simply must be tested and tweaked using a working software product. It is our continuing experience that no game design survives contact with actual implementation, and accepting this fact and acting accordingly is essential.

Iterative development also lets you decide when the game is "good enough". In essence this means that you can stop the project when you feel that the resources spent each iteration do not yield sufficient return. The software is always “complete” at any particular time in development. This property of iterative development is very interesting and leads to the important realization that there is no point in worrying about unknowns in the project, you simply do the best you can to improve the game based on the state it is in today. As problems arise you deal with them when they are a concrete problem, not before. It is very common for projects to be completely unproductive and paralyzed by analysis if they start worrying over speculative possible future problems and issues. Worrying about problems that in 90% of the case actually never happen is a waste of resources when what you really need to do is solve the 10% that actually do occur.

Another key benefit of working iteratively is team motivation. Always having a product that steadily evolves and moves in the right direction is very important. The opposite of working months or even years without seeing any progress is a certain project killer.

Iterative development is also the basis of many other best practices, making it probably the most important practice to understand, implement and refine.

Continued in Manage Requirements

users avatar

Great article

I can really speak for iterative design, even on the small level I work in. I don't understand how games work inside, and I don't like reading other people's opinions because there are so many of them, some of which over-complicate themselves by trying to be simpler for newbies.

So, when I made my first game, I just tried to draw something on screen. Then make it move. Make the screen erase the previous frame. etc. etc.

This article gives me a feeling that making larger games in groups will be much the same.


users avatar


I'm glad you found the article helpful.

I also agree that many things about game development is over complicated and mostly so just for the sake of being complicated, or to show that you are the best thing since sliced bread.

This is also where many projects get stuck; over speculating on future problems, making the code/design or whatever much more complicated than it needs to be, rather than solve the current problems...

users avatar

Also good

I experienced first hand the need for iterative design. I worked on a game type project for 3 months over the summer. I worked with an initial design and did my first user test of the software about 6 months after my initial ideas for the game and found them unworkable for this particular user. Goes to show that as programmers, what we consider as normal isn't so for our end user group. It really showed me that I need to do smaller tests of my software with a much higher turn over rate. It is also a really great way to motivate yourself to fix those small little things which, as a programmer you put up with, but which cause others greif. Otherwise I completely agree with the article, sad I had to experience it first hand lol.

users avatar

Good way to learn

Making misstakes (and realizing what went wrong) is one of the best ways to learn though...

I can recomend 2 week cycles, we use that for our games and it works very well for us. Also you should release at all cost, if it means skipping some planned features you should do that, otherwise it's easy to get into a spiral of "just one more thing" and suddenly a couple of months has passed...

This also meanst that you have to be ruthless in your prioritizations...

I'm really glad that this part of the article seems to resonate well with other developers! Hope the other parts will do so as well.

users avatar