One topic that comes up a lot during discussions of game design is the value, or potential lack thereof, of the Game Design Document. This living document, which can be used to guide and define the design of a game during both its planning and production phases, is a tool used by most major game studios, but it’s usefulness to a solo developer or small indie or academic team is more debatable. What exactly this document should contain is another point for debate.

So, what exactly is found in the usual GDD? That varies. This document, essentially an outline of a game project, is often tailored to fit the project and studio using it, but for those unfamiliar with the concept, some common examples of content might include:

• Basic technical information about the project:
  • What engine will be used for development?
  • What platforms will it be released on?
  • What is the latest stable version of the game?
  • When is the projected release date?
• Project goals and general design notes:
  • How could the game be described in one paragraph?
  • What are the game’s major gameplay and narrative genres?
  • What target audience is this game designed for?
  • What is the target gameplay length of the final game?
  • What are the game’s major selling points – why would players choose this game over the countless others they could be playing?
• A mechanical overview:
  • What are the game’s major mechanics?
  • How will these mechanics be implemented?
  • How will players learn these mechanics?
  • Are there multiplayer modes or other optional gameplay modes?
• A level/world/environment design overview:
  • How many levels/dungeons/towns/etc will there be?
  • What locations can the player visit?
  • Does the game feature shops or currency?
  • What are the designs of these levels or other locations?
• A narrative overview:
  • Who is the character that players control?
  • What NPC characters are present in the game?
  • What is the game’s central premise or theme?
  • In what narrative setting does the game take place?
  • How does the player advance the story?
  • Does the game feature dialogue?
  • How does the story relate to the mechanics?
• An overview of the User Interface:
  • How will the controls and camera work?
  • What menus can they player navigate?
  • What controls will they use to access and navigate these menus?
  • How do players save and resume progress?
• An art design overview:
  • What is the overall atmosphere of the game?
  • What style should be used for the character designs?
  • How should the menus look and feel?
• A sound design overview:
  • What atmosphere should the audio portray?
  • What style of music should be used?
  • What player actions will require sound effects?

Of course, this is only an example of a few game design basics that may, or may not be, present in any given GDD. Another thing that varies is the level of detail provided on any given subject. For instance, many game design documents also serve as technical documents, with specifications about how the mechanics, menus, and modes will be implemented in terms of programming and scripting, but others focus primarily on the design aspects themselves, without getting too deep into how these aspects will actually be implemented into the game. The genre of the game also naturally changes what should be present in the GDD. A highly story driven game, for example, might feature a full narrative outline or game script, whereas a more arcade style game may forgo the narrative design section nearly all together. Actual sketches, demos, or screenshots of level designs and other game environments may also be present or not in the GDD – it all depends on the amount of detail a developer desires to have in this single document, or in the case of some major companies, the amount of detail publishers require.

As with nearly anything, there are pros and cons to creating and maintaining a GDD for your game project. The discussion actually reminds me quite a bit of the classic ‘pantsing’ versus ‘planning’ debate for traditional writers – that is, whether or not to outline a novel or other writing project before actually writing it. As with a GDD, a ‘planner’ often writes the outline before beginning the novel and tweaks their notes as they go along and progress with their project. However, where game design documents differ from novel outlines is that a game has many more aspects to take into account, aside from narrative alone. A game design document can be very useful for combining the gameplay, narrative, audio, and artistic ideas a designer might have into one cohesive vision of a game. It can also help a designer remember some of the aspects of the design that might perhaps be slightly less exciting, such as the User Inferface and some of the technical details. After all, a game isn’t made from any one aspect – not the gameplay, the story, the art, nor the music. Instead, it’s the sum of its parts.

Personally, I tend to believe that game design documents are a very useful tool in the design process, even for a solo developer or small team, because they help the designers and the developers ascertain that all of their disjointed ideas really come together to form a complete and satisfying product in the end. However, there does come a point where the simple chore of recording and updating every detail of the game becomes a bit excessive or just another distraction from actually getting the development done.

Here is my personal take on the pros on the cons of the GDD:

Pros:

• They are definitely useful for teams, and they help make sure that every team member is united in their vision and knows what they need to be working on.
• They help a designer work through the small details of the game, from saving and loading to the gameplay camera.
• They help designers ascertain that all of their disjointed concepts for the various components of game design – the gameplay, the narrative, the art, the audio, etc – all really do come together to form a cohesive whole.
• The road map they provide, and their encouragement to plan out contingencies and details in advance, help designers attempt a project they might be more likely to actually finish.

Cons:

• Game design documents must be constantly updated throughout the design and development process to remain useful, as the design of the game is always shifting as features are actually implemented, stories are edited, and resources are composed.
• They take time away from actual implementation, and can lead to a slower start for a project. This is especially true for solo developers, who don’t have team members also working on and relying on the GDD.
• They sometimes have a tendency to lead to either overscoping or underscoping. That is, they can encourage either feature creep or over simplification. After all, it’s easy to add a new feature to the design when all you have to do is write it down, and it’s also easy to be so intimidated by the road map that the nerves can cause a designer to play it safe.
• They can turn into a distraction in and of themselves, if a designer becomes too focused on the accuracy and detail of the GDD.

For these reasons, when it comes to solo projects or small teams, I would tend to recommend GDDs more to those designers who might also outline a novel before writing one. For those who would simply sit down and start writing, forcing themselves to plan out and update a GDD might only hinder their progress on the project, itself, and they may find it easier to simply take less formal notes as they carve out their progress from nothing but the ideas in their head. I also find that game design documents tend to be more important for mechanical or gameplay oriented games. If a game is more story-driven, even if it’s otherwise fairly long or complex, it often seems to be more crucial to focus on nailing down the details of the plot, instead. The value of a GDD really does depend on the type of designer you are, and on the type of game you are making.

Regardless of the genre or situation, however, I personally find it most useful to write a GDD that focuses on the actual design of the game, not on the technical specifications of how that design will be implemented. In other words, I find it more useful to focus on concepts such as why anyone would want to play this game, how the gameplay and narrative connect, what the overall atmosphere should be, and how the difficulty curve should feel, instead of how any given feature will be programmed. I believe that a GDD should be about vision – it should be about turning your ideas into a cohesive experience that you are truly excited about creating, and it should be about why this experience will matter to the people who might one day play it.

If you are interested in creating a GDD for your project, a simple Google search will offer plenty of ideas and examples. If you would like something to start from, you can also download and edit the GDD template that I generally use for my projects here. (Some of the terms and concepts used in my usual GDD, such as engagement types and micro and macro arcs, come from terms used specifically at my school. They’re fairly self explanatory, but you can find definitions of those terms here.)

Regardless of what type of GDD you choose, it is important to tailor the document to suit your own personal style and the needs of your game concept.