|
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!
    
|
My experience with detailed design documentation versus streamlined documentation has followed the stereotypical expectation: streamlined docs can be adopted easily, but require a shepherd, while detailed docs are viewed differently by different members of the team; a clear sign that the target audience is too broad. Artistic team members saw the heft of the document and would opt for their own intuition, seeing the tome as a largely technical document that didn't apply to their concerns. The technology-oriented team members saw the document as something that was useless in terms of describing how things should be done technically and simultaneously irrelevant as a creative reference that didn't apply to their concerns. The result was everyone could only agree to ignore it. Indeed, the detailed docs I've written in the past *were* trying to target an audience that was way too broad. (tech, art, design, management, client, etc.) Needless to say, I now favor the approach of streamlined docs and shepherding.
To me the GDD (and the role of the Game Designer) is to answer the question, "What are we doing?", while the TDD answers more the question, "How are we going to do that?". Both these answers (the docs) need only be as detailed as the granularity of the question at the time. If you're early in pre-production, these questions are vague. If you're in a meeting reviewing user feedback late in production, these questions are quite specific and the answers need to reflect that; but by then, it is not the job of the document to provide the answers.
So in my opinion, "Desert Eagle does 50 damage" isn't as good as "Desert Eagle deals more damage than the 9mm, and less than the Combat Shotgun."
Personally, I think GDD's are great and force the Designer (or me anyway) to refine their ideas into a cohesive whole, but I write them to be as streamlined as possible, focusing on core mechanics and interations. But I'm with Glenn, and think that they need a shepard that understands the project on a deep level to answer any questions that will arise.
I've found that the balance between "saying too much" and "cutting to the chase" is simplified by making it an ONGOING part of the process. By refining the goals on a regular basis, the Designer can avoid the eventual irrelevances that plague overly-detailed docs that provide too much too soon, and can better address the questions and issues that will likely need to be addressed in the immediate future.
Initially, when communicating primarily with clients, publishers &/or manufacturers, we call it a "Design Document"... and it's full of all of the lofty, ponderous ephemera that the folks holding the purse strings like to take back to the board room with them. It explains the concept(s) to those who want to "know", but don't necessarily have the time, need or desire to be a part of the process.
Later, when communicating primarily with the Team that's actually doing the work, we call it a "Task List" and it's seldom little more than a comprehensive checklist that's updated every couple of weeks. It provides inspiration and instruction about what needs to be done & why, and sets boundaries without inhibiting the creativity of the talent.
Of course, the above assumes that the Lead Designer is taking an active, hands-on role in the process and is available at all times to exchange ideas and provide guidance as needed.
So far, I've found it the best of all worlds: the GDD is for a general overview and those who don't care about as much detail (artists, marketing team) can get the bite-sized chunks they care about (and I can throw in pictures to entice them), and the FBs are for the programmers so they can get all of the information they need to implement a specific feature with as little noise as possible (and in efficient, targeting documents).
Embracing the iterative nature of the documentation and excepting the document as a dynamic entity has made me switch to a digital format. There are situations where this approach is not needed and is overkill... Nevertheless I think we can all appreciated reading something that you can skim easily in order to find the right content. Imagine trying to look up a reference in a book without an index.
@Brian
I wholeheartedly agree
As a designer, if writing helps you to flesh out ideas, do it.
When your team asks for written data (whether that's developers asking for specific direction, or marketing folk asking for promotional information), be prepared to produce it quickly.
But remember you're shipping a game, not paper. If your design is not onscreen right now, it doesn't exist, may never exist, and will very likely come across differently onscreen than on paper.
Some level of documentation will always be essential, but it's crucial to realize that every doc is a “maybe”; only what you can playtest is a sure thing. It is in this light that a team should choose how much time is spent documenting and how much time is spent actually building a playtestable experience.
Boomzap sounds like they have the right balance:
http://www.gamasutra.com/php-bin/news_index.php?story=26109
While they're doing small-scope casual games, this kind of approach, with some modification, is far more applicable to larger projects than not.