We are really grateful for all the feedback we have received since this post was initially published. Some really constructive and passionate discussions have emerged, and we are all better Game Designers because of it.
After circulating the article through different networks (Reddit, Facebook, Twitter, etc.), there were a few points that kept showing up the most:
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’d like to clarify where we stand on these two subjects, and probably write a full post discussing each topic in the future.
1.- Like every other industry, the game industry evolves, and the techniques that are used at some point quickly become a thing of the past. Specially on a young industry that is still developing it’s processes and metrics. 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.
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
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…
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.
“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…
“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.
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.
“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.
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…
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
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.
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….
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
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.
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….
“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.
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:
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.
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: Everyone Casual players mostly
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.
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.
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 designer
Be able to rate levels created by other users
Achievements
Leaderboards
Should 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
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.
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/
* Drops Mic *
