If you are preparing to start a game development project, then you probably understand the importance of building a game design document. Having a game design document will help you ensure you have a clear vision for your game, will help avoid project creep, and will be a great asset for any project that has multiple people working on it. But, what should your game design document include?
The Divide of the Game Design Document
The First Four Sections
I believe this is a fairly comprehensive list. The first four on the list are pre-production. This is the idea phase. Be creative here. Write in what makes your game unique. This is the four sections that should draw a person in and make them excited about your game.
For a game development team, you are giving them a strong overview of what your game is in the first four sections. This gives them the lens through which everything else is to be built. It’s the filter for what goes in the game and what ideas should be tossed.
The Remaining Sections
In the remaining sections, you are working through building out the vision of your game. You are planning an initial level or a demo area in a 3D environment. I am a firm believer that you should plan thoroughly for roughly 5-10 minutes of gameplay. This is the amount of gameplay necessary for a publisher or a solid demo.
The Sections to Include in a Game Design Document
1. An Elevator Pitch
An elevator pitch is meant to be a short paragraph or possibly as little as a few sentences. This is a condensed explanation of what your game is. I recommend condensing it as much as possible. The purpose of an elevator pitch is to give you the language to explain your game quickly. You want your explanation to be a clear picture to potential publishers or to anyone that wants to hear of your game. If it takes you more than 1-2 minutes to explain your game, then people may lose interest and it may feel too complex.
Keep the language very condensed, but easy to understand. Here are a few things I recommend to students when coming up with an elevator pitch:
- Your elevator pitch should include the genre. Examples may include things like RPG, MMORPG, RTS, FPS, etc. I think it’s okay to use acronyms when speaking to people familiar with game genres.
- Your elevator pitch should include a simple explanation of the setting or time period. Examples may include things like Steampunk, the revolutionary era, the 1900s, fantasy, or sci-fi.
- Your elevator pitch should avoid referencing other projects. I believe when people say things like, “Hey, my game is a cross between Mario and Tetris.” huh? That’s open for a lot of debate or may not leave enough room for creativity.
- Your elevator pitch should not exceed more than five sentences. I would recommend 2-3 sentences, if possible.
2. Thorough Story
Unlike the previous section, this is where you get into the nitty-gritty of what your doing in your game and the backstory for your game. Answer the question of “Why do the mechanics exist in the game?”.
For reference, if you tell me you’re going to have a planting mechanic in your game in which you grow crops, why do I need to grow crops? Am I starving farmer? Do I need it for a starving population of some kind? Your story should drive the mechanics in which you have in your game. Your mechanics help the player solve the struggle you find within the story. They are not separate.
While there should not necessarily be a limit to your writing, I would still work on being concise with your explanation. Focus on the areas of importance. These are often areas that will impact gameplay and assets that need to be built. If it impacts the look, feel, or gameplay of the game, it should be included. Try to limit the “fluff” of the story for simplicity of reading.
3. Marketing Plan
Marketing plans can be very diverse. I will not spend too much time here, but you should have a general idea of how you will build an audience. If you are a bit confused, I recommend checking out my marketing guide.
You should know who would most likely play your game and what platform you may be targeting. Then you must establish a plan to build that audience base before your game is released. It doesn’t have to be done through traditional forms of advertising or spending a lot of money. Instead, putting effort into this will go a long way in being successful.
4. Inspiration
The inspiration portion should include a few areas of importance. Answer the following questions:
What games aesthetically match what you have pictured for your game?
What games have similar mechanics to the mechanics you would like to feature in your game?
What games evoke similar emotions for the player?
I recommend listing these games out and speaking of how they influence your game. You might consider key moments in games and study them. If you are trying to evoke an emotion of awe, how was that accomplished and when did you have that moment in a game exactly?
I recommend not using this section as simply “Hey, great, I loved this game.” Use it as a list of games to thoroughly study. If you would like to learn how to study a game, Game Maker’s Toolkit does an excellent job of this. Here is a video looking more in-depth into the design of The Last of Us.
5. Concept Art
Concept art could be considered pre-production as well. It can be mixed in, but I think a few pieces of concept art for key parts of the game is really important for establishing an art style and presenting your idea to others.
Concept art has to be helpful though to the production. As an example, if you are building a first-person shooter, then the character of the player you are playing is likely less helpful, especially when the player will never see the character. Instead, art pieces of the environment, key models, or buildings, may be more beneficial.
The character likely becomes extremely important when you consider a 2D or 3D platformer or any third-person game. In this case, the concept art of the main character becomes extremely important. Concept art will help get a feel for who that character is, and may influence other design decisions on the environment. As an example, you may want a complementary or contrasting color palette against the main character to help them stand out.
6. Level Layout
The level layout should be a rough sketch of how you picture the world. It is generally a top down view sketch of the world, environment, or level that the player will find themselves in. It can be simple, rectangles or squares may reprsent buildings. Circles may represent trees. This is not about full perfection or detail, it is about putting your vision to paper to explain to others. It will help a team understand some of the larger assets, such as buildings, that will be required for the project.
I recommend you also show NPC’s and/or puzzles on your level layout. It helps you determine how many you will have and begin to work on the flow of your game early. It’s easy to change if it’s on pencil and paper first. If you wish to know more about flow in a video game, I highly recommend checking out this theoretical article.
7. Assets List
The assets list should be prioritized in order of importance. Using your level layout, identify the assets required for the first 5-10 minutes of gameplay and start there. You may consider the assets in the player start area, a tutorial, and the first two or three puzzles of the game.
I like the assets list to be prioritized so that a team knows exactly what has or should be done first. This helps lead your team and capitalize on the time invested into the project as much as possible. If team members are focusing on areas, such as the end of the game, then likely that time investment will never be properly utilized well into the production of the game.
Make the assets list fairly comprehensive. Try to list out even the detailed assets for an area. All the while, ensuring that you start with the assets you have to have for gameplay.
8. Code Plan
The code plan should give some direction to a developer, even if you aren’t the developer yourself. The way I encourage students to do this is to go through your assets list first. Pick out the assets that are able to be usable or do something on their own.
A few examples here will hopefully clear this up:
If you have a gate, then perhaps that gate needs to be able to open and close.
If you have a character, then perhaps that character needs to be able to walk, run, crouch, jump, pick up items, and scale walls.
If you have a weapon, such as a pistol, then perhaps that pistol needs to be able to be picked up, shoot, and reload.
These simple instructions give developers a general idea of what they have to build and what functionality assets may have. You may want to include other functions that are not dependent on the asset list.
As an example, if you intend to have an inventory system, you need to be able to add items to inventory, remove items in the inventory, and move items visually in the inventory.
Consider unique aspects of your game. Items such as picking a character, timer mechanics, or scoring mechanics are all areas that must be programmed.
Lastly, consider your user interface components such as showing the remaining bullets in a weapon, health meters, and starting, saving, or closing a game.
Essentially, you want to list anything that needs a developer’s hands on it to be listed. A thorough list will give you a more solid overview of how much work the game really is. Understand that this is your wish list and items may be cut or added as the game development goes along. Being able to list everything is unrealistic, but this should help you prioritize for a developer.
9. SWOT Analysis
The SWOT analysis is a realistic overview of what your project is supposed to become. You want to be critical and identify the strengths, weaknesses, opportunities, and threats of your project.
SWOT analysis’ are often completed in any type of business venture. It helps business owners to understand how to play to their strengths and work at mitigating their weaknesses as much as possible.
Note though, that all projects have weaknesses. It could be that you are building a game in a smaller market. If you are building a game for mobile, you might have to consider how saturated the market is. If you are a solo developer, your game may be quite complex to build as a solo developer. These are all weaknesses or threats to being successful.
Here is an additional video on helping you build a quality SWOT analysis.
Conclusion
A thorough game design document is meant to be a document you can pass off to anyone you want to bring into your team, and provide some guidance on speaking with others about your project. It brings clarity to what your project is, and is not.
A good game design document is not meant to be started and finished at any given time. Rather, your game design document gives a good framework early to work from, and should be revised as needed. New ideas will come. You will change your mind on certain things to incorporate. That is okay, but the game design document is meant to be the basis in which everything is built.
In my classroom, when two game developers disagree about a topic in the game. We refer to the game design document. It doesn’t always solve the problems, but many times it will. It helps reduce the project creep that you may find in game development projects.
If you wish to reach out to me about your game project, I would love to look over your game design document and provide some feedback. I really enjoy this process. The idea phase is inspirational and exciting. Game design should be fun! I hope you find it to be as well!
