Writing Modern Game Design Documents (+Examples)

Let’s talk about what place game design documents (GDDs) occupy today. Are they still relevant? How big should they be? Let’s have a deep dive into the origins of game design documents, why we still use GDDs and how to write a game design document. You can find examples of game design documents at the end of the article.

Waterfall vs. Agile Development for Games

Back in the day when software production employed a waterfall type model, Game Design Documents were considered something that you created and then executed. In a classical waterfall model each step of the workflow is considered to be more or less completely separate. You spent time crafting the perfect GDD and then “threw it over the wall” to get it built. Since you perfectly scoped out the video game design document in advance, you knew exactly what to build, which tools to use for it and which team skills to acquire in advance.

The reasoning for this comes from the very relatable idea that fixing issues is cheaper the earlier you encounter them in production. A mistake that is identified just based on an early text document is much cheaper to fix (just spend some time brainstorming a better solution and update the text), than late in the project especially when reworking mechanics and content would potentially mean throwing aways lots of already done work and dealing with additional complex interweaving dependencies.

This sounds great in theory. Unfortunately it doesn’t work for most software, certainly not for game planning. Nowadays it seems completely obvious that building video games is different from other construction disciplines, like building houses or machines or cars. Once you start working on a concrete building any new changes to it are extremely expensive and prohibitive, to a degree which we usually don’t see in games.

Instead we’re dealing with the challenge of knowing much less about the thing we’re building: we’re not creating the thousands iteration of an office building, but something (hopefully) uniquely innovative and highly artistic that nobody had created before and thanks to modern game engines and tools our main challenge is not the technical capability of creating something anymore, but creating the right thing with the right team. The game development waterfall model is not the right fit for dealing with these challenges.

Agile methodologies replace heavy upfront design by iterative work. Already in 2001 a group of people with lots of team project experience published their famous agile manifesto which went on to change how we think about software and game development today.

Here are two lines of the manifesto which directly speak to over believing in lots of up-front documentation and planning work:

Working software over comprehensive documentation
Responding to change over following a plan

Does this mean we should throw away the notion of GDDs completely? No! It just means thinking of them as these big all-encompassing monolithic documents is heavily outdated. There is no perfect game design document template, but here are some benefits for writing specific documentation for your game vision, which I’ll go into in the following section, whether you’re developing for Steam or for other platforms. (Read our tips for designing your Steam store page here.)

Why use Game Design Documents?

Helps you think about what you’re trying to build

If you’re like me, you’re probably constantly coming up with new rough game ideas. Articulating your loose thoughts into a written text forces you to think through the basic structure and helps you define your game vision, which can give you confidence in pursuing your idea further. In the best case scenario it helps you fix some issues already in the paper phase of your project (see some advantages of the waterfall model above, but don’t count on it).

Acts as a guiding light

Sometimes games move into a lot of different creative directions at the same time. This is often important and useful as games tend to find their own way. Sometimes some or all parts of your game might slowly drift apart from each other resulting in something which feels less coherent for its own good though.

Having a document with a list of the core pillars of your game vision can help the team to refer back to it when there is disagreement about ideas and can act as guiding light. It is not bad veering off your initial vision, but it is good to understand when you’re doing it. Make it a conscious decision and make sure you’re still creating something that the whole team is excited by and that is still at a manageable scope.

For example for the initial release of Curious Expedition 1 we took the drastic step of removing our whole combat mechanic, which we had prototyped for some months. We realized that it was not part of the core experience that we had laid out when starting the project and focused on getting the travel mechanics right instead. Over time and many updates we were able to add a new combat mechanic which was more in line with our overall vision. (We shared all our financial numbers for Curious Expedition 1 here.

Brings new team members up to speed

There are often a lot of implicit ideas and feelings related to your game, which seem very obvious and clear to you. They are also probably clear to any member of the team that has been around for a long time and has been part of many conversations that strengthened the game vision.

Yet to a newcomer these can be not as obvious. Having written your shared team goals and vision is a great help for onboarding new team members. This can even be important after big sections of the game are already playable.

A basis for publishing contracts

Thankfully publishers have embraced modern game production planning and the days when publishers would demand a full all-including GDD to be part of the contract sheet are mostly over. A real playable game always trumps any documents that you may have and will show the publisher that you’re not only good at coming up with great concepts but also have the team and capability to create the game, as demonstrated by your vertical slice.

Most publishers will still expect some form of documentation of what you’re planning to do for the whole game. At the very least this document will usually be reflected in the type of milestone and deliverables agreement that is part of the contract. Even when creating your game without a publisher, distribution partners like Microsoft or Sony often still ask for documents which give a detailed overview of the game. (Learn how to pitch to publishers here.)

Applying for game grants

State grants often require more detailed business plans and fleshed out game design documents than publishers or platform holders. This is to safeguard them from potential abuse as they often don’t have the same contractual safeguards that shield them from developers who end up misappropriating the resources.

Common issues of Game Design Documents

Having pointed out these advantages, let’s talk about issues with GDDs. After all even though writing a document might be cheaper than putting a feature through the whole code & art pipeline, it is still nowhere free and needs to yield benefits to be worth the time expense for creating it.

• They get out of sync immediately

  One thing that is great about creating something digital is how easy it is to quickly update the product. At least during pre-production, ideas which don’t work can be quickly changed and replaced. Even with best intentions it is almost impossible for text documents to keep track of these rapid changes and they can feel more like an annoying chore to be updated. In the worst case they might even end up being damaging and misleading, if different parts of the team operate based on conflicting information without knowing so.

• Wrong sense of confidence

  Something might read fantastic on paper, but yet even the smartest and most experienced game developers in the world haven’t figured out how to reliably assess how much fun something will be once you actually play it. The only way to figure that out is to actually get your hands on the controller (or whatever input device your game is using) and experience the thing first hand. Relying too much on documents can give a wrong sense of confidence, thinking that hard work on the GDD will automatically translate into a fun game.

  As a game developer I have my fair share of game ideas that marinated for months in my head and that completely fell apart the second I played them as rough prototype. Assume nothing as proven as long as you’re not actually experiencing it.

• Too long to read

  Large documents with dozens of pages can be hard to read. Even if you craft the most perfect in-detail vision of your game, nobody might have the patience to read through it. Even worse: readers might be too intimidated by this magnum opus to challenge the author as they see the huge amount of work that was put into it, especially when the point of discussion is rooted so deeply in guessing as it often is with intricate design documents, which are not prototyped yet.

How to write good Game Design Documents

The answer on how to deal with the idea of GDDs today, lies in a pragmatic wasteless approach. Using it where it makes sense and dismissing the parts of it which have become outdated by our increased understanding of successful game productions.

Here are three tips for creating a modern game design document:

1. Keep it minimal. Focus on outlining the guiding design principles, the basic mechanics and what your overall vision is. Instead of spending lots of time explaining specific game mechanics in great detail, focus rather on the overall goals that you have with that design. How should it make the player feel? How does it stand out from the competition? What is your artistic intent?

   For a lot of cases this might even be possible in the structure of a one page game design document, as used by more and more game designers. Restricting yourself to only a simple game design document, will also help you separating fundamental elements from ancillary aspects.

2. In doubt your game is your GDD. Without extreme effort there is simply no way around your design document becoming quickly outdated. Some would even go as far as basically only using game design documents in preparation for a pitch or contract negotiations and then never touching it again.

   Same as with a bug ticket which only has value at a certain moment in time and becomes irrelevant as soon as the bug is fixed, your detailed design descriptions should be seen as tightly tied to specific points in production and become obsolete as they go into the game. In general your game prototype should be the reference point of truth as much as possible instead of a separate document which gets forgotten to be updated constantly.

3. Treat them as part of your project management. Put your detailed content and game mechanic designs inside your project management tool alongside with your regular tasks and bugs. Handle them as entities which get added, changed or discarded as needed on an ongoing basis and might even live in conflict with each other. To manage them you need to make sure that your production process handles notifications, assignments, comments and other important fundamentals of team management.

   Our first indie game Curious Expedition had a extremely minimalistic game design document for the first year of working on it.

   

Examples of Game Design Documents

Still looking to learn more about game design documents? How about checking out some classical game design document examples? Here are some of my favorite historic game design documents for famous games for you to get inspired by. Just keep in mind that most of these are a bit older and not representative of everything we learned about team productions in recent years.

• The original Game Design Document for Diabo by Blizzard North (back then still called Condor Games).
• Game Design Documents for the original GTA by MDA design back when the game was called Race’n’Chase.
• Some very detailed GDDs (split into Technical Information and Design Bible) of Prince Of Persia by genius game creator Jordan Mechner.
• You can also find the GDD of Doom - the OG of FPS shooters.
• The famous Game Design Documents for Ion Storm’s Deux Ex - also a personal favorite of mine.

This blog post was originally posted in 2020 and was last updated in August 2023.