A GDD Template for the Indie Developer

I'm in the process of making a few different design documents at the moment, so that our iPhone development team can have some options to choose from.

After writing a couple of docs, I've massaged my design document "template" into something that really works for me, and I think works better than the traditional formats for independent game development.

The documentation style you get taught in university and at game companies tends to have a large focus on target audiences, marketability and "selling the project" to whoever is reading it, as opposed to describing the project and laying it out in a more objective and easy to read manner.

The pitch approach is great for when you're making something primarily to sell it - however, in the case of indie game development, often your goal first and foremost is to make something good that you can be proud of, and saleability/popularity, while still desirable, is not the highest priority.

After stripping that stuff out, and adding a couple of sections that are more important to focus on early for smaller development groups, I came up with the following layout. The blue sections are only for story-driven games. For games that are purely gameplay without a narrative, they can either be left out or replaced with a very brief thematic summary.

Intro

1 paragraph description of the game. Describe your game in as few words as possible, as if you only had seven seconds to explain it to somebody. Attempt to capture the feel of the game - general enthusiasm ("This is a fantastic and exciting 3D platforming game!") is less valuable than text written in-theme, such as:

The dame's gone missing, and, just like always, you're to blame. Now you've gotta beat your way through an undead horde before she's sacrificed to Zombie Jesus... and you didn't even get to eat breakfast. The Battle for Zombie Breakfast is a horror/noir 2D side-scrolling beat-em-up starring Isaiah Stakes.

Character Bios

1-2 paragraph description of each of the major characters. Mention in particular how they figure into the game itself, and the way the player will perceive them initially vs. once they get to know them.

Rough Plot

4-6 paragraphs. With as little backstory as possible, describe the game from start to finish. Include a rough breakdown of what is cutscene, what is gameplay, etc. With each part of the plot, it should be obvious how it will be presented in the game itself.

Gameplay Description

1-2 paragraphs describing each distinct mode of gameplay, starting with core gameplay. For instance, Half Life 2 would first describe general running around and shooting, then twists on the core gameplay (such as the gravity gun), then vehicle sequences.

Artistic Style Outline

2-3 paragraphs describing the artistic style and feel. Cover actual in-game art, UI and menus and sound. Mocked up screenshots are preferred, if not, reference art.

Systematic Breakdown of Components

A rough outline of what systems will be required (for example, ones that will show up on most lists: 2D and/or 3D renderer, state machine, save/load system, UI system, collision system, particle system, etc). Include special features that, while they may not have their own system, will still need to be accounted for when creating systems (ie. day/night cycles, sound affecting gameplay, etc). If you will be using an API/SDK for a system, note it down - you'll still have to do some work learning/integrating the foreign system.

Asset Breakdown

Similar to the System Breakdown, but for visual assets, text and sound.

Suggested Game Flow Diagram

The intent of this section is to lay out, step by step, what the player experiences from as soon as they turn on the game until the end. While this can be generic and use a lot of loops (ie. Start Game -> Cutscene -> Tutorial -> loop(Cutscene -> Level -> Results Screen) -> End), it's probably a good idea to attempt to envisage how your game might be able to break up the monotony that is evident in that design.

The great thing about this section is it gets you really thinking about what your game is and how it is presented, as opposed to the amalgam of disjointed ideas in your head. The deeper you get into this Game Flow Diagram, the more confident you will be about what your game is precisely made up of, and what the experience of playing it will be.

Suggested Project Timeline

Here's where we get to the part where hearts break and tempers are lost - laying out a rough schedule for the game's development that utilizes the breakdowns that were made earlier in the document. Schedule aggressively, but be realistic - you're probably not going to get all of your menus in and working in a day. You don't have to be specific about where and when - the most important information to end up with here is the number of work hours per team member required, and exactly who will be responsible for what.

Additional Ideas and Possibilities

This final section is a bit of an amalgam of everything that didn't fit in the sections before hand. It's an appendix of all of the things that you didn't think were necessarily core to the game, but you'd like to consider along the way. It's also for alternate possibilities - for instance, if you had two main characters in mind, put the better one in the main document, and then the alternate here. Finally, if you have any ideas that you're not sure about, but would like to prototype, then this is the place for that stuff as well.

That's it! Design Documents made in this layout can be anywhere from High Concept length (2-3 pages) to full GDDs (anywhere between 5-50 pages). And finally, a few general bits of advice:

HTH, HAND!