Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/public/wp-includes/formatting.php on line 82
In a recent comment, Maxest mentioned how hard it was to find information on how to write a good game design document (to sound like a pro, call it a GDD, pronounced Gee-Dee-Dee). Honestly, the reason there’s so little info is that it’s mostly improvisation at the start of every project. There’s nothing near a standard format. Still, some GDDs are better than others, so how can you write good one?
I have a strange fascination with design docs. While some designers want to get to development proper as fast as possible, I just love to work on conceptualization — finding the right gameplay, giving each element a unique personality, coming up with the overall vision of the game. I’d do that all year long if I could. The GDD is the best way to communicate that vision, so I’ve worked very hard on improving mine. While the design docs I write are nowhere near perfect — I’d love to hear from other designer’s approaches in the comments — I do believe they’re pretty good.
Read on for more details on what a GDD is, what it’s not, why you should write one, what format it should be in and, of course, what it should contain.
What’s a Game Design Doc?
Above all else, a GDD is a tool for communicating the vision of the game to the development team. When a member of the team finishes reading it — ideally they should all read it through — he should understand what the game is supposed to be, why it’s going to kick ass and most of his questions should be answered.
The GDD is about the vision of the game, but not about all of its implementation details. The vision — the high and medium level details about the game — should be thoroughly explained. When you finish reading it, you should have a precise idea of how everything fits together. However, the reader shouldn’t be bogged down in pointless details.
It’s an ever-evolving reference document. Throughout the project, changes will happen which will need to be reflected in the design doc. You should always keep the GDD up to date — if it’s not a reliable reference, your team will stop referring to it, development will lose focus and you’ll spend your whole day explaining things that are already in it. It should also be very well organized: everybody on your team will refer to different parts of it throughout the project, so they should be able to find their way around the document easily.
What it’s not
A design doc isn’t a catchall document for everything and everyone. Create separate documents for separate needs, don’t throw in sales point for marketing, planning for the producer, technical specs for the programmers, etc. The GDD is the document that explains the vision of the game, no more, no less. If you throw everything and the kitchen sink in there, it becomes a huge, messy document that’s hard to use and update.
It’s also not where you’ll write details about low-level issues. You don’t need to give specifics about each menu screen or detailed algorithms for enemy AI — they’re going to change once the project is advanced enough to implement them anyway. You’re better to hold off until you’re closer to implementing low-level items before you document them because you’ll have a better idea of how to approach them. It’s a good idea to document those elements, but keep them in separate files since they’re not part of the overall vision of the game.
Movie scripts describe the overall story in details, but they don’t contain specific info on how to frame shots, where to put lights or the specifics of the costumes of the characters. Likewise, your design doc should explain what your game is all about, but leave out information that’s specific to implementation.
A GDD is also not a sales pitch or a marketing document. Many developers use their design docs as sales pitches or vice-versa. They end up with a pitch that’s as convincing as a design doc, or a design doc that’s as thorough as an advertisement. Convincing somebody that your game is going to rock is entirely different from describing in details what’s in the game. An architect may sell a building with nice little sketches, but he makes a detailed blue print for actual construction. The same holds true here. Make separate pitches and design documents, copy and paste parts between them if you have to, but make specialized documents for each specific need.
Finally, the GDD isn’t where you keep every little aspect surrounding the game: the back story of the hero, the history of the realm, the political structure of the alien invaders, etc. It’s a very good idea to document all these things, but if that information isn’t specifically used in the game, don’t put it in the GDD. It would make the design doc harder to read and to refer to, without real benefits. Do write it down elsewhere however, that information may very well become important later on.
Why Write One?
Writing a game design doc is a lot of work, so you may be wondering if it’s worth the effort. It is: it allows you to avoid costly mistakes and it focuses the team on the vision of the game.
Redoing a part of your game can be very costly: your schedule slips 3 months because your levels lack memorable events and you’ve just missed the holidays and a hundred thousand sales. Creating the initial design carefully can help avoid that kind of problems. I’m not claiming it’s the silver bullet that will slay the werewolf of schedule slips, but careful planning certainly helps.
The GDD also helps focus the team: if everybody’s on the same page and know where they’re going, work is going to be much more efficient. I’ve seen teams almost at standstill because they didn’t understand what the game was supposed to be. In each case, a good design put them back on track with renewed interest and focus.
How much time should you spend on design? As much as you can, really. Design adds value faster than it adds cost. In theory there’s a point where it’s better economically to stop designing and start producing, but in practice I’ve yet to see an over-designed project.
Organisation and ease of reference are crucial for a good design doc. It should be readable enough to be read from cover to cover, but it should also be easy to find specific information.
It’s a good idea to keep an history of past changes. That way if a feature you had to cut is put back in the game, you can fish it back from the distant past and put it into the new version. This can be achieved using a versioning system like the one your programmers are using (SVN or CVS probably), or use a program that features versioning (Word, for example, lets you keep the history of your document inside the document itself).
As for the way to write, some people like to explain everything in text, some people like to put lots of pictures and graphs. I don’t think any method is superior; just use what’s more natural for you. (You’ll probably make graphs one way or another, I highly recommend using something like SmartDraw. Anything but Visio, really)
The most popular format is Word, or some other word processor, but anything that produces a document that’s easy to read, refer to and update is fine. If Latex written with Vi and exported in PDF works for you, go for it. I’ve started using a Wiki for my current project and so far I’m very happy with the result: editing is easy, it’s online so it’s simple to send to everyone on the team, it supports links and comments, and it keeps an history of every changes.
At this point, you’re probably hoping I’ll give you a nice little template with everything you should cover in your design doc and in what order. Sadly, I can’t — every game is different, so every design doc is unique. Grand Theft Auto requires a different document than Bejewelled. A sequel requires different information than an original title. You’ll have to figure out by yourself what is needed exactly and how to present it.
Still, a number of items need to be in most GDDs (mention in the comments anything important you think I’m missing):
- Overview of the game: Give a short overview of what the game’s all about at first, to give a glimpse of the big picture without reading everything.
- Complete rules of the game: Describe the mechanics of the gameplay.
- Game modes: If your game has multiple modes (single player and multiplayer for example, or Career and Quick Play) explain their unique characteristics.
- The player characters: What can the player character do? How do he move? Does his health restore or drop over time? Explain everything needed about the main protagonist.
- Enemies, weapons, collectables, power-ups, etc.: You need to describe pretty much everything interactive that will be encountered during gameplay.
- Description of each level: Where is it located? What are the memorable events that occur? Any cutscenes or special events?
- Controls: Give complete mappings of the controls.
- Story: Put in the whole story, as seen by the player. It may be a good idea to give this its own document if your game has lots of dialog.
- Tutorial: How is the player introduced to the game?
- Menu flow: Draw a flow-chart of how each menu page leads to each other.
- Gameplay flow: Show how each part of the game leads to each other. Especially necessary if your game isn’t linear.
- Saving & loading scheme: How does your game save and loads progress? Automatically? Manually?
No matter how you write your game design doc, it should express clearly the vision of the game to whoever reads it. That’s its goal. Keep it simple and focused and your team will actually read and use it, everybody (including you!) will have better idea what you’re trying to do and you’ll have an easier time keeping it up to date.