Video games are complex.
The interactions between thousands, if not millions of lines of code, assets, and audio components weave a vast network of items that all have to work in harmony for a game to function. Those interactions don’t happen by coincidence though, and there is a good chance that one, or a few, or the entire team of developers spent countless nights fretting over how to put everything together.
From the massive, multi-hundred person teams at AAA studios to the solo indie devs, an insane amount of effort goes into making the games we enjoy. Even more effort goes into making sure they work as intended.
That begs the question then, how do they do it?
Well, part of it is that they’re masters of their craft. They’ve been honing their skills over the years and moving past previous projects and games that never quite landed right. There is a lot to be said about the tenacity required to make games, let alone successful ones at that.
If we begin to look past the individual attitudes and abilities needed to survive game development, we begin to see the tools used to bolster the chances of success. Those that immediately come to mind are the ones used to literally make the games, your Unreal Engines, Unitys, Blenders, Mayas, and so on.
But if we take one more step beyond, we’ll see the tools used to ensure that those individual pieces actually fit together. Key among them is the Game Design Document.
The G.D.D., as we’ll call it from here on out, contains the outlined structure of the game you’re trying to make. If there is an idea that is part of the game’s identity, you’ll find it outlined in the G.D.D.. What you won’t find in a G.D.D. are the actual lines of code, assets, or sounds themselves. Instead, you’ll find everything you need to know in order to make the code, art, or sounds.
However, the issue with a G.D.D. is that it appears like a monumental task. When someone starts their game development journey, telling them to outline every single concept and mechanic in their game can seem daunting, if not outright impossible. It’s no different than telling an author to write a first draft from scratch, or a screenwriter to write a treatment from a concept they had in their head.
What is often overlooked though, is that a G.D.D. can be whatever you want it to be. A G.D.D. is a document that is created by a developer to assist them in creating their game. There is no standard that you have to meet in making it.
However, there should be some basic functionality that all G.D.D.’s have. A useful G.D.D. should be able to:
Keep track of a game’s moving pieces,
Be used as the ultimate point of reference, and
Indicate where a game’s natural boundaries lay.
When creating a G.D.D., it’s best to keep these functionalities in mind. If you do, you’ll have a better grasp when you move from pre-production (or exploration) to actually developing your game.
Organize the Chaos
Game development is a fast-moving process. For my fellow neuro-divergents, you understand the pain of hyper-focusing on one, really cool idea before you get distracted by a flickering light and then having that the cool idea completely vanish. Imagine trying to make a whole game under those conditions.
Fortunately, the remedy to our situation is simply writing the idea down as you develop it. It doesn’t have to be fully fleshed out, but as long as it’s enough to make you remember what you were thinking, it’s good enough. When you get more accustomed to this practice, organizing your thoughts into their relevant sections pays dividends after a period of time. Sooner or later you’ll end up with an over-abundance of ideas that can easily kick start the actual development process.
Momentum is an often under-appreciated concept when it comes to moving a project through it’s lifecycle. While it might feel great to finally stop concepting, if you’re constantly searching for a note that’s vanished, are you really developing? A G.D.D. prevents you from losing momentum by (ideally) being easily accessible and tidy enough to reference any information within a couple clicks. But honestly, your information being accessible is the key aspect.
With all of the information in one location, the development process can then be realistically evaluated.
Initially that evaluation will be whether the game itself is worth creating. Not every idea is meant to be brought to fruition, and there are many first drafts of ideas that definitely shouldn’t see the light of day. The flip-side of this is determining whether you can realistically make the game. I hate to dip into cliches, but unfortunately you, as a solo indie developer, are not going to make the next World of Warcraft. But that cool platformer is probably really doable.
Once you’ve figured out whether you can make the game, now you need to determine how you’re going to make the game. A concept is all well and good, but actually making that concept is a whole other process. Fortunately, this is where the “obvious” tools come into play. If you’re looking for a simple game with simple mechanics and simple gameplay, the options are endless. Unity or Godot might suit you perfectly, and come along with a plethora of learning resources to help you out.
As you scale upwards in complexity and difficulty, your options begin to narrow and you have to look at whether the tool required for the job is feasible itself. Unless you are a crazy person wanting to create their own engine, Unreal is likely the biggest and baddest you can get. But keep in mind that with Unreal, you’ll be doing the heavy lifting yourself. While there are assets and learning content readily available, Unreal is a beast like no other.
These are the considerations that you need to think through when making a game. They are also the considerations that a G.D.D. can help solidify once you’ve decided on a course of action.
The earlier you can keep yourself organized, the easier of an experience you will have.
The Ultimate Reference
So far we’ve talked about the Game Design Document as it relates to the decisions you make and how organized you make yourself, but how about when it comes to a team environment?
It gets even better.
When I say that a G.D.D. should be in an easily accessible place, that concept carries over to any potential teammates as well. Collaborative game development is a process of combining everyone’s individual ideas into a cohesive product. Those ideas need to be easily accessible so that everyone ends up making the same game. An artist that envisions a gritty, realistic survival game isn’t going to make the appropriate art for a happy-go-lucky resource sim. While it seems obvious that this is the game you’re making, it can be surprising how two team members can have completely different ideas of what they’re making.
Ensuring that each team member has a similar vision of the game they’re making prevents a lot of conflict down the road. If everyone is in agreement with a G.D.D. before development starts, it’s entirely possible that future issues could be resolved by simply referencing the G.D.D. An accessible G.D.D. allows team members to voice concerns around areas they are more knowledgeable in. An RPG with a heavy focus on cut-scenes and dialogue might necessitate changes if the artists aren’t confident in producing those components.
Essentially, it boils down to utilizing a G.D.D. to ensure that your team is organized and in agreement as to the game you are making.
If done correctly, then the scope of the game should be possible to roughly estimate by the time a G.D.D. is made. While a G.D.D. isn’t an official schedule, the effort you put in should allow you to determine how long a game will take to make. Larger games will have a larger G.D.D., which likely means a longer development time. If you’ve found yourself with a larger than anticipated game, maybe you reassess with your team and figure out what can be trimmed or moved into the “nice-to-haves.”
Conversely, not fully developing a G.D.D. can leave you scrambling in development. If there is ever a concept that you think you can leave until you come to it, think again. Unless you rigorously evaluate that concept, you might find yourself at a road block that requires you to stop and reassess whether it’s feasible. As I mentioned above, momentum is key to making quick and reliable progress. Stopping to do the work you should’ve been beforehand is the fastest way to lose that momentum.
Steady Boundaries
Finally, a good Game Design Document subtly shows you where the boundaries of your game are.
A G.D.D. is most useful when used to hone development before it begins. Knowing what a game needs is the first step to making it, but the next steps are all about determining how much of one aspect is needed, how long you can spend making it, and where one aspect ends and another begins.
I had mentioned in my article on what makes a good game that part of a game’s “greatness” is how well it captures a specific fantasy. Part of the process of enabling a core fantasy is elevating the elements that support the fantasy while de-emphasizing those that don’t. This process can certainly be done in the actual development of the game, but its possible (and even preferable) to accomplish it almost entirely in pre-production.
If not predetermined, the core fantasy of a game becomes readily apparent as you fill out a G.D.D.. As well, the elements that don’t align with a core fantasy will become glaringly obvious. While you might eventually come to the realization that a particular element doesn’t belong in a game at some point in the development process, catching it beforehand means you can save resources that otherwise might’ve gone to waste. Resources not wasted can be put towards areas that need them.
It’s also worthwhile to use a G.D.D. for assigning task priority, determining what aspects of your game need more time or resources. If you find that each element in a G.D.D. contributes to the core fantasy, but that some will require more effort and care than others, then your G.D.D. has determined your list of priorities for you.
When working in a team environment, assigning priorities enables you to divvy up tasks quicker and more efficiently. If you know that a specific game element needs a certain amount of resources allocated, then team members can be assigned quickly and the task can be evaluated and worked on. If your initial estimates were off, then you are able to better assess and adjust as needed.
The use of a G.D.D. extends beyond pre-production, allowing teams to quickly make adjustments and find spots they need to improve upon based on their initial plan. But it’s also important that a G.D.D. be a living document, that changes are allowed to happen in order for the development to progress as easily and fast as possible.
This is the balancing act that happens once the realities of development set in. Adhering to an initial vision for the game might not be feasible once you’re three, six, or even nine or more months into development. Being able to anticipate future road blocks or changes might be possible with a thoroughly thought out G.D.D., but can never be entirely accounted for.
Finding that balance is going to be an individual task that takes place each and every project. But if you place your trust in a well-planned G.D.D., that decision should become easier and easier as time goes on.
Outro
A Game Design Document is a multi-functional file that dictates what, how, and when a game and it’s components are created. The amount of effort put into making it as clear, cohesive, and comprehensive as possible returns an equivalent amount of clarity, ease, and progression when you begin development. Creating a G.D.D. allows you and your team to outline and organize your game together, ensuring that everyone is both excited for and able to develop the game as you envision it. Finally, relying on a well-planned G.D.D. provides additional support and guidance for you and your team as you progress through development.
I am still learning the ins and outs of creating design documents. I would’ve provided more concrete examples of items to include within one, but I wouldn’t be able to honestly suggest them. Instead, I found it more constructive to outline the reasons for creating a design document. Hopefully I’ve been able to either convince you to use one, or reinforced your belief in its ability to assist everyone who works on a game.
Next week is MipMap’s 25th issue! Its not much, but I like to celebrate milestones as they come. As for what I’ll be discussing, I’m not entirely sure. Perhaps I’ll put together the insights of the past couple of newsletters and outline a game design document for a hypothetical game I might make. Stay tuned to find out!
In the meantime, stay comprehensive!
- Adam