As with most things within the games industry, there is no standardized method for documenting or planning a game project. The amount of information you will find in a GDD will vary wildly depending on the company, the size of the project, and the author.
4 http://www.ganttproject.biz
5 http://www.dotproject.net
6 http://www.achievo.org
7 http://www.anxietyapp.com
8 http://www.openoffice.org
9 http://www.notepad-plus-plus.org
10 http://www.peterborgapps.com/smultron
11 http://simplenoteapp.com
12 http://www.hogbaysoftware.com/products/plaintext
1.12. Writing Game Design Documents 13
In development, some companies will follow a GDD rigidly, whereas others will change it along the way. In too many cases, the document only gets written out of necessity and becomes something that gets tossed in the trash once actual production starts.
A good GDD should provide a team with information about the overall ideas and goals of the project, give a rough guide to how the game play will work, and give an idea of the technology behind it. In a large-scale GDD for a commercial title, it is common- place to find descriptions of every single component and game mechanic. In a puzzle game, for example, each puzzle piece would be listed out in detail along with break- downs of piece functionality, scoring, and, in some cases, even concept art. Smaller studios often stick to just a few pages of information about the game and leave the detail for later; whether or not this method is successful depends on the team, as it can lead to more time spent prototyping and trying to find core mechanics (the key play ele- ments that make the game work), but if a studio employs prototype-centric practices, this could in fact become a winning method. A GDD should always be present, but bear in mind that it only needs as much detail as will be useful to you and your team.
The actual length of a GDD can be anything from just a few pages to over a thou- sand pages and beyond. If you do choose to write something detailed, do not be afraid to stray from the original path if you know that it will make for a better game. The GDD should always be taken as a fluid part of the game development process, and you should expect it to change, grow, and evolve as your game progresses. Great games are not made on paper and it is almost a certainty that your project will go through a number of changes, which may take it far away from the original draft of the GDD. I’ve seen games end up in completely different genres from the original GDDs by the time they reached completion. Although this is an extreme example of what might happen, some devia- tion from the GDD is a normal part of the creative process; making games is an organic process and you will need to remain flexible and open to revision.
Having detailed documentation early on in a project can never really be a bad thing, regardless of how much of it actually makes it through to the final release. At the very least, a detailed GDD can help a team to take the time to consider many of the small- er points that may not have been obvious from a birds-eye view, addressing potential problems prior to or early in production. In a way, it can be a great risk-assessment document.
In this section, we are going to look at what it takes to write a GDD suitable for a small- to medium-sized studio or game project. I have compiled several different design styles and formatted them into this single style. Feel free to use just a little or all of this formatting style to produce your own GDD; just remember that at the end of the day our goal here is to reach completion—whatever works for you is more important than anything you read in a book or on a website. You are the game designer, this is a creative process, and all I can do is offer you the tools I have. It’s up to you to make them your own and to make them work for you.
1.12.1 Writing an Overview
Many of the projects that I have worked on began as proposals—that is, single-page documents made up of an overview of a game concept and a brief description of what the game will have in it. Those proposals would usually go off to a client for sign off and,
if all went well, would form the first part of a full GDD if the client wanted to take the project further. At the proposal stage, the objective is to make the game sound exciting and sum up all the best parts within a relatively small number of words, so it makes an ideal start to the GDD because we want our readers to also get excited before we start in on the details.
The overview is a bird’s-eye view of the game, designed to give readers the right information about it without requiring too much of a time commitment. The first part of your overview is a brief description, similar to what is known in the film industry as an elevator pitch—that is, a paragraph or two of text to describe the game in an exciting way, all within the time it takes for an elevator to reach its floor (hopefully a floor near the top of the building!). Try to create an exciting mental image of the game within a few short sentences:
Brief Description
Soccer-O-Tron 9000 is a fast-paced twitch game with the action in 2D, top-down. The sounds of the crowd roaring and gasping along to a thumping soundtrack orchestrate this experience, designed to provide a fun, arcade-like barroom game for real soccer fans.
The game is a recreation of the classic soccer tabletop game where users spin bars to rotate small models of footballers to hit and deflect a small soccer ball into an opponent’s goal. Powerups bring the game into the modern day, offering exciting gameplay features such as flaming balls and bullet-time slow motion. Unlockable content also includes dif- ferent playfields in a variety of styles; real excitement and replayability comes from both single-player and multiplayer modes.
In the second part of the overview, we go into more detail as to how the game will work. The text in this section may take the form of a full story or perhaps some of the features that increase replayability—those new additions to the concept that will keep players returning to the game.
The overview should try to answer the key questions that define the entire project, such as what the appeal of the game might be, what the player’s role will be, why this game should be made, and what the main focus points of the game are.
It would also be a good place to include images and illustrations, such as concept art or sketches, both to add some sizzle and to demonstrate the game concepts as clearly as possible:
Soccer-O-Tron 9000 brings much needed life to a tired genre. This includes both multi- player- and single-player-based game modes that bring new concepts to the game:
• Battle mode. Play head-to-head against an opponent.
• Breakout mode. Play head-to-head table soccer in a race to break through a wall in the center of the play area. Knock out bricks with each hit of the ball to break through.
• Invader mode. Table soccer … with invaders! Use the ball to blast the invaders back to planet Soccertron before they land.
Sounds and particle effects will set a realistic tone for the game, taking it beyond a simple tabletop game and into a full-on immersive soccer experience. The game is aimed at giv-
1.12. Writing Game Design Documents 15
ing soccer fans an arcade-like experience within a virtual environment they can recognize that is fresh, fast, and fun.
Following the overview is a good place to build up a list of design goals. Design goals can go a long way to explain how the game will be designed, who the target audi- ence of the game will be, and what the developers hope to achieve with the game.
Visceral Goals
Air hockey is a two-player tabletop game found in amusement arcades worldwide. Soc- cer-O-Tron 9000 tries to recreate that visceral experience. An electronic high-tempo au- dio track aids the arcade ambience.
Art Goals
This game should try to recreate an overload-of-the-senses atmosphere that an amuse- ment arcade has by using bright, interesting visuals and many particle effects to act as aesthetic rewards throughout the game.
Novelty Goals
Users may also unlock play areas by completing the tournament mode, which should serve to provide extra replay value. The new game modes will draw in both younger and older users who have experienced air hockey before and are looking for something dif- ferent.
Casual Goals
The game must be able to be played in short, satisfying sessions. A Save Game feature in tournament mode ensures that users can pick up and put down whenever it suits them without losing game progress.
1.12.2 Writing about Key Features
The Key Features section should take the form of a list of the features that will stand out as your game’s biggest selling points, with a single paragraph for each one to explain, in simple terms, what each feature means. If you are making a racing game and your most interesting feature is artificial intelligence (AI), you should start with this feature and highlight what is going to be different about your approach. This section demonstrates that you understand what is important in your game and that you have considered the competition and how you can offer something fresh to the market.
Key Features
Air hockey powerups need to be charged by holding two fingers on the charge zones.
Once the selected powerup is fully charged, the user needs to make the correct gesture to fire it. The action doesn’t stop, so trying to squeeze in the powerups and keeping the puck in play is a fun and exciting challenge.
Levels are procedurally generated, resulting in an almost infinite amount of playfields to keep up the replay value and to bring something new to the game. Just when you think you’ve seen it all, try another level and see how the whole dynamic changes!
Users can challenge friends over Facebook Connect and post scores to Twitter. A You- Tube replay system will capture the action and give users the ability to upload the most exciting game highlights for the world to see!
Bluetooth and Wi-Fi multiplayer games bring up to four friends together to play a variety of never-before-seen ways to play, including capture the flag and other game modes, add- ing a new slant to traditional air hockey.
1.12.3 Writing about Background
The Background section contains any extra information that a reader of your GDD might need to know. This might include a particular technology, an existing game en- gine, a previous game (if this is a sequel), or anything else that affects the decisions made later on in the document.
Background
The Soccer-O-Tron 9000 game engine is currently in its first version. Built in Unity3D, the current browser-based game will provide a solid technical base for this iOS-based title.
This version will add new features to the existing engine, such as enhanced visuals, im- proved physics, the ability to upgrade characters to improve performance, new 3D assets, and a Career mode.
This new game will offer a more advanced game flow, giving users a store to purchase powerups with virtual money and a Career mode where pitches and skins are unlocked and made available to play in quick-game mode.
1.12.4 Writing about Genre
This section is a single paragraph outlining the genre of the game and, if anything, what new aspect this game might bring to the genre. Is there any particular reason for choos- ing this genre? Write it here.
1.12.5 Writing about the Platform
This section contains a paragraph or two that explains which platforms the game is go- ing to be released on and what benefits or challenges the platforms offer.
1.12.6 Writing about Core Game Play
This section contains a few paragraphs explaining what the core game play elements are and where the focus for game design needs to be in order to make the user’s experi- ence a good one. This is different from your key features and genre definitions in that it should focus on actual game play, such as powerups, upgrades, or jumps—any kinds of game elements that will help to enforce the type of experience you want to achieve.
1.12. Writing Game Design Documents 17
1.12.7 Writing about Walkthroughs and Game Modes
Some people like walkthroughs, some people don’t. Personally, I like to have walk- throughs to both try and define the experience and to provide a first-person perspective of how the game might work. My walkthroughs usually start just after the game loads and take readers through the menu system and to the actual game or feature I am at- tempting to demonstrate.
Walkthroughs help me to visualize the game and all its menu screens, step by step.
As I write them, they sometimes give me new ideas on game flow or new features.
Walkthroughs are also a great tool for exploring and discovering any potential logic flow problems at a stage where it doesn’t cost anything to fix them. Here is an example for a single-player battle.
Description
In this single-player battle mode, players battle against an AI computer opponent to pro- pel the ball offscreen on the opponent’s side. When a player (AI or otherwise) manages to score a goal, one point is scored. The objective of the game is to achieve ten points. The first player to get ten points wins the game.
There are three difficulty levels available. Difficulty levels affect the accuracy and speed of the AI opponent and likelihood that an AI player will be able to attain powerups suc- cessfully.
Walkthrough
From the menu, the user will select single-player mode.
The user will then be prompted to select an easy, medium, or hard difficulty level.
At the end of the game, the entire play area will explode.
A popup window will display final game scores, with options to return to the main menu or play again.
Here is an example for a multiplayer battle.
Description
Multiplayer battle mode allows two users to go head to head. The only difference between this game mode and the single-player battle mode is that the opponent is another human player as opposed to an AI computer player. Powerups are present in this game mode, and the objective is to push the ball past an opponent to score points.
Walkthrough
From the menu, the user will select multiplayer battle mode.
Any player can first select a playfield.
At the end of the game, the entire play area will explode.
A popup window will display final game scores, with options to return to the main menu or play again.
1.12.8 Writing about Game Play Elements
Whereas our Core Game Play section listed out the core parts that make up our game, the next section of your GDD takes the form of a breakdown of all elements—a game play shopping list, if you will. This should include every item that the character can pick up, interact with, talk to, shoot, swap—all of the individual elements that make up the game.
A short paragraph should explain what each item is, what it does, and how it is used. In some cases, you may need to list out any dependencies, or other elements that may be impacted or combined to make something else.
Writing a list like this can help to define your game, brainstorm new elements, and provide a to-do list during production. Having a breakdown of each game play item helps in producing realistic development timelines since your team can go through each one line by line, applying time predictions to each one before reaching a complete timeline.
Ball
The ball is heavier than a ping-pong ball and it should have a good degree of inertia when a soccer player hits it. The ball should be smaller than a ping-pong ball and similar to its real-life counterpart, which would be made of rubber. We should try to give the regular game ball similar levels of restitution and friction in its physics properties.
The ball can be modified by various powerups, so its code needs to be structured in a way that allows for easy modification of its physics properties and potentially caters to the addition of extra visual or audio effects like particles or fire.
Bars
The bars are steel and immovable except for a single axis where users are allowed to slide them up and down. The sliding movement velocity is slightly smoothed out to allow for jittery input methods such as accelerometers. Users can rotate the bars around their x- axes, with the rotational velocity slightly smoothed out, but not so much as to impede upon the required feeling of real-world inertia. Bars have soccer players arranged at uni- form positions.
Soccer Players
Soccer players are arranged uniformly across bars. They add a small amount of inertia to the rotation of a bar, but carry little weight and present a very small amount of drag. The soccer players are made from tough plastic, which will give the ball a hard surface to hit.
The bottom of each player is constructed in a wedge shape to allow for extra control of the ball.
1.12. Writing Game Design Documents 19
Pitch
There are a number of pitches of various shapes and sizes. The pitch is a hard surface that offers little traction and maximum bounce. The walls of the pitch will be coated in a number of different materials depending on the level style being played:
• Cloth. A thick cloth coating will slow the ball slightly, acting as a minor penalty for hitting the walls, dampening impacts with the edges of the pitch.
• Metal. A smooth, shiny metallic surface will allow the ball to bounce off the sides of the pitch with little impact on its velocity.
• Rubber. Rubber-coated walls will allow the ball to bounce off at either its inverse velocity or at a slightly accelerated inverse velocity.
The sides of the pitches are decorated with different sponsors, logos, and advertisements just above the play area walls.
Powerups
Numerous powerups will appear at different positions on the pitch, at random times, de- pending on the chosen game mode. In single-player mode, powerups appear from the cen- ter of the pitch. In multiplayer mode, powerups appear from multiple points on the pitches.
In a multiplayer game, some powerups only affect the ball when it is on the opposing player’s side of the table. (This is true for any powerup that negatively affects the other player.)
Please see the section on powerups in this document for a full breakdown of each avail- able powerup and its effects.
1.12.9 Writing about Asset Listings
In the games industry, we refer to graphics, sound effects, models, etc. as assets. Here, we list out all of the assets required to complete the project. These listings should be split into relevant groups, such as graphics, sound effects, 3D models, animations, and any additional required notes.
If you are working with a third party, note that the more detail you can add to the Asset Listings section, the easier it will be to put together a realistic quote and time- line—especially for creative assets such as music or graphics.
1.12.10 Writing about Concept Art and Reference Images
This is the place to include all of the concept art, sketches, character outlines—es- sentially, anything graphic that will help a reader to understand how the final product might look or the kind of visuals it might have.
If you don’t have concept art, that’s okay. You don’t have to have expensive concept art to get the message across and you will be okay to use images from existing games, images from other sources, or stock pictures. The goal of reference images is that they should collectively represent the overall aesthetic of the game. For example, you might