There is different kind of “design” documents. How you write it, which details and how much informations you put into it really depends on who it is adressed to. Personally I don't like using a lot of documentation. Often short notes on your intentions are enough to get you started in the right direction. Documents can be useful when used well but it really depends on the given situation.
What's necessary for the teamSince I've been working alone on my two first games as an independent game developer, my design documents mostly look like a pile of paper with scribbles and a one or two pagers written on the computer. Really just some notes to keep track of my ideas and put a bit of structure in it. I've also worked as a designer for a big company in which I was part of teams of 7 to 12 peoples. You might think that the documents are more important when working with a team, but we did not work so much with docs. Before the project started we initially developped what we called a “pitch” for the game, detailing the intentions of the project, the main mechanics, the main features and selling points and was also used to compare other existing products. This document was aimed to get the project started by convincing lead producers that it would be profitable. This was the biggest document written during development.
There were a dozen designers in this company and most of them wrote their designs differently. However, all of them relied heavily on “mock-ups”. I don't remember seeing any huge bible describing all the details of a project. The pitch was there if we ever doubted the direction and then we mostly did a bunch of Flash demos, still images or animated gifs depicting what we wanted (yes, the animated gifs were very popular). When we DID write documents, they were short (never more than 5 pages) and detailing only small, ambiguous parts of the project that needed more thought. And nobody read them. If it was explaining a game mechanic, the programmers would jump to the pictures and graphs or look at the mock-up. If they could not figure it out instantly they would come to the designers for explanations. The documents were not totally useless though. Even if nobody read them, they still allowed the designers to deepen their reflexion and have a better, more structured vision of the mechanics, making them easier to explain with confidence and clarity.
The design changed so often during development that writing a huge design document detailing the project in it's entirety before the project started would have been a tremendous waste of precious time. It's impossible to accurately “imagine” how the game will play until you've tried it yourself, so how could you know what would work and what would not?
So what should we do??If you work alone, all you need is a pile of notes to keep track of where you are, where you're going and a short but strong description of your focus. The focus statement, a few paragraphs about what you want and how you want it to feel like, is a strong tool to keep you on track. You can come back to it once in a while to take you back to the initial spark of interest that triggered the project. It might change during development but you should still keep that initial spark somewhere handy. The rest of the notes (mine anyway) really are just random schemas, sketches and datas about the mechanics of the game, the structure of the data, the basic display of informations in the screen, the look of the characters, etc..
Here is the main “design document” I've used before starting
HyperSpace Shooter. I have a few other pages of notes but the single page you see here is the initial spark. Note that almost nothing from these notes made it into the game (mostly because it was too ambitious for the time constraint).
Prototyping is the key!Yes, this is the golden key. It's good to pin down your ideas on paper as they come, but writing long and detailed documentations about behaviors, look and backstory will prove useless if, once done, the game is uninteresting. (As an example,
building a prototype allowed me test and redirect my focus for
HyperSpace Shooter.) Also, written documentation always bear the risk of being wrongly interpreted by the various team members while mock-ups and prototypes allow direct testing of the ideas, making them quick to assimilate and easy to understand. With it you can easily find the most important problems and team members are able to make constructive criticism before anything is built, thus improving on the ideas and saving development time.
When is a design document really useful?I found that documents have a lot of value to structure datas. For example, when you need to write the story, keep track of how the events are linked together or what are the dialogs, make a list of the available weapons in the game, etc.. If you have a lot of designed content (as opposed to user created or procedural content) it allows you to have a whole view of it. Documents are also very useful as a “to do” list. When we had to record, cut and edit spoken dialogs of a game I worked on, we applied color codes to the excel sheet to keep track of the work (for every line of text, we marked them as red when they were recorded, yellow for cut and green once integrated in the game. The producer could take a quick look at it and estimate the remaining work load in seconds).
In all these cases, and many more, documents are invaluable tools. But you don't need no stinking document to explain how the character moves or jump. You are waaaay better off with a prototype or mocked-up animation. Remember that when people are asked to perform a task, the less they have to read, the more they're happy.
ConclusionTo me, design documents are more like a tool than a plan. They are invaluable to keep track of datas and structure ideas but as soon as development starts, they are useless in explaining how the game works. So my own way of working is to start by writing a few pages about my initial ideas, work on a prototype to test them and, once I'm happy with the direction, write a few “to do” lists and structure documents to make sure I'm not forgetting anything. Unless you need to convince someone to join in or invest in your project, any other documentation is futile.
