Whether you’re a solo auteur crafting an experience that remains true to your vision, or you’re the chief ideas guy of your three man team; every game needs to start with a Game Design Document. Or at least a design document of some description. But what makes a good one?
What is a Game Design Document?
A Game Design Document serves multiple purposes:
- It’s a single place for everyone involved in the project to find information on how the game should work, what’s in the game, potentionally what’s not in the game
- Additionally, everyone involved in the game can be reminded of the vision of the game. The thing that drives people to play it, the feeling of the game. Some consider this the most important aspect of the doc, a reminder that we’re making not just a horror game, but a pyschological horror game that is trying to drive it’s players to depression (hey, don’t judge, I’d play that)
- A box built around the game’s features and functionality. If it’s not in the design document, it’s out of scope. I consider this the most important aspect of the game.
Think of it as the game written on paper. After having read the Game Design Document, I should have a firm grasp of what the game is that’s being made. I can potentionally already see it in my mind.
What file-format is a Game Design Document?
Using an actual document, as in a word processor file, isn’t done a lot these days. I personally still do it for my own games that are small in scope (like a 2-player spaceship shooty pew pew game I’m making), but for larger projects there’s a few different options:
- Stick to the word processor file – This works because you’ve got everything in a single document and people can read it like a document. You might find that the design needs to reference many other parts of the design, which requires you to spend a lot of time structuring the document. There’s also the potentional in much much larger teams that multiple “versions” of the doc start floating around.
- Create and host a wiki – This works because you can add to it when needed, which allows you to be a little lazy with the initial document. It makes internal references a lot easier because everything is just linking here and there. Hosting it online, even behind a login, allows remote team members to always have an up to date version, which even for small teams makes things easier.
This can be extended to a degree and allow team members to comment on pages talking about a feature so that you use it as a sounding board as well. - Markup Document – This is personally how I go about it. I create a markdown document and have doxygen read these files and include it in my projects code documentation. It’s probably a real “programmer” way of doing it, and it probably only works for one-man or potentionally small teams. I think it’s good because all files related to the game are all in one project folder, which works for me as I’ve got 1000 game ideas and it’s hard to keep everything separate. It also requires no additional setup from me because I already need to create text files in my IDE.
Whichever you choose, make sure it’s works not just for you, but for the whole team. If you’re like me and it’s always just you, do whatever you want, but make sure you do it. Game Design Documents are important.
What should be included in a Game Design Document?
Everything. I mean everything. When it comes to developing a game, it’s already hard enough, you don’t want to have to pause that momentum to think about what exactly should happen when the player double-taps the jump button. That sort of distraction is not what you want when you’re trying to Get Games Done.
I really struggle to think of any aspect of the game that shouldn’t be written down in the Design Document first. If you’re in a team, you can get started prototyping as soon as the idea is down, but the game proper shouldn’t be developed until the entire document is completed.
As a one-man developer, I write the entire docuement before even prototyping. This is becaues I usually already know my game is fun (because it’s small scope), or because I’ve already made a prototype to see if it’s worth the effort of writing a design document. Your milleage may vary so you’ll need to see what works for you.
How should I structure a Game Design Document?
However you want. There’s a lot of people who are going to try and say there’s a way to do it and a way not to do it. But honestly, these are the kinds of people who have jobs in the industry that are trying to add some science to a creative art and they’re missing the forest for the trees. Years of working in big corporate has taught me to be wary of these “processes” people.
Having said that; there are a couple sensible rules of thumb, but they could be applied to everything, not just a Game Design Document:
- Be concise – No one wants to read paragraphs about how the idea came up or why something is the way that it is. In one man teams, you already know (unless you need reminding, in which case write it down). In small teams, you all know why something is the way it is. In large teams, it doesn’t matter, you’re all just cogs in a machine and will do what you’re told, it’s the Lead Designers problem.
There are times when you want to be a little more flowery. When describing the feeling of the game, or the look and feel of a level or scene, you want to be a little more verbose. But use the opportunity to mention other games, movies, books etc that have the feeling you want to go for, having a known reference point will help others understand what your high-school poetry level writing is trying to convey. - Be precise – Don’t leave anything up for misunderstanding. It’s very easy for people to read a sentence two different ways. Learn how to read back over what you’ve written and adjust the sentence structure to compensate. Often this will mean that you can’t write in a conversational tone, and that’s fine, this is a reference document first and foremost.
- Be organised – Make sure that if you’re using a Wiki you don’t get lazy. A new page for eveything is probably a good idea (don’t get too carried away though). If you’ve got a lot of power-ups, maybe you don’t keep them all on one page, but give an overview of each on an index page and give each it’s own. If you’re writing it in an Open Office Document be sure to add headings so Navigation will work properly. Doxygen generated docs can make use of /page and /sub-section etc. Be organised so others can find what they need quickly, or so that you can find what you need quickly.
I hope that helps and explains some of the mystery surrounding the elusive Game Design Document and I hope it helps some developers get their game idea into their hands and ready to make reality.