Documentation

Now that we have covered all the main aspects of our game, it is important to prepare them to be shared with others. Through this book you will probably work alone, but in real-life productions you will likely work with others, so sharing your vision is a crucial skill you need to earn in order to create successful games. You will not be sharing your vision only 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 info into comprehensible documents.

Game Design Document (GDD)

This document is basically the Bible 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 answered in the Implementation Plan, and you will deep dive into them. 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 are saying you don't need a GDD because all the ideas can fit in your head, and that can 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 be easily fixed instead of discovering them when coding the entire game.

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

GDD formats

Sadly, there's no standard or unique way of creating a GDD. Every company and team has its own way of doing this, not only in terms of which tool they 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 to start creating them 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 a list of all characters, while some can be just a list of bulletpoints explaining certain facts of 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 actually decide how you will write that format, and besides using pen and paper, a better idea is to use all those great digital tools out there. Let's see some of them.

GDD creation tools

After reviewing the existing GDDs, the next step is to pick a proper tool to write it. 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, and maybe text processors won't be enough.

Your GDD will be big I mean, BIG, even for simple games, so 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, those being extremely useful tools that I strongly recommend using in these cases. 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 this 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 media. 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.

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 in a building taking an elevator, and on the next floor, an important game investor just gets in. They push the tenth-floor button, so you have eight floors of time to convince them to throw money into your pocket to help you create the game. I know this is an improbable case, but in real life, when you are in front of an investor in a round table, you won't have too much 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 all would 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 convincing about 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.
• Iterate it until you can 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 it, 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 NOT EXISTING 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 that you have gained the attention of an investor, it's time to show all the gameplay systems and the little details to them to hype them up further well, no—not right now. You just gained their attention; you haven't already convinced them. It's time to start talking a little bit about your game, and a high concept is a good way of doing so.

A 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, Top-Down Medieval Roguelike role-playing game (RPG).
• Platform and demographics: You need to be very clear about who will play your game. It is not the same creating a game for adults in North America as creating a game for Chinese teenagers, or games for business people who want to spend a few minutes distracted on their way home, on the bus. 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 fit 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. Put the features you will be using from the genre you choose—for example: you will shoot waves of enemies with a giant array of weapons. 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. 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 added 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 previous analysis we did in the previous sections of this chapter will be here and will be further explained and analyzed.
• Content sections: You will want to also 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 on 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—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: know when enough is enough. 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 far 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 created a better way of handling Y system, you think it's worth the time to change already existing parts of your game after a test showing that the players don't understand how to use a brand new key feature in your game, and so on. Be open to change and pivot your game idea. 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 an image 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 the perfect timing, damage and health values, and so on.
• Regular prototypes: While your game is being developed the GDD will constantly change based on players' 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.

Game design and GDD creation is a complex topic that can 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.

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