Welcome Guest ( Log In | Register )

[ Big| Medium| Small] -

Post new topic Reply to topic  [ 5 posts ] 
    united washcloth express
  Mon Dec 21, 2009 9:23 pm
Silenced Security
User avatar

L1 Slime
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.


• 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.

Final Points

• 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.

Top Top

  Thu Dec 24, 2009 10:12 pm
User avatar

Big Dumb Guy
A good game design doc is VERY important for making a serious game (or one as work). It clearly outlines what you want to achieve, and everything your game HAS to feature. I'm guess you're in Uni right now since we have to do pretty much the same thing. I've actually found it very useful in planning my game (*which I really should have started by now...)

Top Top

  Tue Dec 29, 2009 3:05 am
gamer. reader. writer.
User avatar

Location: Canton, OH
A well written design doc goes a long way to help you not only organize your thoughts, but also to keep you from being overwhelmed or lose motivation to work on your project. I had a general game design class a couple semesters ago where our final grade was a design doc we had made from a template that was provided. I found the template online here. It is probably a bit too comprehensive for what we do here, but I think it is a good example of how a professional design document is organised, and it can provide a good starting place for many of our members.

ΩЬȿίδίαη ρϦϕεηίϗ

Top Top

  Tue Dec 29, 2009 7:51 pm
Golden Sorcerer
User avatar



Last edited by Sailerius on Thu Aug 25, 2011 2:47 am, edited 1 time in total.

Top Top

  Thu Jun 09, 2011 2:32 pm
The Third Man
User avatar

Location: Germany
Now, I really don't want to become the new negative person on game dev forums, but what can I say... I completely disagree with what's been said here so far (except for Sailerius' post, maybe).

A game design doc (just to mention it in this topic once: that stands for documentation, not for document) needs to be an alive media that is developed until the game is finished. It's not meant as a piece of text that's written by one person alone, and neither to be left at whichever initial state it's at, but to change content and expand it upon need.

Having a game design doc like you mentioned it is pretty suitable for a first idea, and in a much less detailed and length. Because that's all you need a non-organic format for: Making sure you don't forget about stuff. As soon as you want other people participate on it, you're fucked when all you have is a non-shareable media such as a text document - you could just as well have a stone plate.
Now, even if that wouldn't be the case, your method sounds pretty much like this specific format is the best to use for all appliances. Not too cool for a non-generally defineable media such as a game.

Now, the reason why I don't say much more to the topic as usually is that Danc can say this much better and with much more success in his past backing him up, and after all, since he convinced me of the method, I would probably just say the same things from here on that he said... so let me link you up to LostGarden.com, which would be his blog. He has an impressive article about just that.

One thing I do agree with you upon is to have a pretty short description of your game. I'm not sure an 8 to 10 pages text is right here - one page max should do it.


If you have a slightly positive memory of my Power Shift contest game,
you might be interested in this development screenshot...
More info about that soon!

Top Top
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 5 posts ] 

Who is online

Users browsing this forum: No users and 4 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

We are an independent, not-for-profit game making community.
Board Index
About Us
Downloadable Games
Free Browser Games
Games in Development
RPG Maker Support
Game Maker Support
Construct 2 Support
HBGames the eZine
Advanced RPG Maker
Site Announcements
Powered by phpBB © phpBB Group