OvervIEW:
“Boxed In”
You start out in a relatively small box, with a maze. You have to press the arrow keys to navigate out of the maze. There will be limited time, each level further increasing the difficulty (that be the size of the “box”, and decreasing the time you have to work with. Mistakes will have a big impact, as it will take a good amount of time away from you. They are not random, as the player will learn how to navigate the mazes with trial and error. You will get points at the end of each level, that being the amount of time you have left, which you can buy power ups and cosmetics with those points.
There are really two core mechanics to this game, one being the countdown timer, which activates when the level starts. It determines your score, when and how the end game procedure starts. The other core game mechanic is the movement, as it is how you control the player and play the game. Movement is instant, as you move until a wall hits you.
The target platform is for PC/Mac/Linux, but would like to have a mobile version as there could be a very good saturation for simple maze like games in the mobile scene. This game will not have any monetization practices. It will cost no money, as all the work is done in class, on the given programs and assets. The time frame is about six weeks, which is very doable, as the game is very rudimentary and has simple mechanics. The team will be comprised of three people.
Title Page
The title page includes general information about the game:
- Game Name :
- Game Logo :
- Game Catch Phrase :
- Document Type :
- Document Version :
Credit Page
The credit page should present information about the person who authored the document and for what company.
- Document Purpose:
- Document Version:
- Working Title:
- Game Concept:
- Game Document Author:
Sign-Off
The sign-off section lists all the people involved (by rank and role) and confirms that each member of the team has read through the document and agrees with the current plan.
GAME CONCEPT SIGN-OFF
- Lead Artist:
- Lead Designer:
- Lead Programmer:
- Lead Producer:
Introduction
The introduction should include a brief sentence or two about the game, its genre, player type, technical form, references and theme. Everyone that reads this should be able to understand what the basic idea of this game is.
A new purpose for the introduction can also be the reason for the concept and history of the game the concept is based upon. Here is a short list of subjects to address in the introduction:
- Genre
- Player Type
- Game Play
- Technical Form
- History
- Reference
- Theme
- Design Intentions (original or cloned)
Game Analysis
The game analysis provides a general overview of the game.
GAME DESCRIPTION
Genre: Describe the Genre, Examples are listed below:
- Role-play
- Adventure
- Strategy
- Puzzle
- Simulator
- Construction & Management
Game Elements
Game elements are the basic activities the player will be doing for fun during the game, Examples are listed below:
- Shooting
- Collecting
- Chase
- Combat
- Dodging
Game Content
Examples are listed below – pick one:
- Horror
- Thriller
- Humor
- Drama
Theme
Examples are listed below – pick one:
- Western
- Sci-Fi
- Fantasy
Style
Examples are listed below – pick one:
- Real
- Old School
- Manga
Game Sequence
Examples are listed below – pick one:
- Linear- Storylines
- Hyper- Storylines that the player can influence
- Simulation
Players
The Number players that can play the game at once
Game Story
Story Idea
- The idea for the story was excellent.
- Message extremely clear.
Characters
- Characters are extremely interesting excellent effort.
- Characters are extremely suitable to storyline.
- Main characters are named and very clearly described (through words and/or images).
Setting
- Many vivid, descriptive words are used to tell when and where the story takes place.
Problem/ Conflict
- It is very easy for the reader to understand the problem the main characters face and why it is a problem.
Game Storyboard
Sketches for all scenes. Shows excellent planning and organization of visual details.
- Titles,
- Detailed notes
- Transitions
- Special effects
- Sound all described
GAME REFERENCE
Game Taxonomy
Game Taxonomy is here as a reminder of what the design direction is.
- Game Taxonomy is made up of Simulation, Game and Narrative based. These can further be divided into Chance, Simulation and Narrative. This is further divided into fiction or non-fiction.
- Example: Xyanide is a Fictional Game/Narrative, while Sim City is a Non- Fictional Simulation/Game.
Player Immersion
This is an attempt to understand what kind of enjoyment the player will receive from the game.
- Example:
- Tactical
- Strategy
- Narrative
- Physical
- Emotional
- Mental
Reference
References can come from anywhere.
- The idea is to describe your game’s story, play, and style with references.
GAME TECHNICAL
Technical Form: Basically there is 2D graphics (Flat) and 3D graphics (Form)
View: Camera view the player will experience the game from
Platform: iOS, Android, Mac, PC
Language: C#, C++, Ruby, Java
Device: PC, Mobile, Console
GAME SALES
Consumer Group: This could involve conducting a research or focus group with actual consumers to gather or validate market acceptance data
Payment: This could involve discussions on monetizing the game and receiving payments from customers
Estimated Price: This could involve market sizing and market pricing strategies for the game product
Game Atmosphere
In the game atmosphere section, it is best to have a mood board or a clear description of the game’s style. This is a good place to start interacting with a graphic designer.
Atmosphere Mood Board
A Level (Locations) Sketch & Description
Character/Units Sketch & Description
Audio Description
Game Play
The game play section is utilized to create a descriptive paragraph about how the game is played. The idea is that you want the person imagine they are actually playing the game. Try not to use ge- neric (i.e. broad, non-descriptive) names when writing about the game play.
Example: Few readers want to hear statements such as: “enemy_1 will have more hit points than enemy_2.” Instead, it is better to make statements such as: “the Lazarus Fighter has more armor than the Apollo Fighter.”
This outline will vary according to the type of game – include what makes sense.
- Opening the game application
- Game Options
- Story Synopsis
- Modes
- Game Elements
- Game Levels
- Player’s Controls
- Winning
- Losing
- End
- Why is all this fun?
Key Features
Key features are a list of game elements that are attractive to the player. It may be a good idea to research the key points below or consult with a professional marketer – include what makes sense.
- Number of Levels
- Number of Enemies/ Characters
- (Example: 12 characters or amount of enemies, end bosses)
- Time of Game Play (Example: 2 hours of fun)
- Replay ability
- Audio Specifications
- Graphic Specifications
- Device Compatibility
- Number of Players
- Online Activities (high scores, etc.)
- Number/Type Modes
Selling Features
This is a list of features that could be potentially helpful to market and/or sell a game. If a game has any copyrightable material, note it here. It may be a good idea to research the key points below or consult with a professional marketer – include what makes sense.
- Marketing Ideas
- Unique Features
- Consumer Group
- Merchandising
Design Document
This document describes how game objects behave, controlled and properties they have. This is
often referred to as the “mechanics” of the game. This documentation is primarily concerned with
the game itself. This part of the document is meant to be modular, meaning that you could have
several different Game Design documents attached to the Concept Document.
Design Version
A version can single out a certain series of devices that may have limitations, different OS or more
advanced features. A code convention for different versions would be advisable.
Design Guidelines
This is an important statement about any creative restrictions that need to be regarded and includes
brief statements about the general (i.e. overall) goal of the design.
Game Design Definitions
In this section, the definition of the game play is established. Definitions should include how a player
wins, loses, transitions between levels, and the main focus of the gameplay.
Issues that should be addressed here are:
Game Matrix
The game matrix is a spreadsheet containing the generic names of the player and antagonistic
elements and their game properties. This should allow an easy cross reference for any elements in the
game that have numerical or other descriptive values associated with their name.
Game Flow Chart
The game flow chart provides a visual of how the different game elements and their properties interact.
Game flow charts should represent Objects, Properties and Actions that are present in the game.
Flow chart objects, properties and actions should have a number reference to where they exist with
in the game mechanics document.
- Menu
- Synopsis
- Game Play
- Player Control
- Game Over (Winning & Losing)
Player Elements
The player elements section lists all the elements that are directly related to the player or serve to
benefit of the player.
Devise two sets of names for player elements.
- One set is a generic name (or code) and
- the other is its game name.
- Describe the terminology that you use to describe the player’s properties.
- This is a good place to interact with a graphic designer to ensure the game graphics match the
game names.
- This is a good place to interact with a graphic designer to ensure the game graphics match the
- Graphics that will be seen during game play should be exhibited here.
- Multi-player issues should also be mentioned here.
Player Definition
Use the player definition section to make quick descriptions that define the player.
Below is a suggested list of player definitions:
Player Properties
Make a list within the player properties section that defines the properties for each player. Player
properties can be affected by player’s action or interaction with other game elements. Define the
properties and how they affect the player’s current game.
A suggested list of player definitions may include:
- Health
- Weapons
- Actions
- Etc.
Each property should mention a feedback as a result of the property changing!
Player Rewards (Power-ups & Pick-ups)
Within the player rewards section, make a list of all objects that affect the player in a positive way.
(i.e. health replenished)
Define these objects by describing what affect they cause and how the player can use the object.
User Interface (UI)
This is where a description of the user’s control of the game can be placed. It is also recommended
to think about which buttons on a device would be best suited for the game. Consider what the
worst layout is, then ask yourself if your UI is it still playable?
A visual representation can be added, where we relate the physical controls to the actions in the game.
When designing the UI, it may be valuable to research quality control and user interface (UI) design information.
- Default (Status): What are the default settings
for the player at the beginning of the game or
level? - Actions: What can the player do?
- Information (Status): What information about
the game is available for the player? - Default Properties: How does the player begin
the game? - Winning: How can the player win?
- Loosing: How does the player lose?
Heads up Display (HUD)
The HUD section is where a description of any graphics that will represent information during game
play should be described.
A visual representation (mock-up screenshot) here would be useful.
This is another good place to seek the advice or collaborationof a graphic designer.
Player View
A screen shot is very necessary in the player view section.
It is also beneficial to include a definition of how the camera moves for the player.
Finally, a (mock-up) overview of the level relative to the screen size will help create a perspective of a
levels size compared to what is actually seen.
Antagonistic Elements
This is where a list of antagonistic (i.e. enemies, opponent) objects should be listed with graphics and
written description.
Describe the terminology that you used to describe antagonistic properties.
Devise two sets of names for player elements. One set is a generic name (or code) and the other is its
game name.
This is another good place to collaborate with a graphic designer to ensure the game graphics
match the game titles, names, and descriptors.
Antagonistic Definitions
This where a description goes of what makes an antagonistic element.
Antagonistic Properties
This is a list of properties that antagonistic elements have in common.
Antagonistic List
This is where a list of all the antagonistic elements goes.
Artificial Intelligence (AI)
This is where visuals and written description(s) of the antagonistic element’s behaviors. These should be
labeled in such a way that they can be used in level design without having to describe them again.
Devise generic names for repetitive behaviors.
This is how an AI action could be deconstructed:
- Normal State: What is the object doing if it has not come in contact with the player?
- Detection State: What does it take for this object to detect the player?
- Reaction State: What does the object do as an action after passing the reaction state?
- End State: What happens to the object after player has reacted correctly or incorrectly to object?
Global Game Elements
In this section, it is important to describe the boundaries, neutral objects, camera views and scale of
the world.
Neutral game world objects can be things like a static background, objects that do not interact with
the player or antagonistic elements.
The Story
This is where the story can be described in detail. A story board can be used to tie in graphics to the
text. This can later be used for splash screen concepts.
The Story Copy
A shorter version of the story (the in game version) should also be written here. This is where the script
for in game characters or story information during the cut scenes would be placed. This category
does not always pertain to the current Game Design.
Concept Art
Sketches that are used for the concept can go into this section as visual reference. In the case of a
brand, certain creative restrictions should be noted here. This is a good place to collaborate with a
graphic designer to ensure game graphics match game names.
Level Design
This is where information pertaining to level design and visuals of the level design goes. Level design
can best be shown as a flow chart. Use generic names to create level design.
Level Copy
This is where the script for in game characters or story information during the cut scenes would be placed.
Audio & Sound F/X
This is where game audio and Sound F/X should be listed, first with generic names and then described.
This section also includes deciding if you will use a device’s vibration ring mode.
Game Architecture
The game architecture section is best produced using a flow chart to represent the overall game.
Be sure to identify (i.e. name, number) each screen.
- Title Screen
- Option Screens
- Game Modes
- End Screens
Game Architecture Overview
The splash screens or video clips need to be in accordance to game story and style.If cut scenes use
video then story boards should be created.
Menus should be designed with the most important options easily accessible. Be aware how many
clicks it takes to accomplish a task.
The game instructions should be written so that the player understands how to play the game.
Mock-ups should be made so that the game programmers get the correct layout of the menu.
It is a good idea to mention and describe the high score screen in this section.
Architecture Copy
All text from the game can be compiled here.
Review the Game Architecture Overview section.
How To Play Copy
This section will organize the game copy.
The game copy includes information for the player, clearly
describing how to play the game.
Technical Document
The information concerning the technical aspects of the game should be placed here. The technical
document is best achieved with consensus from the people responsible for the Visual, Programming,
and Audio aspects. This part of the document is meant to be modular. This means that it is possible to
have several Game Technical documents attached to the Game Design Document (GDD).
System Requirements
This is a list of system requirements that a device will have to meet to run the game.
This also represents the restrictions that may apply to the end product.
Visual Content
A list of technical requirements from those in concerned with the visual aspects of the game. All
objects should be listed with their generic names.
General
- File Size Restrictions
- File Format Type
- File Quality Type
- Visual Scale
Player Elements
- Type of States (Default, Damage, Destroyed, etc.)
- Amount Animation Frames
Heads Up Display (HUD)
- Type Icons
- States
- Font Type
Antagonistic Elements
- Type of States (Default, Damage, Destroyed, etc.)
- Amount Animation Frames
Global Elements
- Background/Texture/Tiles
- Font Type
Audio Content
This is the section for organizing the audio content. It is very important to communicate with the audio
designer before and while the audio content is being developed.
General
- File Size Restrictions
- File Format Type
- File Quality Type
Player Elements
- Type of Sound f/x
- Device Vibration
Antagonistic Elements
- Type of Sound f/x
- Device Vibration
Global Elements
- Ambient Music
Splash Screens
- Ambient Music
Menus
- Type of Sound f/x
Programming Content
The programming content section should help permit good collaboration with the programmer. The
objective of this section (and task) is to try to organize and modulate as much as possible.
General Requirements
- File Size Restrictions
- File Format Type
- Specify Coding Conventions
- Language/Device Restrictions
- Screen Type (Small, Medium, Large)
Player Elements
- Type of States (Default, Damage, Destroyed, etc.)
- Amount Animation Frames
Heads Up Display (HUD)
- Type Icons
- States
- Font Type
Antagonistic Elements
- Type of States (Default, Damage, Destroyed, etc.)
- Amount Animation Frames
Global Elements
- Background/Texture/Tiles
- Font Type
Menus
- Type of Sound f/x
- Font Type
Options
- Add here
Code Structure
This is where an overview of how objects/functions/data interact, a list of what specified functions/routines do and a list of what order modules will be written.
Concerns and Alternatives
If there are concerns about something technical, they should be stated here, along with any
alternatives to the concern.
Resources
The resources section lists applications and equipment that are acceptable for use in the development
of this game. This begins to satisfy a legal challenge that developers must begin to be aware of.
Technical Matrix
The technical matrix section will be split into the different device series for each content category.
The technical matrix includes the content lists of Audio, Visual, and Programming.