GDD Template
Translation: Game Design Document Template
A game design document is kind of like a business plan for a game. This is probably why I’m so conflicted about them. You need a GDD to get a deal, but spending a great deal of time on the GDD is useless if the core mechanic of the game isn’t fun. I think prototyping a mechanic is going to be far more valuable in the long run than developing preliminary maps of each level of the game.
But in any case, if you want to get a publishing deal, you have to play ball and provide a GDD to the publisher so that they can evaluate the risks involved in developing your game. This seems to be very similar to going to a venture capitalist with a business plan, so they can determine whether it’s worth investing in your company.
I know from experience that once a game gets into production the GDD becomes a dead document that never gets updated and rapidly falls out of sync with what’s being created. I’m sure the same goes for business plans at a startup.
Recently game developers have been trying to change the way design docs are created and maintained by using wikis, unfortunately design docs still read like wacky pipe dreams and the day-to-day reality is it’s better to have something on screen than in wiki. Once any kind of time pressure hits stuff gets implemented that doesn’t get into the wiki and then it takes more time to forensically find what’s been added to the game and make sure it gets into the wiki.
Below is a game design document template that comes out of the Activision/Spark contract that I was so excited about a few weeks ago. Regardless of how I feel about GDDs they aren’t going away, and it’s good to know exactly what a publisher expects out of it.
(I also recommend looking at Chris Taylor’s Game Design Doc Template. It’s similar to this outline, but with some useful pointers in there.)
A GDD is a document that serves as the preliminary basis upon which a Product will be produced. The GDD will include, at a minimum, responses to the following questions:
1 Concept
1.2 What is the “high concept’ of the game?
2 Design
2.2 What is the planned interface? Provide a detailed description of the game’s interface and controls.
2.3 What is the planned perspective (1st person vs. 3rd person)?
2.4 What is the basic interactive structure (e.g. chapters vs. great middle section, Levels, etc.)?
2.5 What is the “heart” of the gameplay (e.g. speed, actions, style, continuous, turnbased, etc.)?
2.6 How does mufti-player work?
2.7 How difficult is the game?
2.8 How long will it take the average player to complete?
3 Story
3.2 What is the genre?
3.3 What is the tone?
3.4 What is the basic narrative?
3.5 What is the “heart” of the story?
3.6 Is it a linear story?
3.7 What is the player’s goal and why would they want to accomplish it?
3.8 Who does the player play? Single/multi player?
3.9 Are there other key characters?
4 Gameplay
4.2 Describe a typical play session including what the player does, what happens, player response, and so forth. The idea is to give a kinetic sense of gameplay.
4.3 Describe each mission or Level of the game (as applicable).
4.4 Preliminary maps of each Level or mission of the game (as applicable).
4.5 Describe all characters and enemies in the game.
4.6 Provide a written walk-through of a sample path through the entire game.
4.7 Provide sample art (in the form of conceptual drawings or CGI).
4.8 Provide a detailed description of the sound design (music and effects).
4.9 Provide a detailed description of any cinematic sequences (as applicable).
5 Market
5.2 Is this a product for core garners or more “mass-market?”
5.3 Does this product target one core audience or multiple audiences?
5.4 How does this product compare with its competition?
5.5 What is the key competition for the product?
5.6 What does this product offer that they don’t?
5.7 What do they offer that this product doesn’t?
5.8 What competitive products we in development?
5.9 This should also function as a potential list of Do’s and Don’ts for the production team.