Effectively Organize Your Game's Development With A Game Design Document

9/28/22, 3:00 PM Effectively Organize Your Game's Development With a Game Design Document
Code  Game Design

Effectively Organize Your Game's Development
With a Game Design Document
Gamux Nov 11, 2011 (Updated Aug 31, 2022)
 29 mins |  English
Do you want to learn how to plan a video game? Have you ever dived right into
developing a game, but found yourself having to constantly change aspects of the
design or the gameplay due to a lack of planning? You should consider using a game
design document: a guiding vision of the game as a whole, pulling together ideas and
plans for the design, development, and business sides of your game.
In this article, we'll teach you how to organize your game development.
Introduction
To put it simply: we like to tell stories. Some true, some not so much. But the point is
that we have been crafting tales for a very long time, and as time went by these tales
began to evolve, becoming more complex, with richer details, with more and more
fantastic backgrounds and appealing plots. Whole new worlds were born from thin air,
hammered into shape in the anvils of the human brain.
And as the stories grew in complexity, so did the tools used in their making. Art
diverged into several different categories, music became more elaborate, and movies
found their way into the world. Technological enhancements allowed the sharing of
information, spreading art all around the globe. New fantasy worlds were created each
day. Worlds so rich made people want to become a part of them. A new concept was 
being brought to life.

https://code.tutsplus.com/articles/effectively-organize-your-games-development-with-a-game-design-document--active-10140 1/27
Although video games were first just about getting the highest score possible when
faced with a pre-determined task, developers soon realized the endless possibilities
lying ahead of them. Playing a video game is more than simply sitting through another
story. For the first time, one could have a say in how the tale told itself. Players could
take hold of characters and live the hardships of the journey themselves, diving into
that particular world and mastering it, making the protagonist's conquests and failures
their own.
A game has the potential to bond player and story in a way never seen before. This
connection can be established in a variety of ways, be it the fantastic landscapes in
which the story unravels, the soundtracks, or the well-constructed personality of a
particular character. It forces players to thrive in order to see more of what they want.
Unfortunately, since a game is composed of so many different elements, different
experts from different areas are required in its creation, making the coordination of the
development process a rather tricky job. In order to help developers do their job, a
document known as a GDD, or Game Design Document, is often employed. This game
development process flowchart will help everyone to be on the same channel.
A GDD template, or a flowchart for game design, is a tool that helps developers to
merge the components of a game. It registers the general ideas of every aspect of it,
from graphic design to the storyline. In short, it registers the game concept, creating a
closer feeling of the finished product.
Although filling out a GDD template is not a vital part of the creation process, it is of
major help to the team of developers, especially in major projects involving large
amounts of personnel. Also, there is not only one way of writing a GDD. In fact, GDD
templates differ vastly among game development companies, but as a general rule,
most games are built around these documents.
So without further ado, here is what you need to know about creating flowcharts for
game design. 
Overview
A Game Design Document must teach everyone who reads it how the game that you’re
talking about works. In order to do this, you need to explain not just the mechanics, but
also how the game’s objects (characters, enemies, puzzles, weapons, environment,
and so on) interact with each other, what your game is about, and how it looks. When
working with a GDD template, these points are discussed in some general sections.
Advertisement
Marketing
Marketing is a big section divided into many subsections that explain the major
commercial aspects of the game, like public target, deadlines, competitors, and selling
points. This section is very helpful for business, since it shows what advantage your
game has over others and how it meets the consumer demand. In others words, it
shows the game’s appeal.
High Concept
Before you start to tell the reader how your game works, you must clarify the core
concept of your game, i.e. you must talk about the major aspects of your game in a
very short way, so that the reader can anticipate what will be said in the GDD template
and pay attention to what is important to the game. For this, there is the High Concept
section, which explains all of it, so that the reader won’t have to read many pages of the 
document just to know what your game is about.

9/28/22, 3:00 PM
j y g
Effectively Organize Your Game's Development With a Game Design Document
For example: if you tell the reader that your project is a futuristic space shooter game,
the reader will be able to imagine what kind of weapons, movements, enemies and
others things will be used in the game.
Gameplay
This section is one of the most important in the GDD template because it explains how
to control the objects in the game and how to make them interact with the other parts.
Also, it explains how the player will execute the possible moves. Moreover, it’s
interesting to comment on the way that the game flows and what happens during the
course of the game.
First Minutes
This is a subsection of the Gameplay section, and it exposes what the player will see in
the game when it has just finished loading. It exposes the actions and reactions
between the game and the players during this interval, helping readers understand the
game’s progress throughout the gameplay and giving a better idea of how to play it. It’s
also an important subsection, since it will determine whether or not the game is fun.
Gameflow
This is a more detailed subsection of the Gameplay than the First Minutes. It
describes all the options that players can choose while they're playing. It’s a kind of
flowchart that shows which reaction each option has, giving a picture of the game as a
whole. Generally it shows a flow of screens (e.g. from the “Main menu” screen it goes
to the “Select level” screen), but you can also put actions and consequences in it (e.g.
if the player chooses the “Mage” character, all the backgrounds will have a “magical”
feeling). It literally explains the way that the game flows, as the name suggests.
Victory Conditions
You also need to teach the reader what must be done to win, when the player loses,
and under which conditions this happens. In other words, the Victory Conditions
subsection explains the goals of the game.

Number of Players
It’s important to specify how many people can play because this implies the type of
multiplayer—where applicable—that the game will support. For example, it could use
split-screen, LAN connections, or Internet connections. Note: this section has an
influence over the Victory Conditions, since the players will need to do different things
to win in a competition than in a cooperative game.
Art
Once you've explained how to play your game, it’s important to show what your game
will look like and what kind of art is behind it, since that will influence how the elements
of your game’s universe will coexist, affecting the emotions of the players. This is a
crucial point in the game's marketing because it shows the appearance of the game
and the feelings it will pass to the player.
Technical Aspects
Another section that must be put in a GDD is the Technical aspects, since it defines
the physical game requirements needed to play and specifies on which platforms the
game will be developed, which engines will be used, and more. This affects the
Marketing, as the kind of hardware used affects both the fanbase and the public
target, i.e. the people who will consume the game.

Advertisement
Is There a Formula?
All things said, you need to keep in mind that even if some general subsections are
common between different GDDs, there is no static form to make this kind of
document, and no such thing as a perfect formula. Every game designer has their own
way of doing it, and you must discover yours. This is a hard job, but in this article we’ll
give some tips explaining how to create each subsection of the GDD. However, it’s up
to you to decide which of them are necessary to design your game.
Always be clear and concise in your text and use a lot of images, because they give the
reader a faster and more tangible view of the game’s final result, and they also ease the
explanation about puzzles (if your game has them) and how characters, environment,
monsters, screens, weapons, and other objects from the game will work.
Moreover, you can also find new topics to add in your GDD, as long as they're
necessary to the understanding of the game’s core. Some things that deserve attention
are the innovations and the particularities of your game. For example, if your game
project brings up a new way of playing or a specific graphic concept or if it’s focused
on music (like a music game), you should discuss it in the document to convince
everyone why this innovation is a good idea.
Guidelines
A good way to start your Game Design Document is with the Marketing section,
because it will be the section that your investor or client is interested in, thus allowing
them to gain interest in your game faster. In indie game development, it is not a
common section due to the common lack of investors. However, if you think about
other projects not related to commercial purposes, such as a free game on Apple's App
Store to help a charity institution, it’s important to keep track of plans related to the
marketing aspect, since it will be really important to have a publishing plan.
After this, it’s important to include the High Concept, so the reader will immediately
understand the core of the game and pay attention to the major aspects. You will figure
out that in GDDs it’s common to start with a basic and summarized definition of the 
game, and go on to present every detail step by step.

In the next section, you should write about the Gameplay, which should include, as
sub-sections, the First Minutes, the Game Flow, the Victory Conditions, and
Number of Players.
After that, you need to show how your game will look, so talk about the Art, using as
many images as you can. In the end, you can talk about the Specific Sections, which
should bring topics that explain the innovations, the aspects that not necessarily all
games have, like story, artificial intelligence, characters, and other particular things.
All the things mentioned above are represented in the game dev chart below, but it’s
just a general schema and you can (and should) adapt it to your game. Remember:
there isn’t a perfect formula. Now that you have a kind of skeleton of the GDD template,
you will find in the Composition topic of this tutorial a more detailed explanation of
what each section of a GDD template contains.
Composition
Although there isn't such a thing as a perfect formula for composing your GDD
sections, it's important for you to include some crucial topics in it, as well as avoiding
some major mistakes. This section teaches you how to detail the sections presented in
the Overview topic, while showing examples of how it's done and some common
mistakes. 
Advertisement
The Marketing Section

There is no correct way of dealing with this subject, since your objectives for it will
depend on your game. It’s also not really needed; you can either concatenate it all in a
major subsection or spread it across the document, as some of the topics discussed
here have much in common with others elsewhere. Despite the way you choose to do
it, some topics should always be addressed:
Target Audience
Who will play it? This is no ordinary section, so don’t settle for a simple “for children”
description, for example. There are endless ways to "classify" gamers, and you must
explore this. Comment on how it will appeal to each category and try not to leave
anyone out; they might share little in common with your product, but they still share
something.
Right:
Turret Defense wil appeal to male gamers of ages 15 – 25
who typically play FPS and RTS PC titles. In particular, fans of
Sci-Fi themed games, movies, and books wil be immediately
attracted to Turret Defense’s space adventure setting and
theme. Turret Defense wil have an ESRB rating of T (Teen) for 
ESRB Content Descriptor of Violence, suitable for ages 13 or

ld T f h i h f h bli h T
older. To conform to the wishes of the publisher, Turret
Defense wil not use blood or any other content that would
lead to further ESRB Content Descriptors related to violence.
Wrong:
Turret Defense wil appeal to a large audience. Based on the
experience of similar games, it should be a huge financial
success in the video games market. We plan to advertise it
heavily with ads on games-related websites with huge traffic.
(“A large audience” isn’t a valid fanbase, and it doesn’t explain why they would enjoy it.
No mention of the ERSB rating or whether the game has any age-restricted material.)
Another good example:
OrBlitz is expected to receive an ESRB rating of Everyone.
The main target market wil be puzzle game fans, but the
game’s many original aspects wil attract a wider audience,
including people that prefer to buy action-based games. Real
time strategy game fans could also be interested in the game
for its tweakability and other similarities with RTS games.
Because of the lack of graphic violence and the intuitive
interfaces, this game can target women as well as men. The
game is relatively cute and colorful, and is expected to appeal
to both American and Japanese audiences due to the content
in it.
Notice all the classifications in the example: gender, age, nationality, and genre. Keep in
mind that many more categories may arise depending on your game. Predictions on the
ESRB rating are also welcomed, so some restrictions regarding violence, sexual content
and language should be addressed if needed.
Platform
This is an extremely straightforward section. Just enumerate the platforms that your 
game is being designed for. An estimate of the system requirements is also a good call.
If d d i h d h diffi l i i l d
If needed, you can comment on porting the game and the difficulties involved.
Competitors
This is a key subsection of your document. Here you must compare your game to
others already developed. It is important to give a small description of the game being
compared to, and point out the similarities between both. This is an excellent
opportunity to expand the comparisons that were already made across the GDD and
give the reader a better picture of what the game will actually be.
At the end, summarise your product's strong points and convince the reader why your
product would sell despite its competitors. This is the trickiest part, because you must
pick good opponents, otherwise the reader just won't know what you are talking about,
and still keep your game’s image shining; therefore good writing is crucial. Your
‘adversaries’ also help with the notion of how big your market can be.
Milestone Schedule
The Milestone Schedule subsection is where you must define all the necessary steps
in order to develop the game, which is basically a timeline of the intended completion
of phases of your game. Through that, not only you, but also the investors, can have a
very rough estimate of the amount of time needed to complete the project.
Other Subsections
You may choose to add some heavy market-related topics such as Costs Overview,
which can lay out equipment costs, people costs, additional costs, and expected profit.
Future Plans
Sometimes there are so many ideas to complement a game that some of it must be put
aside in order to meet the tight schedule of development. This section is specifically
made to store those ideas, so that you can work on them later depending on how
things work out. DLCs, possible sequels, minor improvements to gameplay, graphics
and so on all come in here. You can also gather some ideas of what to do with the game
once it is finished.

Example:
Add some side quests.
Enable the character to jump.
Make a movie telling your story as a developer.
The Introduction Section
The introduction section should provide the reader with a basic overview of the game
itself, first with a light approach in the High Concept subsection and then with a
broader one within the Summary subsection. You can also highlight the more
innovative aspects of your game in a Key Features subsection.
High Concept
Give a one-paragraph description of what your game is about. This should sound like
the summary of a summary. Avoid any technical aspects, graphic or sound designs,
complex gameplay features, or marketing details that aren't strictly required (for
example, if you're making a rhythm game you should mention what kind of music style
you will be using, whereas if your game is a puzzle you can just forget about music for
now; it's better to describe what type of puzzle the player will have to solve instead).
The idea is to describe your game in the shortest and most non-technical way. A good
tip is to use well-known games as examples for comparison, such as “X is a three-
dimensional racing game with power-ups like Mario Kart”.
Right:
Scavenger Hunt is a three-dimensional arcade-style game
where players race to collect items from a list before their
opponents do.
Wrong:
Scavenger Hunt is a three-dimensional arcade game with
puzzle elements set in a fictional neighborhood in the 50's

with cartoony graphics and music where the player races to

with cartoony graphics and music, where the player races to
collect various home-related items from a given list in each

stage, while using gags as powerups, before his opponents,
which can be either CPU-controlled when in singleplayer
mode or human-controlled players in multiplayer mode.
(Keep it short and simple.)
Summary Overview
A more detailed description of your game, with fewer restrictions than the High
Concept subsection. Start with the core aspects of the gameplay, describing what role
the player will take, what the goal is, what they will have to do in order to accomplish it,
what will hold them back, and why the game will be entertaining.
Next, do a quick introduction to the game’s setting and a brief description of the history
(if any). It’s always nice to use an image instead of describing what the graphics will
look like, so if you don’t have any sketches or conceptual art, you should just paste
pictures with similar art to what you will be using (that includes screenshots of other
games as well!).
Key Features
The best way to compose this is using short topics (i.e. bullet lists) instead of long
paragraphs. Basically you should tell the reader right away about all of the creative
ideas you had which you thought would make your game a great game.
Right:
- Simple yet powerful physics that provides surprising results
from a set of simple rules. - Amazing Hatched and Cel-
Shaded graphics. - Never seen before paint system where
color spreads out to the world as the gameplay picks up
speed to a frantic pace.- Powerful land crafting abilities that
allow you to build complex paths the orbs can take, like tunnels
and bridges.- Various game modes and scenarios to choose

from each of which feels like a totally different game favoring

from, each of which feels like a totally different game, favoring
action or reflection.
Wrong:
The game wil have simple yet powerful physics that provides
surprising results from a set of simple rules, while using
amazing Hatched and Cel-Shaded graphics and a never seen
before paint system where color spreads out to the world as
the gameplay picks up speed to a frantic pace, when players
build complex paths by using powerful land crafting abilities
which the orbs can take, in various game modes and
scenarios.
(Too many ideas at once make the reader lose the train of thought.)
Third-Party Software Used
Give a little explanation of the programming languages, libraries, and software you will
be using to create your game, as well as the programs you will use to adjust your
graphics and sound engines and any other engines your game may need (like a
networking one for multiplayer games).
If you’re under some heavy software/hardware restrictions, you should specify that
here (e.g. if you’re making a game for Apple devices, you have to mention you’ll be
using iOS-compatible technology). Also, if your game is aimed at PCs and you have an
idea what the minimum requirements will be, you should note them here. Although the
non-programming people of the project probably won’t understand what the heck a
“NVIDIA Cg 1.2.1” is, they'll have to know it by name since that’s what the game will run
on.
The Gameplay Section
This section is designed to describe how the game will effectively work, describing the
game’s objective as well as its elements (menus, victory conditions, enemies,
powerups, stages, etc.), and the interaction between these elements and the player. If 
you feel like one subsection, such as “Enemies”, has too much content to be just a
subsection, you may promote it to a section of its own.
First Minute
It's interesting for you to describe what the player's reaction is going to be like as soon
as the game loads, such as describing whether they can start playing right away or if
they can navigate through menus to change some options beforehand, whether the
player will have to learn the controls by trial and error or a tutorial will be presented,
whether all stages will be available at the get-go or if they will have to unlock them in
progression, and so on. Given you have already planned some stages ahead, you could
narrate a short run of the player clearing a stage, describing the enemies and/or
puzzles they had to go through in said stage.
Right:
After the title screen the player is presented with a list of
games they can join and an option to create a new one. After
selecting the option to create a new game, a list of predefined
levels appears on the right of the screen. (...) After the settings
are adjusted, three other players join, and the game begins. A
timer counts down from five while the players get ready, using
the small amount of money they start with to place a few
blocks. As a simple beat plays in the background, the board
rotates around the middle of the screen, revealing the layout of
the level. (...) The player’s goals are on each corner of the
board. (...) As soon as the countdown reaches zero, ‘Go!’ is
displayed in the middle of the screen and the orbs start falling
from the cloud, creating havoc in their path. (...) The player
quickly places a stone corner block on the edge of the level
and the orb bounces off it, only to end up in the player’s goal
followed by a familiar cashier sound. The player’s score and
cash are updated to 200, and they start going through the
blocks they can now place (...).
Wrong: 
Th b i ith th l f i h th i
The game begins with the players facing each other in
opposite corners. Player 1 decides to use all his money from

the get-go and wins the game by using well-placed stone
blocks to earn points.
(Although being essentially how the game will run, it needs more details.)
Gameflow
A nice complement to the “First minute” would be the “Game Flow” or a game design
flowchart, which is usually represented as a flowchart or game flow summary. In
contrast to the previous subsection, this one won't focus on the first impression but
rather give an overview of the whole picture, showing step-by-step which actions the
player can take from the moment the game is loaded to when the player hits the “exit
button”, i.e. ends the gaming session—including the gameplay itself in a somewhat high
concept. Remember to be as specific as possible when creating your game design
flowchart.
Right:
(Example from Drexel Game Design's Scavenger Hunt GDD.)


Creating a very simple game design flowchart like the one below will not help the
Creating a very simple game design flowchart like the one below will not help the
creation of the game.

Wrong:
(Nothing THIS simple. Include, at least, all the screens that the player will run through!)
Victory Conditions
Here you state what is required for the player to clear a stage, win a match, or advance
to another level, whether your game is a puzzle, where the player advances to the next
level when all pieces are combined in a certain way, or a side-scrolling shooter where
the player advances a stage when they defeat the boss at the end, or whatever.
Obviously, this depends entirely on what kind of game you’re designing.
Example:
In Space Invaders, the player advances to a new wave each
time they destroy all enemies from the current wave. Since the
waves are endless, the game wil keep going until the player
runs out of lives.
Graphics
You can’t really provide the reader with screenshots or video footage of something you
may not even have designed yet, so in this subsection you should simply describe how
you plan to handle your graphical engine and maybe show some sketches of your game
or a few drawings in the art style you intend to use. Planning the game HUD from the
beginning will save you a lot of time later on, for example.

HUDs
The head-up-display is the in-game interface the player will have when playing the
game. Rather than in-game menus like settings or inventory screens, this refers
specifically to the floating windows and bars which don’t normally interact with the
game and serve an information-only purpose. This includes health bars, mini-maps,
time counters, equipped items and their amounts, money, etc. Although the size of the
HUD will vary according to the game type (MMORPGs and RTSs will have big HUDs,
while side-scrollers and puzzles will have very small ones), keep in mind that an HUD
shouldn’t occupy too much of the screen.
Example:
Sounds
On the other hand, one cannot sketch sounds, so you’ll just have to detail your sound
engine here, and maybe the style of songs your game will use. Although for most
games you will simply state that there will be different background music for different
situations, it goes without saying that this subsection is most important for a rhythm
game.
Controls
Stating which buttons/keys do what can be troublesome in the case where a single 
button performs more than one action (e.g. the ‘A’ button in any 3D Zelda). Start by
including a simple picture of a controller or a keyboard with each button highlighted
including a simple picture of a controller or a keyboard with each button highlighted
with their function in a more general sense. After that, if your game has advanced
combos or something similar to that, explain them carefully, stating under which
conditions each combo is “activated”.
Example:
(Image from CrunchTime Games Inc's Shred Nebula document.)

Game-Specific Subsections
Puzzles could have a “Pieces” subsection, side-scrollers will probably have a “Level
Design” one, space shooters may have “Enemies”, and so on. As the title in bold above
says, each game will have its own specific subsections, and since we can’t compose a
subsection for all the possible ones that a GDD can have, we'll provide you with the
three bold subsections presented here as examples.
Pieces
Suppose we have a puzzle game, where the player rotates different pieces in order to
create a line of matching pieces to gain points. This would be a nice subsection to 
show some sketches of the many different types of pieces, as well as explaining their
rotation pattern, stating their points value, and maybe describing their placement.
Pictures are welcome as always!

Example:
(Image from Colin Fahey's Tetris article.)

Level Design
Now let’s pretend we have a typical 2D platformer. One of the core elements of the
game is the stages the player has to go through. It’s important that each stage feels
unique so the player won’t feel as if they're just repeating the same thing over and over
again. On the other hand, the player should still be familiar with the flow of the stage,
e.g. if there’s always a checkpoint somewhere halfway through it, or some collectible
items along the way.
What are the different types of enemies, terrains, doodads, and power-ups, and do 
they allow the level designers to come up with many different stages? You could
present some beta stage diagrams to illustrate how will they be carried out
present some beta stage diagrams to illustrate how will they be carried out.
Example:
(Map from Super Metroid; image from jansenprice.com.)

Enemies
It’s very popular for space shooters to have many kinds of enemies, each one with
different attacks and movement patterns, as well as different values for health, speed,
and targetable area. As such, it’s no surprise you would need an extra section to
present all the game’s foes and their stats. Also, you could state some of their more
obscure behaviour, like shooting an extra beam when their health is low.
Example:
(I f C hTi G I ' Sh d N db l d t)
(Image from CrunchTime Games Inc's Shred Nedbula document.)
Plot
Many games are set in fictional worlds with their own geography, history, and
characters, in which the player will undoubtedly play a large role as the protagonist. If
your game has a particularly interesting setting, it would be interesting to include a little
insight on the game’s storyboard, describing the protagonist’s main events during their
adventures and details about the lore.
Characters
Lots of games aren’t made of enemies alone. There may be a protagonist and allies to
help players overcome their foes. For example, even a tower-defense game without a
controlled character can still have side-characters like a tutorial-NPC giving you tips on
how to overcome certain challenges at the beginning of each stage. If you do have a
protagonist that the player controls, then what are they like? Do they have any abilities
and powers? Keep in mind that this shouldn’t feel like a “How to Play” subsection.
Artificial Intelligence
Any game will need a persisting world to handle all the player’s interactions with the
game. That includes enemy movements, player controls, collision handling, time
counting, random number generators, and many other things one could need in a
game. Although people not directly related to the programming may not understand
this subsection entirely, they should at least grasp the basics of it. Most of all, keep the
coding out of here and simply state the enemies' moving patterns, the chain puzzle
piece falling algorithm, maybe illustrate the combat system with a flowchart, and so on.
Example:
The characters on the board wil escape the orbs using simple
pathfinding / flocking algorithms. Every level wil use up to
three different script files to issue commands to the animated
characters. (...) Player bots wil be used to simulate real
players. This wil allow any level to be played even if there are

more goals than players The decision process that the A I

more goals than players. The decision process that the A.I.
system is trying to solve is this:

– Should I place a new block? If so:– Where do I place the
block?– What type / material should the block be?
Technical Aspects Section
Another important part to add to the game dev chart is the technical aspects of the
game. These consist of a series of game data, such as the system requirements on
which it will play, the framework in which it was developed, the method or algorithm it
was based on, and the maximum number of elements that can be rendered on screen.
The graphical technical aspects consist of software used, modeling type, art style and
others according to these topics.
The system requirements are the necessary computer settings for the game to be
played, like the size it occupies on the computer’s HD and how much RAM is needed.
Another important technical aspect not to forget is the ESRB (Entertainment Software
Rating Board) rating (or similar), already explained earlier. Some of the ratings are
shown below.
To Include or Not to Include? When? Why?

Technical aspects interest the companies that will distribute the game or that will use
the technology developed in it, so always add something in this section if you're
showing this to someone that will approve or disapprove the game. There has to be
some care when writing technical aspects. You can write something in the wrong
section. For example, limiting the platform and distribution game mode belongs to
Marketing Aspects, not to Technical Aspects.
More Examples
In this section, you'll find how other designers do their own game development process
and flowcharts. Every flowchart for game design might vary from one to another, but
the main ideas always remain the same.
Check out the following links for professional examples of the game development
process and flowcharts: Shred Nebula and Play With Fire.
For more material about the structure and composition of a GDD template, you could
try the featured Gamasutra article The Anatomy of a Design Document and the self-
explanatory Creating a Great Design Document.
More on how to organize your video games: The Two C's of Video Game Design.
Moreover, there are other visions of how to organize your video games in the Game
Industry, as seen in Return of the GDD. Although they seem to contradict what we've
said here, this should fall in a case-by-case analysis considering team size, budget,
and deadlines.
Conclusion 
For designers who need the approval of an investor: truth be told, before you can make
any progress with an investor, you must first get their attention, and to do so, the
following key points of your game development process flowchart must be in excellent
shape.
High concept: you never get a second chance to make a first impression, and here is
where you will make it. We have already given you the tools to make this section, so just
remember to give its construction a high priority and point out everything that makes
your game more appealing here.
Pictures: do not be fooled into thinking that the reader will always go through your
entire GDD—there are some documents that surpass a thousand pages (yes, this is
true!). But the reader will surely take a better look if something catches their attention,
and what better way of doing so than with pictures? After all, one image is worth a
thousand words.
It goes without saying that your document must have a great appearance. Take your
time to make everything readable and nice. Also, don't forget that this article only
presented a skeleton structure of a GDD for you; you will have to adapt it to your own
game!
Advertisement
G i l h
Game Design Flash
Did you find this post useful?

 Yes  No
Want a weekly email summary?

Subscribe below and we’ll send you a weekly email summary of all new Code tutorials. Never
miss out on learning about the next big thing.
Sign up
Gamux
Gamux is a game development group composed of students from Brazil who
study, design and create games and content related to them, including articles
and scientific papers.
QUICK LINKS - Explore popular categories
ENVATO TUTS+ 
JOIN OUR COMMUNITY 
HELP 

30,759 1,316 50,290

Tutorials Courses Translations
Envato Envato Elements Envato Market Placeit by Envato Milkshake All products Careers Sitemap
© 2022 Envato Pty Ltd. Trademarks and brands are the property of their respective owners.

Effectively Organize Your Game's Development With A Game Design Document

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Effectively Organize Your Game's Development With A Game Design Document

Uploaded by

Copyright:

Available Formats

9/28/22, 3:00 PM Effectively Organize Your Game's Development With a Game Design Document

Code  Game Design

being brought to life.

document just to know what your game is about.

game, and go on to present every detail step by step.

The Marketing Section

ESRB Content Descriptor of Violence, suitable for ages 13 or

with cartoony graphics and music where the player races to

collect various home-related items from a given list in each

from each of which feels like a totally different game favoring

subsection, you may promote it to a section of its own.

opposite corners. Player 1 decides to use all his money from

(Example from Drexel Game Design's Scavenger Hunt GDD.)

creation of the game.

(Image from CrunchTime Games Inc's Shred Nebula document.)

Pictures are welcome as always!

(Image from Colin Fahey's Tetris article.)

(Map from Super Metroid; image from jansenprice.com.)

more goals than players The decision process that the A I

system is trying to solve is this:

To Include or Not to Include? When? Why?

Did you find this post useful?

Want a weekly email summary?

QUICK LINKS - Explore popular categories

JOIN OUR COMMUNITY 

30,759 1,316 50,290

You might also like