Game Design document

So what is a game design document? A game design document or GDD is a piece of living documentation that is developed by a development team of a game. this piece of documentation is filled with information about the game that will be made, e.g. what the game is, how it works, what is needed to make the game, plans for the game, development teams, schedule and deadlines.

The purpose of a GDD is so that it provides a single vision for the game for the whole development team. It gives the programmers, artistes and designers a clear vision of what needs to get done so that they can work together with less issues, and also know when things need to be done.

For some examples of some GDDs we have:

‘Race n’ chase’ by DMA Design Ltd

(http://classes.dma.ucla.edu/Winter12/157A/doc2/gta_gdd.pdf)

‘Amnesia – the dark descent’ by Frictional Games

(https://www.scribd.com/document/61699696/Amnesia-The-Dark-Descent-%D0%90%D0%BC%D0%BD%D0%B5%D0%B7%D0%B8%D1%8F-%D0%9F%D1%80%D0%B8%D0%B7%D1%80%D0%B0%D0%BA-%D0%BF%D1%80%D0%BE%D1%8)

‘DOOM Bible’ by Tom Hall

(http://5years.doomworld.com/doombible/doombible.pdf)

First we are going to look at the Race n’ chase GDD and how its laid out. First of all, it starts off with the name of the project and swiftly moves on to the table of contents where you see what in the document and what page it’s on. Following that it gives a quick introduction to the document and the rules of how it’s been written. Next it talks about the target systems and quick look at the game itself, from there it moves on to talk about the technical side more on how the game will be made and the work practice that will have to be used, for example in the part ‘5.7.2 Objects’ it says that the objects like cars ‘Each will be around 64x64 pixels’. After the technical part we move onto a more detailed look at the game itself like the world, landscape and controls. And then to finish off we have a list of the teams and the times and deadlines.

The document is laid out the same throughout, it starts with the chapter number and name e.g. ‘1. Introduction’, and then the information that corresponds with the title. Then after that a new sup-chapter written e.g. ‘1.1 scope’, this still relates to the over arcing chapter so that’s why it’s a sup-chapter. Another one will be written until all parts relating to the chapter are done. Then the next chapter will start and it will then have sup-chapters too.

All these chapters and sup-chapters can be found on the table of contents.

So why is this GDD written like this? Well first of all this project looks like it has a large team aboard, meaning that they all need to be filled in on exactly what the project is, so everything is clearly listed. Also because of the way the document has been laid out with its chapters its much easier to find the information that you need. For example, someone doing programming might not need to know what the artist need to know and so can easily find the information applicable to them. One last thing is that this was a very large project and so all know information had to be written down. When they talk about the limitations of the hardware they are working with, they have clearly laid out how they will store the data, how they make the game look and play within the limitation they have. This is so that when they are making the game they can keep in mind these limitations so no work goes to waste.

The next GDD we will look at is Amnesia. This one jumps right into the design of each level, it has not starting page that introduces the game or what it’s about.

Starts with the name of the level and then a top-down map of the level. It then goes on to give an overview of the opening of the level, written out similar to a script. It then goes on to list all the rooms found in the level and a deception to what they are like and what happens in them. Also events, puzzles, notes, visions, quests and items and listed, describing what they are and how they happen/are obtained. After this it moves on to the level and goes through all this again, leaving out any that don’t apply to the level. This goes on all the way to the end of the document.

So why is it laid out like this? First of all, the team that made it was a lot smaller and so they all may have had a good image of that the game would be like beforehand, so a full design document would have been a waste of time. They just needed to detailed plan for the lay out of the levels. Another thing would be the unlike race n’ chase where they were pushing their game to the limits. Amnesia wasn’t nearly as revolutionary technology wise, and so didn’t need to worry about the limitations as much, so information about keeping to the limits weren’t necessary.

The last GDD is the DOOM bible. This one has an of similarities to the Race n’ chase GDD, it also starts with the game of the project and a table of contents. it then starts off with the game specs, split into sections from 1 to 5. Then moves onto the game itself talking about the characters of the game. and then goes into episode on of the game, talking about its story, actors, unique bits and the map (all of which have separate sections on the table of contents). it then has sections for episode 2, 3, 4, 5 and 6 to do the same, however these have been left blank. It then moves on to a commercial level for the game and then a list of the weapons and items for the game.

The following section is designed for the DOOM press release, showing a sort of script about the game. and after that it just random notes.

In a sense it is laid out very simile to the race n’ chase in that it goes through every part of the game, list them to make it easier to find the information needed. It is also similar to amnesia in that it goes through the levels in great detail.

The reason for this is that this team may have been a bit larger as well, and so a clear vision of the game was needed for the whole team. However, in this document there is a lot less about the limitations of the hardware and also its talks about the game but not so much the coding or how the visuals work. And so the team members may have partaking in many of the areas of the game, and so may have known the limitations of the system beforehand so that information wasn’t needed for the document.

In conclusion a game design document has no industry standard. They change depending on the project, the size of the team or even who’s in the team. A larger team may need a more detailed documents to make it clear to everyone, and to understand what everyone in the team is doing and how they are doing it. a smaller team may not need that information as its easier to keep track of everyone and so make that part of a document may just be a waste of time. Its important not to put in point less information.

If the game itself is large scale, then a large document will be needed so that the game doesn’t lose forces and go of track. Whereas a smaller game may not need to have one as large.

Overall a game design document is important to all projects, but what for that document comes in can and will change depending on the project.