The Importance of Convergent Iteration
Games today, particularly MMOs, are large and complex. No matter how experienced a development team is, it is difficult to know the requirements up front. As in other areas of software development, the producers of games have gradually come to realize the need for modern, iterative development methodologies.
Previously the generally accepted development methodology was called the waterfall method. This is a straight-through method that involves gathering requirements, performing analysis and design, implementing the system, and testing it. In a system of any reasonable complexity, at the point of testing, the developers will realize that the requirements have changed. They will then have to go back to the beginning and redo things, often throwing away large parts of the system and performing costly refactoring on others.
Iterative processes were developed to address the inefficiencies of this methodology.
Let’s take a look at an analogy with art. Say you need concepts for a character. You describe the character’s role in the game to the concept artist and they go to work. After several days the artist presents a beautiful, full color, detailed painting of the character. It turns out that you don’t like it. The proportions are wrong; the face is too rugged, the eyes too big. And don’t even mention the clothing. So you give feedback and the artist starts again. You keep repeating this until you get what you want or the artist quits because they can’t reproduce your changing vision.
While in this example you are iterating, the process is not efficient. The fundamental problem is that you don’t know what you want until you see it. This makes it particularly difficult to give good direction to the artist. Because of this it is a waste of time for the artist to do so much work in each iteration.
Instead, perhaps the artist draws several silhouettes for you to look at. Maybe you choose three and they produce some additional variations. Once you like a silhouette, the artist sketches a few characters with more detail. You give feedback and the detail level grows. Eventually you get the proportions and features right and move on to equipment.
The key is that at the beginning, when you don’t know exactly what you want, the artist performs the minimum amount of work necessary to provide something that you can examine. As the process continues and you become sure of some aspects, you have a solid foundation for refinements.
The same thing is true for software development. Instead of developing a fully detailed system for review, the team starts on a subset of functionality that represents the core gameplay. But even this subset is not developed fully. Only the minimum work is done to provide something meaningful to test. Feedback from these tests is incorporated into successive iterations to refine the system. But additionally, as the core is enhanced, new systems are added on the periphery. Think of doing wide and shallow development instead of narrow and deep. Don’t choose a small set of systems and fully develop them (narrow and deep), rather choose a large set of systems and partially develop them (wide and shallow).
Having a wider set of systems not only makes feedback more meaningful, it helps to avoid costly integration issues which occur when fully developed subsystems need to work together.
Back to the art analogy. If the game requires ten main characters, it is better to develop them together, to start by doing all the silhouettes, than to do one character fully and then start on the next. This is because part of the requirements would be that the characters look distinctive while sharing a common style. By roughing them all out together, the team can discover ten unique looks. If they only build them one at a time, after creating the first few, they may find it difficult to create others without changing the ones that have already been done.
Software must be treated the same way. The individual subsystems must grow together in order to enhance each other.
- Robert Marsa