What is the minimum content that a game design document should have?
closed as too broad by MichaelHouse♦ Mar 16 '14 at 22:49
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
I come from a different stream of life (TV Production), but it's basically the same. You need a production bible. But, to put it more simply - you need what you need and nothing more.
- Character list
- Levels list with each level set list (areas that need/deserve special attention)
- Prop list
Each list contains layout sheets (or character layouts for characters - front, side, 3/4), notes, mechanics notes for animation, etc. Whatever you need or might need.
Story/Game production sheet.
- Screenplay and X-Sheets for animators if you have a story and dialog/VO
- Run through screenplay which describes game as though linearly progressed (if game is intricate enough to need it and is, of course, linear in nature)
- Game mechanics per game/level/mini game with set goals, obstacles, rewards - you can do this per level list and only a big idea in run through screenplay
In short, whatever works for you and size/scope of your team.
Having just begun studying design documents, I've come to the conclusion that no-one really knows what goes in them.
The design document itself should be what you need to progress from pre-production to production. How do you turn the game design from this nebulous idea to something that can be created and executed? Too little detail and there's too much ambiguity, creating uneven results, too much detail and you limit possible creativity from your team.
It's not easy, and the science of game design documents is woefully under-explored in comparison to other software domains.
A good paper on this is Requirements Engineering and the Creative Process in the Video Game Industry.
The size and scale of the project documentation completely depends on the size of team and the scope of the project.
Typically large games aren't built off monolithic design documents, but a distributed document system. Either a series of smaller targeted docs or a wiki. Personally I prefer the wiki approach as allows readers to quickly jump between related topics which maps well to system designs which are often integrated.
When using a Wiki there are a few guidelines that can help with:
- One Wiki Page per system/character/level/...
- Keep the Wiki highly organized and structured, each content type should have a defined template. You need at least one WikiNazi to keep the site clean.
- Describe the design briefly and with bullet points, a design document is not the place for narrative text
- Keep pages short and focused, the goal being no longer than 1-2x screen height.
- Pictures are indeed worth 1000 words, use diagrams to help get your point across.
There are no minimum / maximum. It should contain everything you need to start work on the game. Nothing more and nothing less.
You should not require yourself to add information that you think you need just because some template has it.
I'd say you should work out what the gameplay is, who your character is, and what the environment is like. But my advice would be to start making playable prototypes as early as possible.
I like to have headings related to what Art, Sound and Storyline I'll need going forward as well as a basic coding design I can follow when I am coding the engine.
However it is a personal thing and everyone varies on how much detail they put in. Mine are fairly short since I like to jump straight into the code rather than dwelling on design.