We are reader-supported. Purchases made through links on our site may earn us a commission. Learn More.
Game design documents have been an industry standard for a long time. More recently, arguments against the game design document have begun to surface.
“It becomes obsolete immediately after it’s published.” “No one on the team likes using it.” “Nobody updates it and that leads to serious confusion.”
While there is some merit behind these arguments, a game design document can be very helpful if it’s done correctly.
This guide takes a look at the benefits of a game design document, and how you can put one together for your next game design project.
If you and your team are building a simple game, you could probably get away with storing the concept in your head. It’s small enough, and you know it well enough, that every detail can be safely contained in your brain.
You and your teamwork in the same space all the time, and you’re constantly communicating any small changes to each other. Since the game is so simple, you don’t need to bring on any new help. You don’t have to explain the game to anyone because your team already knows the details as well as you.
That’s a reasonable situation. Your team sounds like it can get away without a game design document.
But let’s say you’re working on a game like Halo.
All of a sudden, the concept gets way too complicated to try and keep in your head. Instead of a detailed breakdown, you describe it more like this:
“Humans are on the frontier of space and have to fight aliens for the control of an ancient super-weapon planet that could bring about total annihilation for organic life.”
The simplified version of the game is easy to understand, but hardly covers everything a game developer would need to know about the game.
If you explained Halo–using that line–to ten different people and told them to build the game, you’d end up with ten different games.
And probably not one of them would have made the super-weapon planet a Halo.
This exposes one of the primary functions of a game design document–it acts like a guide to keeping everyone on your team on the same page.
It’s a document that should be thorough enough and specific enough to let a team of people build a cohesive, consistent game. It is the kind of document that will inform every decision your team makes. It takes out most of the guesswork.
Instead of having ten different versions of a superweapon planet, the document would show that it’s an artificially-created ring planet. Not a death star. Not an enormous ship. A ring planet.
The game design document includes way more than just the setting. It encompasses everything. The plot, the characters, the core concepts, the game mechanics, etc.
A game design document can be a lot of work to iron out, but you’ll find that the upfront effort can be worth it in the long run, especially for complicated concepts.
Sometimes you’ll have this great idea for a game and the more you think about it, the more you want to add to it.
Imagine Skyrim–“there should be dragons!” could quickly become “there should be dragons and the player should be able to ride them!”
And that could quickly become “there should be dragons and the player should be able to ride them and fight other dragons in the air. And destroy towns. And lay waste to the castles and temples and mountains and forests in the game.”
All of a sudden you have a very different game.
Are we saying you shouldn’t let your imagination run wild? Absolutely not. Are we saying that you should set some limits? Well, only if you want to finish your game….
A game design document acts like both an anchor and a compass. If you find too many ideas creeping into your game, you can go back to the game design document and refocus. It’s your reference point. Your northern star.
If the core concept of your game is “A hero with dragon blood, who can speak the dragon language, fights undead and the returning dragon scourge to save his home in a medieval time period” you can return to that idea and say “ok, space dragons and castle destruction are cool ideas, but they aren’t a core part of the game I’m trying to build.”
Things like the dragon language and the animations for the dragons he’ll fight would be more important to the game.
More like Reign of Fire (great movie, how has a great game not been made from that concept yet?)…
The game design document helps you form a finite scope for your game. You can set some parameters to keep the project manageable. You can map out things like plot, and characters, and locations, and at a certain point you can decide the game is big enough.
As you work through something, it’s easy to get caught up in it and forget why you’re doing it in the first place. It’s times like these where having a compass is vital.
As you work through iterations of a concept, the changes can get to the point where you forget the “why.” When you lose sight of the original purpose, the game design document can put you back on track.
Now, just because your game design document should be thorough doesn’t mean you need to have it all described at once. This document is your map, but it’s a map that can grow and change with your game (like the Minecraft map).
The core concept, the major tenets, and what you’re trying to accomplish can be outlined in the beginning. But listing every single gameplay feature is unrealistic, especially for complex games.
These are the things you can add as you work them out. The game design document gives you perspective and context. It should provide a firm platform from which you can explore different game ideas.
A puzzle is a lot harder to put together when you have six puzzles’ worth of pieces and no picture to look at for reference.
When it’s done right, a game design document gives you both a picture for reference and only the relevant puzzle pieces.
If you constantly update the document as you progress, you’ll always understand the changes you’re making. Any changes to the game should be tracked through the game design document, which means you can revert back to earlier iterations if something doesn’t work or your idea creep took you too far.
If the game design document is updated properly and frequently, it can lead to less frustration.
A game design document takes time to update. But it can save time in the long run if your team members know how to spend their time. Time isn’t wasted on parts of a game that don’t belong.
You should start with the brainstorming phase. This is the fun time where you put your wildest dreams down on paper.
Write everything down. Let it sit for a day. Then come back to it.
See what still sounds great, and what doesn’t sound as fun now that it’s out of your head.
This is the phase where you decide:
In this phase, you don’t need too many of the logistics sorted out. You don’t need the mechanics mapped out.
You’re working from a mostly conceptual standpoint.
If you know you want the game to include certain mechanics, you should write them down. But if you’re not sure about mechanics just yet, then don’t worry about them.
If you’re working with a team, you’re going to want to enter the discussion phase next. Everyone will bring something different to the project, and getting together to talk about the project can bring out the best in your unique team.
You might get a better sense of what’s possible from your programmers. You can start discussing early prototypes for the game.
With prototypes, you can figure out what’s working and what isn’t. As you finalize these decisions, you can add them to the document. You’re putting together a strategy guide that everyone on your team can follow.
You won’t always be able to test everything before you decide to add it to the document. This is where you should be careful–if you have a game design document that’s based too much on untested ideas, you can run into trouble.
Say you’re building everything around a game mechanic or concept that doesn’t work out. You’d have to go all the way back to the root of the problem.
That’s a lot of potential time and programming wasted (this is worse than forgetting to save even once while wandering the wilds of Morrowind for three hours and having the game freeze).
A game design document is at its best when it’s verified. Prototype the major elements and build from there. You wouldn’t build a house on a flimsy foundation, so you shouldn’t build a game on one, either.
At the heart of great games are great ideas. Who knows what the best part about the game will end up being? It isn’t always an idea that comes up at the beginning of the game’s development, that’s for sure.
Encouraging new ideas is a worthwhile endeavor throughout the entirety of your game design process. You don’t really know what’s going to work well before you try it.
Fueling creativity can keep morale high and lead to excellent games. It can also lead to surprise last-minute additions that end up being one of the game’s best features.
You just never know.
While it’s good to be flexible at some points during the creation of your game development guide, there comes a time where you need to “publish” it.
Like a novel, or a strategy guide, or a game itself–at some point, it needs to be finalized.
It shouldn’t be changed anymore. This is the end of the Game development guide’s “life,” so to speak. It has gone through its chrysalis phase, and it has emerged as a butterfly, never to change again.
This saves a lot of effort and frustration at the end of the game’s life. The art is cohesive. The game mechanics are understood and finalized. The plot, the characters–everything matches the information specified in the document.
And there aren’t a landslide of last-minute changes to every part of the game–the game design document is the dam that’s supposed to hold back that flood.
Your game design document isn’t customer-facing–at least, not at first. By this, we mean that the document is specifically for your team, first and foremost.
So write like it.
Use technical, descriptive language to describe elements of the game in detail. This will contrast quite a bit with the language you’d see on the back of the game box in the store.
“Drive fast cars and blow things up!” Might sound cool to the 14 and 15-year-olds you’re marketing your racing game to. But for your design team, it doesn’t provide enough detail to support a cohesive development effort.
Instead, you can describe the types of cars, the environments, how things blow up, what “things” blow up. The physics behind the game–the list goes on.
Language is an important element to consider as well.
You want this game design document to be useful, not boring.
Because no one wants to read a boring manual. If you make the game design document a reflection of the fun behind the game and personality of your team, your team will be more willing to reference it. No one wants to open a document that’s going to suck the fun out of them.
A game design document can be a hefty document, so making it palatable for the users will make sure it gets used.
You can keep the language clear and concise and have room to make it enjoyable, too. Keep the passion alive!
The whole point of the game design document is to keep everyone on the same page. Words aren’t always the best way to do this, so don’t be afraid to supplement your explanations with visual material.
Concept art, for example, plays a vital role in the game design document. Storyboard art can help describe scenes or the feeling of the game.
A game design document isn’t helpful if none of its parts come to fruition. Use the document to prioritize tasks–what are the most important elements to figure out now?–the ones that will make the rest of the game easier to build?
Set deadlines on these tasks.
Keep the changes updated in the document–you might want to put everything you replace at the end of the document. You could also put the outdated info into a separate document.
It’s good to keep track of the progress and changes. If you need to revert back to something, you have the text trail to see where things went wrong and what you can do to restore an earlier idea.
The Game design document becomes a clear list of “next tasks” while also serving as a way to keep everyone moving forward towards the same goal.
Ultimately, the game design document is supposed to help you and make things flow more easily. It shouldn’t be a burden or a “chore.” It might not be the sexiest part of game design (we’re still not sure one exists), but it is a worthwhile endeavor (at least on paper).
It’s one more tool you can use to design the game you actually want to build. Happy documenting!
Very simply, a game design document is a kind of outline of a game design project in which the leader or director writes up for the development team, allowing them to follow a game design template to accomplish design goals better.
Game design documents can be exciting and extremely efficient ways to get a better idea of what your game or project will be about. This includes all of the pertinent info: demographic, marketing strategies, platform, and more.
Before you begin or show your game design template to others, you need to familiarize yourself with the team undertaking the feat of developing. This seems obvious, but meeting and collaborating with others will only make it easier for you to design games and projects further.
This way, you are all on the same page when it comes to all the little details. The last thing you need is to work with strangers, breaking down communication, and making your game a lot harder to work out.
We are all familiar with filling out job applications and sometimes cover letters. You need to convince the potential employer that you are best for the job.
Think of the title page as the beginning of the ‘cover letter,’ but for game design. For example, a title page will include the title of the project, like ‘The Witcher.’ The title page will also include many other aspects listed below.
What is your concept? Is it a puzzle game in which an alien must find his way home? Or is it a game like Outlast in which the main character needs to find crucial information in an ‘abandoned’ hospital? This is where you outline what the main idea of the game will be.
What genre is your game? Is it a first-person shooter? What about an RPG?
This is where you write down your aims in terms of what the game will turn out to be. This should be a breeze, as you should have a pretty solid idea of what you would like to develop.
The game mechanics refer to different aspects of the game. Very simply, they are the visuals, sounds, animations, physics, and more.
For example, think about specific mechanics from games like Grand Theft Auto V. A mechanic would be stealing cars to get to a destination, or committing crimes, namely bank heists to further the plot of Michael and Trevor, exhibiting their distrust with one another.
It is very general and could be a lot of fun to list. However, you need to be extremely specific, as this could muddy the waters with individual developers. Be specific and lay everything out there.
Delving deeper, you need to flesh out the descriptions of the story, setting, and who the characters will eventually be. Back to Grand Theft Auto V, the story revolves around three characters, Michael, Franklin, and Trevor.
The story is that Michael is a former bank robber gone into the witness protection program. Trevor, his old partner, soon discovers Michael is still alive, and they get back into heisting.
What will your story be? Will it have multiple character arcs, or just one?
You can partake in the ‘hero’s journey’, or you can subvert gaming and story tropes altogether by making something new and refreshing.
In GTA V, these characters all have distinct personalities, and you must do the same for your characters. What are their wants, needs, and motivations?
This is where you fully flesh out our protagonists, antagonists, ancillary characters, and more. This is where your roster of loveable, (or perhaps not so loveable), characters will go to grow and develop into finished products.
This is where your world can take shape. In GTA V’s case, the world is that of a fictional reality, more specifically Los Santos, a west coast city based on real-life Los Angeles.
My personal favorite scenario is when game developers create a new, unique fantasy world for their games to take place in. It shows a lot of creativity and ambition.
However, that isn’t to say that games that take place in established universes aren’t good too. In fact, when they are good, they’re really good, as they have to be new and innovative in an already established timeline and setting.
Your target audience is the main gamers that you are making this for. For example, The Witcher is geared mostly towards young to middle-aged males who enjoy story-driven RPGs.
Call of Duty is geared towards a wider audience who enjoy high-octane first-person shooters. Knowing your audience whittles down a lot of grey areas and defines your project better.
This can be a real fun one. Break this down into two parts. This is where you outline what world your game will take place in.
Is it in the real world? New York City? Or is it in your own, unique fantasy world? Building a fantasy or general world may be more labor-intensive on your brain, but it is your chance to really flesh out what world the characters will interact in.
After creating lore (if you so choose), you need to focus on the actual, physical levels. Will they take place in dusty, abandoned corridors? How about a bright city street? You need to outline where the story’s action will take place.
Outside of the basics that you have outlined thus far, this one can truly make or break the feeling of a game. Too many times have I seen gamers complain about the terrible user interface, or UI.
This is the display that gamers will use and see during their playtime. These are menus, health bars, advice panels, tutorials, and more. An easy to use user interface will score major points with gamers, trust me.
I once saw a review for a game that was praised for gameplay but overall given a more negative review for the poor user interface. Beware!
These are the aspects of game design like which game engine to use, what programming language to utilize, and more. This is where the coders shine. Will it use JavaScript? C++?
These are actually the assets used in-game. For example, assets can be specific objects and in-game items. In half-Life 2, a gaming asset would be something like Gordon Freeman’s crowbar, or the gravity gun.
Think of this as a regular progress report. You can even add some milestones for you and the team to complete to get an idea or roadmap of the project better.
For example, a milestone can be completing the outline of a dungeon or developing a boss character. A particularly useful milestone is actual game completion and launch date!
This is also where you will get feedback from your team. This is also where you should go through all of the progress so far. Make sure to communicate your ideas about how things are going thus far.
Hopefully, you can clear a path towards creating a game design document by creating or following a game design document template. Remember to be specific with certain aspects of the game design document, as the more precise, the easier the team can communicate ideas with one another and turn out a great product that you can be proud of.
