Fundamentals: Game Design Documents

Over the many years I have spent designing games the most important thing I have learned is creating clean game design document (GDD). Every project I have worked on that did not have a concise and detailed document has always been late, out of scope, or disconnected from itself. We are going to discuss what a game design document is, how to make a proper one, and maintaining one.

A GDD is what it sounds like, a document that contains the full design for a game. It is a living document that breaks down the desired art style, the game mechanics, sample level layouts, and even the inspiration for the game itself. This is basically your script for your game and what you can pitch to your team, without it you’re going to run into issues.

Within your average GDD you will usually find the following:

  • Summary of gameplay.
  • Target Audience.
  • Story.
  • Characters.
  • Level / Environments.
  • Detailed Gameplay.
  • User Interface / Game Controls.
  • Inspiration
  • Prototype.

This isn’t the full list of what you could find in a GDD, it can change from game to game but it is a good baseline for what can be found in one. For example not all games are going to have a set of characters to use or a underlying story for the player to interact with. It is very important that as a designer you give as much detail as possible when you write one. There is nothing worse being an artist and having vague descriptions of what the vision of the game is. People often say less is more, however in the case of a GDD, no one is going to terribly be upset if you write a book on how you want the jump mechanic to work exactly.

Now there is an exception to what I just said above, when you’re first writing out your first draft in order to pitch the game to your team. Go into detail for the big core features of the game at first and then add onto it over time.


Now that you know what a GDD is, it’s time to learn how to make one. I recommend making a template for yourself before filling it with any information. It will save you a ton of headaches for when you move onto the next project and save you time in the long run. You could also find a template already created online, but here I’ll show you a snippet of one of my GDDs to understand how information is broken down.

Above you can see how I’ve broken down the in-game systems and how they are supposed to work in-game. I provided some vague information in the Growth section of the GDD as we were unsure how long we wanted the player to experience the growth cycle of their pets. The structure you see here is how I approach all of my GDDs, they follow the same hierarchy:

  • Gameplay (Category)
    • Systems (Subcategory)
      • Growth (First System)
        • Details

The reason why I do it like this, as it makes it easy to do a table of contents at the start of the document to make finding specific information faster. As long as you keep your information clean and concise, you can structure it as you feel flows best for your project.

Another thing I use in my GDDs is visual aids because a single mock-up image says a lot more than a wall of text. Sure, you could go into detail of how you would like the user interface of your game to look or you could do this:


There is that perfect phrase, a picture is worth a thousand words. As you can see I still describe certain actions in the mock-up, pressing buy brings up the confirm screen. So bring out your flow charts, UI mock-ups, and inspiration photos into the GDD. As long as it remains readable and clear, everything helps.


Great! You used a GDD template or made one yourself and filled it out. Now you need to maintain it and keep the information in it relevant. If your team decided that something needs to change with one of the mechanics, you better go back to the GDD and make sure it’s noted there too. If you bring in new talent halfway through the project, they’re going to look at the GDD first to get an idea of what needs to be done and how.

GDDs are living documents, they will constantly need updates as the development cycle progresses. Don’t feel pressured to run and edit it at every single change though, pick a day of the week that you will go through and clean up the document. Just make sure that you note down all of the changes that have happened in that week!

Depending on the size of your team, having one person in charge of the weekly edits makes maintaining the vision of the game much easier. If you’re on a massive team however it might be better to split up certain categories based upon skill set.


I hope this was able to help some people and for those who work with a GDD daily, is a reminder for how awesome you are. After working with a lot of individuals who have never touched a GDD, I felt that a quick guide of what they are, how they work, and why they are important was needed.

Next time on Fundamentals we will discuss my personal favorite, Level Design.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s