Games are complex interconnected webs of designs, art, and code. Even simple games can benefit greatly from being written down in a way which ensures all team members have a unified vision for it.
Creating a Game Design Document or GDD is the best way to facilitate a shared vision. By writing down all of the necessary details and rules for how your game works, you are crystalizing ideas that would otherwise remain exclusively in the designer’s mind. This is the first tangible step in turning a game idea into a fun and playable game!
Why Make One?
It’s a Reference Point!
In a rush, many amateur game developers or professionals may eschew writing a full GDD in exchange for getting started, assuming everyone on the team is on the same page.
This is a huge mistake!
Words and ideas are open to many interpretations, and misunderstandings can take more time to clear up than implementing features in the first place!
A GDD offers a mission statement for your game. What is this game trying to accomplish? What is it trying to say? Where is the fun?
It Helps to Collect Your Thoughts!
Some concepts can be thrown out after more careful consideration; what seems like a great idea at first can be full of contradictory design elements and pitfalls that wouldn’t appear at first glance.
Carefully looking through your work and defining behaviors saves time wondering how certain systems should interact with each other and other edge cases.
It Acts As Documentation!
For larger teams, there’s a chance that the person writing the GDD won’t always be available for consultation on their game’s vision.
Having as much written down as possible ensures that the game continues to develop consistently. You are ensuring that regardless of who is working on it, none of the critical mechanics are forgotten.
As new devs get added to the project, the GDD can bring them on the same page as everyone else.
It Defines The Scope!
It can be easy to fall into the trap of adding features to games as you go. Still, if you have a GDD available to reference, you can ensure that you aren’t adding anything unnecessary before the central vision is complete and well-implemented.
Larger games require more thought, effort, and planning. If you document all prerequisites as you go, it will become obvious if the project has grown outside of scope. Better to cut things early than to waste dev hours implementing something that will get cut later!
Need some help getting your GDD together? We’re happy to help!
What to Include?
It can be daunting at first, staring at a blank page and holding so many ideas in your head. What to write down first? What things to include or exclude?
We find it easiest to start by listing out all the headers for the important elements we’ll need first. Beginning with the headers ensures that the basics are covered before moving on to the specifics.
Here is the essential list of headers we like to use; feel free to copy it for your projects:
Game Concept
Describe in 2-3 sentences what the gist of the game’s concept is. If you can’t boil it down, revise your concept or wording for conciseness.
Treat the concept like the subtitle to your game or the synopsis you’d see on the back of the box.
What type of game are you trying to make? What niche does your game fill within the genre? Try to make sure that you’re making something that is breaking new ground to help it stand out from other similar games.
Art Style
How will your game be understood by the artists working on the project?
What art can they look to for inspiration? Is it:
What colors do you plan on using? Do you have any concept art to include in the document?
What styles and essential features must be accommodated in the user interface and menus?
Camera Style
How does the camera interact with the game?
Reference other games or media that use the camera positioning you want. Explain your reasoning for it here too. It can help iron out any misunderstandings if the devs working on the project know the why.
Work out how the world will interact with the camera and establish a plan to deal with any obstructions.
Game Mechanics
Answering these questions will go a long way in your development team's understanding:
- What does the core gameplay look like?
- What primary mechanics does your game have?
- What genre conventions are you adhering to?
- What is the player trying to accomplish, and how do they do it?
- How does the player control the game?
- How do various game elements interact with each other?
- How is information conveyed to the player?
- Describe in depth what it means to lose or win in this game, if applicable.
Game Story
Is there a narrative to this game? Most games have a story in them, even if it's as simple as “You’re a frog trying to cross the street.”
Are there any important characters? What are their names and motivations? How do you want the story to progress? It can be as simple or as complex as you want.
Sound Design
What sound effects do the game need?
What music or audio cues are there, and when should the player hear them?
Is there any thematic link between gameplay and music?
The Money Stuff
You’ll want to consider how the game will make money and ask questions like:
- Who is your target audience that will be buying the game?
- Why would they want to play it?
- How do you make money from this game?
- What is your monetization strategy?
Tips and Tricks
Start Basic
Work on the core concept first. You may find it easier to answer the other questions on the GDD when you know what the core of it should be.
You Can Start Now
GDDs don’t require any special software. It will work if you can write text on the screen and save it. We recommend Google Docs since it is the program we use for our GDDs.
Test Before Adding
If you come up with some testable ideas, try to give them a shot on paper at the very least before adding them to avoid backtracking or incurring technical debt later.
Design Within Constraints
Ask your engineers and artists if any ideas need to be changed to be feasible. What could be limiting your team? These should constrain the design.
Source Control
Like with any good codebase, it is good to keep the GDD in either a repository or use software that tracks changes to the document (like Google Docs) in case you need to revert to an earlier version quickly. Seeing what changed and when can help guide further design alterations and avoid headaches.
Be Visual
A picture is worth a thousand words; it's easier to use images or short videos to explain things, especially when they involve games. Try to include as many easy-to-understand visual aids with descriptions as you can.
Math It Out
Spreadsheets like Excel and Google Sheets are excellent places to keep track of things for your GDD that you’ll need to balance later in the game. Creating formulas for how certain things in your game should work makes it easier to scale and balance.
Finalize It
Set a cut-off point to stop working on the GDD. Having a deadline where it can no longer change is vital to avoid feature creep by well-intentioned but overzealous designers.
Integrate With Your Production Workflow
Use a finished GDD to help set deadlines, create tasks, or set goals for your sprints.
Too Long; Didn’t Read?
No game is the same, so no GDD needs to be the same. Feel free to pick and choose what parts of this guide to follow based on the needs of your project and team.
The key benefit of making a GDD boils down to one thing: having a plan. Writing plans down beforehand saves time, crystallizes ideas, and clarifies concepts for others.
Good luck! Have fun!
.svg){kind=small}
.svg){kind=small}
