Documentation

Now that we have covered all the main aspects of our game, it is important to prepare them to be shared with others. Throughout this book, you will probably work alone, but in real-life production, you will likely work with others, so sharing your vision is a crucial skill you need to learn in order to create successful games. You will not only be sharing your vision with your teammates, but also with potential investors that want to put money into your game project (if you convince them to do so). In this section, we will give recommendations about how to properly format your game information into comprehensible documents.

Game Design Document (GDD)

This document is basically the Encyclopedia of your game. It contains a breakdown of all the aspects of it, each one with detailed explanations about how the different game systems should work. Here, you will put the questions and answers we previously looked at in the Implementation Plan, and you will deep dive into those. Remember that you have an idea in your head, and making sure that others grasp that idea is complicated, so don't underestimate this important task.

Maybe you are making a game all by yourself and you think you don't need a GDD because all the ideas can fit in your head. This might be true for very small games, but any size of game and team can benefit from a GDD. It will serve as your notebook to put down your own ideas and read them. This is important because in your head everything makes sense, but once you read your own ideas and review them, you will find lots of blind spots that can easily be fixed before discovering them when coding the entire game.

Let's start by talking about how a GDD can be structured.

GDD formats

Sadly, there's no standard way of creating a GDD. Every company and team has its own way of doing this, not only in terms of which tool to use to create it but also the content of the document. This varies a lot according to the size of the team (or teams), the type of game, and the general culture of the company behind the game. As a matter of fact, some companies actually believe that there's no need to create a GDD.

A good idea when starting to create GDDs is to check out existing published GDDs of several games. There are lots of them out there, including big, well-known games (such as Doom). Most of them are, generally, Word documents with sections explaining the game systems (such as weapons, inventory, and so on) and the list of all characters, while some can be just a list of bullets explaining certain facts about the different pieces of the game. After that, you can start experimenting with different GDD formats that fit well with your project and your team.

Once you have decided on a good format, you must decide how you will actually write that format, and besides using pen and paper, a better idea is to use all those great digital tools out there. Let's look at some of them.

GDD creation tools

After reviewing existing GDDs, the next step is to pick a proper tool to write your GDD. The first matter you need to take into account is that the GDD will change… a lot… very often… all the time. In the process of creating the game, you will validate or discard ideas you wrote in the GDD, so using a dynamic tool is a good idea. This can be accomplished with any text processor you are familiar with, but there are other problems you need to tackle, so maybe text processors won't be enough.

Your GDD will be big… I mean, BIG, even for simple games. It will have lots of sections, and you will find cases where whole sections will refer to other sections, generating a big net of links between several parts of the document. A good tool for managing this instead of a text processor is using any kind of wiki, which I strongly recommend in cases like this. They allow you to break down the whole GDD into articles that can be easily edited and linked to others, and also, lots of wikis allow you to edit articles collaboratively. There are other additional features, such as comments that allow a whole conversation about a feature inside the GDD, with these recorded for future reference. The Wikipedia page relating to GDDs can be seen in the following screenshot:

Figure 1.8 – Wikipedia site

Moreover, you can also use other tools such as Google Drive, which allows you to mix different types of documents—from regular text documents to dynamic slides—to create presentations, communicating complex aspects in a simple yet powerful medium. Also, Google Drive has lots of great collaborative tools that improve the way several people work on the GDD.

All the tools we described are generic solutions to writing documents in general, and they can work like a charm, but there are other tools specifically crafted for games (for example, Articy Draft).

Now, let's start writing our GDD. I know I said there's no standard format, but let's at least see what every GDD should have, starting with the elevator pitch.

Elevator pitch

Imagine you are riding in an elevator, and on the next floor, an important game investor gets in. They push the tenth-floor button, so you have eight floors' worth of time to convince them to throw money into your pocket to help you create a game. I know this is an improbable case, but in real life, when you are in front of an investor at a round table, you won't have lots of time to convince them. Remember that behind you there's a queue of maybe thousands of developers wanting to do the same, so you must be quick and visceral, and that's why having a good elevator pitch is so important.

An elevator pitch is probably the first sentence you will find in your GDD, and the most important one. It needs to describe your game in no more than two lines and convince the person reading the GDD that your game is a great idea—you need to make them want to play your game right now. Yes, it sounds super ambitious, and it is, but this can separate you from the whole crowd of developers wanting to get some funding for their game.

Again, there's no standard formula to create a successful elevator pitch (we would all be rich if such a thing existed), but here are some tips to take into account:

• You must make your pitch in no more than 10 seconds. Any longer, and you will lose the interest of the person you are trying to convince.
• You must sound like you believe in your own idea; nobody is going to invest in a game you are not sure is the next big release.
• Don't use any technical words (I'm looking at you, programmers).
• Include what differentiates your game from all the other games out there.
• Convince any person close to you to play the game, trying to test it with the most honest person you can find—a person that won't be bothered about shattering your idea into pieces (if your idea really deserves that).
• Practice your pitch over and over again, in front of a mirror, until you can say it nicely, clearly, and in one shot.

Here are some examples of an elevator pitch:

• Imagine yourself slaughtering giant Greek gods with just your arms and your strength until you become the king of Olympus. You will feel that power in [INSERT NAME OF TOTALLY NON-EXISTENT GAME HERE].
• Civilization has fallen. A horrendous infection turns people into zombies. You have the only cure, and must traverse the whole country to deliver it, or humankind will collapse.

Okay—nowadays, those pitches are not super original, but a few years ago they were. Imagine the power that those pitches had at that time; you must find something similar. I'm not saying it's easy but look how just two lines can be the start of amazing experiences, so focus first on writing those two lines, and then the rest of the game.

Now you have gained the attention of an investor, it's time to show them all the gameplay systems and the little details to hype them up further… well, no, not right now. You have just gained their attention; you haven't convinced them yet. It's time to start talking a little bit about your game, and a high concept is a good way of doing so.

High concept

A high concept is a series of statements that further describe your game, but again, in a simple and concise way. Even if you are not trying to convince an investor, those statements will outline the way your game will be defined.

A good high concept can include sections such as the following ones:

• Elevator pitch: As we explained in the previous section.
• Genre: Maybe you are creating something new that has never been seen before, but it will probably be inspired by several other games. Here, you will specify the type of games on which you are basing your idea, so the reader of this document can start imagining how the game will be played. Later, you will specify the differences, but it is better to put a well-known idea forward first to start constructing the concept in the mind of the reader. Also, you can specify here the point of view the player will have in the game and the setting—for example, a Top-Down, Medieval Roguelike Role-Playing Game (RPG).
• Platform and Demographics: You need to be very clear about who will play your game. Creating a game for adults in North America is not the same as creating a game for Chinese teenagers, or games for business people who want to distract themselves for a few minutes on their way back home from work. Those profiles will want different experiences, with different levels of challenge and game session length. They will even use different devices to play games. Taking this into account will help you find the game mechanics and balance that best fits your target audience. It's very common to say that you are creating a game for yourself, but remember that you won't be buying that game, so also think about your wallet when creating the game—for example, casual players of mobile platforms.
• Features: Create a shortlist of no more than three or five features that your game will have. Select features according to the genre you have chosen—for example, you will shoot waves of enemies with a giant array of weapons, or you will level up your ship to improve its stats.
• Unique Selling Points (USPs): This is similar to the features list, but here, you will include the features that differentiate your game from the others out there (no more than three or five)—for example, you can traverse the scene using parkour-style moves, or you can craft brand new weapons using looted materials. Think about how unique those features were years ago.

Again, there's no ideal high concept. Maybe you will find some other aspects of your game that can be highlighted here and add them to the document, but try to keep this all on just one page.

Now that we have discussed what every GDD should have, let's talk about what a GDD may have.

Tips for creating GDDs

Now, it's time to define what the whole game is. We said there's no standard format for GDDs, but at least we can take into account several good practices when creating them. The following list highlights a few of them:

• Readability: Your GDD must be prepared to be read by anyone, including people without game development knowledge. Don't use any technical words (guess who I'm still looking at) and try to keep things simple. A good test of your GDD readability is to give it to your granny or anyone that you see as being as far from gaming as possible, and that person must be able to read it.
• Setting and introduction: Before you start describing the game mechanics, put the reader inside the game. Describe the world, the player character, their backstory, their motivations, and what the main problem is that the player needs to struggle with. Make the reader of the GDD interested in the setting of the game and want to keep reading, to see how they will be able to play the game and tackle all the quests the player will face in the game.
• Gameplay sections: These are sections that break the game into several systems and subsystems linked to each other. Some examples can be Inventory, Quests, Crafting, Battle, Movement, Shops, and so on. You will want to be super specific about every aspect of how those systems work because—remember—this document will be used by the team to craft the code and assets of your game. All the analysis we did in the previous sections of the chapter will be part of the GDD and will be further explained and analyzed.
• Content sections: You will also want to create content sections, such as the ones we previously designed. These can be—but are not limited to—Characters, Story, World, Levels, Aesthetics, Art Assets, Sound and Music Assets, Economics, and Input.
• Share your idea: Before immortalizing your ideas in the GDD and making everyone start crafting them, discuss the different GDD sections before marking them as finished. Discuss with your team, people on the internet, friends—anyone and everyone can give you valuable feedback about your idea. I'm pretty sure you are thinking that your idea will be stolen by some random person on the internet who will release the same game before you—and that can happen—but I'm not saying share the whole GDD, just some details about certain implementations you are not sure about.
• Keep control: Everyone in the team is a game designer—some more than others. Everyone will have ideas and things they will do differently. Listen to them—doing so will be useful, but remember you are in charge and you will have the final say. You need to be open, but set some limits and don't deviate from your original idea and concept. Prevent the famous feature creep, which consists on lots and lots of game systems unnecessarily, and know when enough is enough, especially considering the limited amount of resources we will have when beginning to create games. Again, not an easy task—you will learn this the hard way, believe me, but remember this when that happens (I told you!).
• The game will change: I already said that, but I like to stress this as much as I can. The game will change a lot due to many reasons you will find in the process of creating it. You may find that X mechanic is not that fun, you could have created a better way of handling Y system, or maybe test sessions with players prove that Z level needs to be completely redesigned. Be open to change and pivot your game idea when needed. If you do this the right way, your game won't be as you originally imagined but will be a better version of it.
• Graphics: Use graphics, diagrams, charts, and so on. Try to prevent huge text walls. Remember that a picture is worth a thousand words. You are communicating, and nobody wants to spend valuable minutes trying to understand what you want to say. Improve your visual communication skills, and you will have a focused team.
• Paper prototypes: You can test some ideas in your head on paper before putting them in the GDD. Even if your game is a frenetic "beat 'em up," you can have little paper characters moving around a table, seeing how they can attack the player, and which movement pattern they will have. Do some math to look at how to perfect timing, damage, health values, and so on.
• Regular prototypes: While your game is being developed, the GDD will constantly change based on player feedback. You must test your game, even if it's not finished, and get feedback from players as early as you can. Of course, they will tell you lots of things that you already know, but they will see lots of problems you don't see because you are creating and playing your game every day. They have the advantage of playing the game for the first time, and that is a real change.

After this, we can start creating our GDD, and remember: you will need to find out what format works best for you.

Game design and GDD creation is a complex topic that could be explored in several chapters, but there are lots of books out there that do exactly that, and game design is not the main topic of this book.