Chapter 17: Game Development Documentation

Overview

Omit needless words. Vigorous writing is concise . A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts . This requires not that the writer make all his sentences short, or that he avoid all detail and treat his subjects only in outline, but that every word should tell.
” William Strunk in his book The Elements of Style

Many a game designer will proclaim himself better than development documents, and will make them only to suit the managers who demand their creation. Game design, these obstinate designers may insist, is something one cannot write down on a piece of a paper. And these designers are partly correct; writing quality development documentation is very difficult. Much of the development documentation you may come across seems to have been written merely for the sake of it, perhaps to placate a publisher who demands to see something on paper.

Nonetheless, documentation does have a legitimate place in the creation of modern computer games , and it is the designer s job to make sure those documents are created, maintained , and used effectively.

The necessity of game development documentation is a side effect of the increasing- size of game development teams . In the early days of game development, when a development team consisted of one multi-talented individual, documenting the functionality of the game was less important. If that one person was able to establish and implement a vision for the project s gameplay, it did not especially matter if he wrote it down or not.

As development teams grew from one to five, from five to ten, from ten to twenty, from twenty to thirty, and onward and upward, maintaining the project s focus became more and more of an issue. As members of the team became increasingly specialized in certain areas, a reference document they could turn to in order to see how a given system was supposed to function and how their work fit into the project became necessary. And so, various pieces of documentation came to be used, such as the design document, the art bible, the technical design document, and numerous other reference works for guiding the creation of a game s content. Development documents can be a key way of holding the reins tightly on a project, to make sure it does not spin out of control because of the impractical ambitions of team members . Writing down ideas and story components is a helpful way to quickly realize when a game is being overdesigned and whether the project can be completed on time.

Good documents have benefits not just for the production side of game development, but also for improving the game design itself. Chris Crawford has written more about game design than probably anyone else, as a visit to his web site (www.erasmatazz.com) will reveal. Crawford uses documents to refine and sharpen his own ideas and to track how a project evolves over the course of its development. Personally, I use a steno pad to keep all of my thoughts for a given project. I find that I can later go back and review these notes to see how I arrived at a particular design decision, and to recall good ideas that I have long since forgotten.

Of course, it is entirely possible to go too far in the other direction, to spend all of your time working on the documentation and none of it actually developing the game. And having a massive amount of repetitive documents is certainly not beneficial, especially if the team feels as though they are adrift in a sea of documentation, with none of it actually practical to their work. It is also possible to make games without any sort of documentation, but with a team of any size it will be extremely difficult. If one hopes to work at a development house or for a publisher that makes commercially viable , professional computer games, getting used to working with documentation is an absolute necessity.