Creating a Proper Game Doc
01-28-2010, 08:15 PM
I posted this on .Org a while back, and it has helped some people. This is EXTREMELY important if you are considering any form of Game Development as a career
How to Create a Game Doc
Just why are Game Docs important?
Game Docs are used within the industry to organize a design, and tell workers what needs to be done. Game Docs contain the absolute base features of a game first. These are the features that cannot be changed. Over time, as the Game Doc updates, more features can be added. These features are subject to change.
Just what is inside a Game Doc?
The sections of the Doc are as follows*:
1. Table of Contents
2. Introduction/Overview
3. Game Mechanics
4. Artificial Intelligence
5. Game Elements
6. Story Overview
7. Game Progression
8. System Menus
*Note: This is the format you will want to use when creating your Game Doc.
Table of Contents
* The Table of contents must include sub-sections, sub-sub-sections, etc. This is crucial to a table of contents.
* Indexing a book, document, manual is difficult. With a good of Table of Contents, indexing is not really needed.
There is nothing special here. The Table of Contents is just a table of contents. When it comes to sub-sections, break up the Game Doc logically. If an important topic relating to say, Game Mechanics is being discussed, than break that specific part in to a new paragraph and label it.
Introduction/Overview
* Have a short overview of your games design at the beginning of the document; this will be especially helpful to new team members that come on board.
* Try very hard to limit it to a single page.
* Have the games focus as the opening paragraph of the page.
* Start to conclusion, what adventures the player(s) will have during the gameplay (don't dwell on back story or history to much). Go all the way through to the games conclusion mention any different worlds the player will go to.
* Also cover the features of gameplay that are central or most central to the game.
This is the Mission Statement of the Game Doc. Make sure to cover the bullet points. Keep it short.
Game Mechanics
* Game Mechanics is probably the most important part of the document. It describes what the player is allowed to do and how the game will be played.
* Write about the gameplay - this very hard to do, but it must be done, otherwise the game development tends to become much unfocused.
* You are documenting the core game in the Game Mechanics section. Cover things such as: How the character moves, complex moves (jumping, crouching, rolling, etc.), point and click, movement keys. Player path-finding should be addressed.
* List movement keys as âForward Button, Sidestep Button, etcâ, instead of the Up Arrow, Blue Thumb Button, etc.
* Movement model - does it follow realistic physics or some simpler method. What happens when it runs into an obstacle, acceleration, turning, stopping, etc.
* If the first thing is say, Character Creation, then you want to talk about that first.
* The different type of game mechanics should flow one into the other. The type of and variety of puzzles, if any, should be described in this section also.
* Must know if the game is 2D or 3D game. Play on the strengths and avoid the weakness of the system.
* The GUI should be described here, this one the biggest areas people forget to describe fully, and this is the way that players and games interact.
* Try not to assume anything. If you think it obvious, someone else may not, write it down.
Do not worry about length. This section will be long and will take time. Make sure to cover the *core mechanics.* Do not feature creep. Include features and mechanics that are absolutely important to the game itself. Do not include fluff or features that are not required. These features can come later. Worry about the foundation before you worry about the extraneous content.
Artificial Intelligence
* This section will cover how the game will react to the player's actions.
* This will describe how the game-world behaves when the player is not doing anything.
* Some authors put the AI sections in the Game Mechanics chapter. Some believe that they should be separate. If you are writing the document à You Make the Call.
* Do your best to fully describe how you expect the game to behave for the player.
* AI for strategy games is usually more involved. Is the AI a match for the player strategy-wise or does the computers just have more and better units than the player?
* Try to refer to general behaviors, not specific units. Specific units will be covered in the Game Elements section of the document.
* Do not assume anything, be complete.
This tends to be the hardest section for most people. As stated, stick to general behaviors, and how the game behaves to the actions of the player.
Game Elements
* Up to you to list characters, items, and objects before or after the story sections. Do what you think makes sense.
Characters: All the enemies the player will fight, the different AIs in the game, any one who has a conversation with the player. It is up to the writer to determine whether the NPCs that may follow the play should be described here or in the Objects/Mechanisms section
* Items: Anything the player can pick up, use, manipulate in some fashion.
* Objects/Mechanisms: items that are not AI driven, doors, locks, switches, puzzle elements or other objects which can be manipulated through the course of the game. NPCs that follow the character around may also be described here.
* Be logical in the descriptions.
* Try not to assigning actual statistics, this really cant be done until you have a functional game.
How do the elements compare to each other, in strength, damage, difficulty to acquire and use, etc. What AI elements will be used? How do the items/characters/objects appear to the player? Include enough information for a programmer to understand what code will be required for the entity and sufficient description that an artist will be able to make a concept sketch.
Avoid Fluff. That is it.
Story Overview
* Not necessary, but very good to have if the game has a story.
* It should be an easy to read narrative of the games story.
* Keep to a readable length and include the stories major points. This is not always easy to do.
* Don't need to include games sub-quests and side stories.
Summarize the story. Do not go in to full dialog and minor details. Hit key points of the plot and that is it. Even if you are making an RPG, try to keep this section focused on the key points of the plot. This section is not necessarily required, but in my opinion, at least give a quick overview of the world the game takes place in. Include some history. It makes it easier for the artists.
Game Progression
* Can be the longest section of the document
* Level designers use this section as a guide for the levels they will create.
* Must describe the challenges that the player will face at level.
* How will the level communicate the game's story?
* How will the level affect the player à will they be scared, happy, angry, etc.
* If the game doesn't have levels then it should have stages: Try to break down the stages of the game.
* Some games don't need a Game Progression sections. Examples: Sim City, Civilization, Command and Conquer could all be described in the Mechanics section of the document.
If the game requires this section, be specific. Regardless of personal beliefs, level designers are the deciding factor in whether or not a game is fun. Keep this in mind when writing this section. The more detail level designers have, the easier it is to create something.
System Menus
* Detail the main menu and option screens the player has.
* Describe the GUI at this point also.
* Be detailed on how the menus flow together, are accessed etc.
* Will the menus be using buttons, keys, enter key, mouse, analog stick, etc.
* Producers love this part.
This is usually the easiest part of the document. Cover the bulleted points and everything will be fine. Describe the shape of the buttons if you wish. Go crazy.
* Don't write War and Peace as a Design Doc.
* Don't make the game Wafer Thin; a 20 to 40 page Final Design Document will worry most produces.
* Don't concentrate on Back Story to much â back story is important for some games, if it needs a lot of back story, then have a separate story document.
* Be realistic. Don't try to model 20 million people running around a giant Metropolis of the future.
* KEEP THE DOCUMENT UP TO DATE Ã Can't stress this enough.
KEEP THE DOC UP TO DATE. KEEP THE DOC UP TO DATE. KEEP THE DOC UP TO DATE. KEEP THE DOC UP TO DATE. KEEP THE DOC UP TO DATE. ?In case you missed the last bullet point. This is terribly important. Be realistic. Do not include 30 levels if you have a tiny design team. Good games take time to make. Do not give team members unrealistic goals to accomplish. They will kill you.
Why do I need a Game Doc? My game is not that serious.
Game Docs allow the creators to organize and communicate points. Even if creating games is a hobby, a Game Doc will help. 20 to 40 pages are not hard to hit, especially if the Doc is double spaced. It may seem like a large amount at first, but you will find yourself passing this amount as you progress through the Doc.
How to Create a Game Doc
Just why are Game Docs important?
Game Docs are used within the industry to organize a design, and tell workers what needs to be done. Game Docs contain the absolute base features of a game first. These are the features that cannot be changed. Over time, as the Game Doc updates, more features can be added. These features are subject to change.
Just what is inside a Game Doc?
The sections of the Doc are as follows*:
1. Table of Contents
2. Introduction/Overview
3. Game Mechanics
4. Artificial Intelligence
5. Game Elements
6. Story Overview
7. Game Progression
8. System Menus
*Note: This is the format you will want to use when creating your Game Doc.
Table of Contents
* The Table of contents must include sub-sections, sub-sub-sections, etc. This is crucial to a table of contents.
* Indexing a book, document, manual is difficult. With a good of Table of Contents, indexing is not really needed.
There is nothing special here. The Table of Contents is just a table of contents. When it comes to sub-sections, break up the Game Doc logically. If an important topic relating to say, Game Mechanics is being discussed, than break that specific part in to a new paragraph and label it.
Introduction/Overview
* Have a short overview of your games design at the beginning of the document; this will be especially helpful to new team members that come on board.
* Try very hard to limit it to a single page.
* Have the games focus as the opening paragraph of the page.
* Start to conclusion, what adventures the player(s) will have during the gameplay (don't dwell on back story or history to much). Go all the way through to the games conclusion mention any different worlds the player will go to.
* Also cover the features of gameplay that are central or most central to the game.
This is the Mission Statement of the Game Doc. Make sure to cover the bullet points. Keep it short.
Game Mechanics
* Game Mechanics is probably the most important part of the document. It describes what the player is allowed to do and how the game will be played.
* Write about the gameplay - this very hard to do, but it must be done, otherwise the game development tends to become much unfocused.
* You are documenting the core game in the Game Mechanics section. Cover things such as: How the character moves, complex moves (jumping, crouching, rolling, etc.), point and click, movement keys. Player path-finding should be addressed.
* List movement keys as âForward Button, Sidestep Button, etcâ, instead of the Up Arrow, Blue Thumb Button, etc.
* Movement model - does it follow realistic physics or some simpler method. What happens when it runs into an obstacle, acceleration, turning, stopping, etc.
* If the first thing is say, Character Creation, then you want to talk about that first.
* The different type of game mechanics should flow one into the other. The type of and variety of puzzles, if any, should be described in this section also.
* Must know if the game is 2D or 3D game. Play on the strengths and avoid the weakness of the system.
* The GUI should be described here, this one the biggest areas people forget to describe fully, and this is the way that players and games interact.
* Try not to assume anything. If you think it obvious, someone else may not, write it down.
Do not worry about length. This section will be long and will take time. Make sure to cover the *core mechanics.* Do not feature creep. Include features and mechanics that are absolutely important to the game itself. Do not include fluff or features that are not required. These features can come later. Worry about the foundation before you worry about the extraneous content.
Artificial Intelligence
* This section will cover how the game will react to the player's actions.
* This will describe how the game-world behaves when the player is not doing anything.
* Some authors put the AI sections in the Game Mechanics chapter. Some believe that they should be separate. If you are writing the document à You Make the Call.
* Do your best to fully describe how you expect the game to behave for the player.
* AI for strategy games is usually more involved. Is the AI a match for the player strategy-wise or does the computers just have more and better units than the player?
* Try to refer to general behaviors, not specific units. Specific units will be covered in the Game Elements section of the document.
* Do not assume anything, be complete.
This tends to be the hardest section for most people. As stated, stick to general behaviors, and how the game behaves to the actions of the player.
Game Elements
* Up to you to list characters, items, and objects before or after the story sections. Do what you think makes sense.
Characters: All the enemies the player will fight, the different AIs in the game, any one who has a conversation with the player. It is up to the writer to determine whether the NPCs that may follow the play should be described here or in the Objects/Mechanisms section
* Items: Anything the player can pick up, use, manipulate in some fashion.
* Objects/Mechanisms: items that are not AI driven, doors, locks, switches, puzzle elements or other objects which can be manipulated through the course of the game. NPCs that follow the character around may also be described here.
* Be logical in the descriptions.
* Try not to assigning actual statistics, this really cant be done until you have a functional game.
How do the elements compare to each other, in strength, damage, difficulty to acquire and use, etc. What AI elements will be used? How do the items/characters/objects appear to the player? Include enough information for a programmer to understand what code will be required for the entity and sufficient description that an artist will be able to make a concept sketch.
Avoid Fluff. That is it.
Story Overview
* Not necessary, but very good to have if the game has a story.
* It should be an easy to read narrative of the games story.
* Keep to a readable length and include the stories major points. This is not always easy to do.
* Don't need to include games sub-quests and side stories.
Summarize the story. Do not go in to full dialog and minor details. Hit key points of the plot and that is it. Even if you are making an RPG, try to keep this section focused on the key points of the plot. This section is not necessarily required, but in my opinion, at least give a quick overview of the world the game takes place in. Include some history. It makes it easier for the artists.
Game Progression
* Can be the longest section of the document
* Level designers use this section as a guide for the levels they will create.
* Must describe the challenges that the player will face at level.
* How will the level communicate the game's story?
* How will the level affect the player à will they be scared, happy, angry, etc.
* If the game doesn't have levels then it should have stages: Try to break down the stages of the game.
* Some games don't need a Game Progression sections. Examples: Sim City, Civilization, Command and Conquer could all be described in the Mechanics section of the document.
If the game requires this section, be specific. Regardless of personal beliefs, level designers are the deciding factor in whether or not a game is fun. Keep this in mind when writing this section. The more detail level designers have, the easier it is to create something.
System Menus
* Detail the main menu and option screens the player has.
* Describe the GUI at this point also.
* Be detailed on how the menus flow together, are accessed etc.
* Will the menus be using buttons, keys, enter key, mouse, analog stick, etc.
* Producers love this part.
This is usually the easiest part of the document. Cover the bulleted points and everything will be fine. Describe the shape of the buttons if you wish. Go crazy.
* Don't write War and Peace as a Design Doc.
* Don't make the game Wafer Thin; a 20 to 40 page Final Design Document will worry most produces.
* Don't concentrate on Back Story to much â back story is important for some games, if it needs a lot of back story, then have a separate story document.
* Be realistic. Don't try to model 20 million people running around a giant Metropolis of the future.
* KEEP THE DOCUMENT UP TO DATE Ã Can't stress this enough.
KEEP THE DOC UP TO DATE. KEEP THE DOC UP TO DATE. KEEP THE DOC UP TO DATE. KEEP THE DOC UP TO DATE. KEEP THE DOC UP TO DATE. ?In case you missed the last bullet point. This is terribly important. Be realistic. Do not include 30 levels if you have a tiny design team. Good games take time to make. Do not give team members unrealistic goals to accomplish. They will kill you.
Why do I need a Game Doc? My game is not that serious.
Game Docs allow the creators to organize and communicate points. Even if creating games is a hobby, a Game Doc will help. 20 to 40 pages are not hard to hit, especially if the Doc is double spaced. It may seem like a large amount at first, but you will find yourself passing this amount as you progress through the Doc.
Sailerius Wrote:YES! It's about time we got a thread on game design docs. One of my professors last semester had a lot to say on the subject. He told stories about how their company would be contractually obligated to make a design doc, which would answer every question that anyone on the team could ever ask. It was written in such a way that if anyone had to ask the producer a question about what the UI is supposed to look like or how a menu was supposed to flow, he could say "it's in the design doc."
Of course, no one likes to read, even if doing so would make their life easier, so as a result, it usually gets glossed over by anyone that would ask a question about it. As a result, my professor explained, it's become common for the writer of the design doc to hire an artist just to make illustrations for the design doc so that someone 'reading' through it would actually be interested enough to keep leafing through it.
"Who is the design document for? Everyone."
"Who reads it? No one."
This culminated in the following rule of thumb:
Content Hidden Spoiler
"The usefulness of a design doc is directly proportional to how much it resembles a comic book."
