From Computing and Software Wiki

Game Name (TBD)
Windows Cover
Developer(s)		SE 4GP6 GROUP2
Designer(s)		Jeremy Poitras Roshan Jesuratnam Lokesh Thakur
Writer(s)		Jeremy Poitras Roshan Jesuratnam Lokesh Thakur
Engine		C4
Released		TBD
Genre		Action, Strategy, Puzzle
Artwork		Cartoon, Cell Shaded
Rating		TBD
Modes		Single player, Multiplayer
Platform(s)		Microsoft Windows, Mac OS X
Media		CD, DVD or McMaster CAS Server
System requirements		600 MHz CPU, 128 MB RAM, 1.4 GB Hard disk space, 32 MB GPU

(TBD) is a computer game developed by Group 2 of the Software Engineering & Game Design 2009/2010 4GP6 Capstone Project.

All sections of this document are subject to change as the full scope of the product requirements and restrictions become available.

Contents 1 Overview 1.1 Story 1.2 Key Features List 1.3 Functionality and Gameplay 1.4 Pace: Quick and Simple 1.5 Priority in User Experience 2 Customer Requirements (CuRS) 3 Functional Requirements (FuRS) 3.1 System Requirements (SyRS) 3.2 SubSystem Requirements (SuRS) 3.2.1 Main Character SuRS 3.2.2 Capturable Characters SuRS 3.2.3 Friendly Characters SuRS 3.2.4 Enemy Character SuRS 3.2.5 Environment SuRS 4 Usage Aspects 4.1 Players 4.2 World Designers 4.3 Programmers 4.3.1 Controllers 4.3.2 Tools 5 Artwork, Sounds & Animations 5.1 Artwork 5.2 Sounds 5.3 Animations 6 Terminology

Overview

(TBD- GameName) is a 3D action/strategy/puzzle game where players must capture multiple enemies with the intent of building a small army. As the player captures enemies they join the player where he/she can control each unit to further attack and capture larger and more menacing enemies. These friendly units are also used to solve puzzle that help move the player through each level. Levels will have an ultimate goal such as defeating a "Boss" enemy or capturing all units within it to give the user a goal to work towards. Each levels contains new enemies with new abilities allowing for the users experience to evolve with each level.

Story

The story will be kept to a strict minimum so we can focus fully on game play. However the purpose of this story is TBD. The story should give the user a sense of belonging and responsibility in the game world. Story triggers and advancement should be used to introduce new enemies and characters as well as give the user a sense of linearity in the overall story. The user should see how the overall world dilemma is being solved or goal is being achieved. Please keep this in mind when putting ideas on paper.

Key Features List

• Build your army

Like any hero, a humble beginning helps to encourage any underdog to overcome the odds. Capturing small creatures in the environment will help you build up a formidable force to conquer the land and further your goals.

• Interactive creatures/units to create your thrilling army

Creatures for you to overcome are what this game is about; they will all be rendered in the game’s 3D world to ensure that the world is beautiful and immersive as possible, as well as providing a rich combination of creature interactions.

• Play simple & quick, let your creatures help you along the way

Game play shines when a player has to capture another creature. The player can interact with the world directly in only one manner. A "shock wave rifle" will allow the player to impart a force on enemies and objects in an attempt to move them around to his/her advantage while fighting, solving puzzles, or trying to capture creatures. Once a creature is captures, it can be selected and ordered to move, follow the player, attack other creatures and even move object.

• Not all heroes are born of blood and tears

The overall feel of the game however should not be dark or sinister. Creature deaths as well as the overall look of the environment, the creatures, and the larger enemies will be cartoonish. The intent is to focus on game play and bring a light hearted feeling to conquering each level.

Functionality and Gameplay

• Goal of the game

The goal of the game is to conquer each land by assembling an army of creatures to do your bidding.

• Basic game play

The main game play elements will be collecting creatures to help grow your army as well as solving environmental puzzle to help move through each subsection of a level.

As creatures are defeated they will join your army enabling you to defeat and collect larger and more able creatures.

The player is limited in how they interact with the world and rely mainly onthe creatures to do the work.

• Point of view

Set in a 3D environment, the camera will follow behind the player in a standard 3rd person view. The player will have full freedom of rotation but will be limited in how the control the pitch of the camera. This will enable the player to easily control how the select creatures within their army as well as aiming of their "shock wave rifle".

• Interactive creatures/units to create your thrilling army

This game is about the creatures and building armies with them. Our plan for this game is to include as many different types of creatures as possible to make the game play feel diverse and amusing. The table below list possible creatures with their description. If the creation of creatures and their animations ends up being more difficult than expected, time will be spent to analyse if we are able to reduce the number of creatures but make each creature more interactive.

List of Creatures
Creature 1		Render 1
Creature 2		Render 2
Creature 3		Render 3
Creature 4		Render 4
Creature 5		Render 5

Pace: Quick and Simple

The core game play is all about the player’s ability to carefully build an army and decide where and when to try and capture the next level of creature. Depending on the player's current army as well as the strategy they chose to engage the enemy, players can master each level in a combination of ways.

Once a player begins a level

1. Use the environment and the "Shock wave rifle" to capture small non aggressive creatures.
2. Select captured creatures to help solve environmental puzzles as well as attack aggressive creatures, or trap non aggressive ones.
3. If attacking creatures kill a friendly creature it is removed from the game and must be replaced by capturing a new unit.
4. Should the player be attacked and killed, he or she loses the level and must restart. (Levels may have multiple incremental steps).
5. Accomplishing the overall goal brings the player to a new level where he or she can discover new creatures and new puzzles to be solved.

Priority in User Experience

There are four aspects of the user experience that we intend to work on intently to make our game as immersive and enjoyable as possible.

1. Simple controls: The control has to be simple enough to be picked up quickly by any player.
2. Clear objectives: At any moment of the game, the player must know what he has to do and how to do it.
3. Good feedback: For every action you need to have a reaction. Every time an action is performed the game will let the player know(either through graphics or sounds) that the action was performed and what impact it had.
4. Low input and high output: The game has to be simple to play but rewards the player properly in order to keep the player feeling good about their experience and want to continue.

Customer Requirements (CuRS)

(THIS SECTION NEEDS TO BE CHANGED LATER INTO FORMAL REQUIREMENTS "STYLE")

The game will be implemented using the C4 Gaming engine. The C4 engine provides the tools, such as graphics rendering, scene graphs, networking.

The following is a list of the features the minimal system should contain:

• Interface such that a non-expert programmer can customize the game. This includes the development of script elements (the non-expert uses scripts to develop a particular game play). Script elements include: spawn scripts (select object type and parameters to spawn an object), message scripts (display a message on the screen)

• Moving Objects, must have one of the following properties/controller assigned:
  
  • Random move controller,
    
  • Path following controller
    
  • Intelligent evasive controller
    
  • Intelligent chasing controller
    

All objects, including the player will respect each other (collision detection) and the environment.

• Sound effects are played if you catch an object, if you are caught, and a danger warning sound is played if an object or character is approaching you and there is danger that you could be caught.

• Worlds, Artwork, must have at least two sample worlds such as a city and a forest environment. The types of objects should be identifiable by there shape. Other players should be animated, and look different then the default C4 Soldier character.

• User Interface, must implement a splash screen, a menu system (choose network mode, character name, etc.), a current score report, and pop-ups if other players join/leave the game.

• Networking, the game has to be multi player and you have to implement a Server Mode (host a game) and a Client Mode (join a game and participate in play).

• Documentation, must use a documentation tool (e.g. Doxygen or DocBook) for your code, a code repository (so many people can work on the same code), and an on-line electronic tool to write your documentation in your group (e.g. a Wiki).

Functional Requirements (FuRS)

This section describes the functional requirements of the game. Functional requirements describe the inputs, the behaviour, and outputs of a system. The functional requirements for the implementation of the (TBD) game is divided into lower level requirements, namely System Requirements (SyRS) and Subsystem Requirements (SuRS), for modular programming. Following image shows traceability between sets of requirements.

CuRS --> SyRS + Additional RS --> SuRS + Additional RS (Make this into a picture)

Each requirement will have the following attributes assigned to it; Object ID, Title, Statement Type, and Linkages.

Attribute		Description
Object ID		Every requirement, constraint, and goal will have an unique ID assigned for traceability.
Title		Object requirement, constraint, or goal that is to implemented.
Statement Type		Statement type will consist of the following; Technical Requirement - Technical requirements are objects which can be tested by means of acceptance. Constraint - Constraints are restrictions on the degree of freedom for implementation. Goal - Goals are projected low-priority features that enhance the system which are expected to be achieved. Information - Information gives general features of the systems behaviour.
Links		All lower level requirements will be linked to appropriate high level requirements, and vise versa

System Requirements (SyRS)

In addition to customer requirements, this section will itemize all high-level requirements and constraints relevant for sucessful project completion.

SyRS.01--Character is controllable by user--Technical Requirement--Link M.SuRS.01
SyRS.02--Character will have user interface with required information--Technical Requirement--Link M.SuRS.02,M.SuRS.03,M.SuRS.04
SyRS.03--Character will be animated in different states--Technical Requirement--Link M.SuRS.05,M.SuRS.06

CONVERT ALL CuRS into SyRS here, Convert all Usage Aspects into more general statements and put them here!!!

SubSystem Requirements (SuRS)

This section will have specific requirements pertinent to in-game characters.

Main Character SuRS

M.SuRS.01--Character will be able to move through user definable controls--Link SyRS.01
M.SuRS.02--Character will have health bar on UI--Link SyRS.02
M.SuRS.03--Character will have "force gun" ammunition count on UI--Link SyRS.02
M.SuRS.04--Character will have count of enemies captured on UI--Link SyRS.02
M.SuRS.05--Character will "run" when user-definable key is pressed on UI--Link SyRS.03
M.SuRS.06--Character will "jump" when user-definable key is pressed on UI--Link SyRS.03

Usage aspect will go here and will be more detailed, and make all system requirements more specific relation to character.

Capturable Characters SuRS

C.SuRS.01--Characters will move based on required controller behaviors as stated in the CuRS
C.SuRS.02--Character's health will be displayed on screen as a symbol.
C.SuRS.03--Characters will be qualitatively larger or smaller than the playable character.
C.SuRS.04--Characters will be created in Lightwave 3D.
C.SuRS.05--Characters will be textured in Lightwave 3D.
C.SuRS.06--Characters will be animated in Lightwave 3D.
C.SuRS.07--Character's rate of speed will be definable through controllers.n
C.SuRS.08--Character's rate of rotation will be definable through controllers.
C.SuRS.09--Characters will respect all laws of physics as supported by the programming engine.

Friendly Characters SuRS

Enemy Character SuRS

E.SuRS.01--Enemies shall be bigger in size (2x,3x bigger)--Technical Requirement-- E.SuRS.02--Enemies shall be created in Lightwave 3D E.SuRS.03--Enemies shall be textured in Lightwave 3D E.SuRS.04--Enemies shall be animated in Lightwave 3D E.SuRS.11--Enemies shall be imported into C4 Engine through COLLADA E.SuRS.12--Enemies animations shall be imported using COLLADA in .dae format E.SuRS.05--Enemies rate of speed shall be definable through controllers E.SuRS.13--Enemies path E.SuRS.06--Enemies shall respect all laws of physics E.SuRS.07--If Enemies are pushed by gravity gun, then Enemy shall move XX__PUSHDIST in direction of push E.SyRS.xx--Enemies shall have the capabilities to attack friendly units E.SyRS.xx--Enemies shall have the capabilities to attack main character E.SuRS.08--Enemies characters shall be defined through Enemy Controller E.SuRS.09--Enemies will be controlled through Enemy Manager E.SuRS.10--Enemies will be

Attackers Attacking characters will actively seek out and attack players as well as a players friendly units. Initially, attackers will simply "roam" or "wander" in designated areas based on map design and placement. Should an attacker encounter an enemy, ite will then actively seek out that enemy in an attempt to destroy it. If the enemy is too quick and can distance itself adequately from the attacker, the attacker will simply return to its original roaming zone and wait for the next attacker to approach.

Enemy Manager The enemy manager will enable programmers to maintain a working list of the current active enemies or non "friendly units" in the world.

Environment SuRS

Usage Aspects

Players

Players must have all tools and necessary controls to correctly move the avatar within the game. The following attributes outline major components the user has to work with;

• Player Control
  The player must have the ability to move through the world by walking, running and jumping.

• World Interaction
  The user must have the ability to interact with the world.

• Multiple Unit Selection
  The user must have the ability to select multiple units at one time.

• Unit Management
  (Optional) The user must have the ability to quickly select subsets of units.

• H.U.D
  Used to display pertinent and important information to the user such as health, number of units remaining, etc.

• Console Commands
  Changing mouse sensitivity
  Changing controls
  Etc.

World Designers

World designers will have most interaction in the World Editor of the C4 Engine. The following attributes must be streamlined to optimize efficiency and reliability.

• Generating Paths
  World Designers need a mechanism for creating a path that will be followed by a creature

• Placing Players
  World Designers need a mechanism for placing a player in the world with the appropriate model

• Placing Enemies
  World Designers need a mechanism for placing creatures in the world with the appropriate model and behaviors.

• Placing Elements
  World Designers need a mechanism for placing objects in the world with the appropriate model and appropriate interaction behaviors.
  (Eg. Can be picked up by creature x, can be moved by player.)

Programmers

Based on the current customer requirements as well as the game concept/play mechanics outlined in this requirements document, the developers will require the following set of design tools.

Controllers

• Path followers
  Given a set of location markers in the world/level an NPC should follow the path marked out by these markers in a repeating loop.
  A path follower will travel faster than the player such that the player will be required to first analyze the path being followed before he/she can effectively capture the unit.

• Evaders
  Evasion NPCs should simply try to avoid being captured by ALL active players.
  Evaders will attempt to run from the closest player using different strategies such as zig-zag, random turns and random direction changes.
  Evaders will run only slightly slower than the player, making it possible for the player to capture the unit.

• Attackers
  Attacking characters will actively seek out and attack players as well as a players friendly units.
  Initially, attackers will simply "roam" or "wander" in designated areas based on map design and placement.
  Should an attacker encounter an enemy, ite will then actively seek out that enemy in an attempt to destroy it.
  If the enemy is too quick and can distance itself adequately from the attacker, the attacker will simply return to its original roaming zone and wait for the next attacker to approach.

• Random Runners
  Place in the world based on map design these NPC simply run around in random directions waiting to be captured. Random runners will run slightly slower than the player making it possible for the player to capture the unit.

• Follower
  Once a unit has been captured, the unit will follow the player as a "friendly unit". The unit should always follow the player within a given radius. Unit speed will be based on the units' size and properties.
  Larger units may walk slower than the player.

Tools

• Enemy Manager
  The enemy manager will enable programmers to maintain a working list of the current active enemies or non "friendly units" in the world.
  

• Friendly Unit Manager
  The friendly unit manager will enable programmers to maintain a working list of the active friendly units tied to a specific player.
  

• Controller Manager (Local)
  The controller manager will enable programmers to attach and manage multiple controllers designated to a single unit.
  

• Selection Manager
  The selection manager will enable the programmer to maintain a working list of the current friendly units that are selected to perform an action.
  

• Path Determination
  Given two points, mainly the units current location and a destination, the unit should dynamically find the most efficient path to its destination taking into account the terrain as well as any potential obstacles.
  

• Multiple Unit Selection
  Based on a geometry drawn by the user onto the playing field, a list of friendly units that appear within that bounding geometry should be built.

Artwork, Sounds & Animations

Artwork

The artwork of the game is very simple and unporportioned to give a cartoon like appearance. Environments will consist mainly of open concepts with moderate to high lightning. The feel of the game is aimed to target players of all ages and is intended to give a overall 'warm' feeling to the player.

• (TBD-Name) is the main protangnist of the game. He is of moderate height compared to the rest of the characters. He is very simple phsyically, with attributes similar of a (TBD - Add more as character is created)
• (TBD-Name) are catchable characters within the game. They vary is size, shape, and texture. They are smaller than the main character but various features to distinguish their properties.
• (TBD-Name) are enemy characters which vary from size to shape to physical appearance. They can be distinguished by their larger size and more agressive and darker look.

Sounds

Due to limited resources and experience in creating sound effects and soundtracks, this game will feature existing samples from video games that already exist on the market. Since this game is non-commercial, VGMusic.com and other various sources may be used to generate any sound effects and soundtracks used throughout the game.

Sounds might also be created through applications such as Apple's Garageband and mixed in with existing soundtracks.

Animations

Characters are created in Newtek's Lightwave 3D and imported into C4 Editior using the COLLADA plugin. The characters skeleton and editable mesh will be weighted and exported into COLLADA fully reset and non-scaled. All animations such as running, walking, jumping, dying, attacking, shooting, etc will also be loaded into COLLADA and will be created in Lightwave as appropriate. From this, characters and corresponding animations will be loaded into the C4 Model Editor where it will be assigned to each other for usage in design.

Terminology

• NPC - Non Player Controlled Character
• H.U.D - Heads up display
• Friendly Creature - Captured creature controlled by the player
• Unit - Interchangeable with Friendly Creature