6.5. Iteration and Risk¶

Games have many kinds of risk associated with them. There is design risk, the risk that the game will not be fun and people won’t like it. There is implementation risk, the possibility that the development team will not be able to build the game at all, even if the rules are solid. There is market risk, the chance that the game will be wonderful and no one will buy it anyway. And so on.

In the Waterfall method, you will not realize that you have a design that is fundamentally broken, or a technology that is impossible to implement until you are late in the process. Doing design rarely tells you about your exact risks: unless you are designing something very similar to a project you have done before, you literally don’t know what you don’t know. It is entirely possible to make a design that you think is great, spend months implementing code and art assets and then go to start testing the game only to realize you have big issues: It isn’t fun. Game servers can’t handle more than 4 players and you were counting on 64. etc... Until you get to the stage of testing your whole game, the risk of a complete failure hasn’t really gone down much:

With Waterfall, the chance of an epic fail can’t be dismissed until you get to the end of a project and test all of what you have built.

Iterative projects can still fail of course. The purpose of iteration is to lower these risks and to realistically assess them earlier. Done right, iteration will help reveal that your design is fundamentally broken. Iteration will help reveal early on that implementing the fully destructible open world environment you designed is going to be too much work.

The earlier you learn these things, the more likely you are able to either: course correct and still make a good game, or, toss the project before spending months more working on it. The net effect is to more rapidly reduce the risk of total project failure early in the process. Once you implement the fully destructible world your entire design is based around, you know a big question mark has been removed and your chance of complete failure has been reduced.

Iteration does not eliminate risk. It just encourages you to confront the most important and risky issues first.

The greater the risks of your game (if your game play is new or you are working with a brand new game engine or developing new technology), the more you need iteration. If on the other hand, your team just built Epic Unicorn Simulator and is sitting down to crank out Epic Unicorn Simulator: Season Two there are probably fewer risks with the design and technology. In that situation, you may do just fine with a less iterative approach.

That said, most game designers have aspirations of making games that are new, creative, and innovative. For this kind of work, iteration is essential.