Blog Game Design How to Write a Functional Game Design Document (Templates + Examples)

How to Write a Functional Game Design Document (Templates + Examples)

How to Write a Functional Game Design Document (Templates + Examples)

In my 16+ years working as a game designer collaborating on League of Legends, World of Warcraft, Hearthstone, Ori and The Will of The Wisps, and more, I’ve only had to make a massive game design document once.

…After all the pressure of making the GDD for a $44.5 million game pitch, in the end it turned out to be a colossal, demoralizing waste of time and a huge waste of money for the studio that hired me, since none of that 112-page GDD was even used! 

I did get compensated for this work, but I definitely don’t plan on doing it again. 

But hold up! The sprawling, 112-page game design documents once considered a key skill for game industry success are only one (outdated) approach.

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.

…so what’s a more practical alternative?

A much more helpful plan is to replace that game design document with Feature Documents — short, goal-oriented docs aimed directly at other designers, engineers and artists.

game design doc vs feature doc

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.

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.

We’ll get into a step-by-step guide on how to write these, but first let’s look at an overview of game design documents, what they are, and why many people getting into video game design are obsessed with them.

By the way, if you’re interested in getting into game design, feel free to check out our guide on how to become a video game designer.

So first, let’s clarify…

What Is 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 goal of the game design document is to align the developers, publishers and investors behind one concept for a game. It lists the features, work, story, gameplay and technologies needed for the final experience.

Game design degree programs sometimes treat these like a master’s thesis — the culmination of what it means to be a game designer. Websites sell GDD templates to cater for this supposed need for massive documents.

GDDs for older games are great for design insights, but you don’t need to use their template. This page is from this great archive of docs from many masterful LucasArts games.

Overall, students and early career game developers can end up feeling like there’s a “right way” to do this, and that they’d better learn it or else!

But 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.

I myself had been working in game development for many years before I ever had to write a traditional, giant game design document — and even then, it was mostly an afterthought for a particular publisher.

So with all that covered, what kind of documentation do you need to establish a game concept and guide your team members through the process of making a new game?

My Perspective on Game Design Documents’ Goal & Usefulness

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.

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:

  • 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.

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

What Game Design Documents Are Actually Effective?

Your game needs some kind of documentation, for sure. However, instead of a colossal singular document, you should focus on building feature documents.

Feature documents 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.

(You can reference our beginner’s guide on video game mechanics.)

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.

If you still want an overarching, separate document for the whole project, make it a concise, streamlined master document, including:

  • An executive summary of the overall experience
  • Some key art and brief descriptions to communicate the game concept
  • Links to individual feature documents

Using Google Docs or a wiki (such as Notion) for your documentation makes it easy to direct team members to more detailed feature docs relevant to their role.

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

Game Design Document Template: The Feature Doc

A feature document, as mentioned above, should focus on a single aspect of the game. Then the game design document is just a summary that points to individual feature documents and explains briefly how they interact.

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 exact template may change from company to company, 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
insomniac canceled game monster knight-min
From Insomniac’s canceled game Monster Knight

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

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.

Let’s Go into Nitty-Gritty of The Feature: When and How to Do It

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.

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 put this into practice (from start to finish) on a feature for a game we’re familiar with.

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. 


  • 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.
game feature example mario jump
Image from HTML5 Games

Feature Breakdown:


    • 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


    • 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)


    • 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. 


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.

mario need a plumber art by Fernando Sala
Art by Fernando Sala

Feature Design Documents 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.

d3 gameplay description

You probably couldn’t guess that this was the vision for Diablo’s gameplay (from Mikael Segedi’s collection of GDDs). Docs are a snapshot of your current thinking, not carved in stone.

Pro tip: 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.

Now, Get Started!

I hope this article has convinced you of the value of the feature doc approach. Take a specific part of the game and make the documentation clear, concise and simple. That’s the path to success.

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 feature docs are iterative.

You can do this – one feature at a time.

P.S. If you have any feedback on any updates or additions that can help me make this the most useful post on Game Design Docs, feel free to share them in the comments below!

P.P.S. If you enjoyed this post, you can sign up for the game design digest and get notified by email when the next post is published.

Leave a Reply

Your email address will not be published.

Game Design Weekly Digest

Learn from the practitioners of the game development industry.

Learn More
The game design weekly digest

Every week, we send out an exclusive email with the goal of providing you with proven tips & strategies on how to:

  • Land a job as a game designer
  • Avoid getting stuck scoping your game
  • Build an effective portfolio that actually works
  • Learn design fundamentals to help you excel in your career