GAME DESIGN PROCESS 101: PART IV (THE GDD)

This is a long one...chock full of love.

It would be unfair of me to say that everything I know about Game Design has come from personal experience, trial and error, and (God forbid) talent. It would also be unfair of me to say that I am the foremost authority on the exact and best method for Game Design. Neither would be a true claim. I simply do what works best for me, and implement what I know is vital for success in the industry. However, any of my skill set that is not derived from honed natural ability came from my education when gaining my degree in Game Design. And there is one thing that college drilled into my head about being a Game Designer, be as effective a communicator as you can and be extremely organized.

Now this isn’t my natural state of being. Much like Amadeus Mozart, I’d rather just put my pen to the paper and start writing. However, that would do nothing to further my career, or allow me to better myself as a Game Designer. The same goes for anyone reading this particular article that wishes to do one of the following: Make a career in the Game Development Industry, work on a collaborative or team project, or wish to markedly improve the quality of their designs with each successive project. If that doesn’t define you at all, that is to say if you work alone all the time, are doing this just for fun, and just want to release your next game, then this article is not for you. And to make sure everyone understands that, I’m going to repeat it in bold face:

If you are just playing around with game design as a hobby, and don’t wish to organize yourself as the professionals who make games for a living do, please skip this article! It will bore you to tears!

The next article is a fun one about Level Design, which is in a nutshell map-making. My usual anecdotes and sarcastic comments resume in that article. If you’re skipping this article and reading on, just note one thing: Whenever I use the term ‘GDD’, I am referring to the contents of this article. Bonne appetite!

Alright, for the rest of us that are still here, let me be honest, I’m going to push topics on you that are dry and may seem boring. They deal with organizing your game’s plan into a cohesive form of documentation that anyone can pick up, and use to create any part of your game. This will expand on the material covered in Part III of my articles, the Rough Draft, and move it in a direction that is absolutely ridiculous. While I will not go as deep into the organization of one of these documents as an actual course on Game Design would, I will be very detailed, and not hold back any information. However, and I mean this in all sincerity, if you want a career in Game Design, you have to learn these skills. It would also probably help getting some formal education in Game Design, but that’s me crowing about school, and has no place in these articles.

Like all literary works, video games have their ‘Bible’. For theatrical performances, they are called scripts, for movies, they are called screenplays, and for songs, they are called scores and lyrics. For video games, the most important piece of paper, the script and screenplay of the entire game, is call the Game Design Document. As stated before, the Game Design Document, otherwise called, and herein referred to as the GDD, is the ‘Bible’ of a video game. Any and all information pertaining to a video game is kept within a GDD. Everything. The complete story, all levels, all characters, all encounters and events, side stories, endings, and more are located in that document. Needless to say, some of those documents get very big. The largest GDD’s would be for sandbox style games and RPGs. The GDD for the first installment of Lost Legacy, the version of the game that is currently available, is over two hundred pages.

Don’t let that number frighten you! A lot of people are under the incorrect assumption that a Game Designer writes up a fantastically large GDD and then hands it to a legion of programmers, artists, and designers who then labor to make one man’s vision into a reality. That is not the case, not entirely. There generally is ‘one man’ who comes up with the idea, the Game Designer, the guy who goes through the process of getting inspired, plotting out his or her ideas, developing them, and then creating a rough draft. That person is the Game Designer, and nine times out of ten, he is also the Project Lead. But he’s also an artist, a designer, or even a programmer; so in essence, he is one of the team. (Bear with me, folks, I am going somewhere with this train of thought.) The fact of the matter is that the Game Designer, despite often being the creative lead of the team, is still part of the team.

Because of that neat little thing called collaboration, ideas and details about the game can change, because of that, the majority of the GDD is written during the game’s development. (I told you that I was getting to a point!) What you need to have prior to starting game development, other than the rough draft of your story, is the ‘bare-bones’ of your GDD. This is often also referred to as the Game Concept Document or Game Concept for short. This ‘bare-bones’ version of the final GDD would be what you would submit to a Game Developer (if you were looking to find someone to make your game), or to your Project Manager (if you worked for a Game Developer), to pitch the idea for your game. It shouldn’t be too long, about ten pages maximum should do it, and should contain a number of very important elements. From this Game Concept Document, you will, during the course of your project, add detail, revise detail, rewrite detail, and add more detail, until the resulting document, that will fit lovingly in a huge binder, contains everything that has made it into your game, and perhaps some of the things you will want in your game’s future patches, or your next game entirely.

So what is the best way to begin a Game Design Document? Well, chance are, if you are following this series of articles, you have already written a nice chunk of your GDD’s first draft, and the rest of the work is putting all of that information you wrote in your first draft into an organized fashion. My recommendation is that you start off by opening whatever word processor you plan to use (I usually use Microsoft Word, by Open Office is just as good), and create a header and footer. I won’t go into how to create things like headers and footers in MS Word, or any program, I’m going to assume you can either already do that, or can figure it out on your own. Now, in that header, put the name of your project and your name; while in your footer, put whatever formula will print out the current and maximum number of pages. Once that is done, type up the name of the game, and any other really important information, such as:

Spirits of the Deep

Author: Christian Roule
Date: 02-20-09

Feel free to dress it up, bold-face, add a font you like, and anything else to make this document feel more like something you are creating for a game and not as homework or part of a series of articles on Game Design. It is important, from the start, to approach this with a good attitude, and to make the GDD your own. This will maximize your output on the work you have to do, and help stimulate ideas instead of stifling them.

Once you have your pretty title, header, and footer, it’s time to create the Table of Contents. Yes, I know that sounds completely backwards, creating the Table of Contents before creating the body of the document, but the purpose of this is to begin the organization of your thoughts before you even start writing. Besides, if this helps you create a template to apply to future GGDs, then all the better. So, let’s create the Table of Contents:

  1. Design History
    Game Overview
    Story, Story, and Characters
    Gameplay and Mechanics
    Levels
    User Interface
    Artificial Intelligence
    Programming
    Game Art
    Game Audio
    Creation, Installation, Update Software
    Design Team
    Asset List


If you’re thinking that the above list is not so bad, you are about two paragraphs away from a very rude awakening. Those are just the Section Headers, and like I said are the lighter versions of what a professional Game Designer would use as a Template.

But anyway, for each of those section headers, you will now create sub-section headers, indented directly underneath them. It is important that you note, for each section and sub-section header, you place a question mark a few tabs away, creating a column of ‘?’s. This is because as you add and revise information to your GDD, you’ll want to change the pages in which those sections or sub-sections begin. If you’re feeling like you’re in school now, setting up a report using the MLA format, then don’t fret, it’s only because this was indeed inspired by that very same format.

When you are ready, begin with the sub headers. Skip Design History, since it will merely be a list of changes to the GDD as you revise it during your game’s development.

Game Overview
  1. Game Concept
    Genre
    Target Audience
    Features
    Game Flow Summary
    Look and Feel
    Scope of Game Project


Story, Setting, and Characters
  1. Back Story
    Setting
    Plot Elements
    Story Progression
    Cinemas
    Game World
    Major Characters
    Supporting Characters


Gameplay and Mechanics
  1. Game Progression
    Game Objectives
    Mission Structure
    Puzzle Structure
    Play Flow
    Level Navigation
    Level Actions
    Combat
    Gameplay Continuance
    Economy


Levels (For each Level in the game)
  1. Synopsis
    Introduction
    Objectives
    Physical Description
    Maps
    Critical Path
    Challenges and Solutions
    Closing Material


User Interface
  1. Heads Up Interface
    Menu System
    Control Systems
    Interface Audio
    Help System


Artificial Intelligence
  1. Enemy AI – Out Combat
    Enemy AI – In Combat
    Friendly AI
    Support AI
    Indifferent AI


Programming
  1. Game Engine
    Scripts
    External Code


Game Art
  1. Concept Art
    Art Style Guide
    Characters
    Environments
    Equipment
    Cinemas
    Miscellaneous


Game Audio
  1. Music
    Sound Effects
    Vocals


Creation, Installation, Update Software
  1. Game Engine
    Installer
    Patch Schedule
    Update Software


Design Plan
  1. Game Design Lead
    Creative Team
    Level Designers
    Artists
    Programmers
    Composers
    Sound Producers
    Voice Actors
    Testers


Asset List
  1. Model/Sprite Sheet List
    Texture/Tiles List
    Animations List
    Effects List
    UI Art List
    Cinemas List
    Level Music
    Scene Music
    Action Music
    Environmental Sounds
    Action Sounds
    Interface Sounds
    Voice Actor Lines


Still with me? I told you that this was an extremely long list. And people wonder why Game Designers, especially the Leads, get paid so much more than the Artists or Programmers. That’s a LOT of information to write down, isn’t it? However, if you can go back and re-read the list again, I’m sure you will agree that is the majority of what you need to design a game, regardless of your engine or programming language of choice. However, there is one thing not on that list, and it is the one thing I cannot teach you how to do within the scope of this article – making the game fun.

The ‘fun factor’ of a game needs to be put into the GDD from the very first to the very last section. It’s more of a mindset and an overall frame of mind then it is a ‘section’ or ‘sub-section’ of the GDD. So instead of approaching each section of the GDD with “Oh god…I have to get everything written down or I’m not a good Game Designer”, you need to approach each section of the GDD with “How can I use this section to make the game fun to play?” Once you have overcome that hurdle, you will have moved one step closer to truly understanding Game Design.

The remainder of this Article will be me explain each of the sections and sub-sections in depth, and is the real meat of the article. Unlike previous and succeeding articles, I will not go very deep into the development of my sample came, Spirit of the Deep, the story of a disenchanted Native American who clashes with a Lovecraft Deep One. If I did that, this article would balloon to an unreadable size. However, I will reference the game Spirit of the Deep for the purposes of drawing comparisons to an actual work, as opposed to pure abstraction, and to provide continuity to my series of articles on Game Design. I will also, at times, use Silent Hill 3 and Final Fantasy X as references.

I suggest you get a cup of hot tea, coffee, or cocoa, and sit back. This is meant to be enjoyed.

People often get confused with what the first section, Game Overview is about, and want to put every single thing about the game, the story, and the characters here. That sort of defeats the purpose of the word ‘Overview’, but is an understandable mistake that anyone can make. It is best to remember that this is the first thing, after the GDD’s Change History, that anyone for a Team Member to an Executive will read, so it needs to be short, concise, and communicate your idea clearly.

Game Concept is, simply put, the general idea of your game, expanded to about a paragraph. If you’ve been following the guidelines for idea generation, brainstorming, and writing rough drafts, you’ve already written this part and just need to copy and paste. Otherwise, write a complete paragraph saying what your game is about, highlighting the most important parts. For Spirit of the Deep, I wrote how it was ‘a game about a disenchanted Native American named Eric Roughwater and his girlfriend Trella are caught up in the battle of their lives when the Old One Shub-Niggurath, whom was buried in the mountain on Eric’s tribe’s reservation, is awakened. Over the course of one night, Eric’s life is turned upside down, his grandfather murdered, and Eric is forced to learn the ways of his people in order to combat the Old One.’ You don’t really need too much more than that, maybe another two or three sentences, just giving an idea of what the game is about, and what kind of story you are telling. Don’t be too brief, and definitely don’t be too verbose.

Genre is the category of the game, and as times change, so does the depth of the categories one can choose from. Now-a-days, it is best to define the genre of the game by it’s gameplay category (action, adventure, roleplaying, simulation, sports, etc) and tone (fantasy, science fiction, survival horror, anime, post-apocalyptic, etc). This way of writing out a game’s genre will make it easy for whomever you are pitching your idea towards to understand what type of game you want to make. For Spirit of the Deep, I said that it is a Survival Horror Roleplaying Game.

Target Audience is just that, the audience you are targeting to place your game. You may not thing this is very important, but it is actually extremely important. Think about it this way, if your intention is to target people of all ages, including children, how will that determine the tone of the game and its content? Would you put slithering tentacles and courtesy breasts in a game that mommy and daddy can play with their five year old? Well, all liberal media and European values of sexuality aside, the general community will not be too pleased if you are presenting a game for one target audience, when it is clearly meant for another. It’s not only unprofessional, it’s just bad form. If you are not sure what to target your game for, try looking at the ESRB. More often than not, that will be enough to give you an idea. I’m not saying to rate your game, I am staying to determine who you are targeting as the audience of your game. For Spirit of the Deep, I specifically am target Teenagers and Young Adults, as well as any fans of the Cthulu mythos. However, I am also targeting a Native American audience, as I will research actual Native American totems and tribal shamanic practices.

Features are those lovely things that you want to showcase in your game, something that will make the game really stand out from the others (and hopefully increase sales over whatever rival products come out around the same time). This is not an exhaustive list of everything you want to do in your game. Instead, this is a list of the Features you have already decided you want to use in this game. Maybe there is a dating aspect for the main character, determining over the course of the game who his or her soulmate ends up being? Maybe there is a synthesis system where objects are combined to make better weapons? Maybe there is a monster breeding system where you breed monsters to create more powerful monsters? Take the most important features you developed while brainstorming and add them here, one paragraph per Feature, briefly explaining it. I would give about two to three, an no more than five. For Spirit of the Deep, I list my features as a Spiritual Linking system, where Totems are linked to Eric, giving him Stat-Boosts and powers, a Herbal Alchemy system , where Eric mixes various herbs to create medicines, and an Elemental Weapon Blessing system, where Eric uses tribal stones, based on the elements, to bless and empower his weapons.

Game Flow Summary is a one to two paragraph outline of how your story will progress during the game. Note I said ‘will’ and not ‘should’. Even if your game is totally sandbox, there needs to be some sort of path that will lead the player to some sort of conclusion, even if it’s the beginning of eternal and endless wandering. If your game is highly cinematic, you may feel compelled to right it all up here. Don’t. Use this sub-section merely to write up the basic way the game will progress. If you have followed the previous articles’ ideas of brainstorming, you more than likely already have this written up. Just copy and paste. For Spirit of the Deep, I wrote about how Eric will arrive at the reservation, have a fight with this Grandfather, pass out from drinking, awaken to find the reservation under attack, witness his grandfather’s death, and everything else leading up to the final battle with Shub-Niggurath.

Look and Feel is the mood of the game. When someone sits down to play the game, what will they see and feel? What is the emotion that you are trying to instill in the player? Are you trying to scare them? Are you trying to make them laugh? Think about how the game is supposed to make the player feel and describe it verbally. But go further than just that, and take a paragraph to just describe the overall ‘feeling’ of the game. Silent Hill, for example, is designed to feel dirty and gritty, like it’s the underbelly of the world, while simultaneously exhibited a sense of madness in its world. Final Fantasy X has a grand and epic journey feeling to it, a game of visual splendor, with a homogenous mixture of organic and inorganic, all the while with an underlying feeling o hopelessly against Sin. For Spirit of the Deep, I wrote that the game starts with a feeling of confusion and disbelief, mind-numbing perplexity at the enormity of the problem, degenerating into an almost mindless rage against a being of incalculable power, before finally calming into a strong and immutable resolve.

Scope of Game Project is the easiest of all the sub-sections under Overview to define. Here you simply name the hardware and software the game is meant to be released upon, keeping in mind that future ports may be required. If this game is for consoles, me sure to note if it’s for hand-held or home-based. If it’s for the PC, note which versions of windows it’s for, and if it’s meant to be native to the Mac. For Spirit of the Deep, I wrote that it’s intended for Windows XP only, with a possible port to Vista in the future.

Congratulations! You just finished your Game Concept Document! Yes, the Concept Document is actually the first section of the GDD. Notice how I didn’t bother to go into depth about the characters? That is because most companies don’t care to hear about the characters during the initial consideration for the game. If they want your main character to be the next Lara Croft, they’ve already decided it. If this game is meant for an independent community, you’d be surprised how often too much information about the characters, before development, can turn a person off to assisting. Sell them on your story and features, then impress them with your characters.

Anyway, now you can attract the next Game Studio with your impressive Concept Document. Let’s assume you have the green flag to forward on this game, and are now tasked with writing the GDD for the entire team. Time to get back into the sections!

The bad news is that Story, Setting, and Characters is next, meaning that you are about to write a lot, revise it even more, and then run it through group collaboration. The good news is that if you followed the first three articles in this series, you’re already finished with most of this writing.

Back Story is just that, the entire back story to the game, what happened before that shapes the game at its start. If you’ve already written this from the rough draft, go on and copy and paste, then pat yourself on the back for making less work for yourself. For Spirit of the Deep, I took my back story from the brainstorming article, tidied it up, and pasted it here.

Setting is where the game will take place, and about one paragraph per general location is a good idea. Give an idea of what the setting is like, the place, the time period, the tone. Don’t go so far into detail that you are describing the places and locations the game takes place in, but at least describe the setting. Silent Hill 3 had two settings, Heather Mason’s hometown and the town of Silent Hill. Final Fantasy X had only one setting, the world of Spira (the Dream World in the prologue and the final dungeon within Sin are considered to be Levels and not settings). For Spirit of the Deep, I wrote that the setting is the local Indian Reservation near Sleepyville, Tennessee, and then went into some detail as to the time period, the time of year, and the local mindset at the time of the game’s events.

Plot Elements are things you want to impress upon your design team and players, things you want to sure your designers, programmers, composers, and artists focus on. Use one paragraph per plot element, and describe concisely what the plot element is that you are focusing upon. This is where you need to not be vague, and if you are afraid of spoilers, this is where you get over it. Start telling everything to your team now, and it will save yourself tons of heartache later on. For Spirit of the Deep, I note that the Plot Elements are the enormity of Shub-Niggurath and disparaging feeling of helplessness when beholding him. I also noted that a Plot Element is Eric’s coming to embrace and live by the ways of his tribe, and to become a true Brave.

Story Progression is really simple if you’ve already written your Rough Draft, as you just need to copy and paste it into this sub-section. If not, then plot down bullet lists of how your story will progress, one major event at a time, and then write a paragraph for every bullet point you have. For Spirit of the Deep, I just copied and pasted what I had already done.

Cinemas are the cut scenes that occur, either with or without the player’s character being present, that move the story along. For each cut-scene, write up a paragraph describing it, starting off with a sentence that describes where in the timeline the cut-scene occurs. If the cinema takes place outside of the game’s natural engine, by virtue of an FMV or something similar, please denote it here as well. Do not write a script! That comes later. For Spirit of the Deep, I plotted down each of the cinemas that appear, like the arrival of the characters at the game’s start, to the fight between Eric and his Grandfather, to the beginning of the attack on the reservation, and so on.

Game World is not to be confused with the Setting. The Setting is the place and time the game takes place in, while the Game World is the place that the player can move about. In Silent Hill 3, Heather only goes to the Hospital, Amusement Park, and Church when in the town of Silent Hill. In Final Fantasy X, the player never goes to a number of the islands to the west and east of the main continent. For each major location that the player will go to, write up a paragraph describing it. Give overall detail, but save the deeper details for when you actually tackle the Levels themselves. For Spirit of the Deep, I went into detail about the Reservations grounds, the huts where the Grandfather and the other elders live, the shanties where Eric and the younger members of the Tribe live, and the various dungeons that Eric visits when gathering power and fighting Shub-Niggurath.

Major Characters are characters that have names and some viable impact on the story. Final FantasyX had a lot of major characters outside of the party, such as the Maesters, the named villains, the Aeons, and a number of characters developed over the course of the game. Any character that gets development during the course of the game is consider, for the purposes of the GDD, a major character. The main characters would be the major characters that the game’s central story focuses upon. One paragraph per character is usually not enough. You should make a sub-sub-section for each major character and describe them in detail: The background, personality, physical traits, abilities, and how they relate to the other major characters. For Spirit of the Deep, I wrote detailed amounts of information about Eric, Trella, the Grandfather, Sheriff Fodie, and Shub-Niggurath.

Supporting Characters are the many characters that have no impact on the story’s progression, and sometimes don’t even have names, just generic names. If the character has a name, or is purposefully nameless, but plays some sort of role in things, give them one paragraph of information about them. Otherwise, a paragraph for, for example, the people of the City of Luca, or the people of Besaid Island, is generally more than enough. For Spirit of the Deep, I wrote up a paragraph about the children of the reservation,, a paragraph about the young adults of the reservation, and a paragraph about the older adults.

After the last section, you may feel that Gameplay and Mechanics is going to be just as tedious, but thankfully it’s less descriptive writing and more actually just saying what something is going to be. For each of these sub-sections, you are detailing an aspect of gameplay, so that the Level Designers know what overlapping information transfers from Level to Level, Map to Map, Event to Event. You can get wordy and verbose if you like, but it’s generally in good form to provide a brief summary at the beginning or ending of each sub-section, so that the Level Designers will have something to quickly reference while in the middle of working.

Game Progression is how the player will progress through the game. Is each stage of the game, a dungeon with objectives? Is there a Boss Fight at the end of each dungeon? Can the player go back to previously visited Levels to obtain previously unfulfilled objectives? Silent Hill 3 had a very linear Game Progression: Heather would got through a dungeon in the Normal World, about halfway through the dungeon, she should shift into the Otherworld, and upon completing that dungeon, Heather would be back into the Normal World. Backtracking could only be down while in that Level, in either the Normal World or Otherworld. For Spirit of the Deep, I wrote that the player progressed through the game by completing quest-style objectives in dungeons accessible through certain areas of the reservation.

Game Objectives are, simply put, the objectives that a player needs to obtain to complete the game. Note that this is not the same as winning the game, as there may be multiple endings some of them bad. One paragraph per objective is enough, but you can possibly get away with one paragraph total for this section. For Spirit of the Deep, I wrote that the game could only be completed by two things: Saving Trella or letting her die, and defeating Shub-Niggurath.

Mission Structure is the structure of how the player will go about completing those objectives and progressing through the game to the ending. This can also be a short or long sub-section, depending on the complexity of the game, and how much you feel the Level Designers need to know. Final Fantasy X’s mission structure is the classic ‘linear movement’ model, where the player must move from a start point to an end point, overcoming obstacles and enemies, in order to complete a mission. A warning about writing too much here, though, for the more that you write, the less creativity you will be allowing your Level Designers. My advice is to detail everything in no more than two paragraphs, three if the game is complex. The rest will come up in the Level section of your GDD. For Spirit of the Deep, I simply wrote that Missions are structured as dungeons located on the game’s overworld, and each dungeon is its own separate and unique experience.


Puzzle Structure is where you define how the generalized puzzles will be solved during gameplay, a template of sorts for your Level Designers. This may seem unusual, but if you analyze most video games, especially more Adventure games and RPGs, you will see that the overall feel of puzzles is the same for most games out there. In Silent Hill 3, most of the puzzles were piecing together clues to form some sort of code or password, or finding the useful combination of items to bypass a challenge. In Final Fantasy X, most of the puzzles were the Cloisters to gain Aeons. For each puzzle template you want to use, write down one to two paragraphs, depending on the complexity of the puzzle involved. For Spirit of the Deep, I wrote that the majority of the puzzles fall under the template of switch hitting to unlock more parts of a dungeon, and then went into depth describing that.

Play Flow is pretty much the repetitious part of the game defined. How does a Level generally play out? Is there a template to use when designing a Level? Are cinemas routine for Play Flow? Silent Hill 3’s Play Flow was about as easy to understand as one can get: Heather enters a level via cinema, gathers information and fights weak monsters, solves a number or item related puzzle to continue to the midway point of the Level. The Heather shifts into the Otherworld through a cinema, proceeds further into the level, accessing areas previously locked off, while fighting stronger monsters. At the end, the world goes back to Normal and there is another cinema. Only the Amusement Park breaks this convention. For Spirit of the Deep, I wrote that Eric moves over the overworld freely, unable to access some places until certain dungeons are completed. For each dungeon, Eric starts with a cinema showing where he is at in his development at that stage in the game, goes through the dungeon, solving switch puzzles, until he comes to the halfway point. At that point, he fights a miniboss, has another cinema where he starts to question an aspect of his behavior and beliefs, then continues onward, fighting more enemies and solving less puzzles. At the end of the dungeon, he fights a boss, gains the Totem there, and then has another cinema in which that aspect of him is resolved. Eric then exits the dungeon.

Level Navigation is really very simple. How does the player navigate the Levels? Does he walk? Does he hope on colored squares? Does he propel forward as he eats? Does he ride on a vehicle? In Final Fantasy X, the player can walk, ride a Chocobo, and ‘teleport’ by means of the Airship. For Spirit of the Deep, I wrote that Eric can walk and teleport on the overworld by means of the Leyline Stones scattered throughout the reservation, if he should manage to active them.

Level Actions is also very simple. What actions can the character perform while on the Map of a Level? Can he push things? Can he move things with his mind? Can he pick things up? What do the buttons on the keyboard or controller do? For Spirit of the Deep, I wrote that the space bar is the action button, allowing the player to interact with the environment, push switches, and move objects on the map around.

Combat is how fighting is handled in your game. This is not a detailed thesis on the battle engine, but a synopsis of how the fighting is to be resolved. Is it a turn-based battle engine? Is it an Active Time battle engine? Is it a real time battle? Is it a strategic battle on a grid-like structure? Is it a mixture of several types of combat? Silent Hill 3 was a real time battle engine, while Final Fantasy X was a modified Turn Based battle engine. For Spirit of the Deep, I wrote that the game uses a side-view Active Time battle engine that has to be scripted away from the default engine.

Gameplay Continuance is how the player’s character will continue to survive as he accumulates damage. Of course, if the character is immortal and can only lose to something like time, is there a way to gain more time? Otherwise, how does a character heal? Are their healing items? Does the character heal over time? Does the character buy healing items? Does he make them? Does he eat other things? Does he recover through rest? Only a paragraph or two detailing the information is needed. For Spirit of the Deep, I wrote that Eric can find First Aid kits, but they are few and far between, so most of the healing items he gains he’ll have to make through Herbal Alchemy…one of the Features of the game.

Economy is simply that, how the game handles money, if at all. Is there a static economy, where everything is set to a set amount all the time? Is there a dynamic economy, where various factors change the amount of money one is charged for a good or service? Is there a barter system where goods are traded for other goods? Write up a paragraph or two for a simple economy system, and more for a more complex one. This is one time it’s totally okay to be verbose, so long as you are being descriptive. For Spirit of the Deep, I got rid of any economy system, saying that pretense of the game was gather items. I did mention that some supporting characters doe give Eric items, but none expect anything in return.


In some ways, this is my favorite part of the GDD, the Levels. First off, yes your game has Levels. Even if the game has such beautiful transparency that the player cannot tell when they are moving from one level to the next, you still have Levels. The definition of a Level from a Game Design standpoint is ‘An area of immediately linked gameplay in which the player’s character must overcome a series of challenges in order to advance.’ A dungeon can be a Level, but so can a Town or region of the Overworld Map. A Level can comprise of one map or several maps. However, unless you are using something like RPGMaker, which requires the use of 2D tile sets to create maps, a level is usually a couple of maps at the most. But regardless of the number of maps or files, once you have identified each area as Levels, you need to submit the following sub-sections for each Level! So if you have one hundred Levels, then you have to go through this little loop one hundred times. The good news is that most Game Designers only start with the opening Levels of the game and add to this section as development continues. Feel free to do the same!

Synopsis is a brief (and by brief we mean two to three sentences) description of the Level, what happens when the player plays it, and what can be the outcome. This is actually a very important part, as it allows others to readily identify if this Level is a dungeon, a safe location, or whatever. Just don’t be ambiguous. Don’t hide things from your developers. It’s an extremely bad idea that will only harm your project later on! For Spirit of the Deep, I wrote about the first Totem dungeon, giving a brief synopsis of the dungeon, what happens in it, and how it is resolved.

Introduction is that opening of the Level, a detailed description of the opening cinemas that occur when the player enters the level. Are there any dialogue? Is there a confrontation? How does the story, and the game itself, pull the player into the Level? Do not spare the detail on this, but don’t go too far, as this is not a play or a movie. Detail up to the point where the player gains control, and then stop. For Spirit of the Deep, I wrote the introduction to the first Totem Dungeon, and how when Eric enters, he accidentally loses his flashlight, and is forced to light an old oil lantern.

Objectives are the goal that must be (or can be) accomplished before the Level is completed. Every good Level will have at least one required Objective and one optional Objective, with rewards for completing the optional Objective. Spend a single paragraph on each Objective, but do not include strategies for reaching that Objective. That’s later! For Spirit of the Deep, I wrote about each of the three Objectives in the first Totem Dungeon, two being required and one being optional, as well as the rewards they gave.

Physical Description is what the Level looks like, and is here that one must learn to be descriptive and imaginative. Drawing on all that inspiration that we talked about earlier, you must detail out what the Level looks like. And not just minor detail, as this will be what the Level Designers base their work off of during development. For example, saying that the Level is ‘a dark spooky forest’ is bad detail, while the better what to say it would be something like ‘the forest is dark and primordial, with hanging moss that suspends like the threads of a spider web, and a lush deep evergreen canopy so think that the sun is choked through and only penetrates in pencil-thin rays’. See the difference? One makes it easier to see what the Game Designer is thinking. The other does not. For Spirit of the Deep, I wrote tremendous detail concerning the first Totem Dungeon, down to the foul smell of the mold and then dank dripping echoes that reverb off the walls at maddeningly irregular intervals.

Maps are just that, maps hand-drawn on graph paper, scan, and pasted into the GDD. If you’re not good at drawing maps, then I suggest you let someone, like a good Level Designer, read your Level’s physical description and draw it himself. It will save tones of time for the actual Level Design. For Spirit of the Deep, I draw a detailed map of the first Totem Dungeon. Sadly, I don’t actually have a scanner, so I can’t share it with you all. Sorry.

Critical Path is the path that the player has to take to complete the Level, and should not, by any means, be the only path to take (unless this is a quick, straight-forward Level that all games seem to want to have). Outline it on your map in red and talk about it in this subsection, going over the things that the player will experience on the critical path. If you’ve ever noticed, really awesome special effects generally only occur when on the critical path. Well, this is why, the critical path gets the most detail, so the Effects Artists will know where to place the best effects. For Spirit of the Deep, I wrote about the critical path through the first Totem Dungeon, detailing the effects and events the player will experience along the way.

Challenges and Solutions are the problems that the player will have to overcome with his character in order to reach Objectives and complete the level. Every Objective is a Challenge, but you can have many more Challenges than Objectives. Combat is considered a Challenge, but has special exception to the rules of writing Challenges and Solutions. Every Challenge must have at least one Solution, but a well-written Challenge that is not combat will have three Solutions. That’s right, if you are a really good Game Designer, and if you have a really good talent for Level Design, you will devise three different ways, or paths, that a player can overcome this Challenge. This takes practice, and is not as easy as I may be making it sound. In many ways, this is the hardest thing about Level Design, making it so that a smart player can figure a way through a problem without having to do exactly what you want them to do. For Spirit of the Deep, I had to come up with three different Solutions for nine Challenges, none of them including Combat, and only six of them leading to an Objective! It was the most time consuming part of this entire Level’s design!

Closing Material is what happens at the end of the Level, when the last Objective has been completed, before the player’s character is moved to the next Level. It should be as verbose as the Introduction, included ending cinemas, and clearly state what Level, or Levels, this one leads into. For Spirit of the Deep, I wrote about the end of the Level, including Eric gaining the First Totem Spirit, getting over his intense negative feelings, and then stepping into a sphere of light that transports him back to the Reservation.


Not to be downplayed, but the User Interface is a very important part of the Game Design process. Without, the player just loads up the game, starts playing, and turns off the game when he’s tired of playing. The User Interface is everything from the Heads Up Display that guides the player through the game to the Menu System that allows them to access certain aspects of the game. And a while a sleek looking User Interface, or UI, is nice, a sleek and transparent one is even better. Transparent means that the UI is so deeply incorporated into the gameplay that it is virtually impossible to tell that you are accessing it during gameplay. It is the dream of every UI Artist and UI Programmer to design the ‘Perfect User Interface’. But first, we must design it!

Heads Up Interface, or the HUD, is the part of the UI that the player sees during the actual gameplay, be they in some sort of Level or some sort of Combat, the HUD is abbreviated data that tells the player important things like stats, button assignments, whose turn it is, whose turn is next, and anything else you can imagine. HUDs have been around since the time of games such as Defender. But it wasn’t until First Person Shooters that they become more than just a way to keep track of Smart Bombs and Scores, and become a way to keep all sorts of vitally important information. Now a days, almost every single game has a HUD, and only the most advent garde games willingly attempt to not have a HUD. For this sub-section of the GDD, think long and hard about the elements you want displayed in your HUD, and how you want them displayed. Then describe the HUD in detail. Now repeat for each HUD you need, including the Battle HUD< if one is needed. Some artist will be coming behind you with a pencil and the hopes that you’ve explained what you want thoroughly. For Spirit of the Deep, I wrote about the Level HUD containing the current time (as the position of the stars in some form of conjunction), as well as Eric’s Health, and the Battle HUD containing Eric’s Life Points, Spirit Points, and Active Time Meter, as well as every enemy’s Active Time Meter above that enemy.

Menu System is how the player navigates the game itself, from assigning items or abilities to loading and saving the game. The Menu should have the same look as the game itself, use similar colors, and most importantly not interfere with the game itself. One of the major trends lately is to have the Menu system be somewhat translucent, although some games, like Silent Hill 3, actually show the game screen in one of the corners of the Menu screen. Make sure you add all the elements needed for the map, an element being something like a button, radial, cursor, drop down list, etc. For Spirit of the Deep, I wrote that the Menu Screen should be a shakily held map, with Eric’s thumbs in view, and every time a new page on the Menu system is turned to, Eric will literally turn the page of the map.

Control Systems is how the character is controlled, and while it’s a pretty short section, is really important to the programmers. Keyboard key assignments, mouse clicks, gamepad button assignments, all very important for the programmer to know, and even more important for the player! When you type up this section, make sure that you don’t assume anything. Tell them what every button does in every context. Buttons may change in battle, or in the Menu, and that needs to be written down. Assume nothing with the Control System, or better yet, assume that the people reading it cannot make any decisions for themselves and need to be told everything. For Spirit of the Deep, I wrote every single keyboard button down and either said what it did, or wrote ‘Unassigned’.

Interface Audio is what it sounds like, the audio needed for the UI. That includes the Me nu System, Battle Menu, HUD, anything that is not directly controlling the character. For this sub-section, get ready to write for everything in your UI. Everything from moving through menus to selecting to canceling to saving to loading needs to be detailed here. Look at the mockup of your User Interface. Now look at each element (an element is a cursor, button, radial, choice, etc). Any part that can be interacted with needs to have a sound associated with it. Now write up those sounds. For Spirit of the Deep, I wrote a detailed description of each element in the UI and detailed want kind of sound it should make for navigating to, from, and activating.

Help System is what the player goes to when they have no idea how to play your game. A lot of developers put them in the instruction manual, but not the game itself, thus cheating players who by used copies of the game from ever understanding how to play. A good Game Designer sets up a Help System in the game with things such as basic control layout, basic gameplay tips, and some helpful hints. The end result is a player who can play the game, even if they have never touched it before, and do well. For Spirit of the Deep, I wrote about the Help System, which contains the Keyboard assignments, a brief explanation of how to play the game, and some tips on being effective in Combat.


When most people think about Artificial Intelligence, or AI, in relation to games, they think about complex enemy actions in First Person Shooter games like Doom, Half-Life 2, or Bioshock. The fact of the matter is that any and all instances where something other than the player is controlling the actions and decisions of a character in a game, some form of AI is needed. While a lot of the AI is determined by the programmers of a game development team, the Game Designer needs to detail what he wants the AI to do for the game.

Enemy AI – Out Combat is what the non-Friendly AI will do outside of combative situations. This can be anything from the paths they take, the conversations they engage in, and the disposition they have towards other characters. A good example would be a pair of enemy guards who patrol a corridor, only to stop and converse with each other about the state of the enemy camp, becoming slightly oblivious to the player character and thefore easier to sneak by. Another example would be an enemy from one group antagonizing, and possibly even attacking, an enemy from another group. It is important to detail at least one, if not two or three, paragraphs worth of information for each group of Enemies. The programmers need specific details to make the AI fit the design’s vision as closely as possible. For Spirit of the Deep, I wrote about how the enemy monsters act when patrolling areas, and what level of awareness of Eric they have, depending on the location and the circumstances, as well as the proximity of the game to its time limit.




Enemy AI – In Combat is similar to the behavior of the Enemy AI out of combat, but this deals with enemies when they are being fought. Things such as strategy, uses of abilities, actions at various levels of life, retreat, and death actions are all important. The programmers, once again, need the detail of what the Game Designer envisions in order to make the AI as functional as possible. Again, a paragraph or two per enemy group is a good start. For Spirit of the Deep, I wrote about the way normal monsters acted during battle, the decisions they would make regarding strategy, and provided a new set of paragraphs for each boss monster.

Friendly AI is the AI for characters that are friendly to the player’s character, but do not actually assist the player’s character in the missions of the game. A friendly AI can assist the player’s character in accomplishing an objective, such as pulling a switch, holding back another enemy, or healing the character, but unless they travel with and act as support, they are just considered friendly. As always, a a paragraph or more is needed, as the programmers need detail to work with. For Spirit of the Deep, I wrote about the other Tribesmen and how they would give Eric items, open new paths for him, and offer hints to the various dangers and challenges that await him.

Support AI is the AI for characters that actually travel with and assist the player’s character, often times fighting along side them. Escorts in escort missions, while not Supportive, are often listed here as they travel with the player’s character. The behavior of this group is important, as it underlines how a computer-controlled character interacts with the player’s character. This include path-finding, supportive actions, offensive actions, and strategies. Generally, more detail is put into Supportive AI than any other. For Spirit of the Deep, I wrote about Trella, how she fights, supports Eric, moves independently of him, and yet is always assisting him.

Indifferent AI is the AI for character that don’t help or hinder the player’s character. Townspersons, animals, and anything that is considered a bystander to the action (not necessarily a bystander to the story) of the game are placed in this category. Unlike Supportive AI, this category is the one needing the least detail. A paragraph per group of Indifferent AI should more than suffice. For Spirit of the Deep, I wrote about the animals of the reservation, and how they acted towards Eric, the monsters, and their environment.


Never to be under sold, never to be under emphasized, a game’s Programming is very important, on par with the art and design of the game. After all, a game without good programming is not going to function well at all, and might as well just be a book or cartoon. It’s the solid programming that offers the interactivity that makes the game playable to begin with. However, a lot of Game Designers think they need to understand how to program in order to communicate to Programmers. This is not very accurate, actually, as Programmers and generally pretty intelligent people, and if you tell them what you need, they will figure out how to do it. The important things is to not hold any information back. Tell them exactly what you need to accomplish, when in the game you need it, and the context. That context is important, as a Programmer without it (context) may misapply the code you need, giving you something that works great, but not in the way you want. So for the Programmers’ sake, your sanity, and your projects’ timeline, give them everything up front.

Game Engine is the game engine itself, and while most games do not have their Programmers write the game’s engine, some do. This section can be many different things, such as the elements needed in the engine to be built, or customizations to an already purchased engine. The key in writing this part is that Game Designer have a keen knowledge of what the needs of the game engine are, and then clearly define them. This should be in the first iteration of the GDD, for no other purpose than if work on an engine needs to be done, it needs to happen as early in the game’s development cycle as possible. Like…the beginning. For Spirit of the Deep, I simply stated that scripts in RGSS would be needed for added functionality.

Scripts are code within the game engine itself, and can be a scripting language native to the engine, such as RGSS, or a library of functions in an actual programming language, such as C++. This sub-section is where the Game Designer must define every script he needs, and add to it when he needs new scripts. Unless he wants the Programmers to name the script (and Programmers have their own unique way of naming things that may not work for the rest of the development team), the Game Designer should name the scripts (usually with ‘under_scores’ or ‘TitleCase’ instead of spaces) something that the development team as a whole can understand. It’s best if, in this sub-section, that the Game Designer detail what he wants out of the script, and puts it in context. Otherwise, the Programmer, through no fault of their own, may not give what the Game Designer what he wants. It also needs to be noted that even though the Game Designer made call each ‘Feature’ a single script, the Programmers made need to make several scripts to accomplish the desired effect. For Spirit of the Deep, I wrote about the scripts I need for the HUD, the Menu System, the Help System, the Spiritual-Linking System, the Herbal Alchemy System, and the Battle System. I made sure, for each script, to fully explain what is needed, and the context under which it is needed.

External Code is jargon for any code, libraries, or scripts, that compile and run outside of the game engine, and run independently of the game’s executable. This could be a physics library, a rendering library, or just about anything that adds or enhances the game beyond the engine’s limitations. Otherwise, the rules for this sub-section are identical for this as they are for Scripts. There was no entry for External Code for Spirit of the Deep, so I didn’t write anything.


Similar to Programming’s Section, the GDD’s section on Game Art is one of those ones where detail is not only important, it’s needed in context. You will be writing a lot in these sections, and the better your grasp on the language you’re writing in, the better it is for everyone in the long run. You see, the artists cannot read your mind, and they cannot see the beautiful world, characters, and cinemas in your imagination. Therefore you, as a Game Designer, need to explain it in a way that they will understand. Get ready, for as little as I type here, you are expected to type that much more. In fact, there is no recommended length for you to type in this section. Write and detail each piece of artwork until you feel you have fully described it as it is in your head. Any detail you don’t give, the artist will do for you, so make sure you want that before you leave something out. Does the main character simply have to have blue eyes? If so, make sure you say that, otherwise you may be faced with a green-eyed main character.

Concept Art is where you will simply lay down your initial ideas, and work with your artists to post initial concept artwork. This section is usually never filled in for the first draft of a GDD, unless you are an artist as well as a Game Designer. Scanned pictures, CG Art, and anything that conveys the conceptual sketches for other artists to work off of is important. As of this article’s writing, this section of the GDD for Spirit of the Deep is empty.

Art Style Guide is a very important part where you, as the Game Designer, detail how you want the Art in the game to look. Is it cartoonish? Anime-stylized? American animations? Disney-stylized? Comic book style? Real life? Show some examples of the style you want every artist on the development team to follow, and not just of characters, but places and things as well. For Spirit of the Deep, I decided to go with the same style as the Conan the Barbarian or Red Sonja comics, that dark and gritty style, and posted pictures of people, places, and things from that comic series.

Characters are descriptions of characters, complete descriptions, and chances are you already wrote a lot of this up during the Rough Draft phase. Do not spare the detail here, but leave just enough room for another artist to be creative. For Spirit of the Deep, I wrote about Eric, Trella, the Grandfather, Sheriff Fodie, the other Tribesmen, the monsters, and Shub-Niggurath.

Environments are descriptions of the places that the player will see while he plays the game. Refer to the Physical Descriptions of each Level from before for the lecture on detail. Be descriptive! Don’t be afraid to come back late rand add more detail. The more you tell the Artists and Level Designers, the more they will make it as you envision it. Just leave some room for creativity! For Spirit of the Deep, I wrote about the Reservation, inside the huts and shanties, the cemetery, the leyline stones, the dungeons, and the last dungeon, the mountain.

Equipment, often called Props, are the items that the characters in the game will use. This is much more than the weapons and collectable items, called ‘drops’, that the player character will use. This is everything that is useable within the game. Note that a crate or car that is part of the scenery, even if it is something the player can interact with (see move or blow up), it’s not a prop. For something to be a prop, a character has to be able to utilize it. Mecha, swords, and First Aid kits are Props. Exploding barrels, trash, and boulders are not. For Spirit of the Deep, I wrote about every piece of equipment, including the stones used in Spiritual-Linking, in the game, how they looked and felt.

Cinemas are the descriptions of those cut-scenes that occur during the game, and are often accompanied with a storyboard. A storyboard is a a frame-by-frame graphical guide of the cinematic scene, often depicted at one frame per one second, showing what will happen from the ‘camera’ point of view. If you are an artist, then draw your storyboards yourself. Otherwise, detail everything that happens, second by second if possible, so that a storyboard artist can make one from your notes. For Spirit of the Deep, I drew storyboards of the cinemas in the game and pasted them to the GDD.

Miscellaneous is anything else that just doesn’t fit in the above categories. Sometimes, particle effects will be places here. Since there is no direct guidelines for this sub-section, just remember the cardinal rule of detail – detail – detail. I have no current Miscellaneous entries for Spirit of the Deep.

The concept of Game Audio is a tricky one, as a lot of Game Designers just slap together any sounds and music they get their hands on and call it a day. Sadly, this means a lot of games fall short of what they could become. A key point to avoid overlooking audio is to consider the music, sound effects, and vocals as three actual characters, and give them the same attention as if they were three additional major characters. Like Game Art, the Game Audio needs as much detail as possible, but instead of describing the visual feel, it’s the aural feel. What feelings and tone do you want the audio to invoke? Be descriptive, come back, revise, and let the Composers, Sound Producers, and Voice Actors do their magic!

Music is background music, action music, and music during cinema. The point here is to describe the mood and tone of each piece of music, put it into context, and then give some examples of what you want to hear. For Spirit of the Deep, I wrote about the background music for the various areas, the score pieces for the various cinemas, and the fast-paced battle music.

Sound Effects are the ambient and direct sounds that add to the atmosphere and create a sense of real world interaction with the characters, environment, and equipment. Tthe point here is to describe what is generating that sound effect, put it into context, and then give some examples of what you want to hear. For Spirit of the Deep, I wrote about the various ambient sounds, the sound equipment makes when used, and the sounds that are made during combat.

Vocals are the voiced lines given by characters, whether in a cinema or spoken during the heat of battle. This is not the script for the Voice Actors to read from, that comes later. This is the type of voice each character with speaking lines should have. This will be very useful for whomever has to cast the voice actors. For Spirit of the Deep, I wrote about the voices for Eric, Trella, the Grandfather, Sheriff Fodie, the other Tribesmen, the monsters, and Shub-Niggurath.

Nearing the end of the GDD, one now talks about the Creation, Installation, Update Software for the game. This is a really simply section, but is needed for both management and for the testers to know. After all, nothing sucks worse than an installation or patch file ruining a game.

Game Engine is the engine that the development of the game will take place on, and whether or not it is to be built from scratch, purchased and modified via Programming, or used out of the box. For Spirit of the Deep, I wrote that it will use RPG Maker XP, with some scripts added.

Installer programs are used to install the game. There are a lot of good free ones out there, so there is never a reason to feel stuck with one over the other. For Spirit of the Deep, I wrote that I planned to use the native RMXP installer, and send the game out as a compressed self-extracting archive.

Patch Schedule is the proposed schedule for releasing patches and game updates. Note that this schedule is often skewed by the people who write patches for one game being the same people who are currently developing the next product. For Spirit of the Deep, I wrote that patches will be released every single quarter, on the 5th of that month.

Update Software is the software used to send out updates and patches. A lot of companies are using out-of-the-box, or customized patching programs that will search for automatic updates, download them, an apply them to the main game, so that the user will never have a non-patched game. The other trend, and still practiced, is the external download, where the customer goes to the nearest download site, downloads the patch, and applies it himself. Either way is currently acceptable. For Spirit of the Deep, I wrote that my game will be updated with users going to the game’s main site, where they can download quarterly updated patches.

Now that you have a comprehensive list of the various pieces and parts of your game, you need to come up with a Design Plan to put the game together. The only part of that section that I will focus on are the actual roles on the Game’s Staff. The concept of Project Management, which is the other part of this section, and deals with timelines and milestones, are WELL beyond the scope of this article. For this section, I didn’t reference anything to Spirit of the Deep, because it is not a real Game Project, but one I am using for the purpose of writing these articles.

Game Design Lead is you, the person who acts as the Game Designer. You can credit yourself as Game Designer, but the official title per project is usually Game Design Lead.

Creative Team are all of the people helping with the major brain storming. While anyone on the team can conceivably brainstorm a good idea, the Creative Team is usually the ones that pioneer the ideas. Technically, everyone on the Game’s Staff can be on this team.

Level Designers are the people who’s primary job is to build maps and script out events. They are generally good at some form of scripting, know the elements of good Level Design, and have an eye for detail.

Artists can be your 3D artists, 2D artists, Texture artists, animation artists, concept artists – basically anyone who satisfies the artistic requirements of the game, up to and including box art.

Programmers are your coders, or as some circles call them, your code-monkeys. These are the people who write the more complex game scripts, or code directly into the source of the engine. They are the ones who make the technology work for you.

Composers are the people who create the music for your game, and can be anything from one man synthesizers to conductors of a symphonic orchestra.

Sound Producers are the people who reproduce the sound effects you need for your game. This has become a bit of an art-form lately, with the Foley Artists not as in demand as they once were. A lot times, game developers will subscribe to a sound effects library.

Voice Actors are the people who provide voices for the characters in your games. In the past these were the same as the programmers and artists and designers. Recently, professional and famous voice actors and actresses have been getting hired onto game projects.

Testers are the most important people in the project – hands down! They are your Quality Assurance! They will find the bugs that will turn people off from your games and make them quit playing. They may be at the bottom of the rung pay-wise, but only a fool would mistreat a good tester.


The final part of the Game Design Document is the Asset List, which is a comprehensive list of artwork, sounds, music, voices, etc needed for game development. This section starts out rather small, and ends up absolutely huge. There can be more sub-sections then what you see, these are just the most common of them. Once again, since Spirit of the Deep is a fictitious game, there will be no real asset list.

Model/Sprite Sheet List are lists of either 3D models or 2D sprite sheets needed for the game. A few sentences with a link to concept art would be the best way to put this sub-section together.

Texture/Tiles List are lists of texture art, for 3D, and tiles, for 2D, needed to add ‘skin’ to the world. A few sentences with a link to the concept art of the environments would be best.

Animations List are lists of either 3D or 2D (or both) animations needed for the game. More detail than the previous two lists are needed, since most animations are created with anything but (maybe) a clay model to work with.

Effects List are lists of particle effects, transition effect, and any other type of special effect needed for the game. Again, more detail helps here, since the artists will be working with nothing more than your written description.

UI Art List is the list of artwork needed for the User Interface, the menus, the HUD, and anything else that overlays the screen. Usually, there will be mockups for the artist to use to compose a finished piece.

Cinemas List is the list of the cinemas in the game, usually in screenplay format. My advice to you is to read up on writing screen plays and write each cinematic sequence as a scene from a movie.. That means notate cuts, shot distance, and dialogue (if any). And for goodness sake, make a storyboard! It will help you and your other designers and artists SO MUCH.

Level Music is a list of music you will need composed for each Level. Inversely, if you are using royalty free downloaded music, then it needs to be just as descriptive as if you had a composer, as the person downloading the music will need to know exactly what to look for.

Scene Music is the list of music you will need for the various cinemas in the game. The information here must be even more detailed, as this will be timing a music to action on screen.

Action Music is the list of music you will need for the various action sequences of the game. Battles, Chases, Minigames, etc. The same rules for detail for Level Music should be followed.

Environmental Sounds is the list of sounds you will need to add enrichment to your environment. So many Game Designers forget the importance of this detail. And in fact, environmental sounds can make or break the mood of a game. Silent Hill 3 was scary and creepy due to the environmental sound effects creeping you the heck out as opposed to the monsters with the female genitals for mouths. Write lots of detail for what you want, and the context you want it in. Trust me, you will not regret it, and your game will be so much better.

Action Sounds is the list of sounds for battles, or actions for moving on the Levels. Everything from footfalls to doors creaking to chests opening to blood splattering needs to be detailed here. If you can visualize yourself walking through your level, then you can write the detail needed for your Sound Producers to make, or gather, the right sounds.

Interface Sounds is the list of sounds for navigating the User Interface. Everything from moving through menus to selecting to canceling to saving to loading needs to be detailed here. Look at the mockup of your User Interface. Now look at each element (an element is a cursor, button, radial, choice, etc). Any part that can be interacted with needs to have a sound associated with it. Now write up those sounds. Now give them to the guys who will bring them to you.

Voice Actor Lines is the script of the game from the perspective of the actors playing the characters. What the characters say, how they should say, and in what context it should be said in needs to be detailed here. This is the most important thing for the voice actors, so I recommend that either you be a good writer, or you get someone who is a good writer to do it for you.

And now, twenty-five pages of Word Document later, I have finished my treatise on the Game Design Document. If you made it this far without skipping, skimming, skimping, or falling asleep, I applaud you and your level of concentration. If you use even a fraction of what we went over here, you will notice your Game Design and Project Management skills undergoing a remarkable improvement.

And all this typing will have been worth it!

Posts

Pages: 1
LouisCyphre
can't make a bad game if you don't finish any games
4523
I feel obligated at this point to tell you how much my side-project owes you.

Also, do I get a prize for reading this

"without skipping, skimming, skimping, or falling asleep"?
Thank you, Chaos. It's for people like yourself that I am writing these Articles, especially this one. I'm glad that could help!

And sure, lol, you can have a prize! How about I base a character off of your moniker in my next game and have him do something that drips of David Busey awesome - like juggling flaming chainsaws and babies...while blindfolded? ;)
I have to say that this article is one of the most useful article I have ever seen, Thanks a lot Mayor. =)
Ehhh....real life came and kicked me in the nards. Long story completely unrelated to game making, but let's just say that I have retrenched and focused on more immediate things than articles on game design. I haven't abandoned this place though. I will finish my series if nothing else. Thanks for asking, though.
Pages: 1