10+ ways to write a better game design document from a game dev student.
GDD stands for Game Design Document and it is a vital part of the planning and development of any game. Since there is no industry standard, there are many ways of creating one and this makes crafting your first GDD a difficult process that is full of possibility and uncertainty. The needs for your document will likely change between projects, platforms, and clients as well. With that said, here are 10+ sections that I like to use that may help you write a more effective GDD.
Scott Rogers' book Level Up! The Guide to Great Video Game Design states that "... even though writing a GDD takes lots of time and effort, no one on your team wants to read it" (Rogers 85). So how do designers get around this? Rogers' suggests using diagrams, storyboards, or drawings to communicate ideas and spark interest which are all great options.
I also recommend using subsections throughout your GDD that are tailored to individual roles. Imagine, for example, that you're creating a new enemy AI. As the designer, you should communicate to your team how this enemy behaves, where it spawns in a level, what sounds play when it attacks, and so on. That's all programming related. You also need to describe what sort of vibe it gives off through its body language and color scheme, detail any particle effects, and consider what actions it does that need to be animated. That's stuff for the artist. Artists don't need to read through all the technical jargon and programmers don't need to worry about how an asset is going to be drawn. My solution is to write the two sections separately using the prefixes "For the programmer:" and "For the artist" so they can always ctrl-f to find what's most relevant to them.
The queue is the place to note any errors or inconsistencies in the document and mark down thoughts for discussion at team meetings. All team members are actively encouraged to review and add to the queue (and all other sections of the GDD). This helps designers track any issues that occur as the document grows and keep data clear and consistent. Additionally, it provides the designer with a place to review commentary on the game design prior to group meetings and preemptively look for solutions.
A possible alternative to this section, or perhaps a partner for it, is the idea dump. This is a place to throw any and every idea that the team thinks up. There will always be ways to improve your game and its important to get those thoughts out of your head and onto paper, even if there isn't always time or aren't always resources to implement them. I prefer to keep this as its own document and then transfer ideas over once the team agrees to them, but this section can find a home inside the GDD as well. The queue is for resolving inconsistencies in more finalized designs while the idea dump is for tracking unfinalized designs.
A GDD brings together important information needed by all members of a development team into one place. Having dozens of documents spread throughout multiple folders, even when done neatly, can become difficult to track. At the same time, overloading the GDD with fluff and filler means that teammates spend valuable development time scrolling through blocks of unnecessary design text. There's a delicate balance to strike. That said, it might make sense to track your bugs elsewhere, but I have personally found success in tracking them within the GDD.
While the programmers will be the ones fixing bugs, they won't be the only ones finding bugs. Designers or artists may find ways to resolve bugs that require less time and effort than an outright bug fix. Putting the Bug Report in the GDD will increase the chance that your teammates see the changes noted there as they look for instructions making their next asset or feature.
The game overview section is a place to provide a high-level overview of the game, essentially an extension of the original pitch. What's the game about? What is the narrative? What is the main mechanic? It should be descriptive and straightforward. Teammates can always return to this section to make sure the original vision of the game is being adhered to (which is also the purpose of the document as a whole).
As the largest section in the GDD, this is the place to describe how the game will play, feel, and engage. What is the core game loop? What are the win/lose conditions? What are the core mechanics? Describe your health system, enemies, obstacles, and the systems that govern them in detail. Start each section with a brief, designer-focused description of the mechanic or feature and then get into art and programmer specific info using the ctrl-f method discussed above.
If I learned nothing else in during my education in game development, I learned the importance of tuning variables. These are any aspect of the game that can be tweaked to change the experience. In a racing game this could include the time it takes for nitrous to charge, the number of AI competitors in a race, or the time limit of a lap. Other common examples are the number of bullets in a weapon, character jump height, and the cost of upgrades. All of these are variables that might be raised, lowered, and otherwise adjusted to make an experience more appealing and responsive. These are a must for any design doc. These can be their own section or embedded into the Gameplay section.
Having a healthy knowledge of video games, young and old, is important for communicating ideas to your teammates. It helps to have a common point of reference for any concept in discussion, especially because terminology in the game development community is still not fully agreed upon or standardized. Some people call it juice, some say game feel, others still use the term feedback. Either way, if everyone on your team has played Peggle, then everyone gets the point. Not only can referencing other games help create common terminology (or overcome the lack of it), but teammates can point to them to reference art style, music, mood, or scope. All of these things become more concrete when there's a common reference point.
This section of the GDD, all the way at the bottom, is used to track changes to the document itself including additions, subtractions, and alterations. This helps designers remember what issues have already been raised, considered, and dealt with. Without this log, its easy to forget if particular features have been tested or if certain solutions were implemented. It might not seem like you would forget a solution you've already tried, but after months or even years of development it becomes more and more likely. This can also serve as a way to reliably restore older iterations of your game should the need arise. I use a Date: Symbol: Change Made format in my own GDD.
Milestones are critical points in the development process where a predetermined amount of work is set be to complete. These should be really specific down to the very last asset you'll need. It's not enough to simply say that you need four types of platforms. It's going to help your artists to know that they need to draw dirt, grass, lava, and ice platforms instead. Key milestones include the prototype, first playable, and vertical slice which can read more about in Laurent Victorino's blog.
For use throughout the entire GDD, from change log down to individual mechanics, decide on some icons that your team can use to quickly communicate information. They also help diversify the document and break up the blocks of text. For example, I use the volume icon whenever I'm mentioning a sound file that should be played throughout a level, during an animation, or for a powerup. It helps direct the eye and makes all the text look less boring. Throw in some tables and graphs while you're at it if it makes sense for your designs. Maybe a link to an external excel sheet is more fitting than a large unformatted list of item descriptions. Whatever works, do it because again, there is no standard.
These are still just a few of the sections you can put in your GDD since a lot of it will be up to you, your team, your project, and your investors. There's always more inspiration out there if you need it, like this article by Leandro Gonzalez on Gamasutra so keep exploring and good luck game developer!
Read more about:
BlogsYou May Also Like
.png?width=300&auto=webp&quality=80&disable=upscale)
