Designing a Document

Well… Well… Well… look at the earthling who has come crawling back. Nah I am just kidding with you, do not leave, I need you… please. So this weeks post of the blogs is all about the joy of Game Design Documents and what they entail. Last week I talked all about how to break into the gaming industry or at the very least what steps are advisable in my opinion to get you there. Now of course there are many other ways of getting your foot in the door like modelling or even 2D animation processes so please go out there and try some of your own methods and if they fall flat on your face you know you can always retreat to the simple laid out structure here or elsewhere.

One of the first steps on this list however is the Game Design Document or GDD for short but I constantly find people getting lost with exactly how to write these conniving pieces of paper. GDD’s are not like scripts or story’s or even resumes but rather have their own unique structure which unlike most other forms of writing have barely any sort of reference to go off by and even if you do find one they are usually too random to follow. This is why today I want to end this confusion for all of you lucky and skilled readers.

Before I go into my own method of writing GDD’s though the first thing you need to know is what a GDD truly is and why we right them at all. To put it bluntly a GDD is a document that explains your game and the processes involved in creating such a game. You probably already knew that part though. Most will say that a GDD is used so that another team can pick up and make your game it from scratch in case your team fails or simply moves on. Contrary to this common believe I would rather state that a GDD is supposed to be used for you and your team so that you can all look at the GDD and understand how the game is meant to work if you ever find yourself forgetting. It can be great at keeping the team to a timeframe, generating ideas and keeping consistency throughout design.

Now definitions are fun but if I stopped here (like many sites do) you would still have no idea about how to actually write one of these crazy things unless you already knew. The plan from here on out therefore is to simply describe to you each of the headings that you should find in a GDD document and why they are required. Remember that GDD’s have no truly set out format so feel free to write whatever you want but if you want some direction have fun copying this post of the blogs. Also, yes GDD’s should be constantly updated throughout production to the day you finish the game. I know for a fact that many Game Designers keep a tab open with the GDD at all times to keep them consistent at all times.

Cover Page

The first thing you should find is a cover page. Cover Pages only need the title of the game and the team name or creators name. I also like to add in a quick splash image of the game as well. At first this image can be a quick thing you Photoshopped together but by the end it is best to use a still image of the actual game to help with consistency.

Version Control

Before the Table of Contents I like to throw up a version control heading. Generally version control is a table with a table with four columns. These are the Version number, Date, Person making the changes and the actual changes taking place. If you are the only one writing the document though I would skip out on the person’s name. For this heading all you have to do is update every time you make some sort of change.

By the way for version control the initial document creation starts with 0.01 followed by 0.02. With the first version of the completed game and document it becomes 1.00. If the game continues after this point due to the clients disliking or what not the version becomes 1.01 and so on until the next final version where it becomes 2.00 and so on.

Table of Contents

A ToC is a crucial part of any GDD. Considering that the team will always be using the document throughout development a linked table of contents can save your team ages of searching around the army of pages waiting before to find what they are specifically after. I will not tell you how to make one but a quick google search will give you a whole lot of answers.

Goals

A goals heading is for you and your team to look at so you all remember what the final product is planned to be and do. Generally in here you should describe what the final iteration of the game will do to players emotionally, mentally and physically and what client specific tasks this game is trying to deliver upon.

Purpose

Very similar to goals the purpose is simply about why you all wish to complete this game and what you will achieve from it. However if your game is educational to an extent or has some sort of theme explaining the effect on the player here will be a good idea too. Beware that crossover will occur with the goals heading.

Scope

I admit that I generally suck at this heading. Not because I cannot write it or something but rather because I am not very good at putting a limit on my scope. That is why this heading is so important. The scope heading is all about planning what can be and most likely cannot be added into the game with the allocated timeframe or skills you have available. If you are on your own making a game that has no time frame then feel free to skip out on this but if you have any sort of deadline I advise you think long and hard about this.

Synopsis

Now for the fun stuff, The actual game. The synopsis is simply a paragraph that describes the game and what it is about. Be sure to include the general emotional impact and when and where it will be played. Do not rant about the story or anything for too long.

Rules

Just like any sporting event the rules are all about explaining what can and cannot be done. In other words how the game plays, is it first person, third person, top down etc.

Controls / Mechanics

The title of this heading explains it all. Here is where you put in the player inputs and how these inputs affect the game world. Such as press space to shoot pigeons and hold down A to teleport forward 10 spaces and so on. The type of Physics on display could also be added here if you wish like fall damage and average speed. Remember that many of these variables could and most likely should be modified through game testing by the end and the GDD should reflect the final product.

Narrative

If your game is heavily based on narrative then here is where all of that should go. When I write about this I generally split it into chapters that are formed around each stage of the game. Honestly I find this and the following sections of the GDD to be the most fun especially when not working towards an end goal but do keep in mind that revision is key as you never know when you might stuff up some key section of your story that stuffs up the intended player reaction.

Stage Design

This section lists each stage and almost every little detail in it. It should describe the location and how players are meant to feel during the journey through it. I generally split it in to subsections with each stage as a subheading. Using splash images can really help in this area to get the look and feel across.

Characters

Similar to stage design I usually split this heading into subheadings for each specific character. If characters are split into obvious groups like in Sonic Heroes I would have a subheading for each group and put the character subheadings in here. A description for the groups goals and purpose would be there too. Be careful with characters though as the amount of detail required can be extremely dense if you are going for a narrative heavy game. Things to be included are a splash image of each character, character bio, description, back story, emotions and as I mentioned previously a relationship diagram would be incredible. Generally everything you need was explained in the character post I did a few weeks back now. If you are doing some sort of quick mobile game however then a list of characters and how you unlock them with splash images are good enough.

Weaponry / Tools

This heading is largely based on the type of game being developed. A game like Minecraft would have a huge list of tools right about here while something like Halo would be filled with guns and how they operate. For games that have the characters use magic powers or the sorts I would generally include those details with the characters themselves as well as any specific improvement items for that character. For example for Sonic Games I would put the characters attacks in their character subheading while pickup items like invincibility and even the Chaos Emeralds would go here.

Interface

This is a heading that I find usually overlooked despite it being so important to the overall gaming experience. What should go here is information about how not only the in game GUI works but also how the menu system operates. I usually split it off into subheadings for each menu page. Then I would have a diagram followed by a paragraph detailing how it is designed and why it is designed like it is planned. Stylisation is crucial here.

Audio

Another heading that is overlooked initially is audio but very quickly it becomes apparent of how important this is. A GDD needs to have this somewhere as music can change so drastically from design to design and the audio engineer could easily make the wrong tunes for the game due to his or her interpretation rather than your own. Make sure to include the genre of music you wish if that is to be rock, pop, orchestral or even dub-step and if you can throw in an example or two if that helps. The key subheadings here would be background audio, sound effects and even character voices or narration.

Art Bible

The Art Bible is generally considered something separate to the Game Design Document but usually I just add it below the Game Design Document. The Art Bible is simply a document filled with imagery for the game so artists can look back and get a good feel for the artistic stylisation. How you want to header it is up to you but generally the idea is to show off everything in the GDD visually. Be sure to add descriptions for each image and what the image is meant to portray about the game.

Technical Specifications

Like the Art Bible Technical Specifications is meant to be a separate document to the GDD but I simply add it to the end of the GDD. This section however has a couple of subheading that need to be addressed for any project.

The first of these is communication. If you are working in any sort of modern age group communication between team members is key. This heading therefore is used to detail the methods of communication in which the workers on this project will use. Generally I stick to Facebook, Google Docs or for long range projects Skype to achieve this. Remember that Face to Face is certainly an option and adding in meeting times is a great idea. Recently I have stumbled upon Trello as well and I would seriously advise you to check it out as it has everything a group would need to create almost anything.

Next up is the programs and software. Here all you need to do is list the programs and of course software that you have used in the creation of the game. This is not only great to keep everyone using similar file types but also helps with remembering what needs to go in the credits for your game.

Following this is the targeted release platforms. This small section simply states where the game is planned for release and why you have chosen such a specific platform or such a wide range of platforms.

Then finally is a list of all the workers on the project. This is once again great for credits but more importantly helps a lot in bigger projects when workers need assistance form someone in a specific field but does not know who to talk to about it.

Other Ideas

This is not a title for your Game Design Document but rather some good general practice ideas.

Firstly I would advise the use of headers and footers. In the header you can put the title of the game, team name and page number while in the footer you can put in the version number of the document. This not only makes your document look more professional but helps in ease of access as well especially with the page numbers.

Another trick I find that makes your document look a lot better is using horizontal lines. Adding these between each section helps break up the page and makes it much easier to read which trust me you are going to be reading it a lot.

_________________________________________________________________________________________________________________

It also helps to always keep the title of your game bold throughout the document. This is something I admit to being quite poor at but with time I hope to eradicate this issue. Doing this is extremely helpful as during development games can go through a series of name changes to fit the changing circumstances. Being in bold therefore makes it easy to find and change if changes occur. It is also a simple common practice thing in writing.

Finally I would say to not use some stupid fancy font that looks gorgeous but is unreadable remember the idea is to make the document easy to read and understand not fancy and stupendously original.

And there we have it how to write a great and efficient Game Design Document. I hope you learnt a lot today are ready to jump up and into the action here. Just remember that like everything it takes time and practice to master it and that in the end a GDD is simply meant to help you with your game creation so make it to suit you and your games needs not something else.

At some point I may even add a GDD for you to analyse here, so make sure you keep looking back at this blog and checking for that update. Never the less that is the end of today’s post of the blogs so have fun and keep breathing those oxygenated particles.

Hey for all those who waited here is the that Game Design Document I promised to show you. Keep in mind that it is not perfect and does not represent the majority of GDD as they all vary in form. Never the less I hope you can take something from this pretty extensive document on Artery

ArteryDesignDocVersion2.docx

P.S. Please do not steal anything from this design as my team and I have worked very hard on it. Not to mention that we will have it ready at some point in the near future. 🙂