[Massive Entertainment (Ground Control series) veterans Norneby and Olsson use this in-depth technical article to discuss how to radically improve your experience planning video games through applying software engineering processes to game development.]
This article describes and elaborates four best practices of software engineering in the context of game development. These practices are:
We urge game developers to realize that many of the software problems commonly encountered in game development have already been encountered and successfully addressed in traditional software development organizations. The article is intended as an inspirational starting point for applying best practices in your own projects.
Software development is plagued with many serious problems. Complexity is increasing, time to market is decreasing and quality requirements are skyrocketing. This puts great strains on the software developing organization and the people therein. It is no longer possible to work harder; we must work smarter.
Best practices of software engineering are commonly observed, commercially proven approaches to successful software development. Developers that wish to compete on the bleeding edge of software technology should adapt these practices to the specifics of their own organization and projects.
The most complex part of any computer game is the software behind it. The software needs to incorporate gameplay mechanics, artificial intelligence algorithms, network protocols, real-time physics simulations, decompression and playback of music, filtering and mixing of sounds, 3d visualization and more. In addition to all of this, multiple platforms must often be supported. The software must also be packaged with huge amounts of data in the form of textures, models, animations, sounds, scripts etc. to create something fun and entertaining; an elusive mix of technology and art.
Considering all of this, it is not surprising that many games are released with poor quality, often requiring fixes in the form of software and/or content patches from day one. All of these complexities cause games to exceed their budgets and miss time to market by not days, but months and years. As a result, many game developers are fighting a losing battle to survive.
We maintain that a large number of these problems are the very same problems "traditional" software developers have faced and conquered by implementing best practices in their organizations.
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 each iteration continuously delivers a working executable that allows for proper assessment of current project 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 a per-iteration basis but also on a project basis; the focus of the earliest iterations being more towards nailing down the fun of the game, often working in conjunction with focus groups and requirements, while later iterations focus more on detailing features of the product. This workflow can also be found on a daily basis, with a single developer's day starting with the acceptance of a task, investigation of the requirements of the task, perhaps doing some small analysis/design sketches, moving on to implementation, and finally testing and integrating 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 abandon 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, functional, 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 and/or to the actual end user (perhaps represented by focus groups). The output of one iteration becomes the input of the next, with the most critical flaws and/or missing features becoming the goals of the next iteration. This way the developer has a chance to re-evaluate and steer the project in the most appropriate direction once per iteration, 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 any 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 document 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.
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. You deal with concrete problems that actually exist, not with abstract problems that might 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 -- 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.