From concept to game plan.
How to create a design document.
So you've got a game idea, and you just know it's the best thing ever. You've been over the details in your head a million times and there's simply no way around it — this thing is good. So what's the next step?
In the early days games were usually designed on the fly. The designer (who was probably also the producer, programmer, artist and sales team) had an idea and he or she sat down at the computer and started hacking it out. But in today’s market where games are infinitely more complex, this kind of approach just isn’t practical, if for no other reason than a game designed to today’s standards requires a long-term commitment, vast amounts of pre-planning, and of course daunting financial considerations. Try talking a publisher into backing a project that exists nowhere but in your head and you’re likely to get laughed out of their office (unless you’re already an established name in the industry). Creating a professional design document says to the world that you’re serious about getting your game produced and you’re willing to prove, on paper, why it deserves to be made.
But a design document does more than give a designer an orderly way to shop their game concept around. A well-crafted design document sharpens the game idea itself. As any designer will readily admit, sometimes the ideas in our heads simply don’t work when they’re finally put into play in a real game design. Sure, it would be nice if one of the characters in your new fighting game could fly like the eagle he is designed to look like, but in putting the game on paper you may discover that allowing only one of your characters to fly creates a severely unbalanced game. By the same token, putting a game down on paper will often give birth to a host of new ideas by forcing you to think about every aspect of the game, and this is in many ways what is most important about doing a design document. For example, you know what happens in your fighting game when one character pulls off his special power-up move, but what happens when both characters resort to this move at the same time? It’s by thinking about this type of scenario that your game idea will become a deeper and more rounded experience. It’s all about thinking it through, planning, organizing, and putting your initial ideas through a feasibility test.
While it may not be the most enjoyable aspect of game design, due to the level of detail required, creating a thorough design document is always a step in the right direction for quality game design. Knowing exactly how to represent your ideas will prove infinitely beneficial to the process of taking that game idea that’s been swimming around in your head and bringing it to the PC or television screen. Over the following pages we’ll outline what it takes to put together a professional design document — we’ll assume you’ve already got a great game idea. But even if your game never gets made (a likely scenario in today’s cutthroat market), going through the process of creating a design document is one of the most positive exercises a prospective game designer can attempt, and the lessons learned are easily carried over into your next project. It’s important to understand from the start however, that unlike the movie industry, in which the format for a screenplay is so rigid it even determines what kind of font it’s acceptable to use, the game industry does not yet support a single definition of the term “design document.” According to Ian Verchere, a senior producer at Radical Entertainment in Vancouver, “There are probably as many different formats for a design document as there are developers and publishers.”
Pre-Design Document Work
Sо you’ve made the commitment to design your game idea and you’re ready to get started on the daunting task of creating a thorough design document. Not so fast! Before you get started it’s best to have a few things in order. Since creating a design document is a process of moving from vague ideas to detailed concepts with every step, it is wise to create a smaller scale “design treatment” before getting started on the actual design document.
A design treatment is a self-contained document that outlines in non-specific and non-technical terms what your game is all about. The concept is based on a similar creature from the movie industry called a movie treatment, wherein the basic storyline and general requirements are outlined in a short and easily digestible format. And just as a movie treatment is not the same thing as a screenplay, a design treatment is not meant to be as detailed as an actual design document.
What a design treatment will allow you to do is to get your game idea, in its most basic form, to the point where you can start to feel what it will be like on paper. If in doing your treatment you find yourself already doubting the feasibility of your game, it may be time to re-think your idea from the ground up. This is also a great time to have other people look at your idea and make suggestions before you start down the wrong path on a concept which might have been very cool with just the slightest tweak in direction. Still, don’t worry too much if your treatment raises questions that can not be easily answered right away.
With experience, you will learn to differentiate those issues that simply require further thought from those that indicate real problems, but for now a few unanswered questions do not necessarily spell tragedy.
A good design treatment is no more than one or two pages, and describes in ambitious terms what your game is about. This is your chance to get people, including yourself, excited about the game, so don’t be afraid to make it sound like an earth-shattering experience. On the other hand, it’s important to keep your documentation (no matter what the format) clear and focused. It’s one thing to get someone excited about your idea, but it’s another to lose them in two pages of fluff.
Depending on the game’s genre a design treatment should include most if not all of the following elements: a brief description of the storyline, including main character descriptions, settings and scenarios; a general description of the main character’s actions (if the game was Tomb Raider this is where you would describe Lara running down a corridor shooting bears with two guns at a time); the look of the game (is this a 3D dungeon game with tight, dark corridors or a futuristic adventure game with photo-realistic prerendered backgrounds?); a description of the computer Al (“The enemies will search out the main character by the amount of noise he makes and so it pays to be very quiet. When they find him they will surround and overpower him.”); a list of development tools which may be required; and finally the team members and skills you will need to make the game. Once the design treatment is in good shape, it’s time to get started on the actual design document.
Your Personal Situation
While there are rules that apply to all design documents, the general scope of the document you are about to create should reflect several things about your personal situation and how it relates to the environment in which games are actually produced. If you’re already a game tester at a software house, for example, you can probably feel pretty confident that someone with the authority to green light a project is going to actually read your design document. This being the case, you might want to consider creating a document that not only thoroughly pitches your idea (all design documents should meet this minimum requirement), but also leaves room for further development and detail work once your superior has been bowled over by the idea and rewards you with a full development team to help bring out the subtleties.
If, however, you’re not currently working in the game industry you’re going to have a much tougher time of actually getting someone to look at your document (for legal reasons and otherwise), so your strategy will be slightly different. This is your chance to sell yourself not only as a game designer but as a potential employee. According to Connie Booth, executive producer at Sony, “If you’re sending in a design document to a company without wanting to become a full time employee for that company — don’t bother.” Hence, your design document should reflect the same kind of well-rounded confidence that you would want to portray in a job interview. This means that if there is any single detail that needs considering had better be thoroughly expressed in your design document. A potential publisher is going to want to hire someone who can hit the ground running on day one, and a complete design document may very well prove that you’re up to the challenge.
The Design Document
Now that you’ve done your pre-planning in the form of creating a design treatment and made important decisions about the depth of the document you’re about to create based on your personal situation, it’s time to get started on the actual document itself. Again, it’s important to remember that everyone’s definition of a design document is going to be slightly different, and the document explained in the following sections will only match some of those definitions. The following format, however, will be recognized in the industry as one of the many acceptable forms, and should serve to get your foot in the door.
The Essential Elements
What’s This Game All About
In many ways, this first section of your design document is the most important of all. The first thing you’re going to want potential publishers or marketers or programmers to read, after all, is what kind of game you’re thinking about making. This basically means genre, style and technical features. This is also the first time most designers get caught up in the “but my game’s not like any other game ever and it doesn’t fit into any established genre!” dilemma. Let’s face it, it’s highly unlikely that your game idea is 100% original, and that’s nothing to be ashamed of. While very few publishers are going to get excited about a game that is billed as and designed to be exactly like another existing game, the fact is most publishers will feel more comfortable if your game shares at least some elements with other popular games, and hence mentioning that your main character will be able to drift through the air similar to the character in MDK is not necessarily a bad thing. Remember, you’re not only trying to get a publisher excited about your idea, you’re also trying to give them the impression that your game can be made. According to John Botti, president of Black Ops, “The point of a design document is to get everyone on the same page,” and this first section is essential in trying to achieve that goal.
An easy way to convey your idea as something feasible is to reference all the familiar ideas in your game design right up front. Remember, the original touches in your game will stand out even better when visualized in a familiar context. This can be done in a number of ways, including referencing similar elements in other games by giving them the old “it’s like Xevious meets C & C Red Alert” comparison, or even using illustrations (an important point which we will be coming back to later) to make a feature clear. If your character runs, jumps, shoots and climbs, now is the time to write it down. This is not the place to talk about the scene in the fourth level where your character must traverse the lava pit to find the hidden blue key, but it is the place to explain how your game will support analog controllers to maintain precise control in sticky situations like lava pits or how the gameplay revolves around mastering your character’s sophisticated flying controls.
After reading this section a person who was formerly unfamiliar with your concept should have a very good idea of what kind of game it is. In this way, the opening description of what kind of game you’re hoping to make is like the mission statement of your design document. You’re basically setting up the rest of the document with this openingsection, and if done correctly you’ll have a thorough and self-contained description of your game, creating an easy entry point for the reader.
Writing out the storyline to your game is one of the most dangerous aspects of creating a design document. While it’s easy to get carried away writing the back story, this is the one element of your game design that most potential publishers are least interested in. A common guideline when writing the back story is to keep it to nothing more than one page — it can even be as short as one paragraph if that’s all it requires. Of course, if your game is something story reliant like an RPG or an adventure game you may have to break free from this guideline. However, it’s still better to tell the story in your detailed level descriptions than all up front in a long and potentially tedious backstory. The main goal of the backstory is to set the mood. You’re trying to put the game into some kind of context — don’t go crazy!
“I see so many design documents that start out ‘It was the year 2095 and evil corporations are battling for dwindling mining resources!’ but what I want to know about is the interaction,” suggests Verchere.
Detail by Level
Now it’s time to get specific. Up until this point you’ve been trying hook the reader with the basic concept of your game idea, but from here on out you should detail the game as thoroughly as possible. However, there are a few things to consider before getting started. Probably the most important thing to think about is exactly how much of your game can be pre-planned. For example, if you’re planning a 3D action/platform game, it’s probably going to be impossible for you to plan the exact placement of every jump, firepit and hidden item, as these are all elements that will require play testing and experimentation to get the best results.
What you have to do at this point is decide which elements can be pre-planned and focus on those. On the other hand, it’s important to remember that should you be fortunate enough to ever get to make your game, things will change, so don’t be afraid to plan out — and write down — certain details just because you think they might have to change. It’s better to have a concrete plan going in and have to change it than to not have one at all and just expect things to work out. “We really try to break things down and put even more detail in the design document than will probably end up in the game,” says Botti.
The easiest way to create a detailed description of your game is by breaking it down into some kind of manageable sections. Since most games themselves are broken into levels or zones, the break points are typically pretty easy to determine. If you are designing a game that does not adhere to the traditional level format you will need to find some other way of segmenting your game so that you can work with reasonably sized sections. A genre that might not easily adhere to this kind of strategy is an RPG, but even role playing games can be broken down into different geographic sections or chapters of the story. This is important, so be sure to find some way to break things up or you’re likely to get into a project which is very difficult to manage.
Once your game is broken into different levels you’ll want to start describing in detail how each level will work. This includes how the game looks and acts, in what kind of environment the action takes place, which characters are involved, and finally what the goal or goals of the level will be. This section should also include seemingly insignificant details such as what happens if the player fails — does he fall flat on his back with blood pouring out of his gut, or does an angel fly out of his body and float through the ceiling? Even if they change in the end, these are the details you will be happy to have thought of when it comes time to actually make the game. You’ll also want to document things like alternate paths and potential pitfalls in each level. If you’re designing a racing game, for example, you might describe a certain section of the track that features a hidden shortcut and what specific challenges the player will have to overcome to gain access to it.
The following list of elements to include in each detailed level/section description is just one possible way to organize your thinking. Depending on the kind of game you’re designing, you may find some of these subcategories, or close variations, will help to think through every aspect of each level’s design, and therefore lead to the creation of a well-balanced design document.
General Description of Each Level
Just as the general description of your game is meant to convey an overall impression of the experience, the general description of each level will let the reader know what that level is all about. If it’s a level in a game such as Mario 64, you could start by giving the level some kind of name such as the Giant Eel Level. Then you would explain how this level takes place underwater and there is a giant eel around which most of the action takes place. After that, you might write that the ultimate goal of this stage is to collect the star that is attached to the giant eel’s tail. To get the star the player will need to wait above the eel’s cave, and when the eel swims out, the player can grab the star. Of course, you’ll want to be more detailed in your description of elements such as the eel, the location of its cave, and what you can find in the rest of the level.
Once the main goal of the level has been explained, you should go on to explain more of the environmental elements, pitfalls and play mechanics. For example about that same level of Mario 64 you might write the following description: “Since this is an underwater level the primary color used will be a deep blue. There is also an undulating effect to the water to help sell the sensation of being submerged.” Then you might go on to explain that since Mario can not breath underwater he will have to achieve his goals in a hurry, or find the secret supply of air hidden amidst the sea plants on the sea floor. You could also go on to explain how the level will be specifically designed to exploit the limited time factor by including certain enemies that grab hold of Mario, pulling him to the floor of the ocean and giving him less time to achieve his goals.
Finally, it’s important to remember this is your opportunity to tell the reader what’s important about this level of your game. Your main goal is not only to enable the reader to clearly visualize the level you’re designing, but also to tell them why they should care about it. Within the detailed level descriptions this is probably the best opportunity to really sell each level as something exciting and intriguing and so it’s important to pick your words carefully in this section. Always remember that the language you use to describe something says a lot about the way you feel about it. If it sounds like you’re describing the game in a blase manner, the reader is likely to pick up on your attitude and adopt it as part of his or her own impression. Don’t worry, you’ll have plenty of time to in the next few sections to list, chart and illustrate your points. In this section, however, don’t be afraid to be colorful.
Story Relevance in Each Level
This section of your document will vary greatly depending upon the kind of game you’re planning. If you’re designing a fighting game, for example, there’s not likely to be much to think about insofar as how each fight effects the story of the game. However, in a game such as Wing Commander IV each mission works to advance the plotline, and in a carefully constructed game each mission will somehow work together to create, in the end, a large and cohesive story.
This is even more important in an adventure game or RPG, since there are any number of story subtleties that must be developed and exploited. Depending on how your game is arranged, you may also have to consider the effects of a branching story line. If the player is given the opportunity to set his/her own course through your game, you will have to be ready for all possible choices and what consequences certain choices may carry, and here is the place to work through these considerations.
If you’re designing a story-based game, this section is a good place to not only detail some of the characters you’ll be meeting in each level and explain their relevance to the overall game but also to put this “chapter” of the game into the right context. It’s easy to write for days about the scene where your character finally finds the secret entrance to the castle and battles the evil emperor’s finest soldiers as part of his ultimate victory over the dark side, but if you forget to detail your character’s meeting with the old wise man who first informs him about the existence of the secret entrance, then you’ve left an important hole in your design document.
Of course, this does not mean you need to go on at length about the barmaid who offers your character a pint of ale for one gold coin if that is her only role in the story. It’s your game, you know what’s important, but never forget that the people reading your design document will not know until you tell them.
Environment of Each Level
Describing the environment in each level is no easy task, but when done right is one of the most important tools available in making other people understand your vision. When you imagine your game you undoubtedly see the world around the action quite clearly in your head. It is your responsibility to explain all this in words (or pictures) so that someone reading your design document can picture roughly the same environment.
There are two main distinctions in describing a game’s environment, and these are broken into foreground and background (or possibly even interactive and non-interactive). Some games follow this distinction quite literally, with the end result being typically a static background which sets the overall look of the level, and then the foreground elements which could include anything from floating platforms to banana trees depending on the game. You’ll have a chance to describe in greater detail the items in each level and their functionality, but for now you should mainly concern yourself with the appearance of the environments.
This is also a key opportunity to use artwork. The process of obtaining artwork is not always easy. Assuming that you are not an amazing artist to begin with, probably the best thing to do is to team up with an artist who has a real sense of your vision. Don’t panic if you can’t find the right artist, however. There are still ways to illustrate your ideas. One way is to look for photographs or illustrations in magazines that come close to the kind of environment you’re thinking of. For example, if you’re planning some kind of deep jungle setting you could look in the latest issue of
National Geographic or Travel & Leisure for an image that expresses the right kind of setting for your game. This method may not get you exactly the results you’re looking for, but it should at least get you in the right ballpark. Another easy way to illustrate a game’s environments is through the use of maps. While a 2D map may not express the look and feel of an environment, it does wonders for giving someone an idea of scope and of the physical relationships between different rooms or areas.
Characters in Each Level
In this section you will let the reader know about all the characters he or she may expect to encounter in a specific level, and there is is no specific limit as to how detailed you may choose to be. Depending on the genre, some designers go so far as to keep something fiction writers call a “character bible.” A character bible enables the writer to keep a detailed journal about the characters in his book (or game) in an effort to create a believable and consistent personality. However, keep in mind that while you’re free to keep such a journal for your own reference, your design document is not the traditional place for this kind of work.
What you will want to express in this section is what characters will be appearing in the level and what they will be doing. This includes everything from attack moves to conversation dialogue. You will also want to be sure to explain how character’s actions will be affecting other characters and their
environment. This is another opportunity to touch on the storyline, but again don’t go crazy. This is a place for specific examples of what your characters are doing in a specific situation within the level, not what happened to their grandmother’s dog Skippy when they were ten years old — that’s for the character bible. Finally, you’ll want to describe what these characters look like. This includes technical descriptions, such as “this enemy character will be 3D modeled with about 300 Gouraud shaded polygons,” as well as more traditional descriptions of appearance. For example, “The enemy character Boo Boo is a Canadian Mounty gone insane. He still wears most of his Mounty uniform, except that now he also wears a pirate hat.” Note this is also another great opportunity to include artwork.
Actions/Animations for Each Level
Hopefully, by this time the person reading your design document will have some idea about the kinds of things your character can do. In this section, however, you’re going to have to be very specific about all the actions that he/she will be doing in the particular level you’re writing about. You’ll also have to describe the actions of enemy and ally characters. If, for example, you are describing a boss stage in a 3D action game, it’s not enough to say that the main character will jump and shoot the boss in the eye. To the reader who knows nothing about your ideas, this just doesn’t say much. If, however, you describe the boss character as a fully polygonal 30 foot tall gorilla with a powerful sweeping hand gesture which the main character will have to jump over at just the right time, then duck under the explosive wrecked cars and helicopters the gorilla hurls; directly at the screen, then you’ve given the reader a much more vivid picture of the action.
Simply describing the character’s actions in generic terms like run, jump and shoot isn’t enough. This is your opportunity to describe the animation and artistic style of your characters. When it comes time to actually produce your game you will need a detailed list of required animations to give to the programmers and artists working on it. This will have to include every action that your character may have to do at any point. Hence, in this section it is extremely important that you not only list the actions your character will be performing, but also describe how they should look. Remember, greatness is in the details. For example, both Mario and Sonic jump in their respective games, and when it comes down to it, both characters’ jumps perform the same function, but how they each look while doing it makes such a profound difference it helps define the very character of the games. This is the place to convey this to the reader.
Music for Each Level
Creating and describing the music for your game is an important and challenging part of making a thorough design document.
Naturally, this section should discuss the technical aspects of the music, such as the use of event-triggered music or Redbook Audio, all of which should be as thoroughly described as the animation. However, there are also a number of things that must be decided and thus explained about the quality of the music as well. For example, will the music be used as background ambiance or as an element designed to drive the game forward? The music in the original WipeOut, for example, was chosen specifically to elevate the energy level of the game, and went on to become a big part of the game’s allure. If your game was equally dependent on music for its success, you will want to take the time to thoroughly describe exactly the kind of effect it should have on players.
Sound Effects in Each Level
Just as you have to carefully consider the music in each level, the sound effects you choose say a lot about the game you’re planning. If your game idea is to create a hyper-realistic adventure game, then you’re probably planning to use real-world sound samples. Therefore, if the level you’re planning takes place in someone’s office you might want to mention there will be a sound effect for a closing door, the opening of a desk drawer, the background sound of someone typing, a telephone ringing, and the gurgling of a water cooler. If, however, your game is less realistic, you may want to compare the sound effects in your game to those of a classic Warner Bros, cartoon. For example, “When the enemy characters are shot, they will shatter into many pieces and fall to the ground. An exaggerated glass shattering sound effect should be used to compliment the effect.”
Items (Live Scenery) in Each Level
Earlier you described the environment for a specific stage, now it’s time to describe what could be considered the “live” items in a specific level. For an item to be “live” it need be interactive in some way, and so the items described in this section are those which can be stood on, picked up, exploded, pushed, shot, pulled, examined or whatever else your character may be able to do. These are generally items that mean something to the progression of your game, and therefore need to be explained thoroughly for each level.
This is also a good opportunity to roughly explain how each of these items will be created. For example are they 3D polygonal models or sprites? This will give a potential producer an idea from the very beginning what kind of talents he or she will need to put on the project.
And Then It's Time To Start All Over Again
It’s important to remember that you should be working on your game in manageable sections. Thus everything you’ve just detailed for level one must be reconsidered for each successive level. Obviously, a focused design document will not waste time explaining the same thing over and over again, but if your character has a new move in level eight that he didn’t have in level one, it must be explained in the detail of level eight. If however, you’re character is doing essentially the same thing in level eight that he did in level four, you can simply reference the detailed description from level four.
One last thing to consider in creating a design document is that the overall game must have a certain amount of cohesion. It’s probably not a good idea to spend months on a description of level one without ever considering how it all fits with what happens in level two. Therefore, most designers find it easier to apply levels of detail in waves, creating a broad stroke version of the document first, then piece by piece raising it to the level of detail they’re trying to achieve.
Personalizing Your Design Document
As we stated back at the beginning, unlike more mature entertainment industries, the game industry is still pretty liberal about its essential documentation. This means that your document need not follow exactly the format laid out by this story, or in any other guidelines set before you. In fact, it is highly doubtful that it will follow any example to the letter.
As a game designer, you have the opportunity and the responsibility to decide what is important about your game and then highlight that aspect in your documentation. What you will probably find is that some elements of your game idea work very well with this or other descriptions of how to create a design document, while other elements may require totally original treatments. For example, you may find the need to employ a more traditional Hollywood approach in the use of storyboarding, or the fiction writing approach and first create a very detailed outline. Botti recalls, “When I was 13 and designing a game for my Apple II, my design document consisted of a map and a notebook.” In point of fact, that game idea went on to be sold and published.
Whatever the case, your main objective in creating a design document or any other documentation for your game remains the same: to give someone else, be they a potential producer, artist, programmer or whoever, a clear idea of the game that’s floating around in your head. If this takes more artwork than words, do it. If it takes a slide show or a prototype computer program, get to work on them.
The point is, the only way you’re going to get the help you need is through your ability to express your ideas to those who can help you get the job done. A thoughtful design document, whatever its form, can help you immensely in that quest.
Getting your document into the Right Hands
Creating a professional design document is only step one in the long and difficult process of actually getting a game produced in today’s competitive market. The next step is to get your document (be it a formal design document, design treatment, or anything in between) into the right hands. To begin with you should accept the fact that your chances of actually getting your game made, statistically speaking, are not that great. For one, there are legal reasons why many companies will not even look at your game idea no matter how much work you put into creating a professional document. Most of these reasons involve what could be described as the problem of “ownership of ideas.” From a company’s perspective, if it looks at a design document and rejects it, then later the company comes out with a game that bears any similarity to the rejected concept (even coincidentally), the company may open itself to a lawsuit. Thus, most companies have an iron-clad policy of returning game ideas unopened or at least unexamined.
The situation is not hopeless, however. One way to get around this potential problem is to offer to sign a legal document waving your rights to take legal action against the company in question no matter what ideas they may use in the future. Of course, this does take away your right to legal action if the company actually does steal your ideas, but it could end up being your only viable option.
Many companies do have active acquisition departments: the key is finding that key person who can get a project on the right person’s desk. This is why it is important to carefully research the companies you are sending your game ideas to. Be sure to pick a company with a good reputation and try to have some contact with someone at the company before sending them anything. (A good place to meet company employees, especially if you have no other inroads, is online. We know of scores of people who made crucial first employment contacts that way.)
A much safer and more likely way to get your game made is to first get yourself employed by a software company. This could mean any number of things depending on your skills, but the truth of the matter is that having a job in the testing department of a game publisher already puts you in a much better position for having your game idea published by that company. Another important aspect of this approach is that it displays your willingness to work for the company to which you’re sending your game design. Basically, what you’re be saying to a company when you’re sending them your design is “I want to come make this game as an employee of your company.” There is still no guarantee that the company you want to make your game with is going to give you the chance, but if you’re willing to be flexible, you’re likely to find some kind of audience for your ideas.
For further information on creating design documents and other game documentation see:
The Ultimate Game Developer's Sourcebook by Ben Sawyer and Inside Electronic Game Design by Arnie Katz & Laurie Yates
/NEXT GENERATION, vol.3 33, September 1997/