♻️ What you should know about Game Design Documents

A Game Design Document, or GDD, is mandatory when you need to regroup the concept, mechanics, and details about the inner gears of a game. It’s basically the only thing you need to give a team for it to make a game. Ideally, if the GDD is perfect, you could give it to 10 different teams and you would end up with 10 exact same games.

Unfortunately, in the real world, GDDs are often messy, not clear, split in dozens of different documents, and outdated. In short, they are useless. With useless guidance a team will start doing things “its way” in no time. And, as every team member is different, each of them imagines the game in a peculiar way and it explains why the game bricks won’t fit together in the end. The project will be hard to achieve. The team will spend a crazy amount of time to find a vision that suits every one. After such a failure every body will continue thinking that a game designer is useless.

The problem is that they would be right. A game designer is useless… until you meet one great game designer who knows how to clearly explain even complex things to every one while keeping documentation simple and up to date.

Don’t write a book

Books are awesome. The world needs to read more books. Sometimes the reading is so great that you want it to never stop. The exact opposite happens with GDDs. No one wants to read hundreds of technical documentation explaining how a character should jump. And you can’t blame them, because it’s painful, it takes time, and because there are simpler ways to explain it. The longer it takes you to explain something, the longer it’ll take the reader to understand it. And after a few minutes a lot will surrender.

Remember that you are a game designer, not a book writer. Your job is not to use the most complex words or the most elegant sentences to explain how important a mechanic is. Your job is to make sure that everybody in the team has the same clear and exact vision of what the mechanic is after having read the game design document.

Always try to sum up the explanation to its smallest form. Don’t use complex words. Don’t try to make things elegant. Try to make them efficient.

Once a very simple and basic version of your idea / description / mechanic is written down, test it with a team member. If some questions are risen it means you need to add some details to what you wrote.

Ideas evolve

A game design document is a living entity. It will evolve throughout the development. Keep them up to date. It’s very important that, when another team member opens it, she doesn’t have to wonder if the document is outdated or not. For this purpose some teams use a wiki to keep track of modifications and evolutions of documents. Other teams work with a simple shared Word document. The method is up to you, but once you have decided what tool to use, readers must be able to find the latest modification date or the version of the document even before reading it. Letting someone spend hours working and implementing an outdated feature can be catastrophic.

Maintaining documents can be boring when telling the modification by voice to your team is easier. But think about what could happen if, in two months, the team grows with new members? What will they find in the GDD? Useless informations. Don’t let that happen and update your stuff.

Technical readings are hard to understand

All brains are not connected the same way. You can’t always be sure that everyone understands the same things. Sometimes even something very basic takes dozens of words to explain. The more words you write the wider the room for various interpretation is. The best way to avoid misunderstanding is often a simple drawing.

Sketches don’t need to be very precise or elaborated to be cool, fun, and most of all easy to grasp. They can help you in your quest to make things clearer.

Here are examples of how game designer Raymond Teo explained parts of the combat system in Tiny Avengers GDD:

• Combat range

• Engagement rule

With simple drawings and text, Raymond explains very clearly the different regions surrounding the player where things happens and how enemies behave. Explaining the same with only words would have been longer and more difficult to understand.

Never underestimate what a simple drawing can do for you. Use them every time you can.

Combine weapons for a better result

Some things evolve more often than others. For example, the rule defining how a player jump will probably never change during the development, while the jump force or the maximum jump distance will change a lot before you find the best setting. Having the properties written in the same document than the rule is probably not the best thing to do. Let the words in a text document and use a spreadsheet (or any format your prefer) for the properties. Linking your property document in your GDD is easy and reading a spreadsheet to find a simple property is easier than browsing the entire GDD.

Using different software or format for different needs can be a great advantage. However it can also become a pain if you start using them for something they have not been designed to. Also, avoid using more than three different software for your GDD. It would make everything harder to find and add confusion. With confusion, comes the frustration. With frustration comes anger. With anger comes the dark side. You can bet your document will become messy and useless in no time.

In the end

Keeping information simple and easy to read is the best way to spread the same idea to a various set of people. Always sum up your ideas and test your writings and drawings with the team. A mechanic not well understood is your worst enemy. Show the team how game designers are essential when they manage to hide the complexity.