A Simple Guide to Making a Game Design Document (GDD) + Free GDD Template
Start your next game project with my GDD template, including sections on Accessibility, Marketing, Production, and more.
Games are incredibly complicated multidisciplinary miracles. The fact that games get made at all still baffles me. Whether you're a solo developer, or you're working with a team, some central document containing information about the game you're building can be really helpful. If that document is a tangled mess of details, however, it can do more harm than good. Luckily, you're not without help.
Throughout this practical guide on making a Game Design Document ("GDD"), we'll first cover the high-level concept of how a GDD gets used and why it's important, before unpacking the different parts of a GDD individually. Finally, at the end I'll link to a GDD template I've made, which you can download and use for free in your studio, for your game, or in your classroom.
Additionally, my GDD template is so far the only GDD I've seen where accessibility is an entire detailed section. If you use the template I've provided at the end, please make use of that robust section!
The Purpose of a GDD
Whether you're working alone or on a team, having thoughts exist in hard-copy formats outside of our individual heads is useful. People forget things all the time, and when you're working on something as complex as a game, it's always best to have a backup copy of information, plans, and more.
As a game's production gets started, a GDD can help people align on what everyone's work is in service of building, and can act as a source-of-truth when uncertainty or confusion arises.
Over time, the game you're making might drift or evolve from what was included in the GDD, and that's ok! No one can predict the future, and an amazing gameplay concept might be inspired part-way through development. This is completely fine, and can actually work great when adding to an otherwise cohesive and thoughtfully composed GDD.
How to get started
Before anything else, gather everything you can about your game. This includes gathering any concept art you've made, organizing any concept art you've seen made by others that you feel inspired by, any lists or documents you're currently using, and any data that's informing your project, such as genre popularity figures.
With all of that information in hand and ready to go, make some centralized list of what you're working with. If it already exists as a single big document, great! But otherwise, make a single bullet-point outline that covers the materials you already have. This will help you to more quickly search for the details needed in constructing your GDD.
Elevator Pitch, Story Summary, and Comparable Games
To start off your GDD, the first section should act as the front and back covers of a book. It's perhaps the best opportunity to ground your project's theme, direction, and any similar titles, so that the reader of the GDD can be best-informed about what kind of game you're making.
The first section of a GDD should quickly and succinctly describe your game as a whole. This ensures anyone going deeper into your GDD has all the necessary directional context about what your game is.
An elevator pitch is a 1-sentence summary of your game. The idea is to boil your game down into the atomic level of "what" your game is all about. This ensures you and your team can accurately describe the game, which will help a ton when the time comes to share your game with others.
A story summary is a brief overview of the story your game follows. Every game has a story, even if that's more of an abstract description in the case of art or puzzle games.
Comparable games are games you can use as a reference point when describing certain parts of your game. If your game is materially similar to other games, don't worry! That can be a good thing, in the sense that familiar experiences are easier to jump into than totally alien ones.
Genre, Core Mechanics, and Core Gameplay
The next few sections should summarize what genre your game is in, what the core mechanics are (and how they interrelate), and what core gameplay is like.
Genre is important to clarify because it's best not to assume. If you described a game as being an open-world game all about performing illegal and daring actions in superpowered cars, you could be describing either Grand Theft Auto or Need For Speed. If your game is a specific genre, or a hybrid of genres, lay it out clearly.
The core mechanics and the mechanical loop section should go into detail about what your game's core mechanics are and how they work with or against each other. This is important not only as part of planning what your game is, but also to ensure your game's mechanics are complimentary, realistically scoped, and achievable by your team.
For example, if you're working on a space survival game and you want zero-gravity cooking with physically simulated floating cast-iron pans, that's already 3 or 4 mechanics on one small part of gameplay. In defining your game's core mechanics, look for outliers of concentrated complexity to reevaluate certain parts as necessary, stretch-goals, or as things to reimagine more simply.
The core gameplay section should summarize what core gameplay is, how it's presented to the player, and the format of gameplay; such as distinct levels, an open world, sandbox sessions, or other formats. This section is important because it helps you create metaphors with which to describe and plan development.
Targeted Platforms, Go To Market (GTM), and Unique Selling Point (USP)
The reality of making games is that thousands of games are made every year, and it's pretty difficult to stand out. Thinking about how your game will get discovered early-on is not only wise, but also a practical process that can be distilled down into a series of steps and considerations.
Clearly defining what platforms you're building and testing to support is also really important to outline. If you're using a game engine like Unity or Unreal which can be used with a variety of platforms, know that it's never as easy as pressing a single button! Each platform will have its own requirements, quirks, and even specific code requirements with how data is stored.
Planning a Go To Market (GTM) is also critically important, even for free games. You should have a crystal clear idea about who the game is for, how to reach those players to share your game, and how to build a community around your game. In the included template at the end of this, I include more in-depth notes around how to devleop your game's GTM.
In short, however, you'll want to know how big the genre-specific and platform-specific audience for your game is. You can estimate this by looking at the copies of comparable titles sold, and can infer a bit more by looking at the size of online communities for comparable games. You'll also want to consider how to reach those people, whether it's by in-person events, social media, the building of a newsletter, or other methods.
Finally, you should clearly outline your game's Unique Selling Point (USP), even if your game is free. A USP is simply a clear definition about what makes your game special enough to learn more about. As your game develops, you'll want to celebrate and put a spotlight on your USP with marketing and community efforts.
Accessibility
At the time of publishing this guide, I've not yet seen any GDD article, guide, or template that explicitly calls out accessibility. With many studios seeing accessibility as a "tax" to pay at the end of production, this is honestly no surprise. However, with sufficient planning and thoughtfulness, you can make your game accessible to the nearly half billion gamers with disabilities in the world today.
This section of your GDD should outline the various ways you're anticipating the needs of players with disabilities affecting motility, vision, hearing, and cognition; as well as traumas, triggers, and phobias.
Each of these categories of accessibility can be more deeply assessed with thoughtful considerations. For example, if your game has very complicated control schemed, odds are that it lacks motility accessibility. Or, as another example, if your game absolutely relies on the color "blue" to denote meaning, people with a form of color blindness will likely miss out on information or gameplay elements.
If you're new to the subject of accessibility in games, don't worry! In the template linked at the end of this guide, I've included "starter considerations" for each of those 5 accessibility categories. These can be considered a starting point in assessing your game's level of accessibility, and can help point you in the right direction when considering how to make your game more accessible.
Project Scoping, Assets, and Production Plan
This is the portion of the GDD most focused on executing the game concept you've so been describing. The purpose of these three sections, as a united whole, is to clearly explain "how" your game is realistically achievable, "what" it will take to complete, and "when" the project is likely to be finished.
First, you should include a general scoping of your project, including the estimated amount of time needed, the overall production timeline including preparation to go to market, and the size of the team needed. This is important to consider since games almost always take longer to make than anticipated, and taking the time to realistically consider how long your game will take to make increases the likelihood you'll stay on track.
Following that, you should make as exhaustive a list as possible regarding all the assets, visual effects, textures, models, and code you're anticipating you'll need for the game. While you can't perfectly anticipate all your needs here, you should do your best to approximate the total amount of resources you'll need to make.
Finally, you should create a draft production plan organized as milestones. If you've never done this before or haven't worked with milestones yet, it's a fairly simple exercise where you organize the total work needed for your game into a logical sequence of chunks, which are usually a few months long each. This should line up with your general project scoping, and can be thought of as a more detailed and in-depth project timeline.
The general intent of milestones is that each one represents a sequential and self-contained amount of work that can be reflected on after completion. Additionally, each milestone should be small enough that you can use that reflection to fine-tune elements of your workflows and overall production, yet long enough that meaningful and challenging work can still be completed.
You want to strike the balance of not too short and not too long because that constant evaluation of your production practices and mindfulness about how you work is key to ensuring a game's production adapts to the various unknowns and hidden challenges that are inevitable to encounter.
There's no hard rule about how many milestones a project must have, or even how long a milestone is. I tend to plan milestones that are two or three months long, but every project is different, and you should feel empowered to pick what works best for you.
Get My Free GDD Template
If you're ready to jump into your game's production, or want to better organize something you're already working on, feel free to grab my GDD template using the link below, or by clicking here.
It covers all the sections in this guide, and also includes instructional starter content for every section - including accessibility. Feel free to use it in your studio, for your game, or in your classroom.
I hope this guide was helpful to you! If you found this guide or template useful, feel free to let me know on Twitter or LinkedIn.
Have a good one! ✌🏼
Arman
What to read next
Arman Nobari