Leandro Gonzalez: How to Write a Game Design Document

date

May 22, 2023

slug

yw1

status

Published

Author

Leandro Gonzalez

Blogger

July 26, 2016

Some clarifications before diving in

When we first shared this post (a few months ago in Reddit), some really constructive and passionate discussions emerged (and we all became better Game Designers because of it).

There were a few points that kept showing up the most and I'd like to clarify some stuff that will make sense once you've been able to read the whole thing:

Using a GDD is a thing of the past.

When you write a GDD you need to jump right into describing the Game Mechanics.

I'll probably write a full post discussing each topic in the future, but for now:

1.- Like every other industry, the game industry evolves, and the techniques that are used one day quickly become a thing of the past. Specially on a young industry that is still developing it's processes, metrics, etc.... Whatever you like to call it (GDD, Wiki, Board,...), the important thing is to have something that describes your game project (or any other project for that matter) before jumping into production.

Here at Trick we name them GDDs and we also use boards (Trello) for managing tasks, and try to divide our project in two week milestones (somewhat resembling Scrum).

We don't use a monolithic GDD that evolves during development, but rather a document that can be used by the team to get up to speed. Then, a few corrections are made to reflect the feedback or ideas of the team during the Game Design phase.

Once production has started, we no longer update the GDD, all new ideas go straight into the board, some of them prioritized (Priority 1 to 3, being 1 a Must do, 2 a Will do, and 3 a nice to have) and some of them into an "Ideas" column to be evaluated at a later time.

In summary, whether you use a GDD or something else, we recommend Game Designers that are just starting to please, please, please, consider writing down your ideas into some type of document that other people can read and understand.

2.- I think the answer to this is one is that "It depends", which should have been made clear in the post. If your game is something like Tetris or Space Invaders or Asteroids... in other words, games where the Story is practically non-existent and they won't have any effect on the game mechanics, I agree it's the right thing to jump right into Chapter 4 of the template.

For a game like the one we used in this example, it felt natural to describe the characters, what they could do and why, in order to give some context. (The Gnumies can merge, which translates into a certain game mechanic, and they are fighting German the Germ, which explains the game enemies).

Ultimately, it all depends on your game and your Game Design style. Just take into account that there is an Intro section where you can briefly describe (in one or two paragraphs) the overall mechanics, and the intention is that whoever reads the document can immediately understand your game's genre and high level mechanics, regardless of if you jump straight into a full fledged description or take a detour explaining some backstory first.

So, how do I go around documenting what I want to do with my game?

That was the first question that came up when I had the great idea that would make me rich (JK of course, I'm still poor). At that point, I didn't even know that I wanted to write a Game Design, and for that I needed to create a Game Design Document (GDD for short).

Doing some research I came across the term, but couldn't seem to find an industry standard or template to help me get started.

After going through a few Game Design books (I highly recommend Jesse Schell's Book of Lenses), and reading all I could online, it was time to create my first GDD. Through the years and iterations it has evolved into the following template, which we use every time we start a new game here at Trick.

Here's a description of each section in the GDD (you can download the template in *.doc format here => Trick's GDD Template)

Project Description

A summary of what this game is about, without going into much detail about game mechanics or anything else. After reading the Project Description, it should be clear what type of game you are trying to make (Social, Casual, Hardcore, etc.) and the genre (Puzzle, RPG, FPS, etc.). Of course, you can add more information that feels relevant to your game.

This section would ideally be one or two paragraphs long. No more than a page for sure.

For example:

This game design document describes the details for a 
multi-platform touch based 2D puzzle game with novel 
mechanics and an original story and characters.

The game plays like other match-3 games but introduces 
some innovations.

The name is to be defined but candidates are…

1. Characters

The reason we start with characters is because you need to introduce them before the Story. If your game doesn’t have Characters and/or Story, you can just jump to the Gameplay section and remove Sections 1 to 3 (or leave them empty).

An example of character descriptions:

Gnumies

 are the main characters 
in this game. These creatures are happy and wealthy, but not 
greedy.  They are wealthy because their ancestry is related 
to money, or Numismatic, thus their name: Gnumies. 
They’re hairy and come in a variety of colors.

Red Gnumies are passionate and break stuff. Yellow Gnumies

 
are electric and jump up and down.

Green Gnumies

 
are tranquil, relaxed and easy going.

Blue Gnumies

 
are a little sad and grumpy.

Gnumies also have a lot of arms, anywhere from 1 up to 4, and 
their arms have hands. They have a firm handshake and can 
combine when holding hands. Gnumies like rough play and 
leave everything messy…

You can also add some character artwork here.

2. Story

“An important part of the art of storytelling is to create characters that the guests can empathize with easily, for the more the guests can empathize with the characters, the more interesting the events become that happen to those characters.” – Jesse Schell, Book of Lenses

Having introduced the characters, it’s a good time to talk about the events that will happen throughout the game.

For example:

Gnumies are happily playing inside their castle and causing 
mischief. The Butler is going insane, but everybody is enjoying. 
Joker makes jokes.

German is home watching TV and his mother bothers him. So he 
goes out to spy on the Gnumies. Outside it's raining and German 
is looking envious through the window, getting all wet.

A strange mysterious person-something gives him a key that he 
can use to enter through a backdoor. He goes in with his army, 
kidnaps and jails female and baby Gnumies, and kicks everybody 
else out of the island…

2.1. Theme

“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

This is important for when other people read your design. Overall, the theme speaks about what kind of story you want to tell: is it comedy, is it the real life or is it just fantasyyy... :)

For example:

This is a game about sadness and hardships. There is
action and happy moments but between each chapter 
the story must progress in a way that clearly states that 
the Gnumies are sad because they lost their home. 
It must also have a sense of humor and be funny.

You can skip this section if you think it’s irrelevant for your game.

3. Story Progression

So, you have a Story, but how will the game take your players through that story.

“The world of your game is a thing that exists apart. Your game is a doorway to this magic place that exists only in the imagination of your players” – Jesse Schell, Book of Lenses

For example:

The game starts with a short intro scene where the Gnumies
are getting kicked out of their homes. Then they land in an
island and the first chapter begins.

The first chapter is the Tutorial. This can be skipped. Here
the levels are few and the Butler introduces the user to 
the mechanics.

Once the player beats the tutorial he can advance into the 
First World

Forest World.

When the player beats the Forest World, he gets the First Key 
and then can choose to open the

Volcano World

or

Icy Mountain World. Once he defeats one of these worlds….

It’s very important to develop the world like a place were 
not only this story, but multiple stories could be happening 
at the same time. This opens the door for sequels and 
merchandise.

4. Gameplay

“The game begins with an idea.” - Jesse Schell, Book of Lenses

This is (probably in 99% of games) the most important section of the GDD. It’s where you describe what your Gameplay (yes, with capital G), will be like.

Since this section can become humongous, we went ahead and divided it in sub-sections that made sense to us. Of course, this is a very subjective topic and what works for us may not work for you.

4.1. Goals

In short, why is the player playing your game? It’s good to add this information to a separate section so you don’t have to guess while reading through the whole GDD.

For example:

Overall (long term): Help Gnumies return home

Gameplay (short term): Defeat the enemies, 
advance to the next level, etc…

4.2. User Skills

This is not the most intuitive section, but it really helps to narrow down your scope if you think about what are the skills your player needs to master in order to play your game. Believe us, writing this list will help you find problems in your Game Design. For example, you may be trying to develop a game for kids but realize you require them to do something that is too advanced for their age, or some inputs may be good for Mobile but not for a Console with a Joystick. Also, if your game is going to have Custom HW built around it, then this list will allow you to figure out what components you’ll need to make it work.

For example:

Tap on the screen

Drag and drop

Memory

Puzzle solving

Rearranging pieces

Manage resources

Strategize

4.3. Game Mechanics

This is where you describe your proper game mechanics. Spare no words, when you circulate this GDD around your team, there has to be the least reasonable amount of doubt about what the gameplay should be like. This is a very good section to add some Artwork or Screenshots of your prototype (we prefer to prototype the mechanics and figure out if they are fun before committing resources to a game).

There are complete books and sites with materials about how to describe game mechanics, so we’ll not elaborate with examples here. Linked resources at the bottom.

4.4. Items and power-ups

We use this section to elaborate on the Game Mechanics. In order to avoid having a single section with everything in our brains poured into it, we use the section above to describe the core mechanics, and this section to talk about things that can be added to the game in order to improve the fun and empower the player.

So, if your game is a match-3 game, then in the previous section you’d go and describe exactly how a match-3 game would work (and adding your variations to the formula).

In this section you’d add every power up and item the player can use/encounter/buy and how they would affect the core gameplay.

For example:

When finishing a world, you could get a power up 
related to that world. For example, finishing the
volcano world, can give you an item that makes 
red Gnumies more powerful. It could be a scarf, 
or something they can wear, and those items could be 
seen in-game later. You can level up items using 
in-game currency, or use real money to acquire 
in-game currency packs….

4.5. Progression and challenge

This is also a very subjective section that may or may not work in your design. Our idea behind this section is to elaborate on how the difficulty will increase throughout the game, and making sure we give the player the tools to catch up to it.

For example:

Difficulty will advance by making the enemies harder. 
To mitigate difficulty, the user will have to play better, 
level up Gnumies and use items (also level up the items).

Also, here we can talk about the way players will unlock new levels or missions.

For example:

Each boss drops a key with a jewel of that world’s color. 
Worlds can be tackled in any order. When the user beats 
every world and has every key, then he can go and work 
his way through the last world. The order in which a user 
tackles each world can be chosen by him. The boss at the 
end of a world drops a key that can be used to open a 
different world. Once the item is used, it is lost forever. 
That way, the user must complete the world he selected 
before opening the next. At that point the difficulty for 
that world is set

4.6. Losing

Yes, losing! What are the losing conditions? Time, health, all of them? This is the section where you describe how the player gets to see your "Game Over" screen.

For example:

These are the losing conditions: losing by running out 
of time, losing by running out of moves, losing when 
there are no available combinations.

When the player loses, there must be an image showing 
the Gnumies wounded/scratched. Maybe they can lose 
some hair and you can see the skin under the hair.

5. Art Style

This section is self-explanatory: here’s where you describe your ideas about what the game should look like. Since a picture is worth a thousand words, this is a great place to add some concept art.

For example:

This is a 2D isometric game, with high quality 2D sprites. 
The character design should resemble that of Studio Ghibli.

Everything should be very colorful and feel alive, with 
highly animated scenarios and layered backgrounds….

6. Music and Sounds

“Music is the language of the soul, and as such, it speaks to players on a deep level.” – Jesse Schell, Book of Lenses

Here is where you describe your Music and Sound FX. Depending on how important this is in your game, then you can split this section in different sub-sections.

For example:

The music should have a Retro style, appealing to 8 bit 
nostalgia but high quality.

It’s important that a lot of sound effects praise the user 
when he does something good. There should be immediate 
and positive feedback.

When time is running low, add a sound that makes the 
user nervous.

The sad scenes should be accompanied by Accordion/Violin
music and sound like a sorrowful Tango.

For In-Game music, use a more relaxed approach with 
happy tunes and going up on tempo as the level progresses. 
When in caves the music should sound muffled.

7. Technical Description

Here’s where you describe the platforms you’d be launching for and tools you’ll be using or are considering to use throughout your development. This should not be a detailed technical description, for that you have the Technical Design Document (TDD). Here we are just scratching the surface.

Example:

Initially, the game will be Mobile Cross-platform:

•	iOS
•	Android
•	Windows Phone

Follow with PC standalone version and Facebook Canvas.

Could add Mac and/or console support (through e-stores) 
in a future.

Consider the following engines: Marmalade, Unity 3D, 
Unreal Engine 4.

For project management use JIRA. Use Perforce for 
storing code and assets.

TBD properly in Technical Design Document.

8. Marketing & Funding

A completely optional section, but write your ideas now so you don’t forget them later. It’s important to think about how you are going to market your game, even before starting your development. It’s also important to know where the money to make the game is coming from.

“A plan is a real thing.” – Jesse Schell, Book of Lenses

For example:

Prototype the first level, and launch a Kickstarter campaign 
where we show that level.

Try to land a publishing deal. Is there any Government funding we can apply to?Create a press kit and send to gaming news websites.

Start a YouTube Channel and post development diary 
videos.

Etc.…

8.1. Demographics

It’s important to know who you’ll be targeting, this should spill into the game design. If you are targeting 15 to 25 year old males, then your main character probably shouldn’t be a pink pony (not that there’s anything wrong with that).

Not that there's anything wrong with that

Example:

Age: 12 to 50 Sex: EveryoneCasual players mostly

8.2. Platforms & Monetization

You can add a little more detail about how you are going to approach the release on each platform.

For example:

Initially: Free android app with in-game ads, and paid 
version without ads.

Free iOS with ads. Paid iOS version without ads.In game purchases.

Consider: Windows 8, Windows Phone 8, XBOX live 
and Nintendo e-shop.

8.3. Localization

Your supported languages. Just add whatever you have in mind, this is something that probably won’t be a priority until later.

Example:

Initially English/Spanish. 
Later update with: Italian, French, German, etc.

Consider getting an Asian publisher for expanding 
to Asia, someone that can help with localization.

9. Other Ideas

Another completely optional section. If you have ideas that you are not sure if they should go in the game or not, just add them here so you don’t forget them.

For example:

Level designerBe able to rate levels created by other usersAchievementsLeaderboardsShould the game have a Multiplayer mode?

“Generally, it is safe to assume that a multiplayer online game will take four times the effort and expense to create compared to a similar single-player game.”

“There is an old rule of thumb that it takes six months to balance your game after you have a completely working version” – Jesse Schell, Book of Lenses

Closing comments

We hope other game developers can find this template useful. Looking forward to starting the conversation about how this document can be changed or improved.

Please, leave your comment below or reach out to us at play@trickgs.com and if you want to see updates of what we are working on, we'd love it if you can follow us on Twitter or Facebook. Thanks!

Here's are some Gnumies, please take them!

And here are a few interesting resources in case you want to continue your Game Design reading spree:

http://www.pixelprospector.com/the-big-list-of-game-design/

http://gdquest.com/game-design/my-7-most-valuable-game-design-resources/

Link to the template: Trick's GDD Template

Drops Mic *