How to Write a Game Design Document (Examples and Template)
If you’re an aspiring game designer, you’ve probably heard about the importance of a Game Design Document (GDD). A GDD is like a blueprint for your game. It oulines everything from the story to the game mechanics, and can even include your thoughts about art style, game economy, and more.
In this article, we’ll dive into why a GDD is essential, who writes it and who reads it, the key sections in a GDD, and the steps you can take to get started writing the GDD for your game.
Contents
- Does every game need a game design document (GDD)?
- Why is writing a GDD important?
- Who writes the GDD?
- Who reads the GDD?
- Key sections in the GDD
- Steps to writing a GDD
- Example GDD outline
- Professional GDD examples
Does every game need a game design document?
Not every game absolutely needs to have a game design document. But it is a good idea for most projects — especially if your game concept is complex, or if your team is more than just a few developers. But you can tailor the scope and detail of your GDD, anywhere from a few pages, up to a giant, multi-page “bible.”
For smaller games (think game jam entries or solo projects), a GDD might be less necessary or could just be a few simple pages. If you’re the only person on your project, you might have a clear enough vision in your head, even without extensive documentation to guide the development process. Still, even a simple GDD can help you stay organized, and keep a clear focus as you build your game.
For more complex games, or larger projects with many team members, a GDD is crucial. It will help keep the team aligned, help to ensure clear communication, and serve as a reference point as the team builds your game. When everyone is clear on the design up-front, you can avoid needless debate, confusion, miscommunication, and wasted time.
Why is a writing a game design doc important?
A GDD is a super important tool in nearly every game project. Knowing how to write a game design document is a common job requirement for game designers, and for good reason.
It helps make sure everyone on the team has a clear vision of the game
When you have a good GDD, it helps establish a shared understanding of the game’s vision among team members. When everyone is on the same page, it’s easier to coordinate efforts and avoid time-wasting (and frustrating) confusion and miscommunications.
Team members can check the GDD whenever they have questions about the design, instead of having to ask the game designer. That helps them make sure the work they’re doing aligns well with the overall concept.
Laying out a clear vision in your GDD can also help the team stay motivated and focused. Because when team members understand your game’s purpose and goals, they’re more likely to be more invested in its success. Invested team members are more creative, more productive, and usually have a better feeling of ownership.
It helps keep the development process organized and on track
Making a video game is challenging. It requires lots of different tasks, like designing characters, building game levels, programming the game’s mechanics, and composing music. The more complex your game is, the higher the chances that your project and timelines can “go off the rails” if you haven’t planned well enough.
Your GDD can help keep this messy process more organized, because it breaks down the game’s components into manageable sections with clear ownership. That helps each team member understand their scope, plan and prioritize their tasks, and set realistic (well, more realistic) deadlines.
It helps you pitch your game idea to others
If you need to persuade other people to join or invest in your project, having a solid GDD will be a valuable tool. When you can present a well-organized, detailed GDD, it builds trust that you’re a “professional.” And it gives stakeholders confidence that you’ve thought everything through. So it’s a great way to confidence in your ability to deliver the game successfully.
Your GDD can also be used as a sales tool, because it helps potential partners understand what’s unique about your game and evaluate its market potential. When you clearly outline the game’s mechanics, story, and visuals, it helps investors visualize the final product.
In short — it can make the difference between getting the funding you need, or having to scrape and save to build the game on your own dime.
Who writes and maintains the GDD?
Usually, initial drafts of the game design document are written by the team’s lead game designer, along with others on the design team. And while the lead designer will most often continue to be the “owner” of the document, they’re also responsible for gathering ideas and input from everyone else who’s involved in the game’s development.
That’s because good game ideas can come from anywhere and anyone. The best game designers don’t think of themselves as “auteurs” — they think of themselves as the person on the team who synthesizes, organizes, and filters ideas into something cohesive that aligns with the project’s vision.
Who reads the GDD?
The short answer is: Everyone who has anything to do with the game, will read your GDD.
The whole development team will refer to the GDD throughout the game’s development, from early pre-production through launch. That includes designers, artists, programmers, sound designers, producers, QA testers, and others.
Your GDD will also be read by stakeholders — people who aren’t on the dev team, but care about the project’s success. Stakeholders include people like marketing managers, investors, advisors, publishers, and other groups involved with supporting and selling the game.
Key sections in a GDD
There isn’t a single, “right” way to write a game design document. The GDD will be a little different for each unique game. As long as you include the information that you and your team need to build the game successfully, then you’ve done it right!
But if you’re starting fresh and aren’t yet sure what you need to include, here are some of the most common sections to write first. Feel free to pick and choose whichever sections make sense (or don’t make sense) for your unique game.
Also, remember that writing a GDD is a big job, but it’s an iterative process. You’ll write a few drafts early on in the project, and then continue to flesh out additional details well into development. Think of it as a “living document” that you and the team will adjust as you go.
Game Overview
The Game Overview section is a high-level summary of your game’s core concept, game genre, target audience, and platforms. This is your chance to define the essence of your game, and provide a quick, clear understanding of what it’s all about.
Start by describing the game’s unique selling points, and point out what might set it apart from other games in the market. Be sure to identify your target audience, because that will help guide many different design decisions.
Next, define your game’s genre, and provide reference examples of similar games. This helps your team get a better sense of the game’s style, gameplay, and mechanics. Your genre of choice will also affect your team’s marketing efforts, once the game is done and ready to be marketed to an audience.
Finally, mention the platforms your game will be available on, since that will of course influence both technical and design considerations.
Story
In the Story section, you’ll outline your game’s narrative, characters, and settings. Start with a short overview of the plot, calling out the main story beats, and any branching paths or player choices that would impact the narrative. This helps your team understand the game’s structure and pacing.
You’ll also want to use this section to introduce the main characters. Provide short descriptions of their backgrounds, motivations, and roles in the story. Flesh out the game world by describing the game’s setting, key locations, history, and lore.
If your team has game writers, you’ll probably want them to help you draft this section of the document based on their own story and character ideas. It’s not uncommon for this section to basically be a summary of a separate, story-focused document that the writers are busy creating as a supplement to the GDD.
Gameplay
The Gameplay section is where you’ll detail the game mechanics, controls/inputs, and objectives of your game. Start by outlining the core gameplay loop — what players will be doing repeatedly throughout the game. Describe the unique mechanics and gameplay features that set your game apart, and explain how they contribute to the overall experience.
Next, explain the controls, detailing how players will interact with the game and perform various actions. How will players move around? Jump? Attack? Solve puzzles? Interact with game objects, or non-player characters?
Then outline the game’s objectives — both short-term goals within each level, and overarching goals that span the whole game. Be sure to discuss any progression systems, like character leveling up or unlocking new abilities. Call out any failure states or conditions.
This section is critical for programmers and other designers to understand how the game should feel and function. So you’ll need to put a lot of thought into it, explore how similar mechanics work in other games, and write it all down as detailed as possible.
Art and Sound
In the Art and Sound section, you’ll detail the visual and audio style of your game. It’s common for this section to include references from other games, movies, and other artwork for inspiration. Discuss the color palette, character designs, environmental aesthetics, and any visual themes that will create a cohesive look for your game.
You can also include any concept art you or your team may have made. Even if it’s far from being final, it will give readers an idea of the overall art direction you have in mind.
For the sound section, share your thoughts about the game’s musical style, and any specific themes or motifs you want to incorporate. You can also include high-level thoughts on sound effects, especially any unique sounds for specific actions or events in the game.
Like the Story section, the Art and Sound section is usually an overview or summary of the general direction. If your project has artists, game music composers, and sound designers, then those groups will do most of the heavy lifting by writing more detailed, specialized documents for their own areas. But this section of the GDD can be great to kick off early discussions, and to summarize the larger documents from other groups as they’re developed.
Level Design
The Level Design section describes the layout, progression, and goals for each level or area in your game. Start by outlining the structure and flow of your levels, including any branching paths, exploration elements, or gating mechanisms.
Next, describe the various objectives players will encounter within each level. These could be things like puzzles, combat encounters, or collectibles. Discuss any environmental hazards or obstacles players must overcome, and explain how those elements contribute to the game’s overall challenge and pacing.
It’s common for this section to contain early “pencil and paper” mock-ups of potential game levels, to help readers get a better idea of what you have in mind. Any visuals you can include will help a lot here. If your game will have dedicated level designers, be sure to have them help with this section.
User Interface (UI)
In the User Interface section, sketch out and describe the menus, heads-up display (HUD), and other on-screen elements that players will need to interact with. You should also explain how players will navigate menus, which options might be available, and how players will manage inventories or other game systems.
For the HUD, describe what information players will see during gameplay. Common items on a HUD are things like a health bar, a mini-map, objective markers, and weapon information. Make sure that your UI design is clear, intuitive, and visually consistent with your game’s overall theme and art style.
This is another spot where it’s important to include mock-ups or wireframes to help readers visualize the interface layout. If your team will have dedicated UI artists or UI designers, then you don’t need to get too detailed here — just enough for the UI designers to get started on their own (far more detailed!) mock-ups that you can include in your GDD later on.
Technical Requirements
Use the Technical Requirements section to list any hardware, software, or game-engine specifics for your game. Start by specifying the game engine your team will use to build the game, because that will impact many other ares of development, from programming to art asset creation.
Next, discuss any hardware requirements. What are your minimum and recommended system specs for PC/Mac games, or specific console features for console games? If your game is for mobile devices, which devices and what are the min specs? Those choices will help your engineering and testing teams start planning accordingly.
This section could also mention any third-party software, plugins, or middleware that your game will use. Examples might include physics engines, AI systems, UI systems, or audio tools. This will help your team get started obtaining and (if necessary) learning the tools, and will help your producer start to understand licensing requirements and costs.
If you’re not a highly-technical person, you’ll want to lean on your team’s game programmers and system programmers to help with this section. They will likely have a lot of preferences and opinions, and can help by doing technical diligence to figure out which tools and tech might be needed for your game.
Steps to writing a game design document
Remember, there is no one “right way” to write and develop a game design document. But if you’re looking for ideas on how you might go about it, here are some steps to think about as you get started.
- Brainstorm. Jot down your ideas, from the game’s premise to its mechanics. Don’t worry about structure or organization yet. And this isn’t the time to “self edit” — put all your ideas down, you can edit them later.
- Organize. Sort your ideas into the relevant GDD sections. This helps you see what’s missing and what needs more development.
- Write a first draft. Using your organized ideas, start writing your GDD. Be clear and concise, so your team can understand your vision. Use the below example outline to help you get started.
- Review. Once you’ve written your first draft, read through it and look for inconsistencies, gaps, or unclear points. Revise as needed.
- Collaborate. Share your GDD with your team for feedback. They may have suggestions or spot issues you missed. If you’re a lone developers, ask friends or family to read it and share their thoughts with you.
- Iterate. Revise your GDD based on the feedback you receive. Keep refining it over time, as you develop your game and have new ideas or end up changing your mind on something.
- Maintain. Update your GDD regularly to make sure it stays current and relevant. If your GDD is the “single source of truth” for the whole team, it will avoid confusion and help everyone stay in sync.
Example outline for a GDD
If you’re looking for a way to jump start your game design document, start by copying and pasting this outline into a blank Word or Google Doc. Then just start filling in the blanks! As you write, feel free to change or reorganize the structure as the needs of your unique game become more clear.
Title: [Your game's title] 1. Game Overview a. Core Concept b. Unique Selling Points c. Genre d. Target Audience e. Platform(s) 2. Story a. Plot Summary b. Branching Paths/Player Choices c. Characters i. Protagonist(s) ii. Antagonist(s) iii. Supporting Characters d. Setting i. Key Locations ii. World History and Lore 3. Gameplay a. Core Gameplay Loop b. Mechanics and Features c. Controls d. Objectives i. Short-term Goals (within levels) ii. Long-term Goals (overall game) e. Progression Systems i. Character Leveling ii. Unlockable Abilities f. Failure States/Conditions 3. Art and Sound a. Art Style i. Visual References/Inspiration ii. Color Palette iii. Character Designs iv. Environment Aesthetics b. Sound i. Musical Style ii. Themes/Motifs iii. Sound Effects</p> 4. Level Design a. Level Structure and Flow b. Objectives within Levels i. Puzzles ii. Combat Encounters iii. Collectibles c. Environmental Hazards/Obstacles d. Level Progression and Pacing 5. User Interface (UI) a. Menus i. Main Menu ii. Options Menu iii. Inventory/Character Management b. HUD (Heads-Up Display) i. Health Bars/Status Indicators ii. Maps/Navigation iii. Objective Markers</p> 6. Technical Requirements a. Game Engine b. Hardware Requirements i. Minimum System Specs (PC) ii. Recommended System Specs (PC) iii. Console Features (Console) c. Third-party Software/Plugins/Middleware i. Physics Engines ii. AI Systems iii. Audio Tools
So feel free to use this outline, but remember, it’s just a starting point so you don’t have to start with a blank page. Customize and expand it to suit your game’s specific needs. Just be sure to include clear and detailed information in each section.
If it looks like a lot, don’t be intimidated! There’s a lot of creative value in just writing. The simple process of filling out this GDD template will help you start thinking through your game’s design. It’s a living document, so your first draft doesn’t have to be great — just get started, and you can refine it over time as you have more ideas.
Professional game design document examples
Fortunately, many game developers have shared their game design documents online. Even though your game might not be as big or complex as these ones, just having a look at a commercial GDD can be inspiring. Here are a few professional GDD examples that you can download and read.
- Grim Fandango GDD. The design document for Tim Schafer’s classic adventure game, offers great insight into how to describe a game’s puzzles, story, and characters.
- Diablo “Concept Pitch.” This is a high-level pitch for the first installment of the popular action role-playing game (ARPG) series. It gives insights into the level of detail to include in a game pitch, and shows that even the most popular game franchises started with a pretty simple design document.
- Grand Theft Auto GDD. While this game GDD is pretty old, it’s an excellent example of a thoughtful, detailed game design document.
- Deus Ex annotated GDD. This very early GDD, annotated by Warren Spector, shows just how much a final game can change from the original design. It’s almost unrecognizable as Deus Ex.
- Bioshock “Pitch Deck. Okay, this is a pitch deck… but it also contains a “Bioshock Design Annex” section that provides in-depth designs from creator Ken Levine.
- The “Doom Bible.” This is a GDD for the original game, and is a good example of how much content gets designed but then not added to the final game.
- Monaco GDD. Here’s an example of a GDD for a smaller, more “indie” game. The game reached a fair amount of success, even though the document isn’t as large and detailed as some of the others.
Reading these professional design documents can be super inspiring, even help you get started if you’re feeling a bit of writer’s block. Just remember that your game is just that: your game. Feel free to tailor your GDD accordingly.
Write on!
By now, you know that writing a good GDD is an important, early step in the creation of your game. It helps you think through your design, define your initial scope, and rally your team and other stakeholders around your vision. By following the steps and writing some key sections, you’ll start building a solid foundation for your game’s development.
But remember, your GDD is a living document. Keep refining and updating it as your game evolves. Because as you saw with the professional GDD examples, very few games end up looking just the way they were described in the first draft design.
Now, go turn and your game idea into a reality!
Read my new book!
Making games for a living is an incredibly rewarding career, but it’s hard to break in unless you have insider knowledge. This book levels the playing field.
Leave a Reply