From Concept Ideas to Production ~ Game Design Documents[GDDs]

We get fascinated by so many aspects of games which usually ranges from the captivating Narratives,Cinematic Delivery and seamless gameplay of AAA games to the simple motives,unique else cliché gameplay and unconventional Narratives of Indie games and much more. Yet, how do we go about when we get an idea on designing such masterpieces or casual experiences?

Image for post
Image for post
Image by PIRO4D from Pixabay


Creating a video game is far from a trivial task. There is a myriad of questions to be answered in order to sort out what direction your project would go towards and somewhat determining the success of your project. Games like many other kinds of projects, benefit very heavily from proper planning and outlining of it’s scope.

The game design document helps you form a finite scope for your game. You can set some parameters to keep the project manageable. You can map out things like plot, and characters, and locations, and at a certain point you can decide the game is big enough.

Image by PublicDomainPictures from Pixabay

No matter how close they may seem, no two games can be the same. Therein showing a difference in the methodologies and technologies used in creating them. In the same frame no two Game Design Documents would be the same but there are some common aspects and points which need to be addressed when designing most games. These can be a noted as starting point for mosts game design projects.


A Game Design Document exists to set the game’s design bounds and make clear it’s features to the members of the game design and development teams. It could also be an efficient reference for new members joining the team or when team members’ roles are being replaced/swapped. Most people argue and mix this up with a pitching document which maybe relevant when showing people out of the development team the features of the game before testing or marketing into production. Compared to the pitching document the Game Design Document is more technical and usually not for the final consumers of the game.

Image for post
Image for post
Image by Oleg Gamulinskiy from Pixaba

Your design documentation serves as the embodiment of the vision for the game shared by the team.In other words, your design documentation is both backward-looking and forward-looking: it records the decisions you made and their rationales, and provides a map and a guide for developing the game going forward.

In this light it is best if the game design document is drafted with members or lead members of each team partaking in the development process so they share and understanding and add some insight on the design document. As the design and development proceeds there should be comments and updates on the design document at each design iteration or at advent of new ideas and / or features.


  • This document is in no way meant to serve as a replacement for team collaboration services or applications.
  • It is equally not a “BIBLE” or immutable book but open to various iterative updates based on innovations or changes in the game’s design
  • It exists to portray the scope and give guidelines to the various teams so they don’t stray from the vision of the game’s design during their various implementations of the features
  • As part of maintaining the design docs, you can include these in your version control system to have a log of changes and dates, or insert a log at the top of each section to show its history.


Creating your design docs should take into consideration the audience and tools used to explain each concept. The focus is on trying to be as precise and self explanatory as possible. Hence a mixture of text, equations, systems, pictures, diagrams, flow models, diagrams, etc should be used wherever necessary.

The approach may vary depending on the size and build of the team; be it an “Indie” developer/studio or an AAA studio, with each game idea you want to work on, there are a few topics you may have to consider then analyze before and during design and implementation. These include;

Interest and Uniqueness of the Idea

  • Is the idea interesting worth development time, effort and expenses?
  • Has it been done before or is it something new and ground breaking. If it has been done before how does it measure up to similar games in the same genre and what is it bringing new to the table.

Purpose/Philosophy and Audience

  • why is the game necessary and what lessons/philosophy it impacts on the player: Most games have a moral or an underlying lesson which affects heavily the mood of the game and design decisions surrounding the game * You may want to paint the limitations of mortality into the players mind and create gruesome deaths in overwhelming situations out of the players control.
  • Target age-group or community should factor into the interactive elements and content descriptors

Game Setting[Theme and Location]

“Resonant themes elevate your work from craft to art. An artist is someone who takes you where you could never go alone, and theme is the vehicle for getting there.” — Jesse Schell, Book of Lenses

  • The game theme would heavily be influenced by the underlying philosophy of the game and goes a long way into the game art, character designs, music pieces, audio effects and much more. It can be also seen as the intended atmosphere or “Vibe” of the game : A “Gothic” feel would influence by inducing a more “horror Vibe” and the effects and art would be geared towards creating a scary atmosphere.
  • Location involves the world/place, physical structures and anthropological constructs. Location of the game might require references images and some on-scene-research to learn more about the place or the stories and traditions of the place.

Game story validation

  • The initial story idea should be validated within the world context, setting, game genre and should follow the theme of the game. Most people design the game from the story and others the other way around. Pick which ever suits the needs at that time.
  • For most projects where the story is being written while the game is developed it’s easier since iterations are done on both sides and each can easily be blended to suit the other. Meanwhile if the game is made from an existing story, not much can be done while trying to follow the story yet bringing about flexible gameplay. [* I think this opinion is highly subjective]

Genre, Gameplay and UX

  • what game category(s) / genre(s) does the game best fit into: Having one genre which defines the game is OK but some ideas have more than one overlapping genre. In such cases, filter it down to just a few which work well together or see the possibility of achieving your type in case it is not something “conventional”. some common game Genres are;

Arcade games, Puzzles, Platformers, Racing, Adventures, Endless runners, RPGs, First person shooters, Third person shooters, Story/Manga driven JRPG, Visual novels, Tower Defense, Horror, Survival, Simulations

  • Outline the main gameplay points and objectives
  • Determine whether it shall be “open-world” or level based

Game Engine and Target Platform(s)

  • Selected Game Engine greatly depends on the teams build up and funding available for the project. Most AAA studios would prefer an in-house game engine so they can customize and have it address all their needs meticulously meanwhile most Indie studios / developers would use free engines like Unreal, Unity or Godot and some might pay for the professionally licensed versions of these Engines.
  • This is very crucial since Team members might need to upgrade their skill base depending on the engine being used which would not really be ideal in the case of a heavily time dependent project.
  • The platform that you choose to develop your game for will significantly impact the way it is designed and developed. Different platforms have different hardware features and constraints:~ The platform dictates the way the game is controlled hence there might be a an alteration in gameplay experience on different devices for the same game.
Image for post
Image for post
Image by Paulius Balčiūnas from Pixabay

This document is your map, but it’s a map that can grow and change with your game (like the minecraft map).

After several iterations, especially in the case of AAA games with very huge project scopes, it would become quite difficult to manage a single document with design information for several aspects and systems. At this point, each aspect covered in the document could be split into several other documents based on the design or based on the teams or people reading them. As an example you could have everything related to artwork, theme and character creation designated in one document for the concept and 3D artists.


This is an outline/template for your design documentation — a blueprint for the blueprint of
your game.

Image for post
Image for post
Image by Peggy und Marco Lachmann-Anke from Pixabay

N.B: Depending on the game genre and features you could always add or remove features covered in your Game Design Document. Since it is more technical than casual, features of the game mechanics should be elucidated with required implementation details.

Cover Page

  • Starting up with a front page containing information on the company(Name and Logo), project Title (Ideas / Game Name) and other pertinent information readily identifying the document, who wrote it and it’s audience.
Image for post
Image for post
Cover Page

Project Description

  • Overview on the relevance, type, function and aim of this project.

Design History

  • Logs on design iterations and ideas

Game Overview

  • Concept statement: short sentence describing the game experience
  • Background Philosophy: underlying principles driving the game and design
  • Common questions: why this game? where does it take place
  • Genre(s): specific genre or mash-up genre
  • Target audience and ESRB rating
  • Unique Selling Points: Game innovations and difference from competitions

World / Level Design

  • Factions and Locations
  • Characters Biography and abilities
  • world/level Art styles


  • Player Experience and Game POV
  • Objectives and completion
  • Character skills and abilities
  • Items and Interactions
  • Game Mechanics: Progression and challenges
  • Game Systems and Interactivity

Story and Progression

  • Narrative
  • Characters and Faction Biographies
  • Background information and Research links

Visual and Audio Style

  • UI / UX : HUD, menu, Interactions, etc
  • Sound ideas
  • Music feel and types

Platforms, Technologies and Technicalities

  • Game Engine
  • Rendering mechanics
  • Prototyping constraints

Tools and Assets

  • software tool stack
  • Extra Resources

Marketing and Funding

  • Platform and monetization
  • Localization

Other Ideas


Image for post
Image for post
Image by Peggy und Marco Lachmann-Anke from Pixabay

There are several ways to go about organizing a Game Design Document. What is presented here might work very well for some game designs but serve as a tip of the iceberg for others.

It is best to organize the game design document based on and together with your team leads / members in case it’s not a solitary project. It shall also help in building good team energy required during the course of the project.

The game design document evolves throughout the project life cycle to become a resource with enough information which could be extracted to form the Basis of a Game pitch Document ( which is less technical and just for every other person/gamer or marketing company to know what your game is bringing into the industry)

Download: Game Design Document Template


Written by

Dev-Ops Engineer | Game Engine Engineer | Game Dev | Gamer | AI Enthusiast

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store