In a new Gamasutra feature
, Massive Entertainment (Ground Control, World In Conflict
) vets Johannes Norneby and Tobias Olsson say that game developers must look beyond their corner of the industry, and recognize that traditional software development organizations have encountered and solved many of the common problems that game developers experience.
Norneby and Olsson elaborate on four best practices of software engineering in the context of game development: Iterative Development, Manage Requirements, Manage Change, and Verify Quality.
On the topic of iterative development, the writers explain their take on the role of the design document:
"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."
And while game developers may be able to effectively draw best practices from traditional software companies, game makers still have the unique responsibility of making their software as fun as possible.
"The greatest risk of game development is the possibility of inadvertently developing a game that is not entertaining enough to be profitable. Game designers struggle to describe the entertaining aspects of the game in their game design documents, but 'fun' is such an emergent aspect of a game that it can only be verified by actually playing the game, or a rough version of it.
If the game can be demonstrated to be fun without a lot of flashy content and special features, then it's a good bet that it will be even more fun and rewarding once these things are in place. On the other hand, if the core gameplay is boring or frustrating, no extra fancy content or functionality can save it. Game developers need to find out if their games are fun as early as possible."
The full feature
delves deep into the four best practices of software engineering, and is now available at Gamasutra (no registration required, please feel free to link to this feature from other websites).