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.
Create a Reference for Your Entire Team
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 team work 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 keep 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 super weapon 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.
A Finite Container for Your Ideas
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.
Reign in the scope
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 site of the original purpose, the game design document can put you back on track.
Step by Step
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.
How to Put One Together
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 why you’re making the game. What the game is. What the point of it is. And what you’re trying to accomplish.
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 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.
Who Should You Write to?
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!
Don’t Forget the Why of the Design Document
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.
Once it’s Built, Set the Deadlines
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!