This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
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:
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.
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)
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.
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:
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.
“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... :)
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
“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.
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.
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.
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.
Also, here we can talk about the way players will unlock new levels or missions.
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.
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.
“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.
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.
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
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).
You can add a little more detail about how you are going to approach the release on each platform.
Your supported languages. Just add whatever you have in mind, this is something that probably won’t be a priority until later.
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.
“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.
Here's are some Gnumies, please take them!
Link to the template: Trick's GDD Template
* Drops Mic *