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.
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
Submitted by hObbE
Tue, 05/20/2008 - 18:19