How to Write a Game Design.doc

How to Write a Game Design DocIn 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 theres so little info is that its mostly improvisation at the start of every project. Theres 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 game play, giving each element a unique personality, coming up with the overall vision of the game. Id do that all year long if I could. The GDD is the best way to communicate that vision, so Ive worked very hard on improving mine. While the design docs I write are nowhere near perfect Id love to hear from other designers approaches in the comments I do believe theyre pretty good.Read on for more details on what a GDD is, what its not, why you should write one, what format it should be in and, of course, what it should contain.Whats 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 its 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 shouldnt be bogged down in pointless details.Its 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 its not a reliable reference, your team will stop referring to it, development will lose focus and youll 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 its notA design doc isnt a catchall document for everything and everyone. Create separate documents for separate needs, dont 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 thats hard to use and update.Its also not where youll write details about low-level issues. You dont need to give specifics about each menu screen or detailed algorithms for enemy AI theyre going to change once the project is advanced enough to implement them anyway. Youre better to hold off until youre closer to implementing low-level items before you document them because youll have a better idea of how to approach them. Its a good idea to document those elements, but keep them in separate files since theyre not part of the overall vision of the game.Movie scripts describe the overall story in details, but they dont 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 thats 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 thats as convincing as a design doc, or a design doc thats as thorough as an advertisement. Convincing somebody that your game is going to rock is entirely different from describing in details whats 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 isnt 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. Its a very good idea to document all these things, but if that information isnt specifically used in the game, dont 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 its 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 youve just missed the holidays and a hundred thousand sales. Creating the initial design carefully can help avoid that kind of problems. Im not claiming its the silver bullet that will slay the werewolf of schedule slips, but careful planning certainly helps.The GDD also helps focus the team: if everybodys on the same page and know where theyre going, work is going to be much more efficient. Ive seen teams almost at standstill because they didnt 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 theres a point where its better economically to stop designing and start producing, but in practice Ive yet to see an over-designed project.FormatOrganisation 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.Its 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 dont think any method is superior; just use whats more natural for you. (Youll 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 thats easy to read, refer to and update is fine. If Latex written with Vi and exported in PDF works for you, go for it. Ive started using a Wiki for my current project and so far Im very happy with the result: editing is easy, its online so its simple to send to everyone on the team, it supports links and comments, and it keeps an history of every changes.ContentsAt this point, youre probably hoping Ill give you a nice little template with everything you should cover in your design doc and in what order. Sadly, I cant 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. Youll 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 Im missing): Overview of the game: Give a short overview of what the games 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: