[GD-Design] Re: Design Documents

[Daniel C. <dan...@an...>]

This is more of a software development generic response, though it seems
applicable to games as well.

A design doc is heavily dependent on the type of organization.  I tend to
use design documents to communicate key ideas and get people excited about
various concepts. Some organizations have great mechanisms for
communication.  These tend to be bogged down by heavy design docs.  Other
organizations have poor communication.  In these cases, a detailed design
doc can be a critical crutch to getting the game finished.

First off I'd split up the terms 'design document' and 'art bible'.  An art
bible is full of pictures and concepts to help artists. Some folks include
this in the definition of 'design doc' but I find it often confuses the
issue.  A design document is the list of rules and systems needed to make
the game mechanics function. It includes UI, reward systems, and perhaps
even plot points. :-)

I've done big design docs and small ones for games and tools.  These days, I
lean towards lightweight design and development processes. We use a
variation of XP (extreme programming) that involves a database of 'feature
cards'.  Each 3 week iteration involves the programming of a few feature
cards.

The wacky part. Each feature card has at most a short paragraph or two of
text. The rest of the design is fleshed out with constant conversations
between the designer and the programmers.

This has a couple of benefits:
- Avoids massive time spent on upfront design of a unproven complex system
that will probably be reworked anyway during user testing.
- People read the design.  How many developers in your company read and
understand 100% of the 300 page design documents?  Every developer
understands new features because the feature cards keep it short, sweet, and
manageable.  And we talk.
- You can react quickly to new discoveries, or changes in focus by simply
adding a new feature card. There is no need to rework a giant doc.

The downside:
- If your publisher doesn't trust your abilities, then you don't have a
massive 'Design Tome' to placate them. :-)

Daniel Cook

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Sellers, Mike
Sent: Tuesday, November 06, 2001 8:33 AM
To: 'gam...@li...'
Subject: RE: [GD-Design] Design Documents


Matt Newport wrote:
> How long and how detailed are people's design docs generally?
> I personally feel that our design docs could do with being a
> little longer and more in depth but I don't know how they
> compare to those used elsewhere in the industry. I read in
> the Deus Ex post mortem that their design doc ran to hundreds
> of pages, which is rather more detail than we have in ours...

Design docs can easily be hundreds of pages, but I'm not sure they have to
be.  That's like asking how long a novel is -- it's as long as you need to
tell the story.  A design doc serves several purposes, including selling the
design and memorializing it (so you'll remember that incredible idea in
context six weeks from now).  I've seen design docs with too little
high-level design: what's this about, why is it fun, what's the player's
experience, how does this fit together, etc.; and ones with too little
low-level design: what are the pieces, how does movement work, what's the
overall UI like, etc.  The question of when to leave off with the low-level
design and get into implementation is a tough one, but generally I'd say
sooner than later.  Iterate, try it out, and then write it down.  If you've
done the high-level design right, you'll be able to focus on the areas you
need to iterate on a lot more quickly and effectively.

But honestly, this is all still seat-of-the-pants stuff.  I don't know
*anyone* who has a sure-fire design documentation methodology.

Mike Sellers

_______________________________________________
Gamedevlists-design mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-design