I got this design document format from Raph Koster, when he was working on his company Metaplace. He has graciously allowed me to use his format here; his original wording is below:
A paragraph or two that is effectively the sales pitch.
This can be thought of as being the back of the box copy, or the flap
on a hardcover book — it needs to be something that gets the overall
point across. If you can’t provide the core of this in a sentence or
two, you will have real trouble conveying what your game is about to
anyone. For Edinburgh, it was a paragraph that basically said “This is
a game of competitive urban planning,” which is more fun that it
sounds.
A set of design goals.
This isn’t for the public, the way the above paragraph is. It’s for
you. I got this trick from Alan Pavlish, of Wasteland fame. Basically,
it’s a set of one-sentence bullet points that you can come back to
throughout the process to check that you are making what you set out
to make. You can feel free to let these evolve, but it’s a useful
mechanism for checking what you are doing. For Edinburgh, the goal was
to marry a card game with a territory game.
A critical part of this is identifying “what this game is about.”
You need to know this for both the mechanic and for the metaphor,
because these are what the game is going to be teaching. In the case
of Edinburgh, it was the idea of how towns get to their unique layouts
(Edinburgh has an amazing downtown that was the result of an
architectural competition a century or two ago). And for the mechanic,
it was about grouping cards, really — a set-building exercise.
A list of the core mechanics, each with a paragraph description.
Don’t go overboard. You just want to know how the mechanic works. The
idea is to be able to see all the moving parts.
A description of the metaphor – meaning, the art style, narrative,
etc. In a large project, this may mean a bunch of concept art. It
could include a whole bunch of lore and fiction — or not.
That forms what I call “a vision doc.” It’s often preceded by a one
pager that is a stripped down version of even that, which is sometimes
called the pitch doc, but if you’re doing this for yourself, you don’t
need that. The order of the pieces in a vision doc is fluid — it’s
about conveying the overall game to someone else. You’ll notice it is
light on details.
After that, there’s two approaches. One is the design bible. I have
come to hate this approach. This is where you take each of the
paragraphs and turn it into a full-fledged design document, which
includes in it all of the above, only in great detail. So for each
system, you have its pitch paragraph, its goals, its destailed
mechanics description, its art asset list, and so on. The problem with
this approach is that you end up with 700 page documents (or Wikis)
that can be very hard to update, and tend to fall out of date or grow
rigid.
I now prefer a more bullet-item sort of approach. If you can’t
describe the mechanics in a bullet point list, it’s probably too
complicated anyway. And bullets are a lot like a code outline —
there’s clear cause-and-effect. All games work on mathematical
principles, so being able to describe your system in a very logical
flow helps a ton when it comes to implementation — even in board
games.
Game Design Idea 