So, you’ve got your brilliant video game idea that you just can’t wait to turn into an actual game and get into the game development process. You start searching around on the internet (something you will likely continue to do) and maybe you come across a tutorial about How to Make a Game. In it, you notice this section on “game design” and a reference to this thing called a “Game Design Document” (or GDD).
If you do a bit more searching, you’ll find other game developers and designers frequently mention “Game Design Documents” when they talk about the projects they’ve created. Given the number of times a Game Design Document is talked about, you might start to think that a Game Design Document is pretty important when designing a video game. However, most of these mentions fail to answer three questions: “What even is a Game Design Document, how do I make one, and why does it matter to game design and becoming a game designer?”
If you’re asking yourself these questions, I have good news for you! You’re not only starting your project in the best way possible, but you’re also in the right place when it comes to answering those game design questions, especially concerning Game Design Documents.
This tutorial is my “Magna Carta” of game design for all game developers out there. Throughout, we’re going to be taking that game concept in your head and work through designing it via a Game Design Document. We’re going to be taking the raw ore of your game concept and putting it on the anvil to hammer out its form (borrowing a figure from the world of metalworking). A Game Design Document is, in my opinion, the biggest step you will take to making your dream video game come true and becoming a game designer.
And so, with all that said, let’s get into the specifics of what a Game Design Document is and what it is not.
All About the Game Design Document
What is a Game Design Document?
I can give you the material and formal definitions of a Game Design Document. What a Game Design Document is physically is usually a document consisting of your video game’s description. What it could look like is a 3-ring binder with 20 or so pages, or it could just be 8-10 pages in a spiral notebook. The physical characteristics (i.e. number of pages, page length, even page size) will be different for different projects, since the focus here is the game design itself.
What will not be different is the “formal” characteristics of a Game Design Document (i.e. What Game Design Documents are meant to communicate). A Game Design Document is supposed to communicate the “big ideas” of your game. What the essence of your game is. One way of thinking about it is, “What sets your video game apart?” It is important to think this way for two reasons, the first is it encourages you to be unique and creative. If you have an idea for a game and you just think, “Well it’s going to be exactly like Mario Brothers,” then you probably should think about it more. Players are not going to like exact copies of another video game. There are some exceptions to that statement but as a general rule, it’s accurate.
Secondly, thinking like this will help you determine what you should put in your Game Design Document. Answering, “What is unique about my video game?” will help you figure out what characteristics you should emphasize or what you can leave out. When I first started making games and exploring video game design, I quickly realized that projects with a Game Design Document tended to be more polished than ones where I just jumped straight into coding – showing me the value of taking time with the game design.
What a Game Design Document does cover
So that’s what a Game Design Document is, but let’s get more specific than that. What specifically does a Game Design Document Cover? The best Game Design Documents answer these four questions for the game designer and team:
- What is/are the game mechanics?
- Who is the player?
- What is the story/point?
- What will it look like?
If you can answer these questions and compile them into a single document, you will be well on your way to making your video game a reality and becoming a game designer. Also, please note that this is a list, not an order. The order in which the answers to these questions appear in your Game Design Document is something you can decide once you’ve already thought it through. However, I would encourage you to think about it in this order for reasons we’ll get to later.
But having seen what a Game Design Document is about for a game designer, let’s look at what it is not about.
What a Game Design Document does not cover
This is almost as important as knowing what it does cover. If you continue to make games (as I sure hope you will), you’ll likely have family or friends “pitch” you an idea for a video game design. Usually, they will tell you their idea without having thought about it from the perspective of a game developer. I’ve had friends tell me about their game concept and then launch into a long and detailed explanation of the game’s story or a description of what the player will look like. This is important to think about but it’s not going to help you draft a Game Design Document or make it anything more than just an idea. Therefore, let’s look at what a Game Design Document is not.
- A Game Design Document is not an exhaustive story or “script”
A Game Design Document is not a place where you do your world-building. This should be a separate document for two reasons. The first is that this is usually very long and needs to be written much like a movie script. While it is a good idea to include your game’s complete storyline, the exhaustive story should be done separately. You are writing a Game Design Document, not a novel. Therefore, it’s important to only include the portions of the story that affect the game design itself.
Secondly, the game’s complex story, with all its intricacies and backstories, is not the big question you need to answer at the moment. If you’re going for a video game design with expansive lore, then there will be a time when the story should be described in detail. But when it comes to drafting a Game Design Document, the focus is the other things about your game that will make it fun. In fact, as a game designer, you may not even be involved in all aspects of the story!
- A Game Design Document is not set in stone
Do not worry about getting everything right first go. Feel free to modify and change this thing if you feel it is necessary. In fact, it’s bad practice to not have some sort of fluidity attached to your Game Design Document. Lots of things happen during development that can necessitate a change in your Game Design Document.
- A Game Design Document should not contain entire programming scripts
This one is a bit obvious but it’s important for programming nerds (like myself) to understand. Don’t copy-paste a script into the Game Design Document. Leave it in your proof of concept, it’s fine there.
Now that we’ve seen what a Game Design Document is in broad strokes, let’s get into the details about your game’s design and how you can put that into your Game Design Document and become a true game designer.
What are the Mechanics?
By putting this first, I’m deviating a bit from conventional game design wisdom. Most Game Design Document guides say to include other things like characters or story elements first. But I’ve found as a game designer that thinking about the game mechanics first is extremely important for one big reason, it answers the two important questions, “Is this even possible, and is this even fun?”
Maybe I’m a bit biased but I am a huge fan of games that have one incredibly interesting mechanic rather than a deep and moving story. Memorable game mechanics are one of the reasons we’re still playing games like Asteroids, Pac-man, and even Pong.
This is why I think it is important, especially for indie game developers and game designers who don’t have a lot of resources at their disposal, to consider the integral mechanics going into your game.
Here’s an example from one of my projects. I had this idea for a 2D platformer where the only way you could kill enemies was by picking up a block and throwing it to deal damage. No weapons, no magical powers, just this block, and a throwing ability. The player could also manipulate some physics and do a couple of other things but that was the main idea.
Now, on paper, it sounds like a great idea. Whenever I would talk to people about it, they’d say, “That sounds awesome!” I had an idea for a core mechanic and it sounded interesting. But when I created a prototype of the mechanic, it was obvious this would kill the video game. It was slow, clunky, and not an ideal combat system in any respect. By thinking about mechanics first, I was able to determine that, yes, this was possible but that it also wasn’t extremely fun. Thus is the process of being a game designer!
With that said, let’s get into the nitty-gritty of the “Mechanics” section of your Game Design Document.
What even are “mechanics”?
This is an excellent question we need to think about before we can start doing anything with our video game. The textbook definition of game mechanics is that they are: ” [a] construct of methods or rules designed for the player to interact with” [Beginners Guide to Game Mechanics, gamedesigning.org]. An example would be the “shooting” mechanic in Asteroids and the way the asteroids break up. The player presses a key and the space ship shoots (this is the method). A large asteroid breaks up into smaller asteroids when shot (this is the rule).
A mechanic can be as simple as “Press E to open the door” or it can be as complicated as a crafting tree (like in Minecraft or Terraria). Another way of thinking about it is “how does the player accomplish the game objective?” If you answered, “By killing enemies in the dungeon”, that’s your mechanic. If you answered, “by swimming around to find resources to craft items,” that’s your mechanic (two mechanics in that case; swimming and crafting).
This way, projects that are heavily mechanics focused will have a Game Design Document developed in areas where it matters most (i.e. the mechanic’s section). If a project is more story-focused, then the mechanic’s portion of the Game Design Document can be completed relatively quickly. Remember, game design isn’t an exact process.
Coming up with a “proof of concept”
This is basically where you build a prototype of your mechanic. I use the term “proof of concept” in its most general sense. For mechanics in your game, you need a “proof” that this “concept” will work. This is especially important if the mechanic is unique or new. In fact, only do a proof of concept for mechanics that need it. You don’t need to spend time working on a health bar mechanic if all that the health bar does is increase or decrease. You don’t need to prove that “Press E to open the door” is possible. Keep your efforts in this section to the most difficult and obfuscated mechanics your game needs. Also, please do not make it complicated when it comes to graphics or setup. My 2D platformer looked like this in its prototyping stage:
It should be so simple that you can sit someone down, hit play, and say, “This is what our combat system will be like,” or “This is how the player is going to swim,” or “This is how the player can craft items.” The point of this section is to make the programming part of your game development quicker. If you can do the hard work of coming up with your mechanics, you can focus on the other parts of the video game when it comes to full-on production.
Talking about mechanics in your Game Design Document
So you’ve created your “proof of concept” and you conclude, after testing it thoroughly, that this is indeed what your game needs and you like your game design. Or let’s even say that your game has some simpler mechanics like door-opening or dynamic day-night cycles (I guess the latter can vary in simplicity), how should you put this in your Game Design Document? As always in a Game Design Document, formats are fluid rather than rigid but a general format should look something like this:
- A Quick Description of the Mechanic [e.g. “Blocks can be picked up and thrown to deal damage”]
- A Quick Description of how it’s going to be implemented [e.g. “The player uses this to defeat enemies”]
- A way to access your proof of concept
The third step is important if you’ve got a team of people working on it with you – especially if you’re the main game designer. If you’re working on a digital Game Design Document (like a Google Doc or slide presentation), then you can simply add a link to a Github or a Google Drive. The specifics of how you do this isn’t important. The important part of this entire section is that you know what mechanics are going into your game. Having this nailed down will help you in answering the next question of this game design process.
Who is the player?
Since I’ve stressed the mechanics part of your game design and Game Design Documents, we need to jump to the next logical step and talk about how those mechanics affect your player. What is the player going to be doing in your game? This is where you can talk about the story, placement, and characteristics the player has. You can do this in whatever format makes sense for your project. Usually, a short paragraph makes the most sense. An example from a survival game would be something like this:
“The player is a scientist who crash-landed on a watery planet. The player must swim around the environment to locate resources necessary for survival and escape. The player must also fend off hostile aquatic aliens if they hope to survive. By crafting items, the player can build vehicles, tools, and housing.”
This will give some helpful context to your player. Please note that while we are talking about the story, we aren’t laying it out fully at the moment. We just need to highlight some portions of the story to better describe the player. The full story progression will be addressed later on in this tutorial. This short description will serve as a sort of introduction to the other things about the player. First of which being the abilities required of the player when they play your game.
What are the player’s abilities?
We need a list of all the abilities the player has. As close to comprehensive as possible. Going back to our example from the survival game, a list of abilities might look like this:
- Swimming with WASD and mouselook
- Item pickup
- Inventory management
- Item crafting
- Object scanning
By hitting as many points as possible, it goes into much more depth than the description we wrote earlier. And there are two reasons this is important. The first is that it will tell you what level of proficiency is required to play your game, which in turn informs your target audience a bit. Given the above example, I’d say only very young children wouldn’t be able to play this game (i.e. it has a broad possible target audience). The second reason is it will reveal whether or not there is a possibility for imbalance. Imbalance usually crops up when the player has the ability to make a wide range of choices either from characters or items. And it just so happens that imbalance is the topic we’re going to talk about next.
Balancing your game
Balancing a game is a huge topic so we’re obviously not going to cover everything in this short little section (it is also a very difficult part of being a game designer). However, there are some important guidelines we can look at when it comes to writing your Game Design Document.
First off, realize that certain genres require more balance. By looking at our player description and realizing what sort of genre that falls into (i.e. survival games), we can determine that most of the balancing will take place in level creation.
Secondly, realize that balancing a game can be an ongoing chore rather than a one-time event in your game development. In a survival game, you as the dev and game designer have the ability to tweak everything until it’s perfectly balanced. However, for online games with many players (the most obvious example being online shooter games), balancing is going to be a bit more nuanced. If you play Counter-Strike: Global Offensive, you’re likely familiar with all the balancing the devs and game designers have done throughout the game’s history. In fact, most of these guidelines are going to be targeted for that sort of game genre. So let’s have a look at how we might improve the balance of that sort of game.
#1 Look for complementation not cancelation
If you’re the dev or game designer of a shooter game and you notice that one gun has four-times more kills than any others, your immediate reaction might be to tweak some parameters on that gun to make it less powerful. This may be necessary for some situations but as a general rule, it’s much better to tweak another weapon to match the strength of that weapon.
For example, if the over-powered gun is a shotgun that instantly kills when close to the enemy, you might consider giving a bit more strength to the sniper rifles that work better with long distances. This is a more ideal situation that leaves players saying, “The shotgun is good for some situations and the sniper is good for others.” The technical terms are “nerfing” and “buffing” and what I’m encouraging is to buff rather than nerf. Obviously, this is a guideline and not a rule.
There are situations when it is better to nerf. The Counter-Strike devs decided to nerf the SG 556 (also known as the “Krieg”) in April of 2020 because it was quite obviously overpowered. However, they didn’t nerf it to be equal, rather, they nerfed it on only a few parameters (like fire rate and short-range accuracy) while buffing another gun on the opposing team (the Counter-Terrorist AUG). This shows that complementation is still much better than cancelation and buffing is better than nerfing.
#2 Use math and then don’t
When approaching a balancing problem, it might be tempting to come up with some sort of mathematical formula that guarantees a balanced game – making your life as a game designer easier. This is a good idea when you’re drafting your Game Design Document to have some sort of idea as to how you’re going to balance your game. If you write out your player’s abilities and find that your player can pick from a catalog of weapons or characters, you’re going to need to know how to balance everything.
But the danger of this is that your game-play isn’t fun anymore. A set of characters or items may be mathematically balanced, but that can take the fun out of a game. Rob Pardo, the former Chief Creative Officer at Blizzard Entertainment, talked about the effects “mathing everything” can have on your game:
“..often times […] I have more junior deisgners that are more analytical and very math based [who] get very scared of too powerful abilities or too powerful of units. And they want to spread sheet everything down and they want to do a nuanced kind of balance. ‘What if we just increase their damage by one or increase their damage by two?’ Well why don’t you just increase it by 10 and then look at [the opposite team and see] about increasing their armor by more?…Celebrate the big differences between units because otherwise you’re going to end up with an army game […] where everything kinda feels the same…and you can high five each other and say it’s balanced but is it fun? Probably not.” (“Making a Standard: Blizzard Design Philosophies”, GDC 2010)
In other words, a mathematically balanced game isn’t as important as a fun game. So keep this in mind as a game designer.
What is the story?
Now that you’ve got a good idea of what the player is supposed to be, you are ready to place the player into the larger narrative. Here is where your bright fantasy world or cold survival story comes to life. Keep in mind who is going to be reading your Game Design Document. Other game developers or artists are going to be reading it. This means you don’t have to write a novel but more like a synopsis. It should contain details about the setting, theme, and actors in your game. The exact format is, as with everything in the Game Design Document, not as important as getting the information from your head onto paper.
Also, please note that this section is one that can and should be expanded and changed. Story-telling is complicated and so don’t worry about writing a triple-A story the first go. In fact, please take your time with this section especially if your game is story focused. That being said, here are some helpful tips to guide you along as you think about crafting your game’s narrative.
Who are the actors?
Who is taking part in the story? What are their motivations? Are they allies, enemies, or NPCs? Familiarize your development team (i.e. the people who are going to be reading the Game Design Document) with these characters. Describe their place in the story and how the player will interact with them. Consider working out the story behind your enemies as well. This a classic way to add depth to your story. Think about adding a motivation as to why they’re against the player. Lots of storytelling opportunities can be found by using this approach.
Where does your game take place?
Is it an aquatic alien planet? Is it a wooded forest? Is it a post-apocalyptic world torn apart by nuclear war? Think about some of these things and even include some sketches if you think it’s necessary. This will help you describe the overall theme of your game and what sort of artistic skills are going to be needed.
How does the story progress?
Basically, a list of all the events that will happen to your player. This way you can tell what emotion should be felt at that moment. If the player defeats an enemy, it should be a feeling of triumph and victory. If a player watches their home get destroyed, it should be one of grief. These are things that may be obvious to you as you’re planning this but are a bit less obvious to whoever is working on the game with you. Placing the correct emotion at the correct moment is key to good storytelling.
What is the goal?
What is your player trying to do? Is it to rescue a princess? Reach a destination? It’s also important to think about this if you’re using a level system. What is it going to take to defeat a level? This is also important to make clear even if you’re not going to have a story-based game. A simple explanation of the goals your player must accomplish to beat the level and/or the game.
What will the game look like?
This is your concept art section of your Game Design Documents. This, at least in my experience, is a really important section for capturing those most memorable moments in your game. And if you’re anything like me, a visual image solidifies everything I’ve read about on paper. A description of the character or the landscape is useful but an image of it is invaluable – especially for the entire development team.
Getting good concept art can take your Game Design Document from, “Okay I can kind of see what this game will be like,” to, “Ah, now I know exactly what this game is about.” The visual portion of your game is what users are going to be greeted with the most. It’s worth taking the time to plan out your game’s visual aesthetic. Also, another important part about this section is being able to draw menus and UI as well. It is a good idea to plan your UI along with your concept-art. Drawing what the buttons look like and where they will appear on the screen is a designing trick I’ve found very helpful. Otherwise, you’ll end up dropping a UI that doesn’t integrate into the game at all – the bane of all game developers!
Some concluding remarks
Video game design is one of the most unexplored forms of digital art. Many skills mesh together with so many different combinations that it’s really unfathomable. However, it’s quite exciting to think about all the possibilities when it comes to designing and building a video game.
I hope by reading through this guide, any questions you have had about game design or the development process of games has been answered and you feel more confident about designing your game. Remember, designing games is not an exact science, and while there are guidelines, much of designing a game is up to your own creativity. Nevertheless, with the help of Game Design Documents, the process can be a lot more accessible and put you on the right train of thought. It can also be helpful for your entire development team (if you have one), since it makes the lines of communication all the more clear!
I hope you use this brief guide to draft your Game Design Documents, launch your unique video game, and…
Keep making great games!
BUILD GAMES FINAL DAYS: Unlock 250+ coding courses, guided learning paths, help from expert mentors, and more.
