3/19/2016
Project Scope Management Plan
Page 1
Project Scope Management Plan
Production Management Principles GDM521 – Rupert Meghnot
Version 06
Game Design Final Project
Bachelor/Master Programs
Full Sail University
Table of Contents
Table of Contents ............................................................................................................................ 2
1.
Project Team ............................................................................................................................ 6
2.
Objectives ................................................................................................................................ 7
3.
GRC Requirements .................................................................................................................. 7
3.1.
General ................................................................................................................. 7
3.1.1.
3.2.
5.
Game World (GW) ..................................................................................... 10
3.2.2.
Game Objects .............................................................................................. 10
3.2.3.
Game-play ................................................................................................... 11
3.2.4.
Pause Menu ................................................................................................. 11
3.2.5.
Game Flow .................................................................................................. 12
Operational ......................................................................................................... 12
3.3.1.
Game Input.................................................................................................. 12
3.3.2.
Game Delivery ............................................................................................ 13
3.3.3.
Installed Game ............................................................................................ 13
Usability................................................................................................................................. 14
4.1.
Game Object ....................................................................................................... 14
4.2.
Real-Time Display ............................................................................................. 14
4.2.1.
Real-Time Display (HUD) .......................................................................... 14
4.2.2.
Feedback ..................................................................................................... 14
4.2.3.
Game Rules ................................................................................................. 15
4.2.4.
Game Regulations ....................................................................................... 15
Constraints ............................................................................................................................. 15
5.1.
6.
Game .................................................................................................................. 10
3.2.1.
3.3.
4.
Front End (FE) .............................................................................................. 8
GP Games Constraints ....................................................................................... 15
5.1.1.
Technical Constraints.................................................................................. 15
5.1.2.
Additional Constraints ................................................................................ 16
Final Project Requirements ................................................................................................... 17
6.1.
Deliverable Requirements .................................................................................. 17
6.1.1.
Pitches ......................................................................................................... 17
6.1.2.
Design Document........................................................................................ 17
6.1.3.
Technical Document ................................................................................... 18
6.1.4.
POC (Proof of Concept – Playable Game Demo) ...................................... 19
6.1.5. Feature Fragment One (Second Playable Demo with Required A Level
Features) .................................................................................................................... 21
6.1.6.
Feature Fragment Two ................................................................................ 21
6.1.7.
Alpha ........................................................................................................... 22
6.1.8.
Beta ............................................................................................................. 22
6.1.9.
Gold............................................................................................................. 23
6.1.10.
Archive .................................................................................................... 24
7.
Additional Requirements ....................................................................................................... 24
8.
Roles and Responsibilities ..................................................................................................... 26
8.1.
Primary Stakeholders ......................................................................................... 26
8.2.
Production .......................................................................................................... 26
8.2.1.
Internal Producer ......................................................................................... 26
8.2.2.
External Producer........................................................................................ 26
8.2.3.
Executive Producer of GP Games............................................................... 27
8.2.4.
Art Director ................................................................................................. 27
8.3.
Art Team ............................................................................................................ 27
8.3.1.
Art Lead ...................................................................................................... 27
8.3.2.
2D Lead ....................................................................................................... 28
8.3.3.
3D Lead ....................................................................................................... 28
8.3.4.
General Game Artist ................................................................................... 28
8.4.
Gameplay Team ................................................................................................. 28
8.4.1.
8.5.
Quality Assurance Team .................................................................................... 29
8.5.1.
8.6.
Quality Assurance Lead .............................................................................. 29
Technical Team .................................................................................................. 29
8.6.1.
Technical Lead ............................................................................................ 29
8.6.2.
General Game Programmer ........................................................................ 29
8.7.
9.
Gameplay Lead ........................................................................................... 28
Secondary Stakeholders ..................................................................................... 30
8.7.1.
Students’ Friends and Family ..................................................................... 30
8.7.2.
Full Sail University ..................................................................................... 30
8.7.3.
Game Dev. Advisory Board ........................................................................ 30
Project Scope Statement ........................................................................................................ 31
10. Milestones and Deliverables .................................................................................................. 32
10.1.
Game Pitches .................................................................................................. 32
10.2.
Design Document ........................................................................................... 32
10.3.
Technical Document ....................................................................................... 33
10.4.
Proof of Concept ............................................................................................. 34
10.5.
Feature Fragment 1 ......................................................................................... 35
10.6.
Feature Fragment 2 ......................................................................................... 36
10.7.
Alpha Build..................................................................................................... 36
10.8.
Beta Build ....................................................................................................... 37
10.9.
Gold Build ...................................................................................................... 37
10.10.
Archive ........................................................................................................... 38
10.11.
Scope Exclusions ............................................................................................ 39
10.11.1.
Constraints............................................................................................... 39
10.11.2.
Assumptions ............................................................................................ 40
10.11.3.
Risks ........................................................................................................ 40
11. Scope P&P ............................................................................................................................. 42
11.1.
Data Backup ................................................................................................... 42
11.2.
Internal Producer’s Log .................................................................................. 42
11.2.1.
Assignment Plans .................................................................................... 42
11.2.2.
Attendance Log ....................................................................................... 42
11.2.3.
Discipline Log ......................................................................................... 43
11.2.4.
Turbo Teams ........................................................................................... 43
11.2.5.
Postmortem.............................................................................................. 43
11.3.
Professionalism ............................................................................................... 44
11.4.
Infractions ....................................................................................................... 44
11.5.
Scope Verification .......................................................................................... 44
11.5.1.
Inspection ................................................................................................ 44
11.5.2.
Submission .............................................................................................. 44
11.6.
Scope Control ................................................................................................. 45
11.6.1.
Change Request ....................................................................................... 45
11.6.2.
Art Asset Request .................................................................................... 45
11.7.
Attendance ...................................................................................................... 45
12. Budget .................................................................................................................................... 47
12.1.
Budget Descriptions ....................................................................................... 47
12.2.
Overhead ......................................................................................................... 47
12.3.
Software .......................................................................................................... 48
12.4.
Miscellaneous ................................................................................................. 49
13. Appendices ............................................................................................................................ 50
13.1.
Appendix A..................................................................................................... 50
13.2.
Appendix B – Change Request Form ............................................................. 61
13.3.
Appendix C ..................................................................................................... 62
1. Project Team
The following is a listing of all individuals involved in this project.
Customer
Phone
Email
Rupert Meghnot
(407) 679-0100 x8824
rmeghnot@fullsail.com
Project Team
Phone
Email
Benjamin Terry
(515) 468-8819
terryben5@gmail.com
Brian Reilly
(478) 397-2176
4thReilly@cox.net
Erin Eberhardt
(513) 907-4728
eccentricerin@gmail.com
Felix Martinez
(407) 690-4519
hk.felixmartinez@gmail.com
Gustavo Gil
(787) 608-3348
abaremawaru@gmail.com
Joshua Hufton
(603) 965-6043
joshua.hufton@gmail.com
Mark Johnson
(217) 257-7783
johnsonm469@gmail.com
Michael Burroughs
(850) 313-3221
m.burroughsjr@yahoo.com
Steve Emberton
(765) 532-1131
steveembr@gmail.com
Steve Emmerich
(410) 991-8181
SteveEmmerich@gmail.com
Tim Mayo
(407) 965-7681
timothy.i.mayo@gmail.com
Tom Graham
(413) 364-7175
tgraham413@gmail.com
Reynaldo Leon
(301) 455-8869
rleon@reybomb.com
Robbie Sykes
(937) 475-5314
robbiesykes@gmail.com
2. Objectives
The aim of Full Sail University's Final Project is to produce a video game on a five
month development cycle that matches the appropriate skills and abilities of the team.
This team is composed of students from the Game Art and Game Development
Bachelor's degrees, and the Game Design Master's degree. The Project Manager(s)
(Game Design Master's students) along with the GP Games staff (See Organizational
Chart) will guide the undergraduate team of Game Development and Game Art students
in producing the Final Project game.
Students should utilize lessons learned from Full Sail University and their own life and
work experiences in their respective fields to successfully complete their tasks.
All Final Project tasks are determined by a series of milestones that each team must
complete in order for the team to produce a complete and finished product.
These milestones include: Game Pitch Presentation, a Publishing Document, the
Production Document, the Technical Design Document, Proof of Concept, Feature
Fragment I, Feature Fragment II, Alpha, Beta, Gold, Final Project Presentation and
Archive. For more information on Final Project requirements, refer to the Work
Breakdown Structure.
In addition, both the graduate and undergraduate students seek to earn experience in
video game production and development for reference when seeking a job after
graduation.
Final Project mirrors real life circumstances and methodologies by asking students to
participate in a team environment to design and build a video game. Master's students
play the role of Internal Producer, which gives them experience in management,
documentation, scheduling, and risk resolution. Undergraduate students gain experience
in programming, design, and art (according to their respective degrees), and learn how to
function in a working team environment. For more information on team functionality,
refer to Roles and Responsibilities.
3. GRC Requirements
3.1. General
3.1.1. Front End (FE)
Start Up Sequence

Studio Name and Logo
o It must display for 3 seconds.
o The player must not be able to progress beyond the logo before it times
out (the first time the game is played)
o The player should not have to provide input to go to the next screen once
the time out expires.

Team Name and Logo
o It must display for 3 seconds.
o The player must not be able to progress beyond the logo before it times
out (the first time the game is played)
o The player should not have to provide input to go to the next screen once
the time out expires.

Title screen or your games’ intro screen: In actual games this would function as
the copyright screen. This can optionally be combined with the Main Menu
Screen.

Main Menu Screen
o Upon any action in the menu, there must be unambiguous audio and visual
feedback that the player has performed an action.
o Every action, the player can do in the menu, must have clear directions
listed somewhere on each screen.
o All possible selections from the menu must be functional.
o The Main Menu must include:
o Start button. This button launches the game world/play the game.
o Options menu. That selection must contain the following:
o Volume control

Control for volume of dialog

Control for sound effects

Control for background music
o Gamma control.

Must control the gamma of the game and the game only.

Defaults button to return all settings back to normal.
o Mouse Sensitivity slider if the game needs one.
o Accept button to save any changes.
o Cancel button to allow players to return to the settings of their last save
that is not necessarily the default settings.
o Credits button - This will display game credits.

Must include a list of all individuals who worked on or contributed
to the game

Reference any third-party development tools or any art, music and
sound effects resources used.
o Exit button - This will end the game/program.

Accompanying music/ambient sound should play within the FE.
Entering the Application





When entering the application, if a user only presses enter, they should enter the
game with default settings.
The user may have to press the enter key a couple of times to progress though the
menus.
Networked games are the only exceptions.
By default, the program must enter a listening state where it looks for servers or
other clients after pressing only enter.
On one of the menus, only one extra key press is allowed to let the program go
into a waiting or server state where the program waits for people to connect.
Load Times and Load Screens

Times over 15 seconds before seeing the Main Menu are not permitted.



Any load screens must have a moving or an animated indication, letting the player
know the application is not frozen.
Times over 40 seconds once leaving the Main Menu and going into the Game
World (GW) are not permitted.
Initial game loading must appear seamless and should not show or flash the
desktop after the user starts the application.
3.2. Game
3.2.1. Game World (GW)







At least one functioning and complete level must be represented within.
Accompanying music/ambient sound should play within the GW.
o The sound playing, in the GW and FE, is required to be different
The GW must be textured
Must have a skybox.
o If the GW has no world, i.e. a space game, skybox requirements are much
higher and the skybox must immerse the player.
The GW should have no barren areas
All areas of the GW must be populated by areas of interest for the player.
Upon initial entrance to the GW, the player must have a safe time to orient to the
world. (Examples of point that facilitate this include but are not limited to: )
o The game starting with the avatar temporary invulnerability.
o In a paused state which expires via countdown or player input.
o 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.
If any of the examples listed above do not fit within the game’s design, approval by the
EP must be given for an alternative method.
3.2.2. Game Objects


The player must interact with all objects in the GW. If a player interacts/collides
with another object in the GW, there must be reinforcing auditory and visual
representation of an event.
Moving objects should interact with each other and the world.

Moving Objects should be animated, with at least two animations, or have an
animated texture, or have a procedural animation.
3.2.3. Game-play


The player should be challenged by game initiated interactions (GII) at all times.
There should be no point in the game where the player can stand inactive for long
periods of time without any feedback or game progression.
GII is achieved by one of the following:
o Autonomous Artificial Intelligence (AI), which is aware of, and is
motivated to interact with the player’s avatar. AI, which competes against
the player, must appear to follow the same game rules as the player.
o Networking, the game connects at least two human players between at
least two separate computers.
 They must use standard networking protocols such as TCP/IP, or
IPX/SPX, that is not hard coded, and uses menus or dialog boxes
to facilitate connecting the different systems.
 The end user’s knowledge of networking or IP cannot be tested
and cannot be required.
 The interface must be easy to use and understand.
 Directions for each step of connecting to another player are
required.
o Challenge settings that force the player to compete against an outside
entity (i.e., a time mode for a race game).
3.2.4. Pause Menu


A pause menu must be included in the game.
The pause menu must have:
o Resume button – Continue the game
o Exit button - Exit to main menu
 If the user selects the option to exit the game a confirmation must
ask the user if they really wanted to select that option and offer a
save game state if applicable.
o Option Buttons – All these selections must adhere to all the visual and
audio requirements in Section 1.1.1.4.4.2.
3.2.5. Game Flow



Game Logic and Flow must be demonstrated.
The game must progress and end in a state other than one it started in by effort of
the player.
Upon the player’s completion or failure of game objective, there must be
feedback of the state change and final game state (FGS).
o A FGS may include a player results screen or something similar. It should
include details or other feedback that informs the player as to how well
they progressed through the game.
o User input is required for completion of the final state. The player must
return back to the FE after the FGS is completed or the player may go to
the credits then back to the FE after the FGS is completed.
o Statistics or information on world, player or opponent states (for example
Stats summary or Scoring summary) are required to be displayed on the
completion of the level/game.
o This information should be available while in the GW and before the user
gets back to the FE.
o If the player achieves a high score, or an achievement etc., they have to be
notified in game before returning to the game’s FE.
3.3. Operational
3.3.1. Game Input



Input must include keyboard and mouse.
Anytime a mouse is on the screen the user must have a valid selection available.
The keyboard control must contain:
o Esc
 In the FE, the key goes back one menu until the application is at
the Main menu.
 To exit the application, you can either have a confirmation screen
about exiting the application or you can have it highlight the exit
option and another press exits the game.
 In game, the key should trigger a pause menu. If there is a
selection or the mouse is used for input, the current selection
should be cleared first, and then on a subsequent Esc button press
will bring up the pause menu.
o F1

In game, the key must bring up game help.
 At minimum the objective of the level must be included
with the in game help.
o Alt + Enter
 Must toggle between full-screen and windowed display modes.
o Alt + Tab
 Must toggle between currently running applications on the
computer.
3.3.2. Game Delivery

The game must come with installer.
o The installer must install all software needed to run the game with the
exception of PC drivers.
o The user should be able to properly install the game, with default settings,
by pressing only the enter key or by clicking only next.
o The installer is required to create an icon on the desktop, create a folder in
the start menu with at least a start game icon and an uninstall icon.
 By default both the start menu path should go into the
programs\<Studio Name>\<Game Name> and the default install
directory is c:\ Program Files\<Studio Name>\<Game Name>
o The installer must fit on a 650MB CD.
3.3.3. Installed Game






No visual studio DLL’s are allowed to get installed on the computer.
No SDK’s are allowed to get installed.
The game cannot use more than 256 MB of video memory.
If shaders are used, shader model 2.0 must be supported.
The default resolution is 1024 x 768.
Threads:
o The game can use no more than 128MB of RAM, per thread, at any one
time.
o There is no limit to the number of concurrent threads, but the maximum
memory that can be used, in any time slice, is 256 MB.
o If more than two threads are used, concurrently, the memory limit is still
128MB for the main thread. In addition, all the memory used by the rest of
the threads cannot exceed another 128 MB. This rule has been broken if
at any time the addition of all memory used by all threads is greater than
256MB.
o All threads created, while running the game, must contain the team’s name
or the game’s name.
4. Usability
4.1. Game Object



The objective is required to be displayed 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 and controls to be stated in the FE (as a
loading screen into the actual game state) or as an overlay in the game world.
If this is the case, a continue button waiting on player input must also be supplied.
4.2. Real-Time Display
4.2.1. Real-Time Display (HUD)



There must be a Real-Time Display (HUD) of pertinent player or world states
while in the GW.
The HUD must be fully interactive with the game, meaning it represents the state
of the game/player in real-time.
Everything in the HUD must be functional.
4.2.2. Feedback


The game must provide timely feedback of relevant user actions
Feedback must be given to:
o Pauses of more than 5-10 seconds within the FE.
o Pauses of more 2-3 seconds within the GW.
4.2.3. Game Rules


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:
o The player’s character should not incur damage
o Game action should be suspended while the player is in the menus.
o This section neither applies to games where the main competition is
described under section Time trials nor section real-time networked
games.
4.2.4. Game Regulations





Frame rate should be no less than 30fps average on the target platform.
The first game play sessions are required to perform the same as any subsequent
play session, including any initializations, graphics, sounds, GII and end game
conditions.
The game performance is required to work almost identically between the target
platforms.
The memory footprint of the application will remain constant (for each state) no
matter how many times the user has played or how long a user has used the
application.
Game must be playable for four hours without crashing on the target platforms.
There should be no Class A bugs.
5. Constraints
5.1. GP Games Constraints
Game must be created in accordance to GP class process constraints.
5.1.1. Technical Constraints



3D objects are required in the game.
Game must be the result of substantial original work by the student team.
Game may use only 1 3rd party development tool/API.











Any module that has the base functionality of core modules in DirectX is not
included towards this limit.
Scripting languages such as Lua, RUBY, XML and Python are also not
considered 3rd party tools/APIs.
Examples of a 3rd party development tool/API include ODE, FMOD, Havok, and
Wwise.
Boost can be used as an API but only after GP games and the team have come to
an understanding. Using this API will be monitored very closely.
Use of 3rd 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 containing items of originality.
If you are incorporating other code from the studio or outside sources, it must be
properly credited.
Game content must not exceed the ESRB Teen rating category.
o There must be no pornography, profanity (except mild expletives),
smoking or alcohol references.
Flashing effects and sharp camera motions are not allowed.
GP Games has the right to require some of these problem areas to get removed
and/or changed to prevent possible problems that may occur from an audience
watching the game demonstrated.
Operation outside the agreement set up those two parties will constitute an
automatic failure for the entire team.
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.
5.1.2. Additional Constraints






All milestones are fixed by the EPs and thus intolerant of translation.
The project lasts exactly five months.
Development methodology will be fundamentally focused around Waterfall as
robust preliminary documentation is required by the External Producer.
The final product must be a playable game, running off a Windows-based
Personal Computer, containing three-dimensional graphics and animations.
All generated expenses must be acquired and administrated by the Internal
Producer.
A Project Archive must be received by the end of the last class day prior to
graduation.
6. Final Project Requirements
6.1. Deliverable Requirements
6.1.1. Pitches



Team Member Positions Roster
o Team Members Collected Data
o Executive Decision by IP
Two Game Concepts
o Equal in the development of each
o Game Features
o Concept Art
o Potential Risks List
o Feasibility
Presentations to GP staff
o Verbal approval of game concept by GP staff
6.1.2. Design Document





Interface Design
o Theme definition
o Color definition
o Fonts definition
o Navigation map
Game Story
o Theme
o Place/setting
o Plot
Concept Art
o Characters
o Game Objects
Game Features
o Primary features definition
o Secondary features definition
Gameplay definition
o Controls definition



o Game goals definition
o Rules definition
Game Effects
o Texture effects definition
o Geometry definition
o Sound effects definition
o Particle effects definition
o Animation definition
Music style definition
Delivery to GP staff
6.1.3. Technical Document









API
Timing Specifications
o Minimum 45 FPS
o Frame update procedure
Coding Standard
o Naming standards
o Structure setup standard
o Class setup standard
o Commenting Standard
o Coding guidelines
Development environment
o API & third party libraries
o 3D modeling tools
o Input tools
o 2D texture tools
o Compiler
File Format(s)
Naming Convention
UML(s)
o System Architecture
System feature breakdown
o Features
o Estimated completion time
o Author
o Associated risks
Game feature breakdown
o Dialogue manager




o Ability manager
o Cinematic manager
Memory map
o Research RAM performance needs
o Document RAM performance needs
o Research graphics memory performance needs
o Document graphics memory performance needs
Integration Plan
o Create integration P&P
o Create rollback P&P
o Create file checkout P&P
Testing plans
o Create bug database
o Manage bug database
Delivery to GP staff
6.1.4. POC (Proof of Concept – Playable Game Demo)







State Machine
o Implement Framework
Main Menu State
 Implement Framework
o GUI Placeholder
o New Game Creation Functionality Implementation
o Quit Game Functionality Implementation
o Options
o Credits
Gameplay State
o Win
o Loss
Object Manager
o Implement Framework
Input Module
o Implement Framework
o Mouse Functionality
o Keyboard Functionality
o Game Controller Functionality
Event Module
o Implement Framework
Render Engine








o 2D Rendering Implementation
o 3D Rendering Implementation
o Effects Engine Implementation
o Camera Implementation
o Animations Implementation
o Sorting Objects by Opacity Implementation
o Sorting Objects by Depth Implementation
o Texture Manager Implementation
Player Character
o Implement Framework
o Create Placeholder art asset
o Integration of Placeholder asset
o Movement
o Implement Attack
Enemy
o Implement Framework
o Create Placeholder art asset
o Integration of Placeholder asset
o Implement Artificial Intelligence
Game World
o Implement Framework
o Creation of Placeholder art asset
Collisions
o Implement Framework
o Implement Collision detection
o Implement Collision reaction
Run through milestone check list (TBD)
Perform Weekly Test Builds
Update documentation
o Update Design Doc
o Update Tech Doc
o Update Gantt Chart
o Risk Assessment
Fix Bugs
o Allow no A level bugs
o Allow 50 B level bugs
o Allow 500 C level bugs
6.1.5. Feature Fragment One (Second Playable Demo with Required A Level
Features)







Front End State
o Splash Screens
Options Menu State
o Implement Framework
o Volume Controls functionality
o Gamma controls functionality
Implementation of “A” features
o HUD
o Player Character
o Game World
o Sounds
o Effects
Perform Weekly Test Builds
Update documentation
o Design Document
o Tech Document
o Team Logo
o Gantt Chart
o Risk Assessment
GRC Review
Fix Bugs
o Allow no A level bugs
o Allow 25 B level bugs
o Allow 250 C level bugs
6.1.6. Feature Fragment Two




Implement B Features (TBD)
Perform Weekly Test Builds
Presentation
o Create PowerPoint presentation
o Practice PowerPoint presentation
o Deliver Presentation
Update documentation
o Design Document
o Tech Document
o Gantt Chart

o Risk Assessment
 GRC Review
Fix Bugs
o Allow no A level bugs
o Allow 15 B level bugs
o Allow 150 C level bugs
6.1.7. Alpha




Playable Demo
o Create 2D Assets
o Create 3D Assets
o Effects
o AI
o Animations
o Gameplay
o Interactive tutorial
o Testing
o Bug verification
Gameplay Manual
o Introduction
 Control Explanations
 Gameplay Explanations
 Goals Explanations
Updated documents (TBD)
o Technical Document
o Design Document
o Risk Assessment
o GRC Review
o Gantt Chart
o Delivery to GP Staff
Alpha Presentation
o Game Power Point Presentation
o Delivery to GP Staff
6.1.8. Beta

Playable Demo
o Create 2D Assets
o Create 3D Assets




o Effects
o AI
o Animations
o Gameplay
o Testing
o Bug verification
o Delivery to GP Staff
Game Power Point Presentation
Updated documents (TBD)
o Technical Document
o Design Document
o Risk Assessment
o GRC Review
o Gantt Chart
o Gameplay Manual
Delivery to GP Staff
Beta Presentation
6.1.9. Gold





Final game build
o Final polished game
Final game install
Final Game Presentations
o Create PowerPoint presentation
o Practice presentation
o Deliver presentation
Update Documentation
o Design Document
o Tech Document
o Gantt Chart
o Risk Assessment
o GRC Review
Fix Bugs
o Allow no A level bugs
o Allow no B level bugs
o Allow 20 C level bugs
6.1.10. Archive





Compile documentation
o Game Bible
o Final game source code
o Screen shots
o Screen shot captions
o Entire game schedule
o Cover & CD Labels
o Updated Gantt Chart
o ReadMe.txt file
o Credits.txt file
Deliver Final game Installer
Deliver Source Code
Deliver Videotaped gameplay on Mini-DV
Deliver Final Presentation PowerPoint
7. Additional Requirements
These requirements provide a measure of the quality of work expected by the Game
Design Master’s Students.




At least 30% of the pitches’ presentation slides must include concept art.
In-game Interface
o Game world elements and characters cannot overlap the in-game interface
at any time.
o All in-game text must be outlined.
o In-game interface elements must not occupy more than 12% of the screen
area in a screen of 1024x768.
o Game must contain a mini-map if entire game world is not visible at all
times.
Elements that are not exclusively made as part of the static environment must
have more brightness and contrast with the elements that are part of the static
environment.
Every character and object in the game must have three different concept art
sketches, at least one of them in color and in printed version.












The last objective of the game must be a boss battle or a challenge that is more
complex than any of the other challenges in the game.
All items must have different colors and shapes.
There should be at least two different environments in the game world.
There should be at least four different actions available for the player at the start
of the game.
Game goal definitions should have a way to be measured.
o Measure of the game goals completion should be available for the player
at all times during gameplay.
A warning sign must be sent to the player when the player is close to losing the
game.
Control instructions and mapping should be available for the player at all times
during gameplay.
APIs must include name, hierarchy level and purpose of all functions written on
the game source code.
All game assets must follow the same naming standard.
All functions must have their purpose written as a comment above their first line.
The game must allow player name registry.
Saving
o The game should have three or more save slots.
o A saving option should be available for the player at all times during
gameplay.
8. Roles and Responsibilities
8.1. Primary Stakeholders
All information regarding the project’s stakeholders is within the Stakeholder Registry
(see Appendix B). Primary stakeholders are those who are involved in Final Project and
have a direct impact on the development and elaboration of the project. For more
detailed information regarding roles and responsibilities, see Staffing and
Communications Management Plan (TBD).
8.2. Production
8.2.1. Internal Producer
The internal producers are the Full Sail University Game Design Master’s of Science
students who oversee the undergraduate team. This role establishes and enforces policies
and procedures for the entire team, such as establishing roles, work norms, maintaining
focus, resolving internal conflict efficiently, and maintaining an open channel of
communication between the team and the GP Games staff. They also assess all possible
risks that may threaten the scope of the project, while also attempting to mitigate and
control these potential threats. Additionally they schedule all team meetings and group
work in order to fulfill all requirements for deliverables and milestones.
8.2.2. External Producer
The external producers are the Full Sail University Final Project staff members who act
as a bridge between GP Games and each team. Initially, external producers work with
GP Games in deciding which game is best suited for each team to pursue. During the
course of Final Project, they communicate with internal producers to convey work
requirements and milestones, while providing grading and feedback on deliverables at the
same time. They also monitor documentation and team progress through frequent
meetings with the internal producer. If needed, they can also step in to resolve team
conflict that is beyond the internal producer’s capabilities, and can facilitate external art
and sound support.
8.2.3. Executive Producer of GP Games
Liam Hislop is the current Executive Producer of GP Games. His responsibilities
primarily include overseeing and assigning External Producers, while also monitoring
progress of each Internal Producer indirectly through the External Producers. He must
create, assign, and enforce all requirements and milestones for each team, which he
monitors through documentation review and deliverable critique. He can pass or fail
students based on appropriate documentation from the internal producer, and has the
ability to terminate all projects that do not meet GP Games standards. He serves as a key
decision maker during Final Project pitches and presentations.
8.2.4. Art Director
The art directors are the Full Sail University Final Project staff members who act as a
bridge between GP Games and the art students within each team. Primarily, they serve as
advisors to the art students within the team. Art Directors evaluate the overall quality of
all art assets created, providing feedback when needed to help keep style consistent and
the established art direction maintained. Finally, they provide the art students their
grading, as well as creating assets for a team when the team make-up requires so, such as
a team lacking sufficient artists.
8.3. Art Team
8.3.1. Art Lead
The Art Lead is an undergraduate student from the Game Art degree and is assigned by
the Internal Producer based on skill, input from the GP Games staff, and expressed
interest. They work with the Asset Lead to manage and maintain the asset pipeline,
ensuring that communication between programmers and artists is open and effective.
This helps to cut down on errors and misunderstandings that may develop between each
party, resulting in fewer bugs and conflicts between art and code. The Art Lead oversees
all artist work for quality, creativity, and consistency. In addition, they contribute to
environment and level design, and they develop and maintain polygon counts based on
engine restrictions.
8.3.2. 2D Lead
The 2D lead is an undergraduate student from the Game Art degree and is assigned by the
Internal Producer based on skill, input from the GP Games staff, and expressed interest.
Initially, they produce concept art and storyboarding for the Final Project pitch to give
GP Games staff a visual means of understanding game genre and concept. Throughout
the development cycle, they oversee the creation and quality of all 2D art assets in
conjunction with the internal producer. They help to design and generate menu art, the
HUD, interface look and feel, credits, the pause menu, effects such as explosions, ingame 2D art, and textures.
8.3.3. 3D Lead
The 3D Lead is an undergraduate student from the Game Art degree and is assigned by
the Internal Producer based on skill, input from the GP Games staff, and expressed
interest. They contribute to the conception of level design based on concept art and
mapping provided by the team. From these, they develop models, rigging, movement,
and textures. They also work with programmers to create animations iteratively based on
code available and the project’s current stage.
8.3.4. General Game Artist
The General Game Artist is an undergraduate student from the Game Art degree. They
are responsible for creating art assets such as models, rigging, movement, and texturing,
while staying within the consistency constraints set by game concept, genre, and agreed
look and feel as determined by the team. They should be flexible and able to adapt to any
style and task required for the game as assigned by the Art Lead and Internal Producer.
8.4. Gameplay Team
8.4.1. Gameplay Lead
The Gameplay Lead is an undergraduate student from the Game Development degree and
is assigned by the Internal Producer based on skill, input from the GP Games staff, and
expressed interest. They are in charge of design, but should take into account the entire
team’s voice. They fix gameplay problems, while ensuring balance such as enemy and
environment difficulty is maintained within the game. They contribute to level design,
and above all, they must play the game multiple times a day to ensure the game is
functional and within the quality requirements as established by the team.
8.5. Quality Assurance Team
8.5.1. Quality Assurance Lead
The Quality Assurance Lead is an undergraduate student from the Game Development
degree and is assigned by the Internal Producer based on skill, input from the GP Games
staff, and expressed interest. They are responsible for playing the game multiple times a
day throughout all stages of development, attempting to find vulnerabilities, visual bugs,
exploits, and aspects of the game that lack functionality. They monitor and control Test
Track Pro, a reporting database that allows the Quality Assurance Lead to submit bug
reports, assign responsibility for fixing each bug, and for checking progress on the
completion and status of all bug fixes within the game. If necessary, they also do general
programming as delegated by the Programming Lead.
8.6. Technical Team
8.6.1. Technical Lead
The Technical Lead is an undergraduate student from the Game Development degree and
is assigned by the Internal Producer based on skill, input from the GP Games staff, and
expressed interest. This student should not only be a strong programmer, but also a
strong motivator and teacher for the programming team staff. They build and maintain
the game engine, keep track of all code, schedule frame rate reworks and code
optimization as needed, and assign tasks in conjunction with the Internal Producer. They
work with the Internal Producer and Art Lead to ensure deliverables are being produced
on time and a level of quality consistent with requirements set by GP Games and the team
is maintained.
8.6.2. General Game Programmer
The General Game Programmer is an undergraduate student from the Game
Development degree. They are responsible for generating and optimizing code, fixing
bugs, and creating effects while staying within the consistency constraints set by game
concept, genre, and agreed upon standards as determined by the team. They may also
contribute to creating interface, text, and menus in conjunction with the artists, and
assuring each works properly. They should be flexible and able to adapt to any style and
task required for the game as assigned by the Programming Lead and Internal Producer.
8.7. Secondary Stakeholders
All information regarding the project’s stakeholders is within the Stakeholder Registry
(see Stakeholder Registry). Secondary stakeholders are those who affect those directly
involved in Final Project and have no major impact on the development and elaboration
of the project. For more detailed information regarding roles and responsibilities, see
Staffing and Communications Management Plan (TBD).
8.7.1. Students’ Friends and Family
These individuals add nothing directly to the Final Project content. However, they
provide a system of support to the student that encompasses moral, emotional and
psychological encouragement to help them achieve success.
8.7.2. Full Sail University
Full Sail University provides students with the knowledge necessary to be able to
successfully complete Final Project. Additionally, it provides experienced individuals, in
the form of instructors, who can provide support and insight to the team as required.
8.7.3. Game Dev. Advisory Board
The Game Development Advisory is a group composed of individuals from the gaming
industry and the Full Sail University staff that provides feedback and information about
the current state of the gaming industry during Final Presentation.
9. Project Scope Statement
Final Project as it is defined in this document symbolizes the five-month software
development cycle of a video game as it is delineated in (see Objectives). This project
represents the educational capstone project not only for Full Sail University's Game
Design Master's program, but those other video game-related degrees mentioned
subsequently. Ultimately, Final Project aims to equip those participating students with
the skills and experience necessary to leverage corresponding roles in the industry
following graduation.
Tailored to the sundry requirements of Full Sail University's GP Studios (see GRC
Requirements), represented by Studio Director and Project Owner Liam Hislop, various
deliverables and milestones are delineated as measurements of progress toward project
completion (see Milestones and Deliverables). Additionally, as enrolled in the
aforementioned degree programs, the participating students fundamentally shoulder a
varied set of requirements from which Final Project and/or any of its deliverables,
milestones, or component parts ought to render fulfillment (see Additional
Requirements).
The enrolled master's student(s) will behave as Internal Producer(s) (IP) and manage the
project, including the development team, throughout the development process from
earliest concept to gold master, including all those deliverables and milestones in
between and archival thereafter. Working beneath an External Producer (EP) outside the
team, those undergraduates beneath the IP's influence represent a number of Full Sail
University video game development-related degrees including, but not limited to, Game
Art and Game Development bachelor's programs (see Roles and Responsibilities).
Lastly, Final Project carries with it scope-related considerations regarding budget, Policy
and Procedure, Risks, Assumptions, and constraints (see Scope Exclusions).
10. Milestones and Deliverables
This section is comprised of the milestones and deliverables due for Final Project. For a
more detailed description of the requirements needed for each deliverable, please see the
Requirements section.
10.1. Game Pitches
Final Project teams are comprised of undergraduate Game Art and Game Development
students and graduate Game Design students, as assigned by GP Games. At the
beginning of the development of this milestone, the teams develop team member roles,
policies, and work norms. Following team organization, teams must develop and present
two game ideas via PowerPoint. Each game pitch will be between 10 and 15 minutes in
length and will include a brief question and answer session with the staff of GP Games.
Following the pitches, the staff will deliberate and each team will be assigned a game for
development, as well as an External Producer to oversee their progress.
Final Project Pitches will include the following:
 Team Member Positions Roster
 Two Game Concepts in Presentation Form
o Game Features
o Risks
o Feasibility for a five month project
o Game Title
o Game Genre
o Game Marketability
 Final Project Presentations to Staff
 Verbal Approval or Denial of Game Concepts
10.2. Design Document
Once pitches are complete and the GP Games staff has assigned a game for completion,
the team must develop the Design Document to describe the look and feel of their game.
This includes developing and documenting interface design, storyline, concept art, game
features, gameplay, in-game objects, effects, and music. This will serve as the blueprint
for design and should be a living document, constantly being updated and changed as
needed for sufficient detail as a reference for each team member.
Key Sections of the Design Document include:
 Interactivity
 Glossary
 Characters/Weapons/Power-Ups
 Levels
 Key Algorithms/Puzzle
 Combat systems/Special systems
 Art and Production Design
10.3. Technical Document
The Final Project Tech Document is the team’s reference guide to the game’s
functionality and should not only prove that the ideas presented in the Design Document
can work, but should also outline how they will work. This document should give a
detailed plan for the production phase and much like the Design Document, should be a
living document that constantly changes and evolves appropriately with the growing of
the game. This should be a written record of all technical decisions made so that each
member of the team can refer back to the information to keep the project on task and
within the requirements set by GP Games.
Components of the Tech Document include:
 Title Page
 Table of Contents
 Document Overview
 Coding Specs and Conventions
o Unifies Code
o Environment Development
o Naming Conventions
 Timing Specifications
o Minimum frame rate of 45 FPS
 Module/Feature Breakdowns
o Engine
o Gameplay
 System Architecture Chart and Description
 Milestone Deliverables


Memory Map
o RAM Performance
Testing and Integration Plans
o Create and Manage Bug Database
10.4. Proof of Concept
The Proof of Concept is the playable demo and accompanying presentation that
introduces at least 50% of the game features scheduled for Feature Fragment 1 to the GP
Games staff. The presentation should demonstrate that team members are following the
documentation that they developed to outline standards, and the playable demo should
include a player character, enemy, game world, win and lose conditions, collision, and
2D and 3D rendering implementation.
Proof of Concept includes:
 Presentation
o Team introduces themselves
o Game was fully explained
o Team did a full demo walk-through
o Team repeated questions before answering
o Team responded professionally
 Tech should work toward improving or advancing to Feature Fragment 1
o Demonstration shows at least 50% of the core game-play required in
Feature Fragment 1
o Team members’ code should constitute a week’s worth of time
 Integrated code should communicate according to the System Architecture
o Team submits a single unified build
o All team members’ tasks integrated
 Gantt Chart reflects all scheduled work
o Schedule ascribes to all rules expected of scheduling
o Tasks contain sufficient completion criteria
o Progress and slippage correctly displayed
10.5. Feature Fragment 1
Feature Fragment 1 should serve as a second draft of the Proof of Concept and will
incorporate 100% of the core gameplay features. The team will demonstrate consistency
both in art and code, and the Gantt chart and all documentation must be updated and
complete to reflect any changes or updates made. The team will do another presentation
similar to the one done for Proof of Concept, and students will be graded on the same
criteria, plus the complete core features.
Feature Fragment 1 includes:
 Presentation
o Similar to Proof of Concept presentation
o PowerPoint presentation
o Working demo with walkthrough
 Front End State
o Splash Screens
o Art Assets including a team logo
 Options Menu
o Volume and Gamma control functionality
 Implementation of “A” or core features
o HUD
o Player Character
o Game World
o Sounds
o Effects
o Win Condition
 Updated Documentation
o Risks identified and assessed
o Gantt Chart Updated
 Bug Repairs
o Allow no A level bugs
o Allow 25 B level bugs
o Allow 250 C level bugs
10.6. Feature Fragment 2
Feature Fragment 2 will be the last presentation of gameplay before the project enters the
Alpha stages. Similar to Feature Fragment 1 in requirements, this milestone will mark
considerable progress from the last deliverable. Core features should be completely
functional and polished, and secondary features should be seen at least in their beginning
stages of implementation.
Feature Fragment 2’s requirements in addition to those from Feature Fragment 1 include:
 Implement B Features
 Perform Weekly Test Builds
 Presentation
o Similar to Feature Fragment 1 presentation
 Update Documentation
 Fix Bugs
o Allow no A level bugs
o Allow 15 B level bugs
o Allow 150 C level bugs
10.7. Alpha Build
The game Alpha should be considered a second draft of Feature Fragment 2 and will
have the same requirements that it had. Students will have polished and refined the work
from that milestone in order to be successful on this one. The demo will exhibit 100%
completion of all core features, and 75% completion on secondary game features.
Alpha requirements in addition to those from Feature Fragment 2 include:
 Playable Demo and Presentation
o 2D and 3D assets should be fully integrated and consistent
o Environmental, weapon, and interface effects
o Boss and Enemy AI functional
o 2D and 3D animations should be fully integrated and consistent
 Gameplay
o Balance verification
o All A features implemented
o 75% of B features implemented
 Interactive Tutorial
o Control, Goals, and Gameplay Explanations
 Testing


o Bug Verification
o Bug tracking and logging
Gameplay Manual
Updated Documents
10.8. Beta Build
The Beta must incorporate the requirements of both feature fragments, and must have all
features finished including 100% of all core and secondary features. This game should
also be playable and complete, but bugs are still being caught at this point in
development.
The Beta Build involves:
 Playable Demo and Presentation
o 2D and 3D assets should be fully integrated and consistent
o Environmental, weapon, and interface effects
o Boss and Enemy AI functional
o 2D and 3D animations should be fully integrated and consistent
 Gameplay
o Balance verification
o All A features implemented
o 100% of B features implemented
 Interactive Tutorial
o Control, Goals, and Gameplay Explanations
 Testing
o Bug Verification
o Bug tracking and logging
 Gameplay Manual
 Documentation Updates
10.9. Gold Build
This is the final build of Final Project and will be the showcased during Final Project
Presentations. Gold should include any requirement from Feature Fragment 1, Feature
Fragment 2, Alpha, and Beta. This final build should be completely polished and totally
bug-free to the best of the abilities of the team. Beauty quality assurance is implemented
for this phase to ensure the look and feel of the game is consistent, and that gameplay is
balanced, smooth, and error-free.
The Gold Build includes requirements from previous builds as well as:
 Final Game Build
o Levels aesthetics
o Gameplay balance
o Enemy balance
 Final Game Installer
 Final Game Presentations
 Update Documentation
 Fix Bugs
o Allow no A level bugs
o Allow no B level bugs
o Allow 20 C level bugs
10.10.
Archive
The final compilation of all Final Project documentation results in the game Archive, and
eventually the Game Bible. This is comprised of all schedules, policies, and lists that
were generated throughout the project, and will be handed in as the final deliverable for
Final Project.
All Archive requirements include:
 Documentation compilation
o Cover sheet
o Design Document
o Technical Document
o Code Document
o Entire game schedule
o Updated Gantt Chart
 Final game source code
 Screen shots with captions
 Cover and CD labels
 ReadMe.txt file for instructions on gameplay
 Credits.txt file
 Final game installer
 Sample code from each programmer
 Videotaped gameplay on Mini-DV
 Final Presentation PowerPoint
10.11.
Scope Exclusions
Understanding there are limitations for this and any project, it is important to identify the
boundaries of scope. The entirety of this document details all those components
altogether occupying the scope of Final Project. This particular section aims to pinpoint
and define these boundaries by differentiating all that to be considered outside of scope
and thus excluded from Final Project.
Due to the fact that Full Sail claims ownership of the finished game and states that no
game created in final project will be made commercially available, we will not sell the
game for any sum of money.
 Because development of the game is the primary focus during the five months, we
will not be creating a website promoting our game during production.
 Online play features are outside the bounds of GP Studios requirements, and also
creating online play aspects will be too much of a tasking for a five month project.
 Due to GRC requirements, any non PC-based development will be excluded.
 Additional content or update patches after the Gold Master deliverable will not be
discussed or worked on during production.
 Because the GRC states that each team will only be allowed to use one API, we
will not be using multiple APIs.
 Due to us only creating the game for the PC-based platform, there will be no
tactile feedback such as a “rumble” feature.
Due to budget constraints, there will be no professional voice acting.
The genre created will not be an MMO as this genre requires far more work and
maintenance than current time tables and staffing allow.
10.11.1.
Constraints
The constraints of this document reflect the contractual obligations dictated by the GRC.
The scope of our project will operate within these boundaries.
 All milestones are fixed by the EPs and thus intolerant of translation.
 The project lasts five months.
 Development methodology will be fundamentally focused around Waterfall as
robust preliminary documentation is required by the External Producer.
 The final product must be a playable game, running off a Windows-based
Personal Computer, containing three-dimensional graphics and animations.
 All generated expenses must be acquired and administrated by the Internal
Producer.



Third-party development engines are allowed under strict rules and supervision
detailed in the GRC
Most of project must be original work by the students composing the team
Game can’t exceed Teen rating level of ESRB
10.11.2.









Assumptions
All team members will be proficient with necessary tools and skills to allow the
project requirements to be met.
An adequate meeting space with reliable high-speed wireless internet will be
available, free of noise and distraction for the duration of the required meeting
times, to ensure productivity.
All team members will only work on documented features or features that have
been approved by the IP and the EP through the change request process (See
Change Request).
EPs will approve changes requested by the team within approximately 24 hours
All required software and hardware will be working properly at all times
The software and hardware tools used will be adequate to accomplish the
requirements of the project
The EPs will give the teams specific, measurable, and realistic requirements with
adequate time to incorporate them into the project’s scope
Data loss will be able to be prevented by following policies and procedures used
in this project
Deliverables will meet all objectives and requirements when submitted to EPs
10.11.3.
Risks
Team members not proficient with necessary tools and skills can lead to loss of
productivity.
 There may not be an adequate meeting space due to lack of power, excessive
noise, or lack of adequate Internet connection for all team members.
 Team members may work on features that have not been approved through
documentation or the change request process, leading to feature creep.
 EPs may take too long to approve changes requested by the team, leading to
delays or causing intended changes to be cut
 Required software and hardware may not be in working order leading to loss of
productivity.
 Software and hardware tools may not be adequate to accomplish the goals of the
project
 The EPs may not provide specific, measurable, or realistic requirements for all



aspects of the project, causing difficulty when determining scope
Loss of data due to either “acts of God” or by not following backup procedures
Deliverables may not meet all objectives and requirements, and will be
subsequently rejected when submitted to EPs. If sufficient costs are needed to fix
the deliverable, a change request may be needed to alter the scope so that the
project can still be completed within the allotted time.
Narrow scope can result in demoralization from the lack of work available for all
team members, resulting in lower quality work.
11. Scope P&P
11.1. Data Backup
As loss of data negatively effects one or many of the four project management
constraints—and scope among them--data backup is essential to prevent deviations from
project scope as it is defined by this document. Thus, all files will be saved in no less
than three separate locations. This is to ensure that in the event that there is data
corruption or loss, multiple copies of files saved at multiple locations effectively establish
these problems as non-issues. The first location will be on the Full Sail network. The
second location will be on the IP’s computer. The third location will be a separate
external hard drive, maintained by the IP.
11.2. Internal Producer’s Log
The Internal Producer's Log is a written record kept by the Internal Producer to actively
monitor and control the progress of the project. When used concurrently with Scope
Checklists (see Scope Verification and Appendix B for sample Scope Checklist), Scope
Verification is further enabled as a tool to keep the project to the work described and only
the work described in this Project Scope Management Plan. This document is passed
from acting IP to the next assigned IP at the Transfer Meeting. Broken down in the
following sections, the IP can utilize the Internal Producer's Log to proactively monitor
ongoing processes and identify diversions from scope.
11.2.1. Assignment Plans


The Assignment Plan will be developed each team work day. It will reflect the
changes in the assignment, and the roles & responsibilities of the team members.
The Assignment Plan will be done even if it is not required by Rupert anymore.
11.2.2. Attendance Log

The Attendance Log tracks the clock-in and clock-out times of every individual
for arriving, lunch break, and departure for team work days.

The IP is in required to oversee this log. IP initials’ are marked for those who are
on time and tardy team members will be logged in the Discipline Log.
11.2.3. Discipline Log




A form is maintained by the IP(s) each work day that tracks all infractions, the
person(s) involved, and the level of the infraction (minor or major).
The IP is required to re-tally the infraction count for the person(s) involved, and
determine if further action is needed (See Infractions).
If penalty is due, the IP is required to follow the Infractions policy as closely as
possible (See Infractions). The penalty must be logged in detail within the Internal
Producer’s Log.
Penalty Description within the Discipline Log includes:
o Person
o The date it occurred
o Situation description from the IP
o Initials from the IP, perpetrator(s), and all others involved
Example: Joe Student, June 15, 2010
Joe was late for the team work day on three occasions; specifically the 10th, 12th, and
15th. The EP has been informed that our policy requires the proper deduction of GPS
points, as if Joe was marked as tardy for one class. The EP has committed the GPS
reduction as prescribed.
Initialed by IP, Joe Student, and the EP
11.2.4. Turbo Teams


Daily Turbo Team meetings will be led by the IP.
Turbo Team notes need to be taken by the IP. These notes need to be properly
labeled and as detailed as possible, and then placed in the Internal Producer’s
Log.
11.2.5. Postmortem

The postmortem is a description of the IP’s experience leading the team. The
purpose of these descriptions is for the following IPs to have a brief but
intentional reflection of lessons learned so far.
11.3. Professionalism
Full Sail standards, GPS standards, and the GP Games standards for professionalism and
conduct will all be applied. Man-hours are lost and one or more of the four project
management constraints may be affected. Of these, scope remains a potentially
significant factor. Thus, behavior concordant with the professionalism standards outlined
in those documents above is critical to help verify scope.
11.4. Infractions
Infractions are any behavior that affects the overall effectiveness of the team in a negative
manner, resulting in changes in time, quality, cost, or scope. Distracted workers leading
to loss of man-hours is one example. Since scope is a potentially affected factor,
infractions must be minimized. In an effort to do so, the Internal Producer may appeal to
the EP to enforce professionalism standards outlined by Full Sail, GPS, and GP Games
standards.
11.5. Scope Verification
11.5.1. Inspection
Verification that the project is on schedule and within scope will be confirmed by the IP
with scope checklists (see Appendix B). The IP will also be able to verify that the project
is keeping within the scope by measuring the progress within the Internal Producer’s Log
(see Internal Producer’s Log).
11.5.2. Submission
The IP will meet with the EP for the formal acceptance of the deliverable’s completion in
the third week of the final month of final project. The IP will present the EP the final
deliverable by means of CD-ROM. Upon acceptance, the EP will sign off on the project
by filling out a project deliverable acceptance document. In the case the deliverable is
not accepted, the EP will define the changes that need to be done on the deliverable and
will take disciplinary actions as needed.
11.6. Scope Control
11.6.1. Change Request
All changes to the project must be approved by the IP and the EP after reviewing the
Change Request Form (See Appendix C) submitted by a team member. When reviewing
a potential change, the IP should consider how the change will impact all aspects of the
project such as time, cost, quality, and scope, etc. If the IP approves a change, it will be
submitted to the EP for approval. The EP has the same ability as the IP to reject or
approve the change. Once the EP approves the change, it will be implemented by the
team. The IP keeps this form in the IP Log and informs the appropriate team lead to
enact the change. If the Change Request Form is denied by the IP or EP, the change is
not made but the form is still kept in the IP Log.
11.6.2. Art Asset Request
All art assets must be approved by the IP and the Art Director using the Art Asset
Request Form (see Appendix TBD). A team member or the IP may initialize this
process, which must ultimately be approved by the IP before progressing on the EP and
Art Director. Although the EP, and IP are consulted in this process, the Art Director
retains final approval rights to all art asset request changes. If approval is granted, the IP
is notified via the same request form given to the EP and Art Director at the onset, which
is then filed in the IP log. The IP then enacts the change by informing those team
members producing the art assets. If the Art Asset Request Form is denied by the IP or
Art Director, the change is not enacted, but the form is still filed away in the IP log.
11.7. Attendance
Attendance is an important aspect on how the project is completed on time and under
budget. While there are policies and procedures to make sure that team members will
come to work on time, in event of issues, the timeline might need to change, thus
changing the scope of the project. The point of defining the attendance policy is to show
how attendance is controlled and thus how man-hours are tracked.
Tardiness: Arriving one minute past the appointed time is considered tardy and will be
documented by the IP in a logbook. Each tardy will be considered a Minor Infraction (see
Discipline section).
Excused Absences: Circumstances such as illness, car troubles, valid appointments,
emergencies, etc. will be treated on a case by case basis by the IP and may be considered
an excused absence. Excused absences will be noted in the log with the number of hours
missed. Team members with eight or more hours, which will be considered a Major
Infraction (see Discipline), will be counseled on the present situation and a
recommendation to the course director will be considered.
Important Note: If the team member does not call ahead to alert the team, it will be
considered an unexcused absence.
Unexcused Absences: Any unexcused absences will be noted by the IP in the log and the
Major Infraction policy will be acted upon (See Discipline).
Alternate Meeting/Location: The IP is the only person who can change the location and
time of a meeting. However they cannot make changes within 3 hours of the scheduled
meeting time. If a change is made then the IP is also required to email every team
member informing them of the change with the new time and location.
Important Note on Meeting Changes: If the IP changes the scheduled meeting time,
either increasing the time or decreasing the time, the absentee policy only applies to the
original meeting time.
12. Budget
See file “04_SPMP_Budget_ver03.xls” for detailed breakdown.
12.1. Budget Descriptions
In considering a budget, all salaries are figured around dividing averaged salaries for
2007 across the industry for individuals with less than three years of experience, dividing
by twelve months in the year, and then multiplying by the five months entailing the scope
of Final Project. The Business Contingency refers to backup funds necessarily withheld
to reduce risk.
12.2. Overhead
Office Rental (six-month lease) = $24,000
500 by 300 square foot office space in 5-story building with on-site maintenance,
management, conference rooms, building security, and fiber optic capability, suitable for
small businesses or large companies, located at Major Blvd, Orlando.
Furniture = $4,560
$1,632 for 6-month rental of 16 Halton 24” x 45” Right Pedestal Sales Desks at $17 per
desk
$960 for 6-month rental of 16 Lariat Task Chair with Arms at $10 per chair
$1,632 for 6-month rental of 16 Brylee Guest Chair at $17 per chair
$336 for 6-month rental of 2 Halton 48x96 Conference Table at $28 per table
Utilities = $1,200 x5 months = $6,000
Includes average rates calculated for aforementioned office rental including electric,
water, sewage, trash, and internet for five months.
Insurance = $3,500 x5 months = $17,500
Includes general liability insurance for small businesses from State Farm.
Computers:
Dell PowerEdge T100 $2,469 (x1) = $2,469
Intel® Core 2 Duo®E7400, 2.80GHz, 3MB Cache, 1066MHz FSB, 4GB, DDR2,
800MHz, 4x1GB,Dual Ranked DIMMs, Windows Server®2008SP2, Standard Edition,
Includes 5 CALs,w/2003 media, Onboard SATA, 1-2 Drives connected to onboard
SATA controller - No RAID, 1TB 7.2K RPM Serial ATA 3Gbps 3.5-in Cabled Hard
Drive, Primary, 1TB 7.2K RPM Serial ATA 3Gbps 3.5-in Cabled Hard Drive,
Additional, 16x DVD Drive, Internal.
HP EliteBook 8730w $1,629 (x8) = $13,032
Genuine Windows® 7 Professional), Intel® Core™ 2 Duo Processor P8400 (2.26 GHz, 3
MB L2 cache, 1066 MHz FSB), Mobile Intel® PM45 Express Chipset ICH9MEnhanced, HP 3D DriveGuard; Intel® Centrino® 2 with vPro™ processor technology, 1
GB 800 MHz DDR2 SDRAM, 160 GB 5400 rpm SATA II, DVD; LightScribe DVD+/RW SuperMulti with Double Layer; Blu-Ray R/RE DVD+/-RW SuperMulti DL, 17.0inch diagonal WUXGA DreamColor WVA, Microsoft DirectX 10.1 (Shader 4.1) and
OpenGL 2.1 capable (models with ATI graphics), 4 USB 2.0.
MacBook Pro $2,427 (x8) = $19,423
2.8GHz Intel Core 2 Duo4GB 1066MHz DDR3 SDRAM - 2x2GB320GB Serial ATA
Drive @ 7200 rpmSuperDrive 8x (DVD±R DL/DVD±RW/CD-RW)MacBook Pro 15inch Glossy Widescreen DisplayBacklit Keyboard (English) / User's GuideMicrosoft
Office Mac 2008 - Home and Student EditionMini DisplayPort to VGA
AdapterAccessory kit
12.3. Software
Visual Studio Team System Editions with MSDN Premium (x1) = $5,469
VSTS Team Foundation Server Workgroup Edition (5 users), Expression Studio, toolkits,
SDKs and DDKs, four technical support incidents, MSDN library, managed newsgroup
support, online concierge, MSDN Magazine, MSDN Flash.
Adobe Soundbooth CS4 (x2) = $398
Create and edit audio, automatic volume correction, speech search, visual tools for
healing sound, looping tools, multitrack support.
AlienBrain Team Pack License = $32,000
5 Alienbrain Advanced clients, 20 Alienbrain Essentials for Artists clients, 1 Remote
Collaboration Server, 1 year of maintenance.
Autodesk Maya 2010 $4,090 (x6) = $24,540
Autodesk® Maya® 3D modeling, animation, rendering, and visual effects software offers
artists an end-to-end creative workflow. Autodesk Maya 2010 software is the first release
to unify the Autodesk® Maya® Complete 2009 and Autodesk® Maya® Unlimited 2009
feature sets, advanced matchmoving capabilities, and high dynamic range compositing
into a single affordable package*. Also included for a complete CG workflow are 5
additional mental ray® for Maya batch** rendering nodes and the Autodesk®
Backburner™ network render queue manager (from autodesk.com).
Design Premium CS4 College Student Edition $400 (x8) = $1,600
Includes Adobe InDesign CS4, Adobe Illustrator CS4, Adobe Photoshop CS4 Extended,
Adobe Acrobat 9 Pro, Adobe Flash CS4, Adobe Dreamweaver CS4, and Adobe
Fireworks CS4.
12.4. Miscellaneous
Computer Incidentals/Office Supplies
Keyboards, mice, cabling, flash drives, printer/fax/copier/scanner, blank data media,
paper, pencils, pens, sticky notes, paper clips, staplers, router, dry erase boards and
markers, speakers, headphones.
13. Appendices
13.1. Appendix A
GRC
Game Requirement Checklist
GP Games
3/19/2016
Project Scope Management Plan
Page 51
About This Document
The purpose of this document is to describe the minimal requirements and feature constraints of
Game Project’s final deliverable product. Although this document is what GP Games requires,
please be advised that this is not graded until the team’s archive submission except for 0.
We supply this document such that every team will know what will be required of them by the
time they finish this 5 month development cycle. We do require students to plan to complete this
by the archive milestone, but above all else game play will make or break the team’s game.
Technology changes very quickly. This document may not keep up with everything available to
the teams. Please be advised that the general rule listed
will help everyone if there is any
problems. Other than these sets of rules, anything goes!
When reading this document, one will notice a number in parenthesis after each section in an
article. The number is how many points will be earned if everything in that section is correct.
The GP Games staff will sum each section’s number to get the GRC total grade after the archive
milestone. There is one hundred possible points listed in this GRC; each point maps to a
percentage point with a one to one correlation.
General
Front End (2)

The Front End (FE) must contain a start up sequence, containing studio name and team
name and the main menu. The order of these items is listed below:

Studio Logo

Requirements:

It must display for 3 seconds.

The player must not be able to progress beyond the logo before it times out (the first time
the game is played)

The player should not have to provide input to go to the next screen once the time out
expires.
3/19/2016
Project Scope Management Plan
Page 52

Team logo

Requirements:

The same requirements as the Studio Logo.

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 the Main Menu Screen.
Main Menu Screen (10)

Main Menu Requirements

Upon any action in the menu, there must be unambiguous audio and visual feedback that
the player has performed an action.

Every action, the player can do in the menu, must have clear directions listed somewhere
on each screen.

Accompanying music/ambient sound should play within the FE.

All possible selections from the menu must be functional.

The Main Menu must include:

Start button. This button launches the game world/play the game.

Options menu. That selection must contain the following:

Volume control must have a control for each of the following, if applicable, volume of
dialog, sound effects and background music.

Gamma control. That selection must control the gamma of the game and the game only.
Defaults button to return all settings back to normal.

Mouse Sensitivity slider if the game needs one. Please see

Accept button to save any changes.

Cancel button to allow players to return to the settings of their last save that is not
.
necessarily the default settings.

Credits button. This will 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 or any art, music and sound effects resources used.

Exit button. This will end the game/program.
3/19/2016
Project Scope Management Plan
Page 53
Entering the application (3)

When entering the application, if a user only presses enter, they should enter the game
with default settings.

The user may have to press the enter key a couple of times to progress though the menus.

Networked games are the only exceptions.

By default, the program must enter a listening state where it looks for servers or other
clients after pressing only enter.

On one of the menus, only one extra key press is allowed to let the program go into a
waiting or server state where the program waits for people to connect.
Load Times and load Screens (6)

Times over 15 seconds before seeing the Main Menu are not permitted.

Any load screens must have a moving or an animated indication, letting the player know
the application is not frozen.

Times over 40 seconds once leaving the Main Menu and going into the Game World
(GW) are not permitted.

Initial game loading must appear seamless and should not show or flash the desktop after
the user starts the application.
Game
Level (7)

The Game must have at least one functioning and complete level, representing the GW.

Accompanying music/ambient sound should play within the GW.

The sound playing, in the GW and FE, is required to be different

The GW must be textured and have a skybox.

If the GW has no world, i.e. a space game, skybox requirements are much higher and the
skybox must immerse the player. Please talk to your art director (AD) and external
producer (EP) for clarification.

The GW should have no barren areas and all areas of the GW must be populated by areas
of interest for the player.
3/19/2016
Project Scope Management Plan
Page 54
Entering the GW (5)

Upon initial entrance to the GW the player must have a safe time to orient to the world.
Examples of point that facilitate this include but are not limited to:

The game starting with the avatar temporary invulnerability.

In a paused state which expires via countdown or player input.

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.

If any of the examples listed above do not fit within the game’s design, approval by the
EP must be given for an alternative method.
Game Objects (10)

The player must interact with all objects in the GW. If a player interacts/collides with
another object in the GW, there must be reinforcing auditory and visual representation of
an event.

Moving objects should interact with each other and the world.

Moving Objects should be animated, with at least two animations, or have an animated
texture, or have a procedural animation.
Game-play (10)

The player should be challenged by game initiated interactions (GII) at all times. There
should be no point in the game where the player can stand inactive for long periods of
time without any feedback or game progression.

GII is achieved by one of the following:

Autonomous Artificial Intelligence (AI), which is aware of, and is motivated to interact
with the player’s avatar. AI, which competes against the player, must appear to follow the
same game rules as the player.

Networking, the game connects at least two human players between at least two separate
computers. They must use standard networking protocols such as TCP/IP, or IPX/SPX,
that is not hard coded, and uses menus or dialog boxes to facilitate connecting the
different systems. The end user’s knowledge of networking or IP cannot be tested and
3/19/2016
Project Scope Management Plan
Page 55
cannot be required. The interface must be easy to use and understand. Directions for
each step of connecting to another player are required.

Challenge settings that force the player to compete against an outside entity (i.e., a time
mode for a race game).
Pause Menu (5)

A pause menu must be included in the game.

The pause menu must have:

Resume button – continue the game

Exit button - exit to main menu

If the user selects the option to exit the game a confirmation must ask the user if they
really wanted to select that option and offer a save game state if applicable.

Option Buttons – All these selections must adhere to all the visual and audio
requirements in
.
Game Flow (6)

Game Logic and Flow must be demonstrated.

The game must progress and end in a state other than one it started in by effort of the
player.

Upon the player’s completion or failure of game objective, there must be feedback of the
state change and final game state (FGS).

A FGS may include a player results screen or something similar. It should include details
or other feedback that informs the player as to how well they progressed through the
game.

User input is required for completion of the final state. The player must return back to
the FE after the FGS is completed or the player may go to the credits then back to the FE
after the FGS is completed.

Statistics or information on world, player or opponent states (for example Stats summary
or Scoring summary) are required to be displayed on the completion of the level/game.

This information should be available while in the GW and before the user gets back to the
FE.
3/19/2016

Project Scope Management Plan
Page 56
If the player achieves a high score, or an achievement etc., they have to be notified in
game before returning to the game’s FE.
Operational
Game Input (6)

Input must include keyboard and mouse.

Anytime a mouse is on the screen the user must have a valid selection available.

The keyboard control must contain:

Esc

In the FE, the key goes back one menu until the application is at the Main menu. To exit
the application, you can either have a confirmation screen about exiting the application or
you can have it highlight the exit option and another press exits the game.

In game, the key should trigger a pause menu. If there is a selection or the mouse is used
for input, the current selection should be cleared first, and then on a subsequent Esc
button press will bring up the pause menu.

F1, in game, the key must bring up game help. At minimum the objective of the level
must be included with the in game help.

Alt + Enter must toggle between full-screen and windowed display modes.

Alt + Tab must toggle between currently running applications on the computer.
The game delivery (2)

The game must come with installer.

The installer must install all software needed to run the game with the exception of PC
drivers.

The user should be able to properly install the game, with default settings, by pressing
only the enter key or by clicking only next.

The installer is required to create an icon on the desktop, create a folder in the start menu
with at least a start game icon and an uninstall icon. By default both the start menu path
should go into the programs\<Studio Name>\<Game Name> and the default install
directory is c:\ Program Files\<Studio Name>\<Game Name>

The installer must fit on a 650MB CD.
3/19/2016
Project Scope Management Plan
Page 57
The installed Game (6)

No visual studio DLL’s are allowed to get installed on the computer.

No SDK’s are allowed to get installed.

The game cannot use more than 256 MB of video memory.

If shaders are used, shader model 2.0 must be supported.

The default resolution is 1024 x 768.

The game can use no more than 128MB of RAM, per thread, at any one time.

There is no limit to the number of concurrent threads, but the maximum memory that can
be used, in any time slice, is 256 MB.

While we do encourage learning multi-threaded programming techniques, we still do
want a limit in the amount of memory used.

If more than two threads are used, concurrently, the memory limit is still 128MB for the
main thread. In addition, all the memory used by the rest of the threads cannot exceed
another 128 MB. This rule has been broken if at any time the addition of all memory
used by all threads is greater than 256MB.

All threads created, while running the game, must contain the team’s name or the game’s
name.
Usability
Game Objective (3)

The objective is required to be displayed 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 and controls to be stated in the FE (as a loading
screen into the actual game state) or as an overlay in the game world.

If this is the case, a continue button waiting on player input must also be supplied.
Real-Time Display (6)

There must be a Real-Time Display (HUD) of pertinent player or world states while in
the GW.
3/19/2016

Project Scope Management Plan
Page 58
The HUD must be fully interactive with the game, meaning it represents the state of the
game/player in real-time.

Everything in the HUD must be functional.

The game must provide timely feedback of relevant user actions and the UI adheres to

Feedback must be given to:

Pauses of more than 5-10 seconds within the FE.

Pauses of more 2-3 seconds within the GW.
Game Rules (2)

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

Game action should be suspended while the player is in the menus.

This section neither applies to games where the main competition is described under
section Time trials nor section real-time networked games.
Game regulations (11)

Frame rate should be no less than 30fps average on the target platform (

The first game play sessions are required to perform the same as any subsequent play
).
session.

This includes any initializations, graphics, sounds, GII and end game conditions.

The game performance is required to work almost identically between the target
platforms. Refer to

.
The memory footprint of the application will remain constant (for each state) no matter
how many times the user has played or how long a user has used the application.

Game must be playable for four hours without crashing on the target platforms. There
should be no Class A bugs.
GP Games Refusal to accept milestones

This is the only subsection that is always looked at during production.
3/19/2016
Project Scope Management Plan
Page 59

GP Games can refuse to accept a milestone if one of the following are broken.

Game must be created in accordance to GP class process constraints.

3D objects are required in the game.

Game must be the result of substantial original work by the student team. Use of 3rd 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 containing items
of originality. Please refer to

and
.
Game content must not exceed the ESRB Teen rating category. There must be no
pornography, profanity (except mild expletives), smoking or alcohol references.

If you are incorporating other code from the studio or outside sources, it must be properly
credited.

Flashing effects and sharp camera motions are not allowed, please refer to

GP Games has the right to require some of these problem areas to get removed and/or
.
changed to prevent possible problems that may occur from an audience watching the
game demonstrated.

Game may use only 1 3rd party development tool/API.

Any module that has the base functionality of core modules in DirectX is not included
towards this limit. Please see

.
Scripting languages such as Lua, RUBY, XML and Python are also not considered 3rd
party tools/APIs.

Examples of a 3rd party development tool/API include ODE, FMOD, Havok, and Wwise.
If a team wishes to use any module is not directly listed here please read

.
Boost can be used as an API but only after GP games and the team have come to an
understanding. Using this API will be monitored very closely.

Operation outside the agreement set up those two parties will constitute an automatic
failure for the entire team.

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.
Sub-Appendix A:
3/19/2016

Project Scope Management Plan
Page 60
Any Questions or clarifications needed, about this GRC, should be written in an e-mail.
The e-mail should be sent to the teacher grading GP3 and the team should CC their AD
and EP. Feel free to CC anyone else that is interested in the answer as well.

GP Games define Class A bugs as any bug which prevents the completion of the game
within a single session.

Game pad or joystick input may be used as primary input where appropriate, but you
must still support mouse and keyboard.

The GP Games test machine is the primary target platform. The other test machine (If
the GP Games test machine is the ATI machine, then the other test machine is the NVidia
and vice-versa) is also used as a secondary platform. The development machine (the
student’s laptop) and the arcade machine are also used as a benchmarks.

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.
3/19/2016
Project Scope Management Plan
13.2. Appendix B – Change Request Form
Change Request Form
Request Information
Requester’s Name:
Request Title:
Request Date:
Priority:
Status:
Response Date:
Description of Request
Justification
Alternate Solution
Impact Assessment
Functional Scope
Schedule
Effort
Cost
Authorization
Authorizer’s Name:
Authorizer’s Signature:
Date of Authorization:
Page 61
3/19/2016
Project Scope Management Plan
Page 62
13.3. Appendix C
Animation Work Checklist
Project Name: Final Project
Work ID: 10151 (example)
Team Member(s): Game Art Animator
Checklist Requirements
Does the character show proper weight
transfer in motion?
Do the character’s actions show proper use
of the 12 principles of animation?
Are the character’s facial expressions clear
enough to show emotion to the audience?
Do the character’s walk and run animations
cycle?
Are the animation curves cleaned up with
no excess keyframes added?
Is the file named with the proper naming
convention?
Has the file been uploaded to the proper
folder on the server?
Yes
No
Comments