The Value of Game Design Docs

In the comments for my last post (about how game ideas are not very valuable), some readers pointed out that not all ideas are low in value -- design documents by experienced designers can be quite valuable for some projects. That's definitely true!

However, ideas are different from design docs in the same way that an architect's sketch is different from a finished set of blueprints. Ideas tend to be vague and fleeting, while design docs flesh out all the details of the game and clearly communicate them to the team.

"A great idea is meaningless. A great idea that leverages your existing technology, gets the team excited, is feasible to do on time and budget, is commercially competitive, and, last but not least, floats the boat of a major publisher... Now you have something." - Ken Levine

Fleshing out details

The basic idea for Grim Fandango is something like, "A point-and-click adventure game in which the player is entangled in a film-noir murder mystery in the afterlife". From this idea, the design team wrote hundreds of pages of documentation, with design sheets for each character and setting, and detailed descriptions and flow charts for every puzzle in the game.

Here's a picture of part of the puzzle chart for chapter one, from the 72-page Grim Fandango puzzle document. 

Different games and teams need widely-varying levels of detail in the design doc. For example, a game with a really large team will likely need a more detailed design doc. Communication becomes difficult with so many people, and it can become more efficient to have a central document to fall back on that clearly defines every detail.

However, for Overgrowth, we have a very small team, so we need very little documentation -- especially since we already have Lugaru as a prototype (which also never had a design doc). Also, since the lead designer and programmer are the same person, spending a month writing an in-depth design doc would mean a month without writing a line of code.

Communicating with the team

As with any kind of writing, it's vital that the designer consider the target audience for the design doc, and the intended effect of reading it. In this case, the audience consists of artists, programmers, and other developers, and the intended effect is to inform them exactly what they should be doing.

Good design documents usually have a funnel effect to direct readers to the relevant parts -- a level designer might start by reading the overview, then the level design overview, then the specific level overview, and finally the minor details of the level implementation. They also use very precise language -- instead of "The Desert Eagle .50 does a lot of damage," they would say "The Desert Eagle does 65 points of damage to unarmored targets, and 40 points to armored targets."

Here's an excerpt from a design document for Fallout: Brotherhood of Steel 2. This particular document looks like its intended audience was marketers and publishers, since it is fluffy and vague to the point of uselessness -- for example, it says "10 new guns will be introduced," on page 15, but never even lists them:

When to use design docs?

Design documents are definitely useful tools, and essential for projects with large teams in which designers and developers are separate. However, I'm not sure how useful they are for small indie teams like ours, because they can waste development time and prematurely crystallize the design.

What do you think? Should we take the time to write up detailed design documents? Does anyone else have experience working with them?

Follow us here!