How to Make a Functional Game Design Document (Examples and Templates)

You’re here because you have a brilliant game idea and you want to bring it into existence.

You can imagine it in your mind so clearly: inspired by something you played years back, with a twist all your own and a hint of modernization.

It doesn’t matter if you’re a first timer or a 25 year veteran – this excitement is an all too familiar feeling.

If you’re ready to go and you’re doing it all on your own – then fine, feel free to dive in and explore for a bit. However, if you’re going to work with even one other person or spend more than a month on your idea, then jumping straight into execution is a recipe for disaster.

You’ll be stuck with mediocre code, rough concepts and mediocre game mechanics.

You don’t want that…

So where do you start?

Your instinct might be to leap directly into a massive game design document, but please don’t waste your time and energy yet.

In this post, I’ll show you a much more efficient and practical way to put together a game design document that’s actually functional. I will also provide you with usable templates and a list of full game design document examples from famous games.

First, a quick note…

(If you’re trying to make a living doing game design)

Most people who are interested in creating game design docs are new to the industry.

Here is why…

If you’ve ever worked on a game before, you’ll realize how little game design documents matter compare to your ability to rapid prototype and iterate.

So, if you’ve never built a game before, then doing any GDDs outside of helping you organize the games you’re actually building is a huge waste of time.

You need to understand that in the end of the day, game design is a maker’s craft, which means studios want to see what you’ve made, so they understand how do you make your design decisions.

With that said, let’s continue…

What is The Point of a Game Design Document?

A game design document or “GDD” is the master document which lists all of the features, concepts and ideas which are supposed to gel together to create the final game experience.

The main purpose of the game design document is to align the developers, publishers and investors behind one concept for a game. It organizes and lists the details needed for the final experience, which includes:

1. Features
2. Scope (of work)
3. Story
4. Gameplay
5. Technologies

Keep in mind, the video game industry is massive and diverse, with wildly different paths to success. AAA teams, indie developers, and solo developers have completely different needs from their documentation.

To be more specific. Above all styles and methods, a great game design document should achieve the following:

Goal 1: Clearly communicate your core idea to current (and potential) stakeholders. For example:

• Programmers need to know what to make, why you’re requesting it and how it might grow.
• Artists need to know the game’s artistic style and the overall mood of the world.
• Narrative designers need to know the major storyline plot points and the desired emotional buildup leading up to them.
• Investors need to know your target audience, monetization model, timeline of milestones, and project management approach.

Goal 2: Plan out the overall structure

Goal 3: Thoroughly explore the features needed to craft your game

Goal 4: Usable and can be iterated

You should create all of your documentation with these goals in mind.

The Traditional Game Design Document Format is Obsolete

Most game design degree programs often treat these like a master’s thesis — the culmination of what it means to be a game designer.

I often see websites sell GDD templates to cater for this supposed need for massive documents.

(Later in this post, I will provide you with more functional templates and tools for your GDD efforts used by current practicing game designers in the current context.)

Well, first off, you don’t need a monolithic document. Not only is it a terrible idea, modern tools allow us to outline and communicate far more effectively than a single doc ever would.

…If your GDD looks like Charles Dickens wrote it, will anyone actually read it?

This is the equivalent of making a business plan (with financial projections, business model, and etc.) for a tech startup who needs to constantly iterate and pivot.

Luckily, in my two decades of working as a game designer, I’ve only made the mistake of a massive game design document once and I want to emphasize this point so you don’t waste your time and energy making something obsolete.

Don’t get me wrong, traditional GDDs for older games are great for design insights (especially when the goals are the same), but you don’t need to use their template.

The nature of game development:

Game development is an iterative process. If you created a single master game design document, it would change constantly as your game took shape and you learned more and more about it.

Because iteration is a healthy, natural and required part of the game development process, things that hold back iteration are generally best skipped.

Yes, building a game engine or complex game elements takes sophisticated technical experience and careful planning. But game development is also a creative endeavor, one that benefits from a flexible, adjust-as-you-go approach.

By the way, just in case you’re interested…

Feel free to check out this course that provides you with a industry-tested design mental toolset you can use to apply to this exact approach to systematically improve your players’ enjoyment 👇

See How You Can Learn the Gameplay Design Abilities Game Studios Are After To...

• Get more interview invites & job offers
• Replicate decisions that make games fun
• Learn faster with mentorship guidance

See All 7 Case Studies →

Now, this doesn’t mean I believe documentation is a bad idea. In fact, I think documentation and advanced planning are essential to communicate with your team members.

So… How do You Make GDDs That’s Actually Effective?

In the modern era, most of your work in game design won’t be in the game design doc. Usually, the framework is set up early and then left in place with only lead game designers making changes to them.

A game design document structure for your game should be organized into 2 main components:

Component 1: Master document – This document is normally put together by the lead and/or principal game designer. It’s A 10,000ft view, concise & streamlined document that covers:

1. An executive summary of the overall experience
2. Some key art and brief descriptions to communicate the game concept
3. The value pillars of your game
4. Links to individual feature documents

Component 2: Feature document – A short, goal-oriented doc aimed directly at other designers, engineers and artists. Each doc should focus on a single aspect of the game, in just enough detail to outline the goals, the mechanics of how it will work, and the desired player experience.

Feature documents focus on a single aspect of the game, in just enough detail to outline the goals, the game mechanics of how it will work, and the desired player experience.

For example, you might have one feature document for boulder traps, another for the player’s hookshot power-up, and a third to cover how the adaptive music system works.

Communication with your team members is at the heart of being a great game designer. And today, your team is smarter, more technically capable and less patient than ever. So communicate as best as you can, as fast as you can.

Based on my experience, the most successful game designers know the power of the one-pager – a quickly parsed document which gets everyone on board for a united vision of a great game.

How to Make The Master Document

First, you need the right tools available based on today’s technology.

I suggest you using Google Docs or a wiki (such as Notion) for your documentation makes it much easier to direct team members to more detailed feature docs relevant to their role and make collaboration more efficient.

Next, as a starting point, we’ll use a functional modern template.

Modern GDD Template 1: The Master Doc

I highly recommend my colleague Rosa Carbo-Mascarell’s Game Design Template for the master doc.

Rosa is a Lead Game Designer and far more capable TikTok skater than I ever will be. Her template has helped numerous designers get started with their ideas.

What is it that makes her template so effective?

…it is simple.

What do you notice about it right away?

…It starts with a single page.

Modern design documentation is NOT about being exhaustive. It is about being simple, clear and descriptive. Likewise, your design document should echo these values.

Next, we need to establish the important priorities that are driving our design vision. These key concepts, or pillars, are driving forces which we use to help us select the best trade-offs for our unique vision when two equally viable paths present themselves.

Rosa’s template has each header as a link to a separate topic – a great place to put the details about each. You don’t need to clutter up your main doc with all of those details. Very clever!

Next, you describe your core gameplay loops.

In my case, I elected to only outline the macro-level loop – a prep stage where players prepare for the mission, combat where they are tested with their allies.

Then finally crimes – a phase at the end of each mission where players compete to steal away a specific power-up they want from their allies.

Note: There are extensive articles available on game loops, such as this one from David Eng.

The last part of this section is motivations and progression. I cap it off with a quick outline of the drivers for the players to play through the experience.

Keeping it high level and simple is more than enough to start, then you can click on the link and start spelling out your thoughts more in depth.

The final two sections are where most design docs explode in both complexity and length. This is the fatal flaw that creates sprawling documents no one reads.

Here is where you’ll want to link out to more compartmentalized parts of your documentation instead of adding more to the 10,000ft view master doc.

Now, let’s go over a real example that I worked on.

Game Design Document Example – Master Doc: Dawn of The Phalanx

Here is the wiki page for the game I was creating after I left Riot broke down. Let’s go ahead and take this now-defunct game and create a design doc for it from scratch together using Rosa’s template.

Notice short and to the point the result is. With just a few paragraphs you have a general idea of the idea behind my game. A few paragraphs quickly outline the key narrative and gameplay foundations of the game.

You can see the full document wiki here.

Next, let’s go over…

How to Put Together The Feature Doc

The goal of a feature document is to focus on a single aspect of the game.

Then the master game design document is just a summary that points to individual feature documents and explains briefly how they interact. So in turn, each feature should be a separate document that links back to the master doc.

As a designer, you will virtually never need to create a GDD, so let’s go over what you will make regularly: feature documents.

The Modern GDD Template 2: The Feature Doc

The exact template may change from studio to studio, but certain parts are absolute essential:

1. Start with “Why”
   • Why is this feature being made?
   • How will it make the final experience better for the player?
2. Goals
   • A quick bullet point list of the values that are driving this feature
   • Make these measurable and relevant
3. High Level Summary
   • What is the feature and how will it work?
   • What kind of work needs to be done to complete this feature?
   • Give just enough detail to provoke curiosity, without worrying about specifics
4. Illustration
   • Depict an example of the feature in use
   • Keep it succinct — ideally just one image
   • Concept art is great as long as it conveys what the team needs to understand

Concept art makes this complicated weapon feature much easier to understand at a glance.

Now, try to fit all of that on a single page!

A reader should be able to glance at your feature doc and walk away with a decent grasp of what you’re after.

However — and I cannot emphasize this enough — the most valuable part of writing docs is the chance to boil down all of your wild ideas into the essential parts you need to actually START the game development process.

Keep your feature docs as short as possible while providing enough clarity to get you started on those first steps.

When and How to Clearly Communicate a Feature

After you’ve completed your one-page feature doc, there might still be times when you need to go into more detail:

• If your team isn’t sold on the idea
• If there are conflicting design goals that need to be aligned
• If a specialist needs more in-depth information to do their job

In these cases, you’ll want a more comprehensive document breaking down all aspects of a feature. (You might hear this called a technical breakdown or a functional specification document.)

Here’s an example of different parts you can use to structure an useful document like this:

Part 1: A Detailed Example

1. Walk through a complete, step-by-step experience of using the feature
2. List visual communication, interactions, and results that should occur at each step

Part 2: Break Down the Feature into Chunks

1. Explain how each component, variation, or sequential stage of the feature works
2. Include images or videos if possible to help the reader imagine the in-game experience
3. Split each chunk into its requisite parts:
   • Tech – stuff that needs to be programmed
   • Art – assets which need to be created
   • Sound – audio cues to help support the feature

Part 3: Connections & Side Effects

1. Call out any special concerns or details that are relevant to your game
2. What other features might interact with this one, and in what ways?
3. What are your general rules for resolving conflicts with other features? (For example, “player movement input should take priority over movement caused by this feature”)

Part 4: Integration & Backstory

1. How will this feature be introduced to the player?
2. What kind of plot hooks are relevant to this feature?

This template is geared towards the information your team needs to do its day-to-day work, since that’s what you’ll spend most of your time on as a video game designer.

I suggest you to adapt this structure to your specific situation. This is not a static set-in-stone structure. So please adapt it to your context.
And remember the doc is just a structure, you have to be able to clearly articulate and demonstrate you designs decisions, which is a result of having a clear field tested design methodology.

A design doc for a project manager, for example, can skip most technical details and focus more on target milestones for the feature and how it supports overall project goals.

Now let’s make a feature doc together for a game we are familiar with…

Game Design Document Example – Feature Doc: “Jump” in Super Mario Bros.

Executive Summary:

In order to create a unique and memorable experience, we want to develop a jumping system that is richer than our previous game, Donkey Kong. It should create a deep and memorable experience for the players and be an essential core game mechanic from start to finish.

Goals:

• Jump should be an effective tool for dealing with enemies
• Jump should have tight control
• Jump should have nuanced skill expression
• Jump should feel natural and freeing, even if it’s dramatically exaggerated

High Level Summary:

• When the player presses a button on the controller, Mario will jump.
• The height and distance of Mario’s jump is determined by Mario’s speed as well as by the timing and duration of the button hold.
• Jumping on enemies will trigger different reactions from different enemies, encouraging the player to learn when and where to jump on enemies.
• Jump will be useful from the start to the end of the game and be a key element in level and enemy design.

Feature Breakdown:

Controls:

• • Pressing ‘A’ will cause Mario to jump
  • Holding ‘A’ will cause Mario to keep jumping up to a 4-brick height limit
  • Releasing ‘A’ will cause Mario to decelerate and begin falling, as long as he’s gone above a minimum height (1 brick)
  • Pressing ‘<+’ or ‘+>’ on the D-pad should allow Mario to adjust his horizontal speed

Mechanics:

• • Landing on an enemy should trigger a unique reaction in each enemy. Here are some examples we’ve brainstormed:
    • Goomba – squishes flat, dies after a moment
    • Koopa – retreats into its shell, moves again if Mario runs into it later
    • Spiny – hurts Mario (should not be dealt with this way – fireball instead)
    • Buzzy Beetle – retreats into shell, immune to fireballs.
    • Lakitu – dies and leaves his cloud behind
    • Lakitu Cloud – lets you ride and control the cloud. (note: delayed till a future game due to technical limitations)

Visuals:

• • Mario’s animation should change during the jump. Ideally a different frame for going up and going down. (note: cut to a single sprite to save memory)
  • Ideally, a little puff of dust should appear where he left the ground. (note: cut due to expense and lack of processing power on NES)

Sound Effects:

• • A joyful, short sound should play each time Mario jumps
  • Likewise, a cheerful sound when Mario successfully lands on an enemy

Challenges & Connections:

Jumping will be an essential part of the game, so we will need to standardize the height of all pipes and obstacles to 3 blocks high.

Side Effects:

We will be removing the ‘Punch’ feature from Mario. We realize this has been a huge favorite on the team, but we feel that focusing on Mario’s jump ability will make the game more iconic and memorable.

We’ll be reusing the animation from the punch for the new Fireball ability.

Backstory:

Mario was a plumber and plumbers wear heavy boots all of the time. This is why he has such strong legs and can jump so high and so far.

Game Design Docs are Only a Starting Point!

As you can see above, many details may change from the initial pitch to the final experience. That’s fine. The goal of the feature doc should be ONLY to get you started.

Include just enough information so everyone knows what is absolutely essential — and maybe a few ideas that you might want to try in the future.

As your team debates approaches and iterates on game features, retire any docs that are too out of date to easily fix. Trying to update everything constantly is a recipe for disaster. It’s much better to make a brand-new doc whenever a feature changes radically.

You probably couldn’t guess that this was the vision for Diablo’s gameplay

Keep in mind, docs are a snapshot of your current thinking, not carved in stone.

Note: what you should update consistently is documentation for tools and processes in the workplace, which are used to on-board, teach and remind developers how to do complicated processes.

Here is a List of Real Game Design Document Examples:

These GDDs are curated, compiled, and re-organized from /r/gamedesign, Mikael Segedi’s collection, and gamedocs.org.

I’ve filtered out all the broken links and other tangential docs that are not specifically GDDs.

1. Grand Theft Auto (originally “Race’n’Chase”) design document
2. Fallout: Brotherhood of Steel 2 design document
3. Silent Hill 2 design document
4. Diablo design document
5. Deus Ex design document
6. Bioshock design docuement
7. The Doom Bible design document
8. The Monaco design document
9. Dirty Bomb design document
10. Azrael’s Tear design document
11. Tron design document
12. Starfox 2 design document
13. Apocalypse Now design document

Keep in mind that many of these examples are old. However, as I mentioned earlier, the fundamental goals are still the same and you can learn what to do (or not to do) from them.

Time to Take Action!

I hope this post has provided some practical and actionable insights and steps to approach your game design document.

As you put this into practice, keep sticking to these principles of clear communication and focus on specific goals. Your docs will help nail down the core idea behind your game, the art style, the feel of the gameplay, and so on.

Even a simple game from a single person development team can sprawl wildly out of control, though – in both bad and good ways. Return to your docs to keep you grounded, but also to edit, rewrite, and reimagine them.

Just like all other steps in game development, game design and game design docs are iterative.

If you have any questions or comments, please share below and I’m happy to help answer.