Documentation in Game Design is not as clear as it should be.

Is there just one type of document or more? What documents should I write? What’s in them? These are all questions that every beginner (and sometimes not) Game Designer has.

So this week, we’ll fix this problem by not only describing what a Game Design Document is but defining all Game Development documentation so you’ll know what to focus on. Also, I’ll give you some examples so you can look at what real documents look like.

Documentation is a crucial aspect of a Modern Game Designer, so make sure to put the necessary effort into it.

We’re going to discover:

• The 2 Types Of Documentation Every Team Needs
• Some Documentation Examples

Without further ado, let’s jump right in.

The 2 Types Of Documentation Every Team Needs

All Game Development Teams have 2 types of documents to take care of.

When people think about documentation, they often refer to a single document that describes how the game works. But that’s just half of the coin.

The Game Dev Documentation divides into 2 big chunks:

• Game Design Documents (G.D.D.)
• Technical Development Documents (T.D.D.)

Both are collections of documents and never a single one.

Knowing the difference is crucial; otherwise, you could be overwhelmed by the amount of docs, especially inside a big company.

Let’s explore each one.

‍

The GDD is the whole game on paper.

This is the most famous of the 2. It’s a massive collection of documents describing the game content in every detail.

In a GDD, you can find things like:

• Game’s vision
• Gameplay breakdown
• Game levels layout and descriptions
• Story and worldbuilding
• UI & UX elements
• Etc.

Every element must be detailed without taking anything for granted.

As a design team member, you are in charge of a set of documents relative to the aspect of the game you’re designing (gameplay, level, narrative, etc.). And when you combine all the design team docs, you have the full GDD.

These docs help Game Designers communicate, but the main target is the rest of the team (primarily programmers) who take care of the implementation. But the team also needs to know how to implement what you defined.

And that’s where Technical Development Documents come in.

‍

The TDD describes how the team is going to work.

It's a collection of documents that defines the technical constraints and methodologies the team must consider.

In a TDD, you can find:

• The software list the team uses (Technical Stack)
• The game's art style rules (Art Bible)
• The programming rules (Coding Rules)
• The testing procedures (QA Protocols)
• Etc.

Everything the team needs to know to implement what's in the GDD.

The TDD is generally written by the team's Leads, that make decisions about the working pipeline.

And it has 2 main purposes: to keep the work methodology consistent and make new hires up and running as fast as possible.

Before seeing some example, don’t forget the most important thing you need to remember.

‍

Both GDD and TDD are "Living Documents".

If you think to write a document and then you're done. Think again!

Every team member works on documents for the entire development course. The docs are constantly updated and improved, especially in the Pre-Production, where things change rapidly. There's never an actual moment when a document is finished because, in game development, everyone needs to work with an iteration mindset, where you improve things one step at a time.

Ok, now let's see some actual documentation examples so you can better grasp what they are.

Some Documentation Examples

You won’t find many Design Documents online (especially recent ones) for a specific reason.

If you have the complete documentation of a game, you can recreate that game. Companies tend to keep them secret.

So, if you search for GDD or TDD online, you’ll probably be disappointed about the number of them available. The TDD is rarest, so the only one I could find that is near what a real one looks like, it’s the TDD of a school project. The GDD is easier to find, but you usually end up with bits and pieces and only a complete one in a few cases.

But don’t worry; I’ve done all the search work, so you don’t have to 😄.

‍

Here are 3 of the best examples of GDD you can find online.

• Dirty Bomb
• Race’n’Chase (the first GTA.)
• The first Doom

If you search yourself, you can find more of them, but these 3 are the most representative.

‍

Key takeaways:

• All Game Dev Teams must have both GDD and TDD
• Game Design Documents describe the game content.
• Technical Development Documents describe how the team works.
• Both GDD and TDD are Living Documents.
• As a Game Designer, you should focus on the GDD.

I’ve also talked about Game Design Documents in previous Game Design Compass episodes:

• 👉 4 Reasons Why You MUST Write Game Design Documents
• 👉 Wiki Format In Game Design Docs: 4 Key Reasons It Outshines The Single Giant Document
• 👉 How To Build A GDD Wiki Home Page That Boosts Efficiency And Collaboration
• 👉 Game Design Documents: 3 Effective Tips To Use Them And Boost Your Design Process
• 👉 Game Design Document Formatting: 5 Critical Mistakes That Make Your Docs Ignored

Check them out if you want to dive deeper.