Gamasutra: The Art & Business of Making Gamesspacer
A GDD Template for the Indie Developer
Printer-Friendly VersionPrinter-Friendly Version
View All     RSS
April 17, 2014
arrowPress Releases
April 17, 2014
PR Newswire
View All
View All     Submit Event





If you enjoy reading this site, you might also want to check out these UBM TechWeb sites:


 
A GDD Template for the Indie Developer
by Jason Bakker on 06/04/09 04:58:00 am   Expert Blogs   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

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.

  • Art Assets: List each major area of artwork (Player, Enemies, Worlds, UI/Menus, HUD, Effects), specifying roughly how detailed animations and states will be, and however much you know at this point about the pipeline/programs used.
  • Text Assets: Identify major areas (tutorial, tips, scripted dialogue/quests, dynamically presented dialogue, narration), and attempt to gauge the amount of effort required on each section.
  • Sound Assets: Similarly, the major areas (In-game sound, UI/HUD feedback sound, music, voice) should be detailed and described.

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 man 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:

 

  • Be thorough, but don't be absolute. Remember that everything must be allowed to change and evolve over the course of the project, and the design document is a general description more than a blueprint. If you end up with a totally different game to the one that you laid out in the design document, as long as it's better it doesn't really matter.
  • Don't be hesitant to name check other games; it's often the best way to get across a point to yourself/your team members. That said, don't make that all your document is. ("The wit of Grim Fandango meets COD4-quality FPS meets LBP user-creation" sounds great, but doesn't explain what you're doing or how you're going to do it.)
  • Write well. Just because this is for your team's personal use doesn't mean that you shouldn't try to make it as readable and expressive as possible - remember, this is the document that you'll be looking back on during development to try to recapture the feelings and ideas you had about the project in the first place.

 

HTH, HAND!


Related Jobs

Linden Lab
Linden Lab — San Francisco, California, United States
[04.16.14]

Lead Engineer
Gameloft
Gameloft — New Orleans, Louisiana, United States
[04.16.14]

R&D Game Designer
SOAR Inc.
SOAR Inc. — Mountain View, California, United States
[04.16.14]

Game Designer/Narrative Writer
Giant Sparrow
Giant Sparrow — Santa Monica, California, United States
[04.15.14]

Game Designer






Comments


Neil Gower
profile image
Great post, you make some really good points. The distinction between documents for pitching and contractual obligations versus what's needed to actually make the game seems to be overlooked more often than not. The production documentation can be very fluid, maybe even better suited to a wiki or similar collaborative documentation system - something with easy searching, cross referencing, and multi-user editing. On indie projects, perhaps a word processor can still pull it off; communication is probably tighter and the scope isn't so big. What do you think?

raigan burns
profile image
Kudos on explicitly treating the character and plot as optional, this is an insight which many teams seem to overlook.

Kumar Daryanani
profile image
Indeed, thanks for posting this. It's not easy for someone who has never seen a GDD to know what needs to go in it and how to maintain it, and there don't seem to be that many resources on the subject online.



This will be very useful, thanks again!

Jason Bakker
profile image
Thanks for the feedback guys!



@Neil



Yeah, a wiki is definitely a good solution for a larger project. I guess what I like about linear documentation is its comprehensive nature - it can be easier on a wiki to lose focus of the level of detail at which you're documenting each section. That said, a wiki is still preferable if the document is a collaboration with significant input from multiple contributors.



@Kumar



No worries - it was something that I needed to do for myself, and since I've also found a lack of good GDD templates online, I thought I may as well share it. Hope it's helpful in your endeavours.

Eric Carr
profile image
I usually throw a glossary at the end, especially if you have new kinds of systems or mechanics in place.

I would also keep the timeline out though, that seems like a different animal, but that may just be me.



@Kumar, I recommend "Game Design: Theory and Practice " It's what I used in college and still pick up. It's got 2 Docs in it and goes into what each part is in depth.

John K
profile image
Good post, Jason. That's actually pretty close to the format I use for designing small, Flash-based games for my current job. One thing I do differently is place the description of the game's flow earlier in the document (usually as part of the basic gameplay description). I do this to abstract the game at the highest level and then fill in the details. In other words, I list the game's phases and show how they are connected, give a brief description of the phases, and finally explain the mechanics of each phase.



One change I have been experimenting with is pushing the aesthetic details (art, sound, etc.) toward the end of the document after all the nuts and bolts of the game have been explained. I originally had this section about where you had it, but I think the artists were getting tired of digging through gameplay descriptions just to figure out what the skies in the background should look like. :)


none
 
Comment: