Project Management Plan

toycutnshootΔίκτυα και Επικοινωνίες

27 Οκτ 2013 (πριν από 3 χρόνια και 11 μήνες)

513 εμφανίσεις


1



Project
Management Plan

Final Project, Full Sail University




2009

Version 2.5

7/
31
/2009

Christopher Lewis

lewischrisprimer@gmail
.com

Ari
Patrick


ari.patrick@gmail.com

Brian Sorin


bsorin@fullsail.edu


2

Project Team Approval

Programming Lead:







Date:

Art Lead:








Date

Technical Lead:








Date:

Gameplay Lead:







Date:

Programmer:








Date:

Programmer:








Date:

Programm
er:








Date:

Programmer:








Date:

Programmer:








Date:

Programmer:








Date:

Programmer:








Date:

Programmer:








Date:

Programmer:








Date:

Artist:









Date:

Artist:









Date:

Artist:









Date:





I
nternal Producer

Date




External Producer

Date


3

Table of Contents

Project Team Approval

................................
................................
................................
................................
................................
...

2

Project Charter

................................
................................
................................
................................
................................
.................

5

Project
Purpose

................................
................................
................................
................................
................................
.........

6

Project Objective

................................
................................
................................
................................
................................
.......

6

Stakeholders

................................
................................
................................
................................
................................
...............

6

High Level Requi
rements
................................
................................
................................
................................
........................

8

Project Constraints

................................
................................
................................
................................
................................
.
14

Assumptions

................................
................................
................................
................................
................................
.............
15

High Level Risks

................................
................................
................................
................................
................................
......
16

Summary Budget

................................
................................
................................
................................
................................
.....
1
7

Scope Management Pl an
................................
................................
................................
................................
..............................
18

Projec
t Scope Statement

................................
................................
................................
................................
.........................
19

Work Breakdown Structure (WBS)

................................
................................
................................
................................
........
47

WBS Di cti onary
................................
................................
................................
................................
................................
..........
47

Scope Pol ici es

& Procedures
................................
................................
................................
................................
...................
47

Schedul e Management Pl an

................................
................................
................................
................................
........................
49

Acti vi ty List and Attri butes

................................
................................
................................
................................
......................
50

Resource Breakdown Structure
................................
................................
................................
................................
..............
50

Project Schedul e

................................
................................
................................
................................
................................
.......
51

Schedul e Baseli ne

................................
................................
................................
................................
................................
.....
56

Schedul e P
oli ci es & Procedures

................................
................................
................................
................................
.............
56

Staffi ng & Communi cati ons Management Pl an

................................
................................
................................
.......................
58

Project Rol es and Responsi bili ti es

................................
................................
................................
................................
.........
59

Organi zati onal Chart

................................
................................
................................
................................
................................
69

Responsi bi li ty Assi gnment Matri x
................................
................................
................................
................................
..........
70

Performance Report

................................
................................
................................
................................
................................
.
71

Team Acqui
si ti on
................................
................................
................................
................................
................................
.......
71

Resource Schedul e
................................
................................
................................
................................
................................
....
71

Rel ease Plan

................................
................................
................................
................................
................................
...............
72

Trai ni ng Needs
................................
................................
................................
................................
................................
...........
72

Recogni ti on
and Rewards
................................
................................
................................
................................
........................
81

Compl iance

................................
................................
................................
................................
................................
................
81

Safety and Securi ty

................................
................................
................................
................................
................................
...
86

Staffi ng and Communi cati ons Poli ci es & Procedures
................................
................................
................................
.........
89

Issue Log

................................
................................
................................
................................
................................
.....................
97


4

Ri sk Management
Pl an

................................
................................
................................
................................
................................
.
98

Risk Approach

................................
................................
................................
................................
................................
..........
99

Risk Register
................................
................................
................................
................................
................................
.............
99

Stakeholder Ri
sk Tolerances
................................
................................
................................
................................
.............

101

Assumptions

................................
................................
................................
................................
................................
..........

101

Risk Breakdown Structure
................................
................................
................................
................................
.................

104

Pr
obability and Impact Matrix
................................
................................
................................
................................
..........

105

Owners Roles and Responsibilities

................................
................................
................................
................................
.

105

Risk Budgeting

................................
................................
................................
................................
................................
......

106

Risk Policie
s & Procedures

................................
................................
................................
................................
................

107

Quali ty Management Pl an
................................
................................
................................
................................
.........................

109

Quali ty Poli cy

................................
................................
................................
................................
................................
..........

110

Quali ty Base
li ne
................................
................................
................................
................................
................................
......

110

Quali ty Requi rements

................................
................................
................................
................................
...........................

110

Quali ty Metri cs

................................
................................
................................
................................
................................
.......

110

Quali ty Assu
rance Polici es and Procedures

................................
................................
................................
......................

131

Quali ty Control Poli ci es and Procedures

................................
................................
................................
...........................

132

Quali ty Process Improvement Pl an

................................
................................
................................
................................
....

135

Appendi x A


Stakehol der Regi ster

................................
................................
................................
................................
.........

140

Appendi x B


Work Breakdown Structure
................................
................................
................................
..............................

141

Appendi x C


Work Breakdown Structure Di cti onary

................................
................................
................................
..........

142

Appendi x D


Acti vi ty Li st

................................
................................
................................
................................
..........................

192

Appendi x E


Ri sk Register

................................
................................
................................
................................
........................

222

Appendi x F


Scope Management Forms

................................
................................
................................
...............................

223

Appendi x G


Schedul e Management Forms
................................
................................
................................
.........................

229

Appendi x H


Staffi ng & Communi cati ons Management Forms
................................
................................
........................

235

Appendi x I


Ri sk Management Forms
................................
................................
................................
................................
....

242

Appendi x J


Qual i ty Management Forms

................................
................................
................................
.............................

244

Appendi x K
-

Fi nal Project Documents

................................
................................
................................
................................
....

265





5

Project Charter


Project Charter Change Log


Version

Approved By

Approval Date

Implementation
Date

Change List



























































6

Project Purpose

The purpose of this project is to fill critical needs of the video game industry. By providing a strong
educational foundation, Full Sail is able to meet the needs of its consumers while supplying skilled
industry professionals capable of working for any relevant companies. Full Sail is also able to create a
degree that fulfills perceived absences in its curriculum through the Game Design Master of Science
program.

Project Objective

The goal of this project

is to create a “
fun and done” computer video game within a five month period
that falls within the scope of Full Sail University’s Final Project curriculum. During that time, the team
will spend two months documenting the design

of the game, then three mo
nths executing their vision.

Stakeholders

The Project Team

The Project Team consists of undergraduate students from Full Sail University’s Game Development and
Game Art programs, as well as graduate students from the Game Production program. As a team, the
y
will design and develop an original video game, within a five month time frame, as the final project for
their respective degree programs.

Internal Producer (IP)

Each Project Team will have one graduate level project manager known as an Internal Producer that
reports directly to an External Producer. The job of the IP is integral to the success of the project team
and includes the following responsibilities: handli
ng team wide administrative tasks such as moderating
meetings and developing schedules, enacting policies and procedures, managing changes and the scope
of the project, interacting directly with external producers and other GP Games staff, ensuring the
sta
ndards and quality of all deliverables meet expected requirements, and providing support and
guidance to the project team.

Programming Lead (PL)

The Project Team will designate one undergraduate programmer as the Programming Lead to directly
manage
a Tech
nical and Gameplay Lead
and report to the Internal Producer. The PL
main

responsibility

is to design

the games system architecture
.


Technical Lead (TL)

The Project Team will designate one undergraduate programmer as the Technical Lead to directly
manage a team of five other Game Development students and report to the Programming Lead.
T
he TL,
will be responsible for the development of
the games
critical

s
ystems
.


7

Gameplay Lead (GL)

The Project Team will designate one undergraduate programmer as the Gameplay Lead to directly
manage a team of four other Game Development students and report to the Programming Lead.
T
he
GL
s main responsibility
will
focus on the

implementation, balance, and
interactive aspects of the game.

Programmer

Programmers of the project team will consist of undergraduate Game Development students working
directly under either the Technical Lead or Gameplay Lead. Programmers will fill roles

on their
respective teams and are responsible for the low level development of critical game syst
ems as outlined
by their leads.

Art Lead (AL)

The Project Team will designate one undergraduate artist as the Art Lead to directly manage a team of
three othe
r Game Art students and report to the Internal Producer.
The main responsibility of the AL

is
to

develop the visual style of the game
.

Artist

Artists of the project team will consist of undergraduate Game Art students working directly under the
Art Lead. A
rtists are responsible for the design and development of game assets in accordance with the
asset list and the overall style of the game
.

External Producer (EP)

Each Project Team will be assigned a staff member from GP Games known as an External Producer.
The
EP will work directly with the Project Team’s Internal Producer and deal with issues such as
administrative tasks, major scope change approval, conflict resolution, guidance, and general support.

Project Studio

Each Project Team works under the vision and direction of Full Sail University’s game production project
studio known as GP Games. As an external influence on the Project Team, the project studio sets high
level policies and procedures which all Project Te
ams as expected to uphold.

Full Sail University

By employing a strong curriculum, high standards, expectations, and a positive learning environment,
Full Sail University strives to produce the highest quality industry professionals in all aspects of the
e
ntertainment industry. By following these standards, students are able to produce a final product that
positively reflects on Full Sail and makes them more attractive to companies looking for qualified
professionals.

Other Teams

More than one Project Team
works under the scope of GP Games producing similar games and each of
those teams should strive to support other members of the studio. When a team is strong, it is in the

8

best interest of the studio to provide guidance and support to other teams. By worki
ng together, the
studio as a whole will be better off and everyone involved will be able to produce a stronger product.

Friends and Family

Friends and family members of the project team are emotionally supportive and positively affected by
the outcome of t
he development process but are external to the team itself and have no real influence
on project as a whole.

High Level Requirements

Technical Documentation Outline Compliance



Publishing Document

o

Game Charter



Vision Statement



Meeting Schedule



Hours Worked per Week



When Things GO Wrong



Decision
-
Making Process



Rules of Conduct



Team Roles

o

Executive Summary



High Concept



Locale



Genre



Basic Controls



Game Goal



Target Platform



Marketing & Target
Audience



Game
Walkthrough /
Overview



Key Features



Comparative Products



How this Product Stacks Up

o

Treatment



Dust Jacket Story



Game Story



Characters



Power
-
ups



Art and Production Design



Art & Animation Style



Sound Effects Style



Music Style

o

Storyboards and Sample Art




Production Document

o

Interactivity



Goal



Interface



Interactive Rhythm



How the Player Marks
Progress

o

Detailed Design Breakdown



Front End Flow Chart



Game Flow Chart



Glossary of Terms



Characters



Weapons



Power
-
ups



Levels and Maps



Combat System



Special Systems

o

Game Logic, Algorithms, and Rules



Interaction Component
Matrix



Key Game Algorithms



FAQ


9

o

Reference of Key Elements



Scoring



Winning / Losing



Transitions



Rewards

o

Art and Production Design



3D Art & Animation
Deliverables



2D Art Deliverables



Sound Effects Deliv
erables



Music Deliverables



Cutscenes / Pre
-
rendered
scene Deliverables




Technical Document

o

Overview



Coding Standards



Naming Standards



Prefix Convention



Structures



Classes



Relevant Function Names



Macros and Constants



Summary of Naming
Conventions



Commenting



Data Alignment



Coding Guidelines

o

Development Environment

o

Timing Specifications

o

System Feature Breakdown

o

Game Feature Breakdown

o

System Architecture

o

Milestone Deliverables

o

Appendix A



Memory Map



Integration Plan



Testing Plans

o

Appendix B



Game Folder Hierarchy

Game Requirement Checklist (GRC) Compliance



General

o

Functioning and complete
Front
-
End (FE)

Menu system. Menu must including a startup
sequence, title screen and main menu screen. The main menu must minimally contain game
selection, game settin
gs, credits and exit.

o

At least 1 functioning and
complete

Level
, which represents the
Game World (GW)



This
entails all terrain and textures (including skyboxes or panoramas). The game world should
be significantly detailed and populated with features (b
uildings, cars, trees, etc.), which
should be textured.

o

At least 1
complete

animated
model

loaded, moving and able to interact in the GW


This
should be the main character/player avatar at least. All textures must be on the model.
There needs to be at l
east 2 animations on this model (if applicable).

o

The main character/player avatar must be able to interact with the world environment. This
minimally includes moving about the world, colliding with objects and, for example, may
include other actions such
as destroying and opening items.

o

The player must be challenged with
game initiated interaction

within the GW. This can be
combat, shooting, talking with characters, etc. Keyboard
-
sharing two
-
player co
-
op doesn’t
meet this requirement. Interaction can be ac
complished in either of 4 ways:


10



Autonomous

AI
, which is aware of, and is motivated
to

interact with the player’s
avatar.



AI
, which competes against the player, either in real
-
time or turn based, in which
the AI must appear to follow the same game, rules a
s the player.



Networking

in which the game connects at least two human players between at
least two separate computers. They must use standard networking protocols such
as TCP/IP, IPX/SPX, that is preferably not hard coded, and uses menus or dialog
boxes

to facilitate connecting the different systems.



Challenge settings that force the player to compete against an outside entity (e.g., A
time mode for a race game).

o

Game Logic

and
Flow

must be demonstrated. The game must progress and end in a state
other th
an one it started in by effort of the player.

o

Upon the player characters death, victory or completion of game objective, there must be
feedback of the state change and
final game state
.

o

A player results screen should include details or other feedback th
at informs the player as to
how well they progressed through the game.

o

Upon completion of the final state, player must return back to the main menu.

o

Accompanying music/ambient sound should play within the game. Be it original or
previously released, it
must be in the GW, optionally for the FE. (
note:

It is legal to use
copyrighted work without the copyright holder’s permission when used solely for
educational use, as long as credit is given. See 1.8.5.3
)

o

The FE startup sequence of the game must progress
from:



Class logo displayed for approximately 3 seconds. The player must not be able to
progress beyond the logo before it times out and the player should not have to
provide input to go to the next screen once the time out expires.



Your team logo to the sa
me requirements as 1.8.1.



A game introduction (see 4.1), which displays the story/purpose/assumptions of the
game. The player should be able to skip past this intro completely or to another
stage of the intro with any input.



Title screen or your games
splash screen. This should be the glory intro screen. In
actual games this would function as the copyright screen. This can optionally be
combined with 1.8.5 below.



Main menu screen. Minimally this must include paths to:



Launch the game world/play the gam
e
immediately
.



Modify player
-
controlled settings/options.



Display game credits. This must include a list of all individuals who worked
on or contributed to the game plus reference any third
-
party development
tools (openAL, Torque, fmod, etc as license requ
ires.) or any art, music and
sound effects resources used.


11



Exit the game.

o

The game world, environment and interactive elements must be self
-
consistent.

o

The AI must appear to follow the same rules as the player

o

The player should be able to navigate through

the menus without performing repeatable
errors due to expectation not conforming to standard or expected interface guidelines.
Input through the menus must use consistent rules.



Operational

o

The GP room’s demonstration PC is the primary target platform.
Other systems benchmarks
are the Windows XP environment on current class
-
cohort issued laptops and the GP room’s
demonstration PC.

o

Input must include BOTH keyboard and mouse. User configurable key assignments are
preferred but fixed mappings are acceptable

as long as they follow reasonable conventions
or are made obvious. Game pad or joystick input may be used as primary input where
appropriate, but you must still support mouse/keyboard. Your keyboard control must
contain:



Esc = Exits the game back to the F
E, The FE to the desktop. Exit in game should
trigger a pause menu or require confirmation before exiting especially if work
should be saved.



F1 = Game help. May include systems help (keyboard mappings) or game help (map
of world, mission objectives or cu
rrent status).

o

Game, with installer, must fit on a 650MB CD and use no more than 128MB of RAM at any
one time.

o

If the distribution method is via the Internet, entire downloadable game must be under
64MB.

o

Game must contain a setting in the FE options menu t
hat can raise and lower the Gamma of
the game.



Performance

o

Frame rate should be no less than 30fps average or 10fps instantaneous as measured on
systems benchmark. See 2.1

o

Load times or player wait times should be under 60 seconds. Related: 4.4.2, 2.4



Us
ability

o

The player must be able to discern the game
objective
. Whether through movie, cut scene,
or simple text, there must be some sort of intro or explanation to inform the player what to
do. It is acceptable for the game objectives to be stated in the F
E (as a loading screen for
instance) or as an overlay in the game world.

o

There must be a Real
-
Time Display (HUD or otherwise) of pertinent player or world states
while in the GW. The RTD must be fully interactive with the game, meaning it represents
the state of the game/player in real
-
time.


12

o

Statistics or information on world
, player or opponent states that are required to complete
the level should be readily available while within the GW. The player must not have to exit
the GW in order to figure out what to do next.

o

The user interface must provide timely feedback of relevant

user actions:

o

If a player interacts/collides with another object in the GW, there must be reinforcing
auditory or visual representation of an event. Multi
-
modal feedback, which includes both
visual and auditory elements, is recommended if feedback is ind
iscernible from the
environment (such as multiple sounds playing at once) or it is ambiguous, but not required.

o

Must be unambiguous and reassuring feedback of wait times. Examples of feedback include
static loading screens, dynamic text, animated progress
indicators or cursors and sound
effects/music. Feedback must be given to



pauses of more than 5
-
10 seconds within the FE, or



pauses of more 2
-
3 seconds within the GW

o

I
nitial game loading must appear seamless and should not show or flash the desktop after
th
e user starts the application.

o

Upon the players selection (key down/click down) of a menu item there must be
unambiguous feedback that the player has performed an action. Examples include, but are
not limited to audible clicks, animated cursors and 3D but
tons.

o

Upon initial entrance to the GW the player must have a safe time to orient to the world.
Examples which facilitate this include but are not limited to: entering with temporary
invulnerability, in a paused state which expires via countdown or player i
nput, spawning the
player after the GW has been displayed, using an intro sequence or simply not dropping the
player amongst a bunch of angry enemies.

o

The player must not be penalized for engaging in game relevant system operations. If the
player must use
a game menu while in the GW, either the player’s character should not
incur damage, or game action should be suspended while the player is in the menus.
Note:
does not apply to Real
-
Time games.



Reliability

o

Game must be playable for 15 minutes under expecte
d load without crashing.

o

There should be no Class A bugs

those which prevent the completion of the game within a
single session.



Maintainability

o

Code must be sufficiently commented as to allow the general flow to be understood by a
person other than its
author.

o

Must adhere to a coding standard



Security

o

No requirements



Scalability

o

No requirements


13



Constraints

o

Game content must not exceed the ESRB Teen rating category. There must be no
pornography, profanity (except mild expletives), smoking or alcohol refe
rences.

o

Game must be the result of substantial original work by the student team. Use of 3
rd

party
development tools and pre
-
made assets is allowed and recommended to aid development,
but the game, both in effort and effect, must be considered a new work c
ontaining items of
originality.

o

Game may use only 1 3
rd

party development tool/API. These are designated as things that
have prepackaged C++ code that the student will not have to write. Examples include ODE,
FMOD, Boost, Havok. Scripting languages such as Lua and Python are NOT considered 3
rd

party tools/APIs.

o

Game must be created in accordance to GP class process constraints.

o

Game Deliverables must be delivered by the allocated milestones, and a project archive
received by the end of the last class day prior to graduation.

Milestone Checklist
s Compliance



Month One

o

Week 1



Form Teams



Develop Two Game Pitches

o

Week 2



Pitch to Project Studio



Develop Publishing Documentation



Develop Production Documentation

o

Week 4



Submit Publishing Documentation



Submit Production Documentation



Month Two

o

Week 1



Devel
op Technical Documentation

o

Week 2



Submit Technical Documentation

o

Week 3



Develop Proof of Concept Build

o

Week 4



Submit and Present Proof of Concept Build



Month Three

o

Week 1



Develop Feature Fragment One Build

o

Week 2


14



Submit and Present Feature Fragment One
Build

o

Week 3



Develop Feature Fragment Two Build

o

Week 4



Submit and Present Feature Fragment Two Build



Develop Alpha Build



Month Four

o

Week 1



Submit and Present Alpha Build



Develop Beta Build

o

Week 4



Submit and Present Beta Build



Month Five

o

Week 1



Develop Fina
l Build

o

Week 3



Submit and Present Final Build



Develop Archive Build

o

Week 4



Submit Archive Build

Project Constraints

Project Constraints are e
lements of the project’s scope that limit the team’s options.

Scope

The scope of the project will be constrained to

minimally include all elements of the final project
document known as the Game Requirements Checklist. This document outlines necessary elements that
all project teams must meet and include in any final deliverable. Any elements beyond the scope of the
GR
C may be decided upon by the Project Team and approved by the Internal and External Producers.

Time

The project will begin and end within a five month timeframe without exception. The development cycle
will include two months to form ideas, create, and des
ign their documentation and three months to
develop their game. In addition, game deliverables must be delivered by the allocated milestones and a
project archive must be received by the end of the last class day prior to graduation.

Game Requirements Chec
klist

The projects content must not exceed the ESRB Teen rating category which includes no references to
pornography, profanity, smoking, or alcohol. The project must also but the result of substantial original

15

work by the student team. The use of third pa
rty development tools (limit: one) and pre
-
made assets is
allowed and recommended to aid in development, but the game, both in effort and effect, must be
considered a new work containing items of originality. In addition, the game must be created in
accord
ance with the GP Games class process constraints kept in mind at all times.

Assumptions

Assumptions are factors that, for the planning purposes, are considered to be true, real, or certain
without proof or demonstration.



The project team will consist of 17

members including 12 programmers, four artists and one
project manager.



There is no enforced team member hierarchy beyond the EP to IP to PL and AL.



All members of the project team

will be aware of the
ir

roles and responsibilities
.



All members of the proj
ect team will have the necessary competencies
to contribute to the
creation of a quality end product.



All members of the project team

will work to foster a professional environment
.



All members of the project team

will be available, and on time, during the

scheduled work
times
.



All members of the project team

will have all necessary materials and supplies required to
complete the project
.



Communication issues

such as task and meeting scheduling, and role ambiguity

will arise
between members of the project t
eam, producers, and GP Games staff. These issues can occur
at any point in the development timeline.



GP Games
staff will not alter the scope of the game after documentation has been finalized



GP Games staff will be reasonably available to give support and

guidance to the project team



The final project process is similar to the actual game industry’s development process



We would come away with a product that demonstrates proficiency in skills relevant to the
game development process



There will be no major c
hanges to the overall final project process



The two pitches will be polished enough to ensure selection of either one.



In the event that neither pitch is selected, GP Games Staff will issue a game idea to the team by
default



External Producers will
sufficiently support the Project Team. This is done through major scope
approval, the performing of administrative tasks, resolving conflict within the team, and offering
professional advice and knowledge to the team.


16

High Level Risks

An uncertain event or

condition that, if it occurs, has a positive or negative effect on a project’s
objectives.



Dysfunctional Team Dynamic

refers to situations that arise within project teams that hinder or
halt productivity. These can include misunderstandings, member animos
ity, disregard for
established policies and procedures, or runaway egos.



Communication Issues

refer to situations where the core meaning of something is
misunderstood by one or more project team members. Communication issues are at the center
of most confl
icts and can include assumptions, lost details, and misread situations.



Loss of Human Resources refers to
situations

in which team members leave the project

team

permanently due to
internal or
external circumstances. These
factors can include

but are not
l
imited to irreconcilable team conflicts, repeated failures to produce satisfactory work,
health
issues and family obligations.
The team is affected negatively due to the loss of a team member,
the redistribution of work to remaining members and the potenti
al morale and momentum loss.



Subpar Team Member Performance is as its name implies. There may be moments in which
members fail to perform well even at the lowest level necessary to facilitate positive progress
towards completion of the project. This may be

caused by
,
and n
ot limited to,

a lack of morale,
or a conflict amongst members of the same group.



Scheduling Issues refer to moments in the development timeline in which members may not be
able to uphold their scheduled task commitments due to external fa
ctors potentially out
of their
control. This includes, but not limited to

prior commitments
, family
-
related obligations, and
health issues. This will affect overall performance by potentially reducing the team’s overall
production levels.



Team Member Role

Ambiguity refers to moments in which team members are not clear about
their assigned roles. This in turn may lead to redundancy in fulfilling responsibilities and
producing the necessary deliverables in order to meet stakeholder’s requirements.



Subpar Mi
lestone Deliverables

are pieces, or entire milestones that do not meet the
expectations of the GRC, External Producer, and or the GP Games staff. Failure to meet these
expectations will result in a lower quality final product, lower overall grades for the
project team
and possibly the loss of one or more project team members.



Unnecessary Scope Increase
s in the project refer to situations where members of the project
team produce work that falls outside the predetermined scope of the final product. This is
t
ypically referred to as feature creep and results from either improper task scheduling, over
ambition or underwhelmed team members.



Equipment Malfunction

refers to the failure of project critical supplies such as laptops, software,
and data storage locatio
ns.


17

Summary Budget

Although there is no actual cost associated with the final project process, a theoretical set of values have
been calculated for all resources involved.

Project Team

All salaries based on average industry standards for a work period of f
ive months.



External Producer


$41,797.94



Internal Producer


$34,543.75



Programming Lead


$44,637.60



Art Lead


$39,111.75



3
Artist
s



$28,971.67

($86,914.41 total)



Gameplay Lead


$40,032.14



Technical Lead


$40,032.14



9
Programmer
s



$35,426.67

($318,840.03 total)



Total


$654,909.76

Materials

All material costs based on standard retail pricing.



HP EliteBook Laptop


$2,100.00



Software


$3,660.00

o

Microsoft Office 2007
-

$100.00

o

Microsoft Project 2007
-

$130.00

o

Microsoft Visio 2007
-

$130.00

o

Ali
enbrain Client
-

$1,000.00

o

Adobe Photoshop CS4
-

$400.00

o

Autodesk Maya Complete
-

$2,000.00



Per Person



$5,766.00



Total


$98,022.00

Total

After accumulating all costs, the total budget for this project is:



$
1,019,441.80




18

Scope Management Plan


Scope
Management Plan Change Log


Version

Approved By

Approval Date

Implementation
Date

Change List



























































19

Project Scope Statement

Project Scope Description

This project is a culmination of the skills and techniques developed by students of Full Sail University’s
Game Development, Game Art and Game Production programs. A team of 12 undergraduate
programmers, four undergraduate artists, and one graduate project

manager
will

undertake the process
of designing and developing an original video game within a five month timeframe. The project team will
be exposed to a development cycle and a set of rules and regulations outlined in the final project
governing documen
t known as the Game Requirements Checklist (GRC) that is reflective of current
standards in the video game industry. With the completion of the project, students will have gained the
necessary skills and experience to work as professionals and fill critica
l roles within the industry.

Stakeholders

Stakeholders are people or organizations that are actively involved in the project, or whose interests
may be positively or negatively affected by execution or completion of the project. A stakeholder may
also exer
t influence over the project and its deliverables.

The Project Team

The Project Team consists of undergraduate students from Full Sail University’s Game Development and
Game Art programs, as well as graduate students from the Game Production program. As a
team, they
will design and develop an original video game, within a five month time frame, as the final project for
their respective degree programs. Having control over the scope and direction of the project, the Team
will be extremely influential in all
aspects of the process and ultimately produce a product that reflects
their vision and aids in furthering their education by fostering an environment that promotes a real
world experience.

External Producer (EP)

Each Project Team will be assigned a staff
member from GP Games known as an External Producer. The
EP will work directly with the Project Team’s Internal Producer and deal with issues such as
administrative tasks, major scope change approval, conflict resolution, guidance, and general support.
Whil
e less influential then the Project Team as a whole, the EP is the final word in all major decisions for
the Project Team and has the authority to make human resource changes. The success of, and a positive
experience for the Project Team is the primary co
ncern of a strong external producer.

Internal Producer (IP)

Each Project Team will have one graduate level project manager known as an Internal Producer that
reports directly to an External Producer. The job of the IP is integral to the success of the proj
ect team
and includes the following responsibilities: handling team wide administrative tasks such as moderating
meetings and developing schedules, enacting policies and procedures, managing changes and the scope
of the project, interacting directly with e
xternal producers and other GP Games staff, ensuring the
standards and quality of all deliverables meet expected requirements, and providing support and

20

guidance to the project team. Through effective management practices, the IP will promote a positive
te
am environment and an overall stronger final deliverable that reflects on the professional and
technical proficiencies of the entire project team.

Programming Lead (PL)

The Project Team will designate one undergraduate programmer as the Programming Lead to

directly
manage the 11 other Game Development students and report to the Internal Producer. The PL, in
addition to the responsibilities of a programmer, is responsible for designing the games system
architecture, designating and tracking progress of progr
amming related tasks, ensuring all GRC criteria
are met, approving technical changes, assisting programming teams through support and guidance, and
frequently communicating project updates to the Internal Producer.

Technical Lead (TL)

The Project Team wil
l designate one undergraduate programmer as the Technical Lead to directly
manage a team of five other Game Development students and report to the Programming Lead.
Members of the TL’s team, including the TL, will be responsible for the development of crit
ical game
systems including Engine Development, Rendering, AI, Animation Systems, and Tools. In addition, the TL
is responsible for ensuring all GRC criteria are met, assisting the technical team through support and
guidance, and frequently communicating p
roject updates to the Programming Lead.

Gameplay Lead (GL)

The Project Team will designate one undergraduate programmer as the Gameplay Lead to directly
manage a team of four other Game Development students and report to the Programming Lead.
Members of th
e GL’s team, including the GL, will be responsible for the implementation, balance, and
interactive aspects of the game along with the development of critical game systems including Audio,
Interface, Input, and Effects. In addition, the GL is responsible f
or ensuring all GRC criteria are met,
assisting the gameplay team through support and guidance, and frequently communicating project
updates to the Programming Lead.

Programmer

Programmers of the project team will consist of undergraduate Game Development
students working
directly under either the Technical Lead or Gameplay Lead. Programmers will fill roles on their
respective teams and are responsible for the low level development of critical game systems as outlined
by their leads. Programmers are also re
sponsible for developing modules that comply with GRC
standards, assisting other programmers through support and guidance, and frequently communicating
project updates to their relevant leads.

Art Lead (AL)

The Project Team will designate one undergraduate

artist as the Art Lead to directly manage a team of
three other Game Art students and report to the Internal Producer. The AL, in addition to the
responsibilities of an artist, is responsible for developing the visual style of the game, tracking and
manag
ing assets through a comprehensive asset list, designating and tracking progress of art related

21

tasks, ensuring all relevant GRC criteria are met, approving technical changes, assisting other artists
through support and guidance, and frequently communicati
ng project updates to the Internal Producer.

Artist

Artists of the project team will consist of undergraduate Game Art students working directly under the
Art Lead. Artists are responsible for the design and development of game assets in accordance with th
e
asset list and the overall style of the game. Artists are also responsible for assisting other artists through
support and guidance and frequently communicating project updates to the Art Lead.

Project Studio

Each Project Team works under the vision and
direction of Full Sail University’s game production project
studio known as GP Games. As an external influence on the Project Team, the project studio sets high
level policies and procedures which all Project Teams as expected to uphold. By setting these s
tandards,
the Project Studio is able to produce capable industry professionals through teamwork and practical
development experience.

Full Sail University

By employing a strong curriculum, high standards, expectations, and a positive learning environment,
Full Sail University strives to produce the highest quality industry professionals in all aspects of the
entertainment industry. By following these standards, students are able to produce a final product that
positively reflects on Full Sail and makes them

more attractive to companies looking for qualified
professionals.

Other Teams

More than one Project Team works under the scope of GP Games producing similar games and each of
those teams should strive to support other members of the studio. When a team is

strong, it is in the
best interest of the studio to provide guidance and support to other teams. By working together, the
studio as a whole will be better off and everyone involved will be able to produce a stronger product.

Friends and Family

Friends and

family members of the project team are emotionally supportive and positively affected by
the outcome of the development process but are external to the team itself and have no real influence
on project as a whole.

Product Acceptance Criteria

All of the fo
llowing criteria must be met for all corresponding and relevant aspects of deliverables
presented to GP Games staff.

Technical Documentation Outline Compliance

Publishing Document

Acceptance of the Publishing Document constitutes all off the following
sections are present and
complete to their fullest extent.


22

Game
Charter

The game charter provides information about how the team plans to execute its mis
sion of
creating a video game.
Every team member should agree to the contents of the game charter, as
i
t defines the expectations, guidelines and rules for the team.

Vision Statement

This is the statement of the intent or objectives for the team’s final project. It should broadly
state the goal of the game, team, and the process of making your game. It is

a good idea to
include information about what game you are making, why your game will be great, and what
the team expects to learn from the project.

Meeting Schedule

This section will cover h
ow many times
the project team will meet outside of class per we
ek,
w
here and when are these meetings
are taking place, h
ow the meetings
are conducted, w
hat is
to be

achieved during a team meeting, w
hat is the maximu
m time limit for a team meeting and
w
hat is required of each

team member during the meeting.

Hours Worke
d per Week

This section will cover h
ow many hours is each team member expected to work per week
, w
hat
the
m
aximu
m allowed hours worked per week are and any other

pertinent information about
working hours, requirements, tracking, etc.

When Things Go Wrong

T
his section will cover h
ow
the
team
will
kn
ow when an emergency has arisen, w
hat

the
protocol for informing all team members of an emergency

is and what
steps will be taken to
reduce risks i
nvolved with an emergency.

Decision
-
Making Process

This section wi
ll cover how
the team
will
make decisions regarding game design, technical
design and implementation
, w
hat is the time limit for coming to

a decision for any given topic is
and w
hat is the protocol for any decision resulting in a stalemate?

Rules of Conduc
t

This section will cover w
hat behavioral standards are expected of each team member during
team meetings, work sessions, etc.

and w
hat process is used if any standards

are not met by any
team member.

Team Roles

This section will detail administrative, tec
hnical and any other roles for all members of the
project team.


23

Executive Summary

High Concept

The high concept is one sentence describing the game idea. This sentence is usually the
marketing hook, used to push the game in print ads, websites, TV, etc.
Make this your “tag
line,” the sentence that
grabs you

and
gets the attention of execu
tives and perspective
consumers
.

Locale

Describe where your game takes place. This should include information about the physical
location and time period. Use a few sen
tences here to describe your game setting to the reader.
You can further define your game world/level in the Level/Maps section, within the Treatment.

Genre

Define the genre and theme of the game. If your game exhibits elements from multiple genres,
include that information here.

Basic Controls

Descri
be what the player will control in
-
game
, what means of the control the player will use,
and what camera perspectives are available to the user. This section is best utilized with brief
descriptions of
control objec
t types and camera perspectives.

Game Goal

This section will cover what the goal of the game is, what the player is expected to achieve and
what the player does to advance in
-
game.
Describe all aspects of advancement achievable
during the game
.

Target Platform

Describe the target platform. Include operating system and minimum system requirements. If
you intend on developing for more than one platform, detail each platform in a prioritized list.

Marketing & Target Audience

Describe the typical

player. Include info
rmation about common interests such as
TV shows,
books, magazines, movies, etc. This information provides a base market and avenue for
advertising. Provide a narrow age range, gender, and other classifications. The demographical
inf
ormation provided should include explanations of why this game will appeal to your target
market.

Game Walkthrough / Overview

Give a rundown of a typical play session. The idea is to express how your game will play and
provide the reader with a clear view

of what to expect in
-
game. It is effective to use 2
nd

person
perspective within this section. Make this exciting to read and show us what makes your game
fun, as well as detailing what we can do
.


24

Key Features

This section will cover a l
ist of features t
hat identify what makes your game unique, interesting,
fun, worth buying, etc. This list can be used by the marketing department to sell your game to
consumers and/or printed onto the game box.

Include creative design elements, creative
technologies, enha
ncements, etc.

This section can be broken down into the following sections:
General Features, Multiplayer Features, Player Upgrades, and Gameplay Features.

Comparative Products

List comparable games and game play elements. Try to match, as closely as poss
ible, games
that directly compete for your target market. If your game is intended for budget gamers, you
should list comparable budget titles.

How this Product Stacks Up

Detail the similarities (gameplay, technology, etc.) between your game and the compa
rable
products. Compare your game and its features, including information about your improvements
and additions.

Treatment

Dust Jacket Story

This is what appears on the back of your game box. This is what the consumer will read before
purchasing your gam
e. Keep in mind this story must be compelling and descriptive, contain the
end goal of the game, describe at least 3 actions, provide a “hook” for the consumer, and inform
the consumer about the game.

Game Story

This is your entire game story, told in en
ough detail to understand its full impact on the design
of the game. This section should provide a clear vision for the game and its theme, while
maintaining consistency with the game design.

Characters

Name / ID

This is the name or ID of the character.
Each character in the game, both player and non
-
player
characters, should be detailed in its own section. Make sure you specify
what the purpose of
the character is (PC, NPC, Background, etc)

Brief Description

Briefly describe the character to help the
art team create needed assets. This information
should define the character in such a way as to allow m
odelers, animators, musicians, S
FX
artists, etc. enough detail to uniformly create the required assets in a consistent theme.


25

Visual Design

Describe, in

full, the character visually. This should include any sketches or example art, as well
as visually distinct attributes.

Back Story

Describe the character’s back
-
story in enough detail to understand its place within the game and
its impact on the game’s d
esign.

Dialogue

Include all required voice recordings for this character. This includes both dialog and special
effect (such as grunts, getting hurt, taunting, etc.).

Weapons

Name / ID

This is the name or ID of the weapon. Every weapon used (by player an
d non
-
player characters)
in the game should be detailed in this section.

Brief Description

Briefly describe the weapon and its function within the game. This should include what it looks
like, how it operates, and what impact it has on a character. Thi
s information should define the
weapon in such a way as to allow m
odelers, animators, musicians, S
FX artists, etc. enough detail
to uniformly create the required assets in a consistent theme.

Visual Design

Describe, in full, the weapon visually. This shou
ld include any sketches or example art, as well as
visually distinct attributes.

Power
-
ups

Name / ID

This is the name or ID of the power
-
up. Every power
-
up used (by player and non
-
player
characters) in the game should be detailed in this section.

Brief De
scription

Briefly describe the power
-
up and its function within the game. This should include what it
looks like, how it operates, and what impact it has on a character. This information should
define the power
-
up in such a way as to allow modelers, anim
ators, musicians,
S
FX artists, etc.
enough detail to uniformly create the required assets in a consistent theme.

Visual Design

Describe, in full, the power
-
up visually. This should include any sketches or example art,

as well
as visually distinct attribut
es.


26

Levels and Maps

Name / ID

This is the name or ID of the level. Every level in the game should be detailed in this section.

Goal

Fully define the goal of the level. The goal should be both achievable and challenging for the
expected skill level (of
the player). Include any special information about the main objective and
accompanying numbers used to define the goal. Secondary objectives should be detailed in
separate quest/mission section, to be inserted.

Brief Description

Describe the level and it
s placement within the game. This should include what it looks like,
difficulty level, and what impact it has on the game goals. This information should define the
level in such a way as to allow m
odelers, animators, musicians, S
FX artists, etc. enough d
etail to
uniformly create the required assets in a consistent theme.

Back Story

Describe the level’s back
-
story in enough detail to understand its place within the game and its
impact on the game’s design.

Visual Design

Describe, in full, the level visuall
y. Detail all level objects including both static and dynamic
objects to be used within the level. This should include any sketches or example art, as well as
visually distinct attributes.

Art and Production Design

Art & Animation Style

Describe the look

and feel of the game. Include game theme definition and examples. The style
definition should be in enough detail to completely visualize the game and its elements. If you
have multiple themes throughout the game, review each themed section.

Sound Effe
cts Style

Keep this section separate from the music section. The sound effects section needs to specify
the precise style of the sound effects needed for the game. You should consider the game
theme when detailing this section. For example: Should an ex
plosion sound like it came from a
battlefield or a cartoon?

Music Style

The music will help set the mood for the player. Fully express the feeling a player should
experience while playing your game. Be sure to descriptions that are consistent with your
t
heme. For example: Tactical Shooter Background music should have a face paced Techno feel.

27

During combat, the music will change to a more heavy metal style of music and should increase
adrenal output.

Storyboards and Sample Art

Include your game storyboa
rds and sample art in this section. This section may be

broken down
further, to make it easier to use.

Production Document

Acceptance of the Production Document constitutes all off the following sections are present and
complete to their fullest extent.

I
nteractivity

Goal

Define the overall goal of the game. Clearly state how the player will achieve this goal and all
actions needing to be completed. If you have sub
-
goals/mission, create individual sections
within, and define those as well.

Interface

Incl
ude a brief description and explanation of your game interface. This should include
information about its appearance and how to use it. Also, include a mock
-
up (picture) to help
solidify the interface scale and placement. Interface includes both HUD and
Menu systems, so
include mock
-
ups of both.

Interactive Rhythm

Explain the sense of timing that the player should feel. How long does a typical play session
last? How long does the entire game last? What maintains the replay value? Some things to
think
about are downtime vs. uptime, speed of gameplay, how are the interactive and non
-
interactive sections of the game broken up? How long does it take to kill a fodder enemy vs. a
boss? List this out as either an outline or a bulleted list, but never a paragr
aph.

How the Player Marks Progress

Defin
e how the player marks progress.

Make sure to detail how the player will know they are
advancing (or regressing) in your game. How will they know they are winning/doing well?

Detailed Design Breakdown

Front End Flo
w Chart

Insert a flow chart visually representing the game progression from the start of the application
to the beginning of the game. The flowchart should include GRC requirements, menu options,
transitions, etc.


28

Game Flow Chart

This is essentially a vis
ual representation of your game loop. Chart the progression of your
gameplay and include divergent paths and paths looping back to previous junctures, or detailed
actions sets (what the player can do in
-
game and when the action is made available).

Glossar
y of Terms

List and define all of the attributes and behaviors for all of your characters/weapons/power
ups/levels here. Define them in terms of your game.

Characters

Name / ID

This is the name or ID of the character. Each character in the game, both play
er and non
-
player
characters, should be detailed in its own section. Make sure you specify what the purpose of
the character is (PC, NPC, Background, etc)

Brief Description

Briefly

describe the character and the role that it will play in the game. This sh
ould only serve as
an overview, so there is no need to have more than a few sentences about the game mechanics
surrounding this character. Do not copy and paste from your publishing doc.

Visual Design

Describe, in full, the character visually. This shoul
d not include any sketches or example art, but
instead, describe the character verbally. List/Outline/Table is the preferred format.

Behaviors

Insert brief section describing each behavior and a table numerically detailing all behaviors.
These behaviors s
hould fully define character actions/interactions (think gameplay and
methods) with your world and world objects. You can fine
-
tune the numbers during
implementation. The numbers are used as a starting point when you begin the coding phase.

Attributes

In
sert brief sections describing each attribute and a table numerically detailing all character
attributes. These attributes should fully define a character (think gameplay and members) and
how it will interact with your world. You can fine
-
tune the number
s during implementation.
The numbers are used as a starting point when you begin the coding phase.

Weapons

Name / ID

This is the name or ID of the weapon. Every weapon used (by player and non
-
player characters)
in the game should be detailed in this sect
ion.


29

Brief Description

Briefly

describe the weapon and its function within the game. Describe its role in the game, as
in, is it meant to be the “middle road” weapon or something that is very rare?

Visual Design

Describe, in full, the weapon visually.
This should not include any sketches or example art, but
instead, describe the weapon verbally.

Behaviors

Insert brief section describing each behavior and a table numerically detailing all behaviors.
These behaviors should fully define weapon actions/int
eractions (think gameplay and methods)
with your world and world objects. You can fine
-
tune the numbers during implementation. The
numbers are used as a starting point when you begin the coding phase.

Attributes

Insert brief sections describing each attr
ibute and a table numerically detailing all weapon
attributes. These attributes should fully define the weapon (think gameplay and members) and
how it will interact with your world. You can fine
-
tune the numbers during implementation.
The numbers are us
ed as a starting point when you begin the coding phase.

Power
-
ups

Name / ID

This is the name or ID of the power
-
up. Every power
-
up used (by player and non
-
player
characters) in the game should be detailed in this section.

Brief Description

Briefly

describ
e the power
-
up and its function within the game. Include the role of this in the
game.

Visual Design

Describe, in full, the power
-
up visually. This should not include any sketches or example art, but
instead, describe the power
-
up verbally.

Behaviors

Inse
rt brief section describing each behavior and a table numerically detailing all behaviors.
These behaviors should fully define power
-
up actions/interactions (think gameplay and
methods) with your world and world objects. You can fine
-
tune the numbers dur
ing
implementation. The numbers are used as a starting point when you begin the coding phase.

Attributes

Insert brief sections describing each attribute and a table numerically detailing all power
-
up
attributes. These attributes should fully define the p
ower
-
up (think gameplay and members)

30

and how it will interact with your world. You can fine
-
tune the numbers during implementation.
The numbers are used as a starting point when you begin the coding phase.

Levels and Maps

Name / ID

This is the name or ID

of the level. Every level in the game should be detailed in this section.

Goal

Fully define the goal of the level. The goal should be both achievable and challenging for the
expected skill level (of the player). Include any special information about th
e

main objective and
accompanying numbers used to define the goal. Secondary objectives should be detailed in
separate quest/mission section, to be inserted.

Level Travel

Describe how and at what rate both player and non
-
player characters travel throughou
t the
level. This information should define the travel methods in such a way as to allow m
odelers,
animators, musicians, S
FX artists, etc. enough detail to uniformly create the required assets in a
consistent theme.

Scale

Numerically define the scale of
the level in relation to the world, characters, and level/asset
creation tools (e.g. Maya). This is so that you do not have a model that is twice the size of the
level that the model is supposed to walk around in and explore.

Environmental Interactions


B
ehaviors

Environmental interactions are any points of interaction triggered by the player or non
-
player
character. Insert brief section describing each environmental interaction. (For example, when a
player is standing on a platform, it moves down at a r
ate of .02 m/s. When there is no player or
non
-
player character on the platform, it moves up at a rate of .01 m/s. The platform can move
no farther than 1.0 m below the visible screen and cannot move into or below other collision
capable objects.)

Attrib
utes

Insert brief sections describing each attribute and a table numerically detailing all level
attributes. These attributes should fully define the level, its triggers, and points of interaction
(think gameplay and members). You can fine
-
tune the numbe
rs during implementation. The
numbers are used as a starting point when you begin the coding phase.

Ambient Environmental Aspects / Objects in the Level

List the typ
es of audio, level animations, S
FX, particle effects, transitions, or random events that
b
ring the level to life. Include information about what role they play within the level. This list
will be used to partly define your asset list.


31

List the objects within the level. Include information about what role they play within the level.
This lis
t will be used to partly define your asset list.

Time

Detail how long it will take to achieve goals within the level. This should include expected travel
times (travel from one building to the next), battle times, triggered event times, transition
times,
etc. For each level, include an approximate completion time (how long does it take the
average player to complete your level).

Map

Insert a picture of the level. Include information about special areas, hidden triggered events,
NPC placement/spawning, e
tc. The map should be detailed enough for a level designer to
complete its creation. The map should be drawn using a uniform scale.

Level Walkthrough


Verbal Map

Include a
bulleted
/numbered

list of interactions on the level in chronological order (if
possible).
Plan how the player’s experience in the level will flow and record it in the list.

Combat System

Define your combat system in this section. Include at least the following: Turn
-
Based vs. Real
-
Time, Separate vs. In
-
Game battles, Area of Effect D
amage, Location Based Damage, Combat
Resolution, Control Issues and any other aspects you can think of. Tailor this section specifically
to your gameplay.

Special Systems

Any other special systems in your game should be designed here. Examples might inclu
de:
Stealth Systems, Character Leveling, Merchants and Vendors, Upgrades, Mini Games etc.

Game Logic, Algorithms, and Rules

Interaction Component Matrix

Include your Interaction Component Matrix (ICM) within the section. Format the ICM in a table.
Your I
CM should cover all dynamic and interactive objects (characters, triggers, collision
volumes, power
-
ups, etc.). Using notes and/or multiple tables may help format the information
in a more easily used manner. The ICM can be a separate file; it does not ha
ve to be pasted in
here.

Key Game Algorithms

This section should cover any gameplay algorithms required by the gameplay and game design.
This includes, but is not limited to, object usage requirements, accuracy determination,
deterministic AI (including f
uzzy logic), etc. The algorithms listed in this section should directly
relate to the game design and gameplay and should cover base technology only when directly
dependent on the game design.


32

FAQ

Critically think about your game, and put all the
questions that one might ask about your

game
here.

Reference of Key Elements

Scoring

This section will detail through paragraphs and tables, all of the elements and conditions that
can create score increases and/or character advancements in the game. Not
e if there are
alternate scoring conditions or specialized scoring rules.

Winning / Losing

Detail what the player must do in order to complete any sub
-
goals/mission and main game goal.
This should be a step
-
by
-
step detailing of actions needed to complete
the game. This section
should also include any scoring/advancement conditions needed to complete any given goal.

Transitions

This section should cover how the player/game logic will perform saving and loading of the
game. Ensure you clearly define how an
d when the player/game will have the option/ability to
save their progress. Also explain how, when, and what will be loaded upon performing a saved
game load (Does the player return to the beginning of the level, a check point, or last position
within the

game?).

Rewards

Detail how you will reward the player throughout the game. This should include information
about in
-
game, level completion, and game completion rewards.

Art and Production Design

3D Art & Animation Deliverables

Describe the 3D assets th
at will be in your game. You do not need to be technical in this section,
but you must be detailed in your descriptions. Describe all the models so that an artist can
understand what to make for you.

2D Art Deliverables

Describe each asset you will need fo
r all your 2D art. Think about HUD: Health, Timers,
Experience, and Damage Output. Think about your Menu: Start/Quit, Options. Each model will
need a texture. You do not need to get technical in this section, but you must be detailed in your
descriptions.

Sound Effects Deliverables

Keep this section separate from the music section. The sound effects section needs to specify
the precise style of the sound effects needed for the game. You should consider the game

33

theme when detailing this section. For exam
ple: Should an explosion sound like it came from a
battlefield or a cartoon?

Music Deliverables

The music will help set the mood for the player. Fully express the feeling a player should
experience while playing your game. Be sure to
use
descriptions tha
t are consistent with your
theme. For example: Tactical Shooter Background music should have a fa
st

paced Techno feel.
During combat, the music will change to a more heavy metal style of music and should increase
adrenal output.

Cutscenes / Pre
-
rendered
scene Deliverables

If you plan on doing any of these, or something similar, detail it out here.

Technical Document

Acceptance of the Technical Document constitutes all off the following sections are present and
complete to their fullest extent.

Overview

This is where you state the overall purpose for this document, how the team plans to use it, and
how you foresee it helping you in the production of your game. You can go over the overall
layout of the doc, how things are organized and where to look for ce
rtain things.
This is where
you can also briefly touch on any overall philosophies on the group as far as coding, tech design,
game planning, etc. goes. Any future uses you might have for the tech that you are planning
here could also be listed as this kin
d of thing will affect how you design your systems.

Coding Standards

Keep in mind that all of these are just examples. You might not use all of them, there may be
other sections that you do use, and you may use totally different standards than those in th
e
example. Use whatever works best for your group and what everyone in the group can agree on.

Also keep in mind that the examples are meant to be just guidelines to get you going, and don’t
represent the amount of information or effort that should be put
forth for each section.

Naming Standards

What are the purposes of naming standards? What are the group philosophies on it?

You can list
any naming standards you decide on as a group. They can include, but aren’t limited to, variable
prefixing, structures,

functions, classes

Prefix Convention

Are you going to have a variable prefix convention? Will it be some subset of Hungarian notation

or s
ome other method? Don’t just mention the method. The best way to go about it is to talk
about the method, and then li
st ALL the prefixes the group will use.


34

Structures

Will the team require any

naming convention or layout for the structures?

Remember possible
employers might read this; ANSII standard code specs for structures might be better as opposed
to the visual ass
ist variation of the standard.

Classes

This section will list any

naming con
ventions or layouts for the games classes.

You could work a
template class layout into this section as well.

Relevant Function Names

This section will list h
ow you will name functi
ons

including their prefixes, readability, size limit
and any other parameters.

Macros and Constants