An independent game developer builds their game around their own personal ideas, or ideas inspired by the world around them—but all those ideas still exist only in their head, in a hazy, unclear form
Ideas that remain unclear until they’re turned into visible techniques or artwork that both the developer and others can actually see
The problem grows bigger if the developer has a friend or a team working with them—at that point, everyone needs to share the same vision and the same direction
And simply listing requirements isn’t enough. Saying “what we’re going to do now is 1, 2, 3” isn’t enough, because that’s just casual talk—it won’t answer the questions that come up, and more importantly, it’s undocumented, so it can easily be forgotten
The solution to all these problems is what’s known as the GDD, the Game Design Document—though the word “Design” here doesn’t refer to art direction, but to building the game itself. So this article is about:
The Game Build Document
It’s a document where everything related to building the game is written down—development, graphics, audio, story, and everything needed to reach a finished game that can be played without issues
The document provides a roadmap for the whole development team, and even if the developer is independent with no team, it still helps them identify tasks they hadn’t realized they needed to think about
For example, if your game is just an adventure game, you might focus on the story and the way progression works—but once you start writing the document, you’ll find you also need to define the world, define every major character in the story, define the audio direction, and even define how the UI is presented
To get a good document, you should include examples of what’s required. If the game is an action game, are the characters serious or cartoonish? Here, you should include reference images of characters similar to what’s required
Is the Document Actually Useful?
How important the document is depends on your game. If it’s a small game you can develop in under a month, you don’t really need one, and even for a game you can develop in 3 days, you could write a document in the form of a mind map—though sometimes it’s genuinely not useful at all!
So it’s better to first understand its importance before deciding whether it’s useful for you or not. Its benefits revolve around 3 points, as follows:
Unifying the Vision
I mentioned unifying the vision earlier in the article—imagine if the team didn’t share the same vision. You might find that the environment designer drew it in a gloomy style, while the character designer gave the characters a tone that doesn’t fit the overall gloomy atmosphere at all
Even as an independent developer, you might discover you never defined how the player reaches an important item in the game, meaning you’ll have to rebuild a level just because you didn’t unify your own personal vision from the start
A Roadmap
By defining the final shape of the game and what’s required from each department, you can easily build a roadmap that lets every team or individual know what to do next
This also makes it easier for management to direct that work and set priorities, since there may be tasks that don’t need attention early on. And even without a team—just an independent developer—you can now identify the most important things you need to do
Easier Funding
The game can be pitched to publishers, companies, or development studios to back it and provide the investment needed to finish it, market it, handle legal matters, and everything else involved in the production process that independent developers often can’t achieve on their own
But to reach that stage, companies need to fully understand what they’re dealing with. Explaining the game’s idea in a few simple sentences isn’t enough—there needs to be a clear vision for every part of the game. And that’s exactly the document’s role
That’s why companies require this document, to make sure the game’s developers are serious about their work and know what they’re doing
How to Write a Game Design Document
I mentioned earlier that even for a very small game, you might write the document as a mind map covering the most important aspects of your game, and that still counts as a document
But what matters now is how to write a professional document, one that covers everything about the game, not just the important parts. Writing it isn’t the job of one specific person—it’s written by all the partners/developers together
The document can be written in several stages, and you can even write multiple documents: a small one that just outlines the core ideas, which can be shown to friends, family, and players, and another functional one that includes everything needed to finish the game
The best approach is to start by writing a small amount of content in each section, then present it to the team, then start turning it into a functional document to unify the vision, and finally review it all to make sure every part works for everyone. You can always revise it later during development if needed
Now it’s finally time to go over what the document should contain. It should be noted that every game has a different approach, but I’ll go over the most important topics that are recommended, which the vast majority of games need
Document Contents
Game Overview
Here you present the core idea of the game and what sets it apart from other games, and briefly cover the rest of the game’s branches, as well as its target audience
You should also define the game’s genre with examples of other games that resemble yours (mentioning those similarities). Finally, state the platform the game is aimed at (phone, computer, or other)
Story
Not every game has a story, but if your game does, you should describe it here and identify the main characters—you might even need to write out the backstory of both the main and side characters
And if the game takes place in a fictional world, why not describe the features of that world? What new species exist in it, and what does its environment and terrain look like, or even its history?
You can start with a short general summary, then begin writing the story as if it were a novel, and even write it the way it’ll be presented to the player, including any unexpected plot twists
And if your game is small with no real story, you can at least write a very short one
Gameplay
Gameplay is what defines how users will play the game, and it’s also what determines the style of progression within the game
If it’s an action game, is it a shooter or does it use swords? If it’s a puzzle game, what kind of puzzles are there, and how can the player solve them?
It should also be noted that if the game relies on physics to some extent, there’s a “Physics” section right after this one, which defines how objects interact with each other
This section should also describe the user’s inputs (keyboard buttons and controller), so the development team knows how the user controls the character
Art and Audio
Art and audio each have their own section, and art can even be split into two parts: characters and environment, while audio can be split into background music and sound effects. Personally, though, I’ve grouped them together here since they follow the same logic
Here you start outlining the game’s art and audio direction, either with ready-made references or by designing those references yourself. What matters most is that everyone can finally picture what the game will actually look like
Level Design
If your game relies on multiple levels, it’s best to describe how those levels are built—are they small or large, what core elements exist in them, and so on
And what if it’s an open-world game, or one where the world is generated randomly, like Minecraft? In that case, all of this needs to be defined, and a decision must be made about how the game world and its levels are built. This section handles those matters
UI
The buttons, menus, and windows the player sees and interacts with, such as settings pages and the HUD. Since these interfaces don’t need to follow the same art style as the rest of the game, they can be placed in their own section
Here, you shouldn’t only describe the art direction of these interfaces, but also what interfaces exist in the game. Is the settings button inside the game itself, or inside a menu that appears when the game is paused? This is what’s known as UX, user experience
Technical Requirements
What engine is needed to make this game, and what hardware can run it? Does the game include AI, and does it need servers because it’s multiplayer?
This section covers the technical side and the requirements for developing the game—mention the hardware, technologies, tools, programming languages, and even the plugins for the core software, and everything the technical team needs to finish the game
Summary
This has been just a brief introduction to the game design document—I explained what benefits it provides, how it can help lay out a roadmap for the development team, and also how it helps independents secure investment
The document holds a lot of content related to developing the game, whether that’s laying out the story, defining the gameplay style, defining the art direction, and many other development-related matters
In an upcoming lesson, we might go over some real examples of these documents, along with ready-to-use templates