Reason 4: Design documents turn generalities into particulars.

The process of writing a document turns a vague idea into an explicit plan. It’s one thing to say “Harpies will be flying creatures” in a meeting, but that’s nowhere near enough to build from. In fact, there’s not even any point in writing it down if that’s all you have to say. What the developers need are details: How high can they fly? How fast do they fly? Are they affected by the weather? Can harpies land? Can they land anywhere they want to? Can they also move on the ground, and if so, what sorts of terrain and how fast? Are they more, or less, vulnerable when in the air or on the ground? And so on and so on, and it all needs to be written down so that everyone on the team has all the information they need to build the product.

It would be nice if game design consisted of sitting around with your feet up and daydreaming about cool content and features, and I’ve met some designers who thought that was the whole job. It isn’t; they were slackers. The vast majority of design consists of figuring out the details.

Although you’ll always change those details later in testing and tuning, you have to start with something. In a real sense, the process of writing documents is the process of design, because it is then that you turn abstract concepts into concrete plans. Even if no one reads your document at all, an idea written down is a decision made, a conclusion reached.

Reason 5 (most important): Design documents are a record of decisions made; they create a paper trail.

Video game design is a highly collaborative activity, far more so than the movies. Unlike a film director, whose rule is well-nigh absolute, few designers are allowed total control over their game. As developers, we tolerate the long hours and comparatively low pay of the game industry because we get to make a creative contribution, and if that were taken away, it wouldn’t be much fun. A lead designer does not create the entire design himself; he continuously weaves other people’s ideas into the whole, and must also (preferably with a degree of tact) reject those ideas that don’t fit.

As a result, an enormous number of design decisions are made not at your desk, but in meetings, around the coffee pot, or over lunch. Some of these, perhaps made by junior staff, are only tentative and must be cleared with the lead designer or the rest of the team. In any case, when a design decision occurs through conversation or negotiation, you must get your conclusions down in writing - again, even if you already know that you’ll change them later.

The reason is that you need a paper trail, a record of what you have decided. I have sat in too many meetings in which an argument broke out because nobody wrote down an earlier decision, and people’s memories of what was decided were in conflict. “Didn’t we say we were going to do X?” “No way, we were going to do Y!” The result is wasted time and energy. If a week or two has gone by since the previous meeting, a whole team may have spent all that time working based on an incorrect assumption.

THQ and GSC Game World's PC shooter S.T.A.L.K.E.R.: Shadow of Chernobyl

This is why all meetings should have a designated secretary or scribe to make notes and distribute them to interested parties - and where the questions discussed are design issues, these notes are part of the design documentation and should be filed as such. When people’s memories conflict, you can go back and check the notes.

Design docs also help you keep track of what you’ve done and what you still have left to do. If a feature of your game is never described in writing, there is a good chance that you overlooked it and that someone will have to come and ask you about it later, or worse, make up her own answer without consulting you or anyone else. The result can be a disaster, when each part of the team has a different idea of what you intended, and they build incoherent or incompatible material. It’s far easier and cheaper to correct a design error before any code is written or artwork is created.

I listed this reason as most important because above all, design documents are organizational tools. They’re not books or stories to read, but plans: records of things to implement. They can take many forms: diagrams, concept art, graphical reference material, explanatory text, tables of stats or attributes, lists of many kinds, storyboards, flowcharts (yes, even today, but for command sequences in a user interface, not for the code), meeting notes, audio and video recording scripts, and pitch documents to help sell the product to the funding agencies.

When the game is mostly complete and the majority of the work consists of testing and tuning, you can throw the design documents away just as a builder takes down scaffolding - though it’s still useful to keep them around for reference. But while things are in flux, design documents are essential for keeping track of what’s going on and what needs to happen next.

Conclusion

Design documents alone won’t guarantee that you’ll make a great game or even a good one, nor that you’ll get done on time. In fact, when approached wrongly, a design team can waste a lot of valuable time and effort on their docs, and I’ll address some of those pitfalls in a future column. But I hope I’ve answered some of the questions I hear from the innocent and the ignorant.

Yes, a small team working on a small game, perhaps with no deadline to meet, doesn’t need much in the way of design documentation. If your entire design career will be devoted to trivia games on mobile phones, you may never create one (but somebody has to write down the trivia questions, don’t they?). Nevertheless, serious professionals working on a large project that’s due out at Christmas understand the value of documentation. It communicates, organizes, and guides the entire process. A project manager can’t create a schedule, task list and staffing allocation - and follow their progress - without knowing exactly what needs to be built, and that information must exist in written form.

Ultimately, writing (and sketching, and diagramming, and making tables and lists, and writing pseudo-code) is design. You shirk it at your peril.