Razing Ancients Game Bible

Duck `n Cover Productions
Brian Sorin Internal Producer
Brian.sorin@gmail.com
407.920.6609
Brian Goodsell Lead Artist Grant Landreth Lead Programmer
brianjgoodsell@gmail.com Grant_landreth@yahoo.com
516.510.3266 423.368.4111
Robert Barnette Programmer Shane Cadrette Artist Rory Collins Programmer Caryn Cook - Artist Joel Faiella - Programmer Nick Faletra Programmer Brian Hong Artist Dan Mamo Artist Virgil Melvin Artist Morgan Pinkston Artist Dan Southard - Programmer
rbarnettejr@gmail.com darthelessar@hotmail.com Roryjcollins@gmail.com Cook.caryn@gmail.com Joel_faiella@hotmail.com nick@ictbc.com Brian.le.hong@hotmail.com danieljmamo@gmail.com Virgil_melvind@hotmail.com Iki_mono@hotmail.com Southard.dan@gmail.com
267.262.3399 315.790.4576 570.604.8097 619.249.4835 508.843.5451 720.897.5353 860.940.3427 609.610.0342 850.447.1082 813.519.5905 239.357.6423
Table of Contents
Production Document ............................................................................. 3

Game Charter ................................................................................................................................................ 4 Vision Statement ........................................................................................................................................... 4 Meetings ....................................................................................................................................................... 4 Hours Worked per Week .............................................................................................................................. 5 When Things Go Wrong ................................................................................................................................ 7 Rules of Conduct ........................................................................................................................................... 7 Decision-Making Process .............................................................................................................................. 8 Team Roles .................................................................................................................................................... 9 Interactivity ................................................................................................................................................. 12 Interface ...................................................................................................................................................... 12 Controls ....................................................................................................................................................... 16 Interactive Rhythm ..................................................................................................................................... 17 How the Player Marks Progress .................................................................................................................. 18 Detailed Design Breakdown ........................................................................................................................ 19 Front End Flow Chart .................................................................................................................................. 19 Game Flow Chart ........................................................................................................................................ 20 Glossary of Terms........................................................................................................................................ 22 Characters ................................................................................................................................................... 24 Levels and Maps.......................................................................................................................................... 30 Combat System (Cut from final game)........................................................................................................ 52 Platforming System ..................................................................................................................................... 53 Game Logic, Algorithms, and Rules............................................................................................................. 54 Interaction Component Matrix ................................................................................................................... 54 Key Game Algorithms.................................................................................................................................. 55 FAQ.............................................................................................................................................................. 56 Reference of Key Elements ......................................................................................................................... 58 Winning / Losing ......................................................................................................................................... 58 Rewards ...................................................................................................................................................... 58 Transitions................................................................................................................................................... 58 1|Page
Technical Document ............................................................................. 61

Technical Design Overview ......................................................................................................................... 62 Milestone Deliverables ............................................................................................................................... 62 Development Environment......................................................................................................................... 64 System Architecture.................................................................................................................................... 65 Module Breakdown..................................................................................................................................... 72 Critical Components.................................................................................................................................... 72 Overarching Interfaces................................................................................................................................ 78 Object Hierarchy ......................................................................................................................................... 81 I/O ............................................................................................................................................................... 84 Storage ........................................................................................................................................................ 93 Processing ................................................................................................................................................. 104 Rendering .................................................................................................................................................. 109 User ........................................................................................................................................................... 113 Menu ......................................................................................................................................................... 122 Memory Map ............................................................................................................................................ 130 Code Review Plan...................................................................................................................................... 130 Integration Plan......................................................................................................................................... 131 Testing Plan ............................................................................................................................................... 132 Game Folder Hierarchy ............................................................................................................................. 133
2|Page
Production Document
Razing Ancients
Duck N Cover Productions

Brian Sorin bsorin@fullsail.edu Robert Barnette | Shane Cadrette | Rory Collins | Caryn Cook | Joel Faiella | Nick Faletra | Sparky Goodsell | Brian Hong | Grant Landreth Dan Mamo | Virgil Melvin | Morgan Pinkston | Dan Southard
3|Page
Game Charter
Vision Statement
The goal of this project is to create a fun and done pc-based video game within a five-month timeframe that focuses on highlighting the Project Teams technical proficiency and artistic talent while falling within the scope of Full Sail Universitys Final Project curriculum. During that time, the Project Team will spend two months creating and documenting the design of their game followed by three months of executing their vision. This project is a culmination of the skills and techniques developed by students of Full Sail Universitys Game Development, Game Art, and Game Production programs. A Project Team of seven undergraduate programmers, seven undergraduate artists, and a graduate Project Manager will undertake the process of designing and developing an original video game within a five-month timeframe. In addition, the Project Team will be exposed to a development cycle and a set of rules and regulations outlined in extensive Final Project documentation provided by GP Games Studio that is reflective of current standards in the video game industry. With the completion of the project, students will have gained the necessary skills and experience to work as professionals and fill critical roles within the Game Development industry.
Meetings
All Project Team members are expected to attend all defined meetings and work sessions and are expected to work together in the same location for those defined times. Work on Project related tasks outside of work sessions is of course encouraged but the majority of all work completed for the Project will be completed in a cohesive, co-located, team environment.
Meeting Location
All meetings and work sessions will be held at the following location: Duck N Cover Productions 3733 North Goldenrod Road Apt. 1104 Winter Park, FL. 32792 A backup meeting location will be provided if for some reason the main meeting location is not available. Notifications will be set to the entire project team through email identifying the new meeting location and any other required information. By default, the secondary meeting location will be as follows: Dystopian Games Studios 3001 UK Cir. 4|Page
Apt. 2766 Winter Park, FL. 32792
Meeting Times
The default meeting time for all meetings outside of class will start at 11:00am EST. and run until 8:00pm EST, Monday through Saturday.
Meeting Structure
Meetings will be broken up into three main sections; initial review, work session, and wrap-up. Initial Review During this phase of the meeting, lasting roughly 15 minutes, the team will complete a Turbo Team and each member will address three essential questions to the Internal Producer; What tasks have you worked on since the last meeting, What tasks are you working on this meeting, and are there any impediments preventing you from completing your tasks. Work Session This portion of the meeting lasts for eight (8) hours and is the time when the majority of all work for the project is completed. Project Team members are free to take breaks as they see fit, limiting themselves to 10 minutes total per hour. A one hour lunch/dinner break will be provided four hours into the work session and does not count towards the eight hours allotted for the work session. Wrap-up This final section of each meeting will encompass a completed work review and provide a second opportunity to address any issues that have arisen throughout the work session. A final file check will be performed ensuring all work is submitted to the Alienbrain servers and after that point the meeting will end. This portion of the meeting will last no more than 15 minutes.
Hours Worked per Week

Work Hours
All members of the Project Team are expected to work at least eight (8) hours to no more than 10 hours a day, six (6) days a week , Monday through Saturday on tasks related to the Project baring any exceptions as listed below.
Month One and Two

Because of the scheduled classes during the first two months of Final Project exceptions needs to be provided for the formally defined workweek. Lecture in any class will not count towards work time completed for the project. Labs in any class will count towards work time completed for the project.
5|Page
Four (4) hour work sessions will be held on Monday through Saturday after class to facilitate the completion of required Project tasks.
Month Three, Four, and Five

On the one day a week where a class is scheduled the Project Team will not meet outside of that scheduled time. All other workdays scheduled during these three months will follow the formally defined workweek requirements and specifications.
Capacity Planning
Below is a monthly capacity plan outlining the ideal minimum work hours of all members of the project team. Hours Per Day Work Days Work Hours 8 Mon - Sat
23 184 % January Work
23 184 February
27 216 March
26 208 April
25 200 May
124 992 Totals
Name Development Team Totals Programmer Programmer Programmer Programmer Programmer Programmer Programmer Art Team Totals Artist Artist Artist Artist Artist Artist Artist
Team 1288 PT PT PT PT PT PT PT AT AT AT AT AT AT AT 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 184 184 184 184 184 184 184 1288 184 184 184 184 184 184 184 1288 184 184 184 184 184 184 184 1288 184 184 184 184 184 184 184 1512 216 216 216 216 216 216 216 1512 216 216 216 216 216 216 216 1456 208 208 208 208 208 208 208 1456 208 208 208 208 208 208 208 1400 200 200 200 200 200 200 200 1400 200 200 200 200 200 200 200 EQUAL 992 992 992 992 992 992 992 EQUAL 992 992 992 992 992 992 992
Project Team Total (Hours) Project Team Total (Work Days)

6|Page
2576 322
2576 3024 2912 2800 13888 322 378 364 350 1736
When Things Go Wrong

Documentation
Documentation serves a critical role in the management of a large project team. All negative issues that arise, regardless of scale and severity, will be documented by the Internal Producer and kept as public record for the Project Team. If an issue continues to persist, documentation will serve as a record of both the problems and actions taken and will be presented to the Project Teams External Producer for further review. All of the following sections will have associated documentation detailing their associated issues. It is understood that all members of the Project Team have active lives and responsibilities outside of the Project environment. If for some reason a situation arises that prevents a Team member from attending a meeting they are expected to contact the Internal Producer as soon as possible. The Internal Producer will notify the team of any situations that arise and modify and any relevant tasks and schedules accordingly. In case of an emergency situation involving any member of the Team relevant emergency services will be contacted and appropriate follow-up procedures will be enacted.
Rules of Conduct
All members of the Project Team are expected to act as professionals at all times during any group activity.
Attendance
All members of the Project Team are expected to be at all scheduled meetings on time. Being on time constitutes being ready to participate in any work related activity as soon as the meeting starts at 11:00am EST. If any member is expecting to be absent or late for any meeting must notify the Internal Producer ahead of time. Any deficit in attendance will result in documentation detailing the situation.
Work Ethic
All members of the Project Team are expected to work to their fullest potential and meet the standards set and expected by the Project Team and GP Games studios. If at any time a member of the Project Team is experiencing problems with any task assigned to them they are expected to seek help through the appropriate channels as soon as a problem is identified.
Conflict
Conflict such as unconstructive arguing or physical fights will not be tolerated between members of the Project Team with each other or anyone else associated with GP Games. Upon any serious conflict, the offending parties will be immediately separated and given time to cool down before the situation is resolved in a more reasonable manner. If the problem persists, offending parties will be separated and asked to leave the meeting until further mediation can be used. In any circumstance, the issues will be documented and brought to the attention of appropriate GP Games staff members. 7|Page
Decision-Making Process
The following flow chart represents the structure of the project team, how they are expected to communicate, and is the basis of the following decision-making process. This is to be used as a basis for how communication occurs within the team, but is by no means a limit to the channels available to the Project Team.
Reporting Communication Final Project January 2010 Projected Team Structure 1 Producer 7 Development 7 Artist GP Games Two-Way Communication Inter-Team Communication External Producer
Internal Producer
External Art/Sound Directors
Programming Lead
Art Lead
Technical Lead
Gameplay Lead
Testing Lead
Modeling Lead
Environment al Lead
Technical Development Team 2 Members
Gameplay Development Team 2 Members
Quality Assurance Team Floating Members
Modeling Development Team 2 Members
Environment al Development Team 2 Members
Cutting Features
The responsibility to ultimately remove a feature from the approved task list and schedule falls on the project teams Internal Producer. Feedback and discussion on the decision to remove a feature will come from the Leadership structure and the IP. For the removal of features that that affect the game on a large scale, the teams External Producer will be consulted on its removal.
Deciding on Features
During the process of creating our fully realized Feature/Task list, the entire group will sit down together and discuss both the technical and artistic aspects of each feature. After the details of each proposed feature are presented and discussed the relevant Leads will provide additional feedback and ultimately decide on the feasibility and implementation of that feature with the Internal Producer. Through thorough discussion of each topic and the intended reliability of the Leadership teams ability to make decisions on behalf of the team and in its best interest, once a topic is discussed and decided on it is
8|Page
considered to be finalized. To that end, the entire Project Team is expected to ask any relevant questions and address any concerns during the discussion portion of a features discussion.
Team Roles
The following sections outline a high-level view of the roles and responsibilities associated with the development of a GP Games title. In the case someone is assigned a task that does not strictly fall within their assigned following description they are still expected to work on and complete that task according to the standards of the Project Team and to their best ability.
The Project Team

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

Each Project Team will have one graduate level Project Manager known as an internal Producer that reports directly to the studio-wide External Producer. The job of the IP is integral to the success of the Project Team and includes the following responsibilities: ensuring produced work meets the standards and expectations set forth by the Game Requirements Checklist, handling team wide administrative tasks such as moderating meetings and developing schedules, enacting policies and procedures, managing changes and the scope of the project, interactive directly with External Producers and other GP Games staff, ensuring the standards and quality of all deliverables meet expected requirements, and providing support and guidance to the Project Team. Through effective management practices, the IP will promote a positive team environment and an overall stronger final deliverable that reflects on the professional and technical proficiencies of the entire Project Team.
Programming Lead (PL) Grant Landreth

The Project Team will designate one undergraduate Game Development student as the Programming Lead of the Project Team. The PL, in addition to the responsibilities of a programmer, is responsible for assisting the IP in the creation, organization, and management of the Technical and Gameplay Development Teams, designing the games system architecture, designating and tracking progress of programming related tasks, ensuring all programming related GRC criteria are met, approving major technical changes, willingly and openly assisting programming teams through support and guidance, and frequently communicating project updates to the Internal Producer.
9|Page
Technical Lead (TL) Dan Southard

The Project Team will designate one undergraduate Game Development student as the Technical Lead of the Project Team. The TL, in addition to the responsibilities of a programmer, is responsible for the day-to-day management of Technical Development Team. Members of the TLs team, including the TL, will be responsible for the development of critical game systems including Engine Development, Rendering, AI, Animation Systems, and Tools. In addition, the TL is responsible for ensuring all GRC criteria are met, assisting the Technical Development Team through support and guidance, and frequently communicating project updates to the Programming Lead.
Gameplay Lead (GL) Joel Faiella

The Project Team will designate one undergraduate Game Development student as the Gameplay Lead of the Project Team. The GL, in addition to the responsibilities of a programmer, is responsible for the day-to-day management of the Gameplay Development Team. Members of the GLs team, including the GL, will be responsible for the implementation, balance, and interactive aspects of the game along with the development of critical game systems including Audio, Interface, Input, and Effects. In addition, the GL is responsible for ensuring all GRC criteria are met, assisting the Gameplay Development Team through support and guidance, and frequently communicating project updates to the Programming Lead.
Programmers Nick Faletra, Ryan Raye, Rory Collins, Robert Barnette

Programmers of the Project Team will consist of undergraduate Game Development students working on either the Technical Development or Gameplay Development Teams. Programmers will fill available roles on their respective teams and are responsible for the low-level development of critical game systems as outlined by approved documentation and system requirements. Programmers are also responsible for developing modules that comply with GRC standards, assisting other programmers through support and guidance, and frequently communicating project updates to their relevant leads.
Art Lead (AL) Brian Sparky Goodsell

The Project Team will designate one undergraduate Game Art student as the Art Lead of the Project Team. The AL, in addition to the responsibilities of a Technical Artist, is responsible for assisting the IP in the creation, organization, and management of the Modeling and Environmental Development Teams, developing the visual style of the game, tracking and managing assets through a comprehensive asset list, designating and tracking progress of art related tasks, ensuring all relevant GRC criteria are met, approving technical changes, assisting other artists through support and guidance, and frequently communicating project updates to the Internal Producer.
Modeling Lead (ML) Brian Hong

The Project Team will designate one undergraduate Game Art student as the Modeling Lead of the Project Team. The ML, in addition to the responsibilities of a Technical Artist, is responsible for the dayto-day management of the Model Development Team. Members of the MLs team, including the ML, will be responsible for the development of the projects 3D models, animations, textures, model exporters, and any other requirements associated with non-environmental models. In addition, the ML 10 | P a g e
is responsible for ensuring all model related GRC criteria are met, assisting the Model Development Team through support and guidance, and frequently communicating project updates to the Art Lead.
Environmental Lead (EL) Caryn Cook

The Project Team will designate one undergraduate Game Art student as the Environmental Lead of the Project Team. The EL, in addition to the responsibilities of a Technical Artist, is responsible for the dayto-day management of the Environment Development Team. Members of the ELs team, including the EL, will be responsible for the development of the projects 3D environment, textures, collision geometry, model exporters, and any other requirements associated with the games environment. In addition, the EL is responsible for ensuring all environmental related GRC criteria are met, assisting the Environment Development Team through support and guidance, and frequently communicating project updates to the Art Lead.
Technical Artists John Soza, Vergil Melvin, Dan Mamo, Jason Speakmean
Technical Artists of the Project Team will consist of undergraduate Game Art students working on either the Modeling or Environmental Development Teams. Technical Artists will fill available roles on their respective teams and are responsible for the design and development of game assets in accordance with the asset list and the overall style of the game. Technical Artists are also responsible for completing assets that comply with GRC standards, assisting other Technical Artists through support and guidance, and frequently communicating project updates to their relevant leads.
Testing Lead (QAL) Brian Sorin

The Project Team will designate one undergraduate Game Development or Game Art student as the Testing Lead of the Project Team. The QAL is responsible for assisting the IP in the creation, organization, and management of the Quality Assurance Team, developing comprehensive verification and validation testing plans, managing a bug tracking database, designating and tracking progress of Quality Assurance related tasks, assisting other Quality Assurance Team members through support and guidance, and frequently communicating project updates to the Internal Producer.
Testers The Project Team

Testers of the Project Team will consist of both undergraduate Game Development and Game Art students. Testers will dedicate a portion of their time on the Project Team to conducting Quality Assurance tasks and will be responsible for executing both black and white box testing on completed work, completing and submitting bug reports, identifying deficits in completed code or assets, ensuring completed work complies with GRC standards, and testing and suggesting improvements on the games functionality, fun-factor, and usability.
External Producer (EP) Don Smith

Each Project Team will be assigned a staff member from GP Games known as an External Producer. The EP will work directly with the Project Teams Internal Producer and deal with issues such as administrative tasks, major scope change approval, conflict resolution, guidance, and general support. The EP is the final word in all major decisions for the Project Team.
11 | P a g e
Interactivity
Summary
Razing Ancients is a 3D third person platformer set in a nature-based fantasy world. The main character traverses a giant tree-like creature in hopes of discovering what happened to his village and taking revenge on the beast.
Goal
The main goal for the user is to reach the top of the ancient creature by jumping, swinging, and climbing up and along its body. The player will come across environmental puzzles that must be solved in order to proceed.
Interface
Main Menu
Below is a component list of all elements of the games main menu screen. Studio Splash Duck N Cover Splash Game Splash Main Menu 1. Start New Game Load Game 2. Options Video Gamma Fullscreen/Windowed Toggling Graphic Effects Default Settings Audio Music Sfx Mute All Default Settings Game Play Controls
12 | P a g e
Keyboard/Mouse Remapping Default Controls 360 Controller Remapping Default Controls
3. Credits 4. Quit
Studio Name Team Name Team Members/Positions 3rd Party Credit Special Thanks
Menu Interface Flow

The idea of our menu is that as soon as the player enters the menu screen they are already in the game world. The menu takes place inside of the main characters house (which is also level one) where he is still sleeping. Once the player is done interacting with the menu and enter the game, we will be able to directly transition from the menu right into the game itself with no loading since we are actually already there. Main Screen The four basic options are available to the player; Start/Load, Options, Credits, and Exit.
13 | P a g e
Options Screens
14 | P a g e
Credits and Exit
Feedback
All interactions with the menus will have an associated feedback component. When any button intersects with the cursor or is selected by the keyboard the button will become highlighted and a very slight sound will play. When clicking/selecting any button within the menu a confirmation sound will play. Any loading screen within the menu system will display an animation that represents loading progress to notify the player that the game is still working.
15 | P a g e
HUD
To support the idea of a fully immersive environment and because of a lack of relevant and critical ingame information, our game does not make use of a visual HUD. Instead, visual effects and audio based queues will be used to represent actions that affect the player. These effects are outlined in our Effects section of the document but for example, things like camera shake and color changes will be used to signify the living environment and highlight important interactions for the player.
Controls
The controls of any game are essential to a smooth interaction between the player and the environment. Our game provides, by default, a layout suitable for the actions necessary for our style of game. In addition, we provide the player the freely modify their key bindings from the games main options menu as described above.
Mouse / Keyboard
The main way that users will control the player character within the game world is through mouse and keyboard input.
WASD Move the player character forward, left, back, and right within the game world relative to the cameras current position. Space Jump Left Mouse Button Melee Attack Right Mouse Button Context-sensitive Activation F1 Help Escape/P Pause Menu Mouse Look Camera Control Middle Mouse Button Reset Camera Position
16 | P a g e
360 Controller Input

A secondary control scheme for our game is the Xbox 360 controller.
Left Analog Player Movement Right Analog Camera Control A Jump X Attack B Cancel Right Trigger Context-sensitive Activation Left Trigger Context-sensitive Activation Start Pause
Interactive Rhythm
Summary
Times are based on perceived first time player expectancy. Play Session 5-10 minutes Total Play Time 20-30 minutes Replay Exploration and new areas Basic Enemy 1 second Boss Encounter 5-10 minutes
A typical play session which consists of a single play through of one level will last approximately three minutes. Because there are 5 distinct levels, the overall length of the game is approximately 15 to 20 minutes for the average player. Replay value of the game comes in the form of further exploration of the level and the discovery of new areas off of the normal path. 17 | P a g e
As the player progresses through levels the action is broken up between times of action and inaction. The flow of each section of the game follows a similar pattern; a challenging platforming area, a puzzle based room, and finally a section that allows the player to rest and transition between two levels. These final transition areas help to separate the game world and indicate to the player that theyve completed a section and are able to move on. While combat is not the focus of the game, when enemies are present and close to the player they will simply take one hit and they will die. The interaction with the enemy should last no more than one second. In contrast, the final boss encounter, which also acts as the final level, will take approximately three minutes to complete.
How the Player Marks Progress

Our game presents players with a number of different forms of feedback in regards to their progress.
Checkpoints
When the player reaches designated areas within the game world the main character will make a mark on a nearby wall or tree to signify that the character has completed a section of the level. At this time the game will save out the players location as a checkpoint. If a player dies past this point their character will respawn at this checkpoint allowing them to try to progress again.
Collectables
Strategically scattered throughout the game world are a series of basic collectables (ancient artifacts that act as clues to understanding the ancient) for the player to find. These collectables help to both non-verbally progress the story while both providing players with a reason to explore the game world and a secondary goal to keep them interested.
Level Destruction
After a player reaches a checkpoint starting on level two they will trigger an event that burns the previous section of the game world signifying that the player is progressing up this creature and destroying it as they go. In addition, as the player is moving through new areas of the world they will get glimpses of the scope of the game world when they are near the edge of the map, shown in the form of the ancients massive arms swinging by as they walk or the shaking of the entire level as the creature walks.
18 | P a g e
Detailed Design Breakdown

Front End Flow Chart
The front end flow chart of our game represents a breakdown of the possible options and paths available to the user throughout the main menu.
Application Start
Studio Logo
3 Sec
Team Logo
3 Sec
Game Splash
Main Menu
Start Game
Options
Credits
Exit
Loading Screen Help Information
Audio
Video
Gameplay
Application Close
Game Start
Music Sound Effects Default Accept/Cancel
Gamma Default Accept/Cancel
Controls Mapping Default Accept/Cancel
Credit Sequence Return to Menu
Pause
19 | P a g e
Game Flow Chart

The game flow chart lays out the common, generic interaction path the player will follow throughout each level of our game.
Level One and Two

Main Menu Game Start
Opening Level Cutscene
Level One and Two Flow

Player can: Run, Jump, Climb, Swing, Explore, Solve Puzzles
The Player is able to pause the game and gains access to options, help, and a way to exit the level.
Player begins traversing the level
At the end of each section the players progress is automatically saved through checkpoints.
Player Progresses through Platforming Section
Success
Player Progresses through Puzzle Area
Success
Player Progresses through Transition Area
Failure
Failure
Transition to Next Level
20 | P a g e
Level Three
Transition from Level Two
Opening Level Cutscene
Level Three Flow

Player can: Run, Jump, Climb, Swing, Explore, Solve Puzzles
The Player is able to pause the game and gains access to options, help, and a way to exit the level.
Player begins traversing the level
Player engages the final boss Failure
Success
Final Cutscene
Credits
Main Menu
21 | P a g e
Glossary of Terms
Activate The player activates a triggerable object directly in front of them with a delay of 5.0 after each activation. Activate Trigger The machete is used to activate specific triggerable objects throughout the game world. Activation Delay The time between the activation of one triggerable object and the next. Agro Radius The range in which an AI Agent is able to identify the player character and react. Attach The grapple hook extends itself to a designated grapple point within the game world and allows the player to perform the swing action over a gap. Attack The Ancient shakes the entire world and releases boulders from the canopies above the players head. Attack The enemy charges at the player and when they make contact with him they knock him back, making the player stumble, by 0.5 units with a delay of 3.0 seconds. Attack The machete attacks, swung by the player, and deals 100% of the total health of a basic enemy. The attack range of the sword is based on a 180 degree left to right arc in front of the player and a 30 degree arc up and down. Attack The player swings their weapon with a delay of 1 swing every 1.0 second. Attack Count The number of boulders the Ancient is able to attack the player with. Attack Damage The amount of damage a single attack that connects with a target can do. Attack Delay The time between the end of one attack and the beginning of the next. Attack Speed How quickly a specific weapon is able to attack. Chase Duration How long an AI Agent is able to chase the player before giving up. Climb The player will move vertically up a climbable object such as a moss wall at 0.5 units / sec. While in the climbing state the player cannot jump out of it. They will need to either reach the top or bottom of the climbing area to continue on. Climb Speed A constant speed at which the player is able to move up or down a moss wall. Death If at any point the player fails to complete a platforming activity and falls below the platform they will die and need to restart from the previous checkpoint. Emote The Ancient bellows across the lands signifying his anger at the player. This is a passive effect that is used strictly for audio effect to emphasize the size of the creature. Emote Delay The frequency of how often the Ancient is able to emote and disrupt the world. Exit Point A point designated within the game world that signifies where the player exits the world. Exit Point Count The number of Exit Points within a specific level. Jump The ability of the player to move vertically from either a standing or running position. The player always jumps a height of 0.5 units regardless of speed or momentum. Jump Distance A constant distance of 1.5 which a character is able to jump. Jump Height A constant height of 0.5 at which a character within the world is able to jump. Platforms The basis of what the player will run on, they act as small island like landings that the player can jump to. Player Spawn Count - The number of player spawn points within a specific level.
22 | P a g e
Player Spawn Point A point designed within the game world that signifies where the player enters the world. Raze The grapple hook attaches itself to a destructible object within the game world and pulls it down clearing a path for the player to progress. Run A constant speed of 1.0 units / sec that the player moves at. There is no acceleration or deceleration time associated with the player stopping and starting the main characters run action. Run The enemy moves on the ground either aimlessly or towards the player depending on their current AI state at a speed of 1.5 units / sec. Run Speed A constant speed at which a character within the world is able to move. Scaleable Objects Objects within the world that the player can climb on, attach to, swing on, or perform a special run action on. Seek The enemy activates their AI pattern of identifying the players location and approaching him for an attack provided the correct parameters at met such as being on the same platform. Swing The player attaches themselves to a rope or vine and leaps off one platform and lands on another by holding on to the rope/vine. A swing will always move the player 3.0 units horizontally. The player is in control of their forward momentum while in a swing. By holding forward they will swing faster. If the player has no momentum they will not fall off a swing but will be able to add momentum by holding forward again. Swing Force A force applied by the player on a swing that propels the rope forward or back. Trigger Volumes Invisible spaces within the game world that, once entered by the player, will activate actions, effects, or events.
23 | P a g e
Characters
Name
Our character is not given a name specifically. There is no point within the game that it would be expressed and this way the player is able to more easily able to associate with the character.
Brief Description
This is the main character. He can climb and jump around the levels. In addition, the character has a number of tools at his disposal throughout the entire game such as the torch, and grappling hook which are all described in the Weapons and Tools section below.
Visual Design
Short hair, sticks out in random directions Sleeveless shirt Leather Belt/Bracers Loose Fitting Pants Leather Greaves Boots Pouch hanging from belt Grapple Hook wrapped around body Machete hanging horizontally below back
Behaviors
Run Jump Swing Climb Activate Trigger
Attributes
Run Speed Jump Height Jump Distance Swing Force Climb Speed Activation Delay Constant 1.0 units 0.5 units 1.5 units 0.1 forward momentum 0.5 units 5.0 seconds
24 | P a g e
Name
Creepers (Cut from final game)
Brief Description
Enemies in our game are small creatures living on the ancient that have been corrupted by the ancients presence. They are not evil by nature but instead are just protecting the areas they inhabit.
Visual Design
A small, ancient-dwelling, reptilian-like creature with a thick, tough skull used for ramming its enemies. It has two short legs and a round, soft body that makes his movement around the ancient quick and efficient.
Behaviors
Attack Run Seek
Attributes
Attack Speed Attack Effect Run Speed Attack Delay Agro Radius Chase Duration 1.0 second Knockback 0.5 units 1.5 units 3.0 seconds 5.0 units 10.0 seconds
25 | P a g e
Name
Ancient
Brief Description
He is a giant tree-like creature that destroyed the main characters village when waking from its slumber and also acts as the game world. It is important to note that the Ancient takes a very passive role in terms of actual gameplay. It acts as the game world itself and does not directly interact with the player.
Visual Design
Enormous Size Roots Rocks Trees Ruins Biped Creature
Behaviors
Attack Emote
Attributes
Attack Delay Attack Count Attack Radius Emote Delay 10.0 seconds +- random intervals between 5.0 seconds 3-5 boulders 3.0 8.0 units around the player with at least 0.5 unit spacing 5.0 30.0 seconds
26 | P a g e
Weapons
Name
Machete (Cut from final game)
Brief Description
The machete is a curved blade thicker than an average sword on a hilt. Its function is to cut vines, foliage, ropes, and to fend off attackers. It is the characters external tool and main weapon. The character possesses it throughout the length of the game.
Visual Design
The weapon has two parts a hilt and a blade. The hilt is made of twisted wood with small carvings spiraling around it. The metal on the blade itself is dulled and rusted; it has a fair amount of surface scratches like it has been used for generations. The blade is thick and flat with sharpened edges.
Behaviors
Attack Activate Trigger
Attributes
Attack Damage Attack Range Activation Delay 100% enemy health 180 degrees In front of the player left and right and 30 degrees up and down 5.0 seconds
27 | P a g e
Name
Grapple Hook
Brief Description
The grappling hook is another utility of the player designed for climbing. The grappling hook is used in conjunction with grappling points. Once the grapple hook has made contact with a grapple point, the player can either use the grapple to climb, swing between two points or destroy the grappled object.
Visual Design
The grappling hook consists of the actual metal hook attached to a length of rope. The head of the metal hook will have three prongs that curve back towards the base. The hook is made of a strong dull metal. The rope is made of a thick twine extending to a maximum of three units.
Behaviors
Attach Raze (Cut from final game)
Attributes
Attach Distance Attach Delay Raze Distance Raze Delay 1.5 units 1.0 second 1.5 units 5.0 seconds
28 | P a g e
Name
Torch
Brief Description
The torch is an off-hand utility carried by the player throughout the game that is used to burn objects. The player brandishes the torch when near specific flammable locations. The torch is put away when he steps away from these locations.
Visual Design
The torch is a shaft of wood with cloth wrapped around the top for flammability. The shaft is rounded in shape with odd misshapen deformities.
Behaviors
Activate Trigger
Attributes
Activation Delay 1.0 second
29 | P a g e
Levels and Maps

Scale (Globally, For All Levels)
The boundary elements that contain the player will be about 2 units tall. Trees that the character swings to and from will be 4 units tall, and 1.5 to 2 units in diameter. Swinging gaps will be 4-6 units long. Large climbable faces will be 5-8 units tall and or wise with each individual platform being 1 to 1.5 units in diameter. The Wall run distance is 0.5 min - 2.5 units max. Within Maya, all levels will use the defined standard measurement of 32x32x96.
Attributes (Global, For All Levels)

Player Spawn Point Exit Point Trigger Volumes Scaleable Objects Platforms 1 1
Player Spawn Count Exit Point Count
Level One
Name
Tutorial Level (Level 1)
Goal
The main goal of this level is to introduce the player to the main features of the game and teach them how to interact with the player character and environment. Features the player will be introduced to within this level are platforming, jumping, climbing, and simple puzzles. Secondary goals of the level include exploring the new areas and reaching the next level.
Environmental Interactions Behaviors

The main interaction between the player and the environment is platforming (as described in the Platforming section). At the end of the level theres a lever that triggers a ladder to fall into place to proceed to the roof.
Attributes
See Global Attributes section for additional attributes.
30 | P a g e
Enemy Spawn Points Enemy Spawn Point Count 0
Ambient Environmental Aspects/Objects in the Level

Audio o Rumbling o Low Wind o Chirping o Wood Creaking Animations o Ladder Sliding Down Transitions o Revealing the Ancient Cutscene Random/Triggered Events o Rubble Falling o Dust Blowing o Ladder Animation o Building Falling Away from Ancient
Time
Times are based on new player ability expectancy. Traversing all platforms 2 min Trigger Event - Instantaneous Ladder Animation 2 sec Revealing Ancient Cutscene 1 min
31 | P a g e
Map
Maya Blockout
32 | P a g e
2D Representation Concept
33 | P a g e
Level Exterior Concept
34 | P a g e
Level Interior Concept
35 | P a g e
Name
The Beasts Leg
Goal
The goal of this section is for the player to make their way up the awakened titans leg. This section will be divided into 6 (transition area) different sub-sections, each changing the theme, movements and dangers. The player starts in a controlled, open space filled with rocks and broken brush to help re-in force the movement, jumping and climbing behaviors they learned in the previous section. As the player moves through the sections, they are taught one new skill or usage of a previously learned skill to get through the space. Dangers such as death sections begin showing consequence from the third section forward. Once the player makes it to the last section, they will be met with a puzzle, in which they will need to interact with the environment in order to unlock the exit and move forward to the next level.
Level Travel
In the first section, the player will be in a controlled space that is enclosed through the use of static meshes. They will be using the movement keys to navigate the player around the open space and the Jump button to ascend to higher platforms and the context sensitive button to climb up to higher ledges. The player will be using these controls to climb pieces of rocks and scale faces of the walls in order to make their way through the path. The first section ends with a teaching of the swing mechanic with a found rope or vine hanging off of a tree branch. The rope will allow the player to make their way over a non-consequential pit. This will help in force the usage of the mechanics to be re-iterated and expanded in the next section. The second section will begin with a transition in theme, shifting from a safe enclosed wide path to a more complex platform tree area. The layer will be making their way along the edges of tree branches to make their way through the entirety of the space. The ground will consist of a rock quarry that acts as an enclosing volume.

Rope Cutting rope Falling Wall running Wall sliding Climbing
36 | P a g e
Attributes
Object Puzzle rope Falling (death) Swinging Wall Running Wall jumping Platforms Quantity 5 na 4 na na 20 Speed/distance na na 1.5 units per second 1 unit per second 3.0 na Damage 1 hit 100% na na na na

Objects
Static meshes Animations o -Ropes being cut o -Stone pile swaying in puzzle room o -Breaking of tree o -Trees bending as the player runs across the branches
Particles
-Dust for when the player hits the ground or on sections that are applying that they are shifting -Rocks crumbling visual effect for when we are scaling the side of the wall -Leaves falling for areas around trees when player lands on branches that have foliage. There would happen when climbing as well.
Sfx
Ambient crumbing, Shifting/falling rocks Wind sound for wide open faces Low grumble from the titan -Dragging sound from titan moving forward
Time
The player will take approximately 10-12 minutes to make their way through the entirety of all 4 sections including the puzzle area.
37 | P a g e
Map
Maya Blockout - Outside
38 | P a g e
Maya Blockout Side View
39 | P a g e
Maya Blockout Puzzle Room
40 | P a g e
Overview Top View Concept
41 | P a g e
Side View Concept
42 | P a g e
Side View Concept (Cont.)
43 | P a g e
Alternate Top/Side View Concept
44 | P a g e
Puzzle Room Top Down Concept
45 | P a g e
Name
Boss Level (Cut from final game)
Goal
Primary - Defeat the Boss Use all knowledge you have acquired to defeat the boss.
Level Travel
Travel through this level will have the player use all of the known skills in his repertoire these being jumping, climbing, swinging, wall running and wall jumping, to get to all required points of interest.

The main interaction between the player and the environment is platforming to get to points of interest to light on fire. There will be 5 points to light on fire to defeat the final boss these will be mossy areas. Platforms Grapple Points Torches Boulders Vines
Attributes
Spawn Points The starting position for the player. Triggers points of interest the player interacts with to manipulate the boss. Scalables Vines, Moss, grapple points Platforms Tree limbs, Stumps, ruined walls Spawn Points 1 Triggers 5 Scalables 7 Platforms 12

Audio o Wind o Groaning / feedback of damage o Fire o Rumbling/rustling when he shakes and things fall Animations
46 | P a g e
o Breaking platforms o Falling large pieces of debris Transitions o Cutscene of him dying Random Triggered Events o Debris falling from the top of the level to damage player o Wall Falling debris breaks the wall so you cant hide for cover anymore o Leaves Blowing
Time
3 minute battle Ending cut scene 30-45 seconds Breaking Platform Animation 1-2 seconds Debris Animation 1-2 seconds
47 | P a g e
Map
Maya Blockout
48 | P a g e
Top View Concept
49 | P a g e
Camera System
The games camera system is a critical component that allows the user to experience our world through two distinct views that both enhance the gameplay and cinematic experience for the player.
Outside View
The outside view of the camera is going to be relative to the player and the position in the world where he is located. We are going to have the camera faced at the player but also the environment so you can get a great feel of ancient that you are on. We are going to have a vector to the center of the world and the player and make it face in that direction to achieve this.
Transitions
As the player approaches an indoor section of the level the camera will begin to transition, according to the players distance from the doors entrance trigger volume. The closer the player is to the doorway the camera will begin moving towards its 3rd person perspective used in the indoor areas as described below.
Inside View
The inside view of the camera is going to be hard attached over the players shoulder but its also going to be able to handle camera collision. The camera is going to be set over the players shoulder granting you a great viewpoint for the puzzles we plan to have.
Camera Collision
Because we have some tight sections in our indoor puzzle areas we intend to handle camera collision without disrupting gameplay and understood angels. In general, the camera will have basic sphere to AABB collision on regular objects within the game world. When the player backs up to a wall the camera will stay in place and the player will become semi-transparent so they are still able to see the environment in front of them without the camera moving in unexpected directions.
50 | P a g e
Effects System
Description
Because we chose to express story elements in our game without the use of dialog, things like effects become essential to communicating whats going on in the world. Our effects will be used to signify when things are happening within the game world such as trigged events, player actions, and background effects. In addition, effects will be used to identify interactable objects within the game world so the player can visually recognize them.
Usage
Running/Landing The player will kick up dust on the ground when they run Climbing Leaves and dust will fall as the player climbs the moss/vine walls. Checkpoints Interactable Objects/Triggers They will sparkle signifying they can be interacted with Torches Once lit the torches will emit a fire and burning effects Environmental Effects Wind/Leaves/Fog/Falling Rocks/Light that is triggered as the player moves through the world Burning After checkpoints, the previous section of the level will be lit on fire. Rumbling The entire screen will shake signifying the world is living.
Basic Implementation
Our effects system uses two implementations to represent effects within our world; Point Emitters and Volume Based trigger systems. Point emitters allow us to strategically place effects throughout our world that provide an anchor for our effects while a volume based trigger system lets us customize effects and respond to actions the player performs while moving through the game world.
51 | P a g e
Combat System (Cut from final game)

Brief Description
Combat in our game is a simple byproduct of the environment the player interacts in and is strongly deemphasized as an aspect of gameplay. Enemies act as speed bumps against the player and help to break up the platforming elements of the world. Combat itself is a simple one button attack, one hit kill (to the enemy), and knockback to the player interaction that helps to emphasize the players interaction with the environment as a main focus.
Combat
The combat is simple, occurring in real time. The machete is our only weapon. Get within melee range of target and perform a sword attack. All attacks are single swings in the direction the player is facing, resulting in instant kills for any enemies in contact with the blade, not including the boss. The player can swing his sword at any time they are NOT inside a cut scene, brandishing an item, or extending a grapple. If the enemy intersects the swords path while swinging, then it is considered hit. When the player is hit by an enemy the player is knocked back potentially knocking them off a platform.
52 | P a g e
Platforming System
Platforming is an integral part of our games player interaction and involves a number of intricate maneuvers and techniques.
Actions
Jumping As long as the player is grounded jumping pushes the player off the ground vertically by 0.5 units for a distance of 1.5 units. This state ends when the player touches a solid surface. While in the air, the player will continue moving in the direction they were when they began the jump. Assisted Wall Running The act of using a rope as a support while moving horizontally along a vertical surface at running speed. The wall running distance is 3 units. Climbing Contextual interaction with a scalable object will enter a climbing state. This may be cancelled by reaching the top or the bottom of the scalable terrain. The speed by which we can climb is half the run speed. If there is an adjacent climbable surface is not directly connected to the current climbable surface (i.e. gap) and the distance is 0.5 units between these two surfaces, the player can move in the direction of the adjacent surface and press the action button to jump the gap. Balancing When the surface is narrow the players maximum forward movement is reduced to half the run speed. The state ends when the narrow surface has been traversed. Swinging After jumping to a swinging object if the player presses the action button they will grab the rope. Swinging is based on the movement of the player. The swing state ends when the player presses the action button. Grapple Hook Throws the grapple hook towards a grapple point. This creates a swingable object extending down from the grapple point. This swingable object is treated exactly the same as a standard swingable object, allowing the player to perform the swing action on them. The grapple action can never fail, and can only be performed when the player is within 1.5 units a grapple point. There will never be more than a single grapple point within the players reach.
Objects
Scalable A surface that can be climbed by the player in order to reach a higher platform. Swingable A vertical restraint such as a rope or vine that can be swung on by the player. The player can influence the swing using the movement controls. The player can attach and release themselves from the rope using the action button. Ledges The edge of a surface or apex of a wall that can be grabbed by the player, and used to help the player up onto the platform. Beams A narrow surface such as a pole or branch that the player can walk along. Grapple Points Points designated as grapple accessible. The grapple point has a bounding volume that indicates when the player can grapple to that specific point. The radius of the bounding sphere is 1.5 units. 53 | P a g e
Game Logic, Algorithms, and Rules

Interaction Component Matrix
Our Interactive Component Matrix is broken up into three sections to accommodate for the large number of interactions. Player X Knockback X X X X Support / Move Support / Move Blocks X X X Knockback / Kill Save Enemy X X X Kill X X Support / Move X Blocks X X X Knockback / Kill X Boss X X X X X X X X X Damage X X X X
Player Enemy Boss Sword Torch Grapple Hook Platforms Vine Walls Triggers Grapple Points Trigger Volume Boulders Checkpoints
Player Enemy Boss Sword Torch Grapple Hook Platforms Vine Walls Triggers Grapple Points Trigger Volume Boulders Checkpoints
Sword Attack Die X X X X X X X X X X X X
Torch Use X X X X X X X X X X X X X
Grapple Hook Use X X X X X X X X X Support X X X
54 | P a g e
Platforms Player Enemy Boss Sword Torch G. Hook Platforms Vines Walls Triggers G. Points Trigger V. Boulders Checkpoint Stand Stand X X X X X X X X X X X X
Vines Swing X X Cut X X X X X X X X X X X
Walls Run/Jump X
Triggers Activate X X X Activate X X X X X X X X X
G. Point X X X X X Attach X X X X X X X X
T. Vol. Context X X X X X X X X X X X X X
Boulder Knockback / Die Knockback / Die X X X X X X Block X X X Knockback X
Checkpoint Save X X X X X X X X X X X X X
X X X X X X X X X X X
Key Game Algorithms

AI / Physics
Seek AI o A single minded AI pattern that involves trying to close the distance between the player and AI Agent by any means necessary. We want to use this pattern because of its simple yet effective implementation and will function reasonably well within our levels. Enemies will not engage this AI pattern if the player is on a different vertical height then the agent. By restricting their ability to activate this pattern, we can avoid having enemies waiting for the player at the edge of a platform preventing them from safely landing. Simulated Spring Physics o Simulated spring physics is a way to represent realistic rope behaviors within our world without the full implementation of a real world physics model. By using this model we can get the effect and feel of realistic environmental objects without the full implementation of a computationally heavy physics system.
Collision
AABB to AABB for most things o Axis-Aligned Bounding Box, or AABB, is a bounding system that uses a box aligned to a specific axis. This technique is very fast and low memory intensive, and is good for quick bounding checks for flat or low-detail objects.
55 | P a g e
Sphere to Sphere o A basic geometry-based collision pattern useful for quick and cheap detection of primitive objects within the game world. Implementation of this pattern within our game is easy and effective while being computationally efficient.
Culling
BSP for level division o BSP is the division of an environment to produce a subset of compartments that can be used for speeding up rendering, AI, collision, and culling. The individual compartments can be sorted according to their orientation to the player for techniques such as alpha and depth sorting. We will be utilizing BSP simply for performance gains overall.
Animation
Smooth Skinned o Smooth-Skinned animation is the process of rigging a skeletal bone structure to a contiguous skin in order to produce the flexing and bending behavior of organic structures. Though it is computationally more expensive, it produces a more believable organic player-character, which is more appealing to look at.
Rendering Techniques
Bloom/Blur/Shimmer Etc. o A series of visual effects used to better represent real-world lighting dynamics without the extra computational expenses associated with actual lighting. We feel these techniques will be cost effective while promoting the look and feel of our world that we are looking for.
FAQ
1. Is this game multiplayer? a. No. We wanted to focus on solid gameplay and avoid the common pitfalls and restrictions that a networked game presents. 2. Why is combat not the focus of this game? a. While we understand that combat is an important aspect of many games, we wanted to focus on the traditional gameplay style of platforming and focus on the interaction between the player and the environment. 3. Why is the Grapple Hook restricted only to certain areas of the game? a. The grapple hook is a situational tool that was designed to be used in specific, well defined areas of the game to facilitate travel for the player and different ways to interact with puzzles in the environment. 4. Why is there no in-game HUD?
56 | P a g e
5.
6.
7.
8.
9.
10.
a. We wanted to keep the player as immersed as possible within the game world and felt that the inclusion of a HUD would not provide the player with any additional necessary information. Why does the player not have a limited number of lives? a. We felt that to keep the flow of the game moving and to alleviate the stress associated with a limited number of continues we would allow the player to continue from the previous checkpoint as often as necessary. Why is the player not allowed to save at any time? a. To continue with the feel of a fully immersive environment we felt automatically saving for the player in predefined points would be the most effective and least intrusive method. Why is there no clearly defined health system? a. Following the same conventions of a fully immersive environment and to add a sense of realism, if the player is hit by an enemy they simply fall backwards or if the player falls down a hole they die. Why are there no other NPCs or entities to interact with in the game? a. We wanted to convey as sense of loneliness and scope to the game world that helped to convey the story elements presented in the games cutscenes. Why is there a lack of dialogue? a. We felt that dialogue would not be an effective method to convey story elements within our game world and wanted to rely on ambient sounds and visual effects. What happens to the player after the final cutscene? a. We wanted to leave what happens to the main character an ambiguous story element and allow the user to fabricate their own ending.
57 | P a g e
Reference of Key Elements

Winning / Losing
Main goal - Kill the ancient Sub-goals Platforming, Puzzles, Collectables Losing Death from falling too far or being crushed by boulders. When the player loses the screen goes to grayscale, music changes, and game over screen displays offering two choices: continue from last checkpoint and quit.
Rewards
In addition to the reward of finding all available collectables within the world (as described in the How the Player Marks Progress section) , the player is intrinsically rewarded through accomplishing the puzzles presented throughout the game and by skillfully traversing the intricate platforming aspects of the game world.
Transitions
Saving
There is an auto-save checkpoint system. Once the player reaches a predefined location the game will auto-save the players progress. When loading only the players position at that checkpoint is loaded. See the level map layouts for checkpoint locations and the checkpoint system of how the Player Marks Progress section.
Cut-scenes
At certain points in the game scripted visual events will take over the players control. These cut-scenes will be used to illustrate game progress.
58 | P a g e
Opening Cutscene Storyboard
59 | P a g e
Ending Cutscene Storyboard
60 | P a g e
Technical Document
Razing Ancients
Duck N Cover Productions
Brian Sorin bsorin@fullsail.edu

Robert Bernette | Rory Collins | Joel Faiella | Nick Faletra | Grant Landreth | Dan Southard
61 | P a g e
Technical Design Overview

The technical design document is important because it solidifies our ideas on how we will go about building our core systems for our game project. It will be a helpful schematic to look to when questions about overarching implementation arise, and how to organize our solutions for specific problems relating to data management and component interactions. Our overall design philosophy is to build for modularity and speed in processing. Overarching interfaces allow us to extend functionality in our objects simply through derivation. This is advantageous because we can reuse and extend code throughout our code base without having to rewrite implementation.
Milestone Deliverables
The following outlines major gameplay aspects present in the game at the end of each of the respective milestones.
Proof of Concept
A basic game world that represents the flow of our intended level design Character Control o Running o Jumping A win condition similar to the goal of the actual game, to reach the end of a level A loss condition, falling off the side of a platform Basic camera functionality
Feature Fragment One

More refined player movement control and accuracy within the game world Advanced jumping including better accuracy and more control The swinging mechanic, allowing the player to attach to a rope within the game world and traverse wider gaps in relation to normal jumping The first actual level, the platforming section of level 2 A more robust camera system that allows for greater control and accuracy A more immersive world through environmental effects and 3D sound
Feature Fragment Two

The world will begin to come alive with more advanced rendering techniques that add a sense of immersion and flow to the game experience Advanced movement techniques like the grapple hook swing, wall running, ledge grabbing, and wall climbing will allow the user to explore the game world in new ways Lighting and shadows will enhance gameplay aesthetics while providing accuracy to the player through air location information. Cinematic camera effects will provide a sense of the scale and intricacies of the game world
62 | P a g e
An additional section will be added to the main level providing new areas to explore and new challenges for the user. Basic puzzles will add a new layer of complexity and fun to the game world Users will be able to create, use, save, and load through a profile system that will save their preferences and progress in the expanding game world.
Alpha
The tutorial and boss level will be introduced in this milestone The player will be able to wall jump Overall movement of the player within the game world will be refined and more fluid to provide a more immersive gameplay experience Puzzles will be fully implemented Combat will be introduced, providing new forms of interaction for the user Cinematics will help to further the immersive feel of the game world Collectables will be implemented throughout the environment 360 Controller support will be added
Beta
The culmination of the game so far, with a push for polish on both the fluidity of player movement and control and the immersivness of the game environment through the camera and environmental effects.
Final
The final version of the game with a highly polished gameplay experience that draws the player in and urges them to explore the game world while almost effortlessly traversing the environment and its obstacles by the tools and movement techniques at their disposal.
63 | P a g e
Development Environment
Visual C++ v9 Microsoft-brand development environment and compiler for the C++ programming language. Maya 2008, 2009, 2010 3D modeling software package from Autodesk. Alienbrain v9.0.0.10674 Source control software developed by Avid Technology, using license keys provided by Full Sail. Wwise v2009.3 Patch 2 WaveWorks Interactive Sound Engine is an advanced audio authoring tool and sound engine developed by Audiokinetic.
64 | P a g e
System Architecture
System Architecture Flow Chart
Core
65 | P a g e
Context Module Description Engine Overarching wrapper that contains all modules. It is initialized from WinMain and acts as a springboard for the game components. Core Internal Management object that initializes updates and shuts-down all internal components of the engine. It interacts with all critical components. Geometry Processing Manages all the renderable objects currently being processed by the engine, it is updated by the core and sends processed renderable data to the renderer for rendering. User Control Manages the state of the engine and interfaces with the user. It dictates what assets are requested from Filestream. Object Manager Object Manager updates all of the objects that have been placed in the game world. These objects transforms are used by geoproc in order to position rendering data. Asset Factory requests new objects when a new asset request is sent. Effects Processing Updates all current pending effects in the game world. Receives new effect requests from the asset factory. Renderer Renders renderable objects that have been passed from geoproc after they are sorted. Animation Processing Updates the current animations that have been associate with objects in the game engine. It receives new animation requests from the asset factory. Filestream Receives requests from the UserControl and Engine and distributes newly loaded data to the current storage classes. Example, new models go to model storage, or new textures go to texture storage. Asset Factory Interfaces with all the storage containers and assembles new batches of assets that will be referenced by objects in the object manager. Asset factory requests new objects to associate when an asset request is made. Asset factory is sent requests by UserControl. Interpolator Contained by the animation processor. Manipulates the skeleton of a specific object based on an interpolation on an animation. Threadpool Allows streamlining of assets into game without locking main process thread. Used by the filestream in order to delegate tasks. Renderable Object Container for render data. Sent from the geoproc to the renderer. Data contained is used to render the object. RenderCode Container for a rendering function, stored by the renderer, and referenced by a renderable object. GLContext3D Manager for a glContext, initialized by the renderer at startup. Math Set of math wrapper classes used for 3D calculations. Timestep Time-keeping interface that updates the time per frame. Component Interface that all critical game components derive from. Sender Interface that represents a component that can send data through the message system. Reciever Interface that represents a component that can receive data through the message system. 66 | P a g e
CAudio A singleton that is accessed by all components as needed. It is used to post sound events to the audio system. Data Structures Basic data containers used to orient and organize data.
67 | P a g e
Storage and Object Creation
68 | P a g e
Context Module Description Asset Factory Interfaces with all the storage containers and assembles new batches of assets that will be referenced by objects in the object manager. Asset factory requests new objects to associate when an asset request is made. Asset factory is sent requests by UserControl. BSP Storage class for collision data. Receives collision data from the Filestream. Accessed by the object manager in order to do collision checks against the worlds geometry. Asset Base class that all asset containers derive from. BluePrint Schematic class that holds instanced data used to represent an object. It is sent from Filestream to BlueprintStorage. Blueprints are passed from Blueprint storage to asset factory when objects are being assembled. ModelStorage Container class for all of the models loaded into the Engine. Receives model assets from the filestream. This classes data is instanced by blueprints. BlueprintStorage Container class for all blueprints loaded into the Engine. Receives blueprint assets from the filestream. CollisionSection Container class that holds a single set of collision data. These are sent from filestream to the BSP. They are used by Object Manager in collision checks. EffectStorage Container class for all of the effects loaded into the Engine. Receives effect assets from the filestream. This classs data is instanced by blueprints. TextureStorage Container class for all of the textures loaded into the Engine. Receives texture assets from the filestream. This classs data is instanced by blueprints. MaterialStorage Container class for all of the materials loaded into the Engine. Receives material assets from the filestream. This classs data is instanced by blueprints. ModelAsset Container class for models. Sent from Filestream to ModelStorage. EffectAsset Container class for effects. Sent from Filestream to EffectStorage. TextureAsset Container class for textures. Sent from Filestream to TextureStorage. MaterialAsset Container class for materials. Sent from Filestream to MaterialStorage.
69 | P a g e
User Control
Context Module Description User Control Manager For all states. Selects a particular state as its active state. Interfaces with Camera and Input. UserState Base class that all states derive from. Input Receives input from the user and translates for the appropriate active state. Camera Receives actions from the appropriate active state and repositions the camera in 3D space. GameState Manages loading and maintenance of level at runtime. Interfaces with the camera in order to position it in the scene. Makes calls to Asset Factory for new objects. Primary Menu State Manages the Main Menu and positions the camera appropriate to the menu position. Makes calls to the Asset Factory for new menu items. Pause State Manages the Pause Menu and positions the camera appropriate to the menu position. Makes calls to the Asset Factory for new menu items. Profile State Manages the Profile Menu and positions the camera appropriate to the menu position. Makes calls to the Asset Factory for new menu items. Cinematic State Manages the actors in the scene. Interfaces with the camera and any existing actors and positions them according to an animation. Makes calls to asset factory for new items.
70 | P a g e
Object Hierarchy
71 | P a g e
Module Breakdown Critical Components

Engine
Description The Engine is a startup point for all engine code, and is the first class instantiated in the program. This class is responsible for instantiating all core components, and then loading those into the core. This class is the only class that directly gets updated; it then updates all other core classes. When the program ends this class will shut down and close all other components and terminate any processes that may be running. Functions Return Void
Name Initialize
Parameters
HINSTANCE hInstance, LPSTR lpCmdLine, int nShowCmd
Description Loads and initializes the window where everything will be displayed. It instantiates all core components and loads them into the core, where they will be managed during runtime.
Void
Execute
Void
Continuously updates the window, the elapsed time, and the core.
Void
Shutdown
Void
Shuts down the core and deallocates any remaining memory.
const W32Window&
GetWindow
void
Returns a reference
72 | P a g e
Core
Description The core is the central controller which initializes, updates, and shuts down all defined components within the engine. Components are modules that perform specific actions in the engine, and are loaded into the core at initialization. All modules that are to be managed directly by the core must derive from the Component interface. The core then locks the components in when initialization is complete, and begins the execute phase, which updates each component every loop. The time is also updated within core. The core can also receive error codes from executing components during runtime. Functions Return void
Name Initialize
Parameters void
Description Initializes all components that will be placed in the core, adds them to the cores component list, and starts the updating.
void
Execute
float fTime
Updates all components locked into the core.
Component*
GetComponent
unsigned int nIndex
Returns the selected component at the index.
bool
AddComponent
Component* pComponent
Adds a component to the cores component list. Returns false if the core is full or an error occurred.
void
Shutdown
void
Shuts down and deallocates all components currently held by the engine. 73 | P a g e
W32Window
Description This module provides a wrapper for the win32 setup required to get a basic win32 window for rendering purposes. It also possesses custom input calls for both keyboard and mouse with some double buffering support. The window supports both fullscreen and windowed mode, as well as it can switch states on the fly based on keyboard input. The window also possesses a few extra functions to handle idle and minimization issues. Return void Name Initialize Parameters HINSTANCE hInstance int nShowCmd void *WinP int nWidth int nHeight int nFullWidth int nFullHeight const char *szWindowName int nIcon void Description Declares a window but lets you actually initialize it in WinMain.
void
RefreshWindowAttributes
HWND int int int int int int int int int int bool bool bool
GetHWND GetCurrentX GetCurrentY GetCenterX GetCenterY GetWindowWidth GetWindowHeight GetFullWidth GetFullHeight GetCurrentWidth GetCurrentHeight IsMinimized IsWindowed IsIdle
void void void void void void void void void void void void void void
Refreshes the windows X, Y, Width, and Height for the current display mode. Accessor for HWND variable. Accessor for X variable. Accessor for Y variable. Accessor for CenterX variable. Accessor for CenterY variable. Accessor for Window Width. Accessor for Window Height. Accessor for Fullscreen Width. Accessor for Fullscreen Height. Accessor for current width that is being used(fullscreen/windowed). Accessor for current height that is being used(fullscreen/windowed). Evaluates true if the window is minimized. Evaluates true if the window is in windowed mode. Evaluates true if the window is minimized and sleeps for 1
74 | P a g e
bool
MinimizeOnLostFocus
bool bState
void void void BOOL
ToWindowed ToFullScreen SwapWindowState Update
void void void void
void void bool bool
Shutdown RefreshKeys IsKeyDown IsKeyPressed
void void int nScanCode int nScanCode
bool
IsKeyReleased
int nScanCode
void bool bool bool bool
FlushInput LeftMouseButtonDown RightMouseButtonDown MiddleMouseButtonDown LeftMouseButtonPressed
void void void void void
bool
RightMouseButtonPressed
void
bool
MiddleMouseButtonPressed
void
int int int int
GetMouseX GetMouseY GetCursorFromOriginX GetCursorFromOriginY
void void void void
millisecond. Specifies whether or not the window should minimize automatically if the window loses focus. Switches to windowed mode. Switches to fullscreen mode. Swaps between windowed and fullscreen. Manages the win32 message loop and returns false if the WM_QUIT message was posted. Posts Quit Message and shuts down the window. Refreshes the key buffers with the keyboard status. Checks to see if the key was down on the last update. Checks to see if the key was down on the last update in respect to double buffered input. Checks to see if the key was up on the last update in respect to double buffered input. Flushes the input buffers. Checks to see if the left mouse button is down. Checks to see if the right mouse button is down. Checks to see if the middle mouse button is down. Checks to see if the left mouse button is down in respect to double buffered input. Checks to see if the right mouse button is down in respect to double buffered input. Checks to see if the middle mouse button is down in respect to double buffered input. Accessor to the mouses x position. Accessor to the mouses y position. Accessor to the mouses x position in reference to the windows origin. Accessor to the mouses y position in reference to the windows origin. 75 | P a g e
int int bool
GetCursorFromCenterX GetCursorFromCenterY MouseIntersect
void void RECT tBounds
Accessor to the mouses x position in reference to the windows center. Accessor to the mouses y position in reference to the windows center. Checks to see if the mouse is within the tBounds passed in.
Module Author Grant Landreth
76 | P a g e
GLContext3D
Description The GLContext3D module is responsible for initializing, managing, and shutting down any OpenGL related functionality. It allows for automatic resizing in real-time using the handle to the window passed by the W32Window module. Renderer has a reference to this module to get global OpenGL information.
Return HWND HGLRC float float float void void void void void
Name GetWindow GetContext GetPerspective GetNearPlane GetFarPlane SetPerspective SetNearPlane SetFarPlane SwapBuffer Initialize
Parameters void void void void void float fPerspective float fNear float fFar void HWND pWindow float fPerpsective float fNear float fFar int nWidth int nHeight void
Description Accessor to the HWND variable. Accessor to the HGLRC variable. Accessor to the Perspective variable. Accessor to the Near Plane variable. Accessor to the Far Plane variable. Sets the Perspective to the passed in float. Sets the Near Plane to the passed in float. Sets the Far Plane to the passed in float. Swaps the current render buffer. For double buffering. Initializes the GLContext3D using the passed in variables to setup our OpenGL window. Resizes the window according to the width and height parameters. Shuts down the window and releases all dynamic memory.
void void
Resize Shutdown
77 | P a g e
Overarching Interfaces
Component
Description Component is the base interface that all modules in the Core derive from. Components are generally updated by the engines core, and send messages to the Core based on run-time conditions. Components can store a direct pointer to the global time held by the engine. Component derives from the Hub and TimeDependent interfaces. Functions Return void
Name Initialize
Parameters void
void
Execute
void
void
Shutdown
void
Description This initializes the component. This function must be overridden in the child class. This executes internal code held by the component. This function must be overridden in the child class. This shuts down the component and deallocates any remaining data. This function must be overridden in the child class.
void Module Author Grant Landreth
ProcessData
void
78 | P a g e
Sender
Description The Sender interface allows the derived object to send larger chunks of data to specific objects. Senders can only send to objects that derive from the Receiver interface. Data sent must be contained in a structure or class that derives from the Transmissible interface. Senders possess a list of contacts, or specific entities that they can send to. To send data, the sender merely needs to call the SendData function. Functions Return void
Name AddContact
Parameters Receiver *pContact
Receiver *
GetContact
uint nContact
void
SendData
uint nContact Transmissible *pData
void
ClearContacts
void
Description Adds the Receiver pContact to the list of Receivers. Accessor to the Receiver at index nContact in the list of Receivers. Sends the data pData to the Receiver at index nContact inside of the list of Receivers. Clears the list of Receivers.
79 | P a g e
Receiver
Description The receiver module is an interface class that works alongside the sender class, receiving any data that sender may have sent. Receiver contains an input queue where it holds the data it has received. Functions Return void
Name ReceiveData
Parameters Transmissible* pData // the data to be recieved
Description The pData pointer is filled by the incoming data sent by a sender class, and is then pushed onto the input queue.
void
ProcessData
void
Handles any data that may have been sent to the Receiver. This function is pure virtual and is intended to be overridden to suit the specific needs of the derived class.
80 | P a g e
Object Hierarchy
Object
Description The Object class is the base object that all objects in the object hierarchy derive from. It sets down basic object implementation, and provides the bare minimum functionality that all objects should have. Functions Return VMatrix4*
Name GetTransform
Parameters void
Description Returns a pointer to the transform. Updates the transform. Returns a constant pointer to the Bounding Volume. Sets the bounding volume. Returns the type of object by ID.
void
Update
float fTime
const BoundingVolume*
GetBVolume
void
void
SetBVolume
BoundingVolume*
int
GetType
void
Module Author(s) Nick Faletra / Dan Southard
81 | P a g e
TriggerVolume
Description This module is a derivative of the Object class and the Activator interface. It is a collision volume with an associated trigger, which activates an object on intersect with the player. This can be used to trigger other objects such as traps, effects, and cinematics. Functions Return void
Name SetVolumeType
Parameters int eType
VolumeType void
GetVolumeType Update
void float fTime
Description Sets what kind of trigger this volume activates. Accessor to the VolumeType. Updates Object and Activator data.
Module Author Nick Faletra
Prop
Description A prop represents a static object in the scene. It contains the transform for the object it represents, as well as a general collision volume for collision checking with other objects and the world. RenderableObjs generally reference this object as its initial transform when rendering their data. Functions Return void
Name Update
Parameters float fTime
Description Update is responsible for updating the data inside of prop.
82 | P a g e
Rope
Description Ropes, which are activated by the context-sensitive input given by the player, and transition the player into a swinging state, suspended from the object in the scene. As such they are defined in our object hierarchy as interactable props. Functions Return void
Name Update
Description Updates the state of the swingable object. Transitions the player into a swinging state and attaches them to the object.
void
Use
void
83 | P a g e
I/O
FileStream
Description The Filestream is the module used to load any object into the game. Any external data, such as models, textures, and scripts, go through the file stream. They are then distributed to the appropriate storage system for the respective asset type. The FileStream possesses two modes, full load and streaming. In the full load state, the FileStream hogs all processing in order to get the data loaded in as quickly as possible. In streaming mode, the data is loaded in gradually using the Threadpool system without interrupting gameplay.
Functions Return void
Name Initialize
Parameters void
Description Initializes the filestream for loading. Handles any current operations of the filestream. Releases all local data and readies the system to be unloaded. Loads a file from the root Resource directory. Loads in all models associated with the root path passed. Loads a tree of models. Loads in all textures associated with the root path passed. Loads a tree of textures. Loads in all animations associated with the root path passed. Loads a tree of animations. Loads in all blueprints
void
Execute
void
void
Shutdown
void
void
LoadFromFile
Const char* pPath, DataType eRequest Receiver** pReceiver CWord filePath
void
LoadModel
void
LoadTexture
Receiver** pReceiver CWord filePath
void
LoadAnimation
Receiver** pReceiver CWord filePath
void 84 | P a g e
LoadBlueprints
Receiver** pReceiver
CWord tRootBlueprint
associated with the root path passed. Loads atree of blueprints. Returns whether or not the filestream is currently streaming. Sets whether or not the filestream is current streaming.
Bool
IsStreaming
void
void
IsStreaming
Bool bState
Module Author Dan Southard, Grant Landreth
85 | P a g e
Threadpool
Description Threadpool uses the windows threadpool api to create a threadpool of idle threads and passes it WorkItems, which are defined as load functions for engine assets. Threadpool contains items that have callback processes defined, which indicates which load function the thread will call. This allows our system to streamline asset loading without interfering with the games performance. Functions Return void
Name Initialize
Parameters Int nNumThreads
Description Creates a threadpool of nNumThread count threads. If -1 is passed in it will assign an optimal amount of threads. If it cant assign as many threads as are requested, a notification will be sent to core. Checks the input queue of work items for work waiting to be done, then looks through the output queue for work that has been completed so that the data can be passed off to the game. Removes all work that hasnt been processed yet, and releases all of the threadpools threads. Takes in a workitem, and adds it to the threadpools input queue so that it can be processed. Creates a workitem out of the data passed, then adds it to the input queue.
void
Update
void
void
Shutdown
void
void
AddWorkItem
WorkItem
void
AddWorkItem
Receiver** pReceiver, const char* path, Void* fp,
86 | P a g e
Mesh
Description The mesh structure holds all of the 3D rendering data related to a particular piece of a model. The data contained is a vertex buffer, index buffer, normal buffer, and uv buffer. This structure is generally contained within a model class. Return Vector3* Name P_mVertexBuffer Parameters Description Contains all relative Vertex information to represent the mesh.
Vector3*
P_mIndexBuffer
Contains all relative Index information to represent the mesh.
Vector3*
P_mNormalBuffer
Contains all relative normal information to represent the mesh.
Vector3*
P_mUVBuffer
Contains all relative UV information to represent the mesh.
Bool
LoadMesh
Const char* pPath
Loads in a mesh from the file path.
void
Clear
void
Clears out the mesh structure.
87 | P a g e
Model
Description This defines a structure that contains the information necessary for an in-game 3d entity. This structure holds the framework for a renderable entity, and contains the skeleton used for animating this object. These are stored in the Model Storage class, and are referenced by objects being drawn by the Renderer. Members Return unsigned int
Name n_mNumMeshes
Description The number of meshes that make up this model. The meshes contained by this model object. The skeleton of this object used for animation and skinning. Clears out the model of all of its contained data.
Mesh*
p_mMeshes
Skeleton*
p_mSkeleton
void Module Author Dan Southard
Clear
void
88 | P a g e
Texture
Description Texture is the base class in the Texture Hierarchy. It contains the base information shared by all textures that can be loaded. As for loading functionality, it is derived from in order to add specific loading code for a particular format. It is used in conjunction with the GLTexture class in order to bind OpenGL handles for texture information. Functions Return
Name char* P_mBuffer
Parameters
Description A buffer to hold the names of the textures. The data member to represent the format of the texture. The data member to mark the internal byte format of the texture. The data member used for the height of the texture. The data member used for the width of the texture.
uint e_mFormat
uint n_mInternalFormat
int n_mHeight
int n_mWidth
virtual bool
Load
const char* pPath
Pure Virtual Function, must be overridden in order to supply texture loading code. Will deallocate all of the texture data contained within.
Void
Clean
void
89 | P a g e
TGAInterface
Description This interface only has the loading code for TGA's, which allows you to splice TGA loading code into any existing texture type regardless of the API you are using(OpenGL/DirectX). Functions Return bool
Name LoadTGA
Parameters const char* pPath, Texture*, pTexture
Description Takes in all the pointers and will load in that specific TGA.
Example Usage TGAInterface is spliced with the Texture class in order to yield the TGATexture class. This class can load in a TGA texture file, and then up-caste to the Texture class. Now data from the TGA can be interpreted as raw texture data, instead of just TGA data. Texture* pTGA = new TGATexture(pFilePath); Module Author Grant Landreth
90 | P a g e
PNGInterface
Description This interface only has the loading code for PNG's, which allows you to splice PNG loading code into any existing texture type regardless of the API you are using(OpenGL/DirectX). Functions Return Bool
Name LoadPNG
Parameters const char* pPath
Description Loads a PNG file from the specified path (pPath) into the pTexture Texture pointer.
// file path to the texture Texture* pTexture
// the actual texture data
Example Usage PNGInterface is spliced with the Texture class in order to yield the PNGTexture class. This class can load in a PNG texture file, and then up-caste to the Texture class. Now data from the PNG can be interpreted as raw texture data, instead of just PNG data. Texture* pPNG = new PNGTexture(pFilePath); Module Author Dan Southard
91 | P a g e
GLShader
Description The GLShader structure contains the loading code for OpenGL shaders, as well as a handle to a shader. GLShader also contains functionality for binding and unbinding the shader it has a handle to. The clean function takes care of the cleanup for its shader. Functions Return Void
Name BindShader
Parameters void
Description Binds the shader to the graphics card. Unbinds the shader from the graphics card.
Void
UnbindShader
void
Bool
Load
const char*
pVertex
// Vertex Shader Path const char* pFrag
Loads the Vertex Shader and Fragment Shader from the given file paths.
// Fragment Shader Path Bool LoadSource const char* pVertexCode Loads and Compiles the actual source code for the shader.
// Vertex Shader Code const char* pFragmentCode
// Fragment Shader Code Void Module Author Grant Landreth Clean void Cleans up the shader.
92 | P a g e
Storage
Asset Factory
Description AssetFactory handles the creation and distribution of the games assets. AssetFactory has an array of schematics that it uses to create objects. Requests for objects are sent to the factory by other components, whereby the AssetFactory creates the object using a given index into the schematic array. AssetFactory then sends out the newly created objects to the object manager, where the y will remain during the course of their lifetime. Functions Return void
Name Initialize
Parameters void
Description Initializes the Asset factory. The meat and bones of the asset factory. Asset creation would occur here. Cleans up the Asset Factory. Handles any data that may have been sent to the Asset Factory. Using an index into an array of schematics, the Asset Factory creates an object. Takes in a model storage to use as a reference for model data. Takes in a texture storage to use as reference for texture data. Takes in an animation storage to use as reference for animation
void
Execute
void
void
Shutdown
void
void
ProcessData
void
Object*
CreateObject
uint nSchematic // index into the schematic array
void
SetModelStorage
ModelStorage*
void
SetTextureStorage
TextureStorage*
void
SetAnimationStorage
AnimationStorage*
93 | P a g e
data.
void
SetBlueprintStorage
BlueprintStorage*
Takes in a blueprint storage to use as reference for blueprint schematics
94 | P a g e
EffectStorage
Description The EffectStorage class holds all the effects data. Effects data is sent directly from the I/O section of the engine in the form of EffectAssets. Handles to this data can be requested from the EffectsStorage class, and then utilized externally for rendering purposes. Functions Return void
Name Initialize
Parameters void
Description Starts the process and initializes any data that is needed for this class to run. Retrieves pending data from the input queue a places it in local storage for later use. Shuts down any data that was used by, or initialized by this class. Returns a constant pointer to a stored effect for external reference. Moves pending effects from the input data queue and performs any needed manipulation on it. Called from Execute.
void
Execute
void
void
Shutdown
void
Const Effect*
GetEffect
Uint nEffectID
void
ProcessData
void
95 | P a g e
CollisionSection
Description This structure holds a list of triangles relevant for collision checking. Functions Return void
Name SetTriangles
Parameters Vector3 *pVerts, uint nVertCount
Description Assigns triangles passed in to this collision section. Returns the triangles of the collision section. Sets an Objects y coordinate to the position to a triangle if it collides. Start the line segment from vIn and return a collision point, vOut, if there is collision. Checks collision against the bounding volume and all triangles in collision section.
const Triangle*
GetTriangles
void
bool
ClampObjectTo
Object *pObj
bool
ClampVecTo
const Vector3 &vIn, Vector3 &vOut
bool
CheckCollision
const BoundingVolume *pBV
Module Author Dan Southard
96 | P a g e
BSP
Description BSP subdivides our world geometry into sorted sections to allow for quick indexing, sorting and collision checking with our objects. The BSP data is generated by a pre-processor tool that takes in our exported scene data from Maya and generates splitting planes and collision data for the geometry. We can index into the BSP geometry based on its proximity to our object that we are checking collision. This allows us to cull unnecessary collision detection checks thus speeding up our game loop. Functions Return const CollisionSection*
Name GetCollisionSection
Parameters const BoundingVolume* pBV, const CollisionSection *pFrom
Description Returns a section of the BSP local to the bounding volume passed in, on NULL it will start at beginning. Returns a section at the BSP index passed in. Pulls any data off of the input data queue and gets it ready for execution. Gets the BSP data loaded in locally and readies the BSP for processing. Gets data needed for processing collision volumes and prepares for collision checking. Shuts down and deinitializes all of data contained within. Adds a collision section to the BSP. Clears out the BSP.
const CollisionSection*
GetCollisionSection
int nIndex
Void
ProcessData
void
Void
Initialize
void
Void
Execute
void
Void Void Void
Shutdown AddCollisionSection Clear
void CollisionSection *pCol void
Example Usage In order to check for collisions, one must pass a pointer to the object being checked. In order to search the BSP, the pointer is passed into the GetCollisionSection function, which returns a pointer to the next closest set of triangles to the object. Repassing the same collision pointer will iterate to the next closest collision section. Module Author Dan Southard
97 | P a g e
AnimationStorage
Description This class is used for updating and storing Animations. The class iterates through a list of Animations, updating and removing them as necessary. Functions Return void
Name Initialize
Parameters void
Description Initializes data that the class needs in order to run. The class iterates through a list of models, updating them, or removing them at the end of their lifetime. Frees any memory that may have been allocated during the life of the class. Returns an Animation from an array of models at index nAnimationD The class sorts through data sent to it, such as models. Adds animation to the storage and assigns a unique id. Removes animation from storage based on the nID. Clears out the storage container of all animations.
void
Execute
void
void
Shutdown
void
Const Animation*
GetAnimation
uint nAnimationID
void
ProcessData
void
void
AddAnimation
Animation *pAnimation
void
RemoveAnimation
uint nID
void
ClearStorage
void
98 | P a g e
Blueprint
Description The blueprint holds constant handles to all of the data held by other storage containers required for drawing any object in the game. Each blueprint is a schematic for the assembly of the object specified. These are used by the AssetFactory in order to create instances used at run-time. Members Type int
Name n_mAnimationSetID
Description An index into the animation storage for what animation this object uses if applicable. ID of the blueprint Pointer to a model. Pointer to a texture. Pointer to a set of animations.
unsigned int const Model* const Texture* const AnimationSet* Module Author Grant Landreth
n_mIdentity p_mModel p_mTexture p_mAnimations
99 | P a g e
BlueprintStorage
Description This class stores all of the blueprints needed for making any object in our game world. Blueprints can be used for assembling an object for rendering. Blueprint storage gets initialized last because of its dependencies on pointing to other systems data. Functions Return const Blueprint*
Name GetBlueprint
Parameters unsigned int nID
Description Returns the data attached to that blueprint so that the data can be used for another object instance. Pulls any data from the input data queue and gets it ready for execution. Gets the blueprint data loaded in locally and readies the storage for use. Checks to see if any blueprints have been received from the I/O component, and stores them in the asset banks. Ends the blueprint storage system and gets rid of all of its local data. Clears the storage of Blueprints. Adds the Blueprint to the storage.
void
ProcessData
void
void
Initialize
void
void
Execute
void
void
Shutdown
void
void void Module Author Grant Landreth
ClearStorage AddBlueprint
void const BlueprintAsset &pBlue
100 | P a g e
TextureStorage
The texture storage class holds texture assets that have been loaded by the I/O module. Textures loaded in I/O are sent to the TextureStorage component as TextureAssets. TextureStorage returns constant handles to the texture data when it is requested by the AssetFactory during object fabrication. These texture handles are then used by the RenderableObjs in the Renderer. Description Return void
Name Initialize
Parameters void
Description Will initialize all the internal data in the storage component. Will perform any updating code relating to organizing the textures contained. Will deallocate any texture handles currently held by the storage component. Returns a GLTexture* at the specified index in the storage component. Retrieves data from the input data queue and preps it for storage. Clears the storage container of Textures. Adds a texture structure to the storage container.
void
Exectue
void
void
Shutdown
void
const GLTexture*
GetTexture
uint nTextureID
void
ProcessData
void
void
ClearStorage
void
unsigned int
AddTexture
const TextureAsset *pAsset
101 | P a g e
ModelStorage
Description This class is used for updating and storing models. The class iterates through a list of models, updating and removing them as necessary. It receives newly loaded models from the I/O module in the form of ModelAssets. It returns constant handles to model data during the fabrication of a new object in the Asset Factory. Functions Return void
Name Initialize
Parameters void
Description Initializes data that the class needs in order to run. The class iterates through a list of models, updating them, or removing them at the end of their lifetime.
void
Execute
void
const Model*
GetModel
uint nID
Returns a model from an array of models at index nID. The class sorts through data sent to it, such as models. Clears the storage container of all Models. Adds a model structure to this storage container. Removes a model structure at the index nID.
void
ProcessData
void
void
ClearStorage
void
int
AddModel
ModelAsset *pMod
void
RemoveModel
unsigned int nID
Module Author Grant Landreth, Dan Southard
102 | P a g e
CAudio
Description A class used for storing and playing sounds. The class reads in sounds from external files. It is sent events, denoted by long integer handles, which signify what sound event to play. It then posts the event, which plays the sound from a list of sounds relating to the event. The Effects class directly interfaces with this system, generally triggering sound effects as other effects are fired from the class. Functions Return void
Name Execute
Parameters void
Description The class plays, ends, and modulates sounds as needed. Posts an event. If a matrix is passed in, attaches the event to that position. Registers an object with the sound engine for sounds to be positioned. Removes an object from the sound engines object list. Sets a groups switch case to the passed in state.
void
PostEvent
unsigned long ulEventID, VMatrix4 *pAttachment
void
RegisterGameObj
vMatrix4 *pTransform, conat char *szObjectName
void
UnregisterGameObj
VMatrix4 *pTransform
void
SetSwitch
VMatrix4 *pTransform, unsigned long ulMaterialGroup, unsigned long ulState
void
SetRTPC
unsigned lont nID, float fValue
Sets and RTPC value to fValue.
103 | P a g e
Processing
ObjectManager
Description This class updates and stores objects. Objects are created in the AssetFactory, and then sent to the object manager to be updated for the duration of their life. The manager iterates through its stored objects, updates them, then removes and deletes objects when they are no longer needed. It is also responsible for perform collision checks on all objects currently contained. It interfaces with the BSP in order to get world collision data to test against. Functions Return void
Name Initialize
Parameters void
Description Initializes data that the class needs in order to run. The objectmanager will sort through its list of objects, updating and deleting as needed. Adds an object to the classs list of objects. Removes the object from the list and deletes it. Removes the object from the list and deletes it. The objectmanager sorts through data sent to it, such as new class objects.
void
Execute
void
void
AddObject
Object* pObject
void
KillObject
Object* pObject
void
KillObject
VMatrix4* pObject
void
ProcessData
void
Module Author Nick Faletra, Dan Southard, Grant Landreth
104 | P a g e
GeometryProcessing
Description This class contains a list of Renderable Objects. It sorts through the list of objects and passes geometry that should be visible to the Renderer so that it can be displayed to the screen. This class removes objects that are behind the player or out of view so that they do not get rendered for optimization. This class interfaces with the camera, BSP, and other culling systems in order to properly sort the array of renderable objects accordingly. Functions Return const Camera*
Name GetCamera
Parameters void
Description Returns a pointer to the Camera object. Sets the camera to the object passed in. Initializes and data the class needs to run. Returns a model from an array of models at index nModelID Adds a renderable object to a list of objects to be processed. Removes a renderable object from a list of objects. Removes a renderable object from a list of objects. Sets the renderer pointer to pass Geometry data.
void
SetCamera
const Camera* pCamera
void
Initialize
void
const Model*
GetModel
uint nModelID
void
AddRenderables
RenderableObj* pObj
void
RemoveRenderables
RenderableObj* pObj
void
RemoveRenderables
VMatrix4* pOrientation
void
SetRenderer
const Renderer *pRenderer
105 | P a g e
Interpolator
Description Iterates through the frames of a bound animation and interpolates between the transforms based on time and distance in the animation. These interpolations are applied to the bound skeleton. Functions Return float
Name GetAnimationSpeed
Parameters void
Description Returns the speed at which the animation is playing. Returns a constant pointer to the Animation. Returns a pointer to the Skeleton. Sets animation speed. Sets up the interpolator on a new animation and skeleton. Resets the iterator and rebinds the animation. Updates and interpolates the animation data and applies it to the target Skeleton based on time. Performs a matrix interpolation on the given inputs based on the fInterp value. Clears the interpolator.
const Animation*
GetAnimationPtr
void
Skeleton*
GetSkeletonPtr
void
void void
SetAnimationSpeed Initialize
float fSpeed const Animation *pAnimation, Skeleton *pSkeleton
void
Reset
void
void
Update
float fElapsed
VMatrix4
InterpolateMatrix
const VMatrix4 &A, const VMatrix4 &B, float fInterp
void
Clear
void
106 | P a g e
AnimationProcessing
Description This class contains a list of currently executing Animations in the game. It updates Animations that are in the list, and removes animations that are no longer being utilized by an object in the scene. Functions Return void
Name Initialize
Parameters void
Description Initializes and data the class needs to run. Sorts through its list of Animations, calling update on them and removing animations that are not needed. Frees any memory that may have been allocated during the life of the class. Processes data from the received data queue. Clears the processors data. Adds the AnimationControl to the queue of animations. Removes an AnimationControl by pointer. Removes an AnimationControl by index.
void
Execute
void
void
Shutdown
void
void
ProcessData
void
void
ClearProcessor
void
AnimationControl* AddAnimationControl
AnimationControl *pAnimations
void
RemoveAnimation
const AnimationControl *pControl
void
RemoveAnimation
unsigned int nID
107 | P a g e
EffectsProcessing
Description This module is plugged directly into the Core and manages the currently active effects in the scene. It initializes all data involved with effects and updates the common data contained by them. It contains an active list of effects in the scene, and dynamically adds and removes effects based on internal and external input. It derives from the Component and Hub interfaces. Functions Return const Camera* void void void
Name GetCamera SetCamera Initialize Execute
Parameters void const Camera *pCamera void void
void void void void
Shutdown AddEffect RemoveEffect RemoveEffect
void Effect *pObj Effect *pObj VMatrix4 *pOrientation
Description Accessor to the Camera. Sets the camera of the module to the passed in pCamera. Initializes the module. Executes common update code for effects. Called once per frame. Shuts down the module. Adds the pObj to the list of effects contained in the module. Removes an effect in the list by object pointer. Removes an effect in the list by its orientation matrix.
108 | P a g e
Rendering
Renderer
Description This module is responsible for drawing renderable objects to the screen. This class keeps a list of renderable objects and an array of RenderCodes. Renderable objects are rendered via the RenderCodes in the array, or a default RenderCode if no function is specified. Generally, Renderer has a reference to the Geometry Processor, where all of the renderable data is sorted before it is rendered. Functions Return const RenderCode&
Name GetRenderCode
Parameters uint nFunc
Description Returns a RenderCode from an array at index nFunc. Returns the openGL context currently available. Sets the default render information for renderer. Sets the default render information for renderer to the RenderCode in the array at index nFunc. Adds a render object to a list of RenderCode. Returns the index of the array it is stored at. Searches through the list of RenderCodes for one matching the name passed in. Returns the index it is stored at or -1 if not found.
GLContext3D&
GetContext
void
void
SetDefaultRender
RenderCode fpDefault
void
SetDefaultRender
uint nFunc
int
AddRenderCode
const RenderCode& pCode
int
FindRenderCode
const char* szRenderName
109 | P a g e
void
Initialize
void
Allocates any memory the class needs to run.
void
Execute
void
Checks through the array of renderable objects and calls their respective RenderCode. Frees any memory that has been allocated during the classs lifetime. Begins a Renderer scene.
void
Shutdown
void
void
Begin
void
void
End
void
Ends a Renderer scene.
void
Render
const RenderableObj* pObj
Renders the object passed in.
void
Render
const RenderableObj* pObj, uint nFunc
Renders the object passed in with the RenderCode stored at index nFunc. Renders the object passed in with RenderCode pFunc. Ignores the pObjs RenderCode and instead calls the default RenderCode.
void
Render
const RenderableObj* pObj, RenderCode pFunc
void
RenderDefault
const RenderableObj* pObj
Sub Components RenderCode
110 | P a g e
Effect
Description This object stores data necessary to replicate effects. Because this is the base class, it only carries with it base functionality. It possesses an ID that allows it to request a particular EffectCode in the Renderer. The Effect class is overridden in order to gain more functionality. Functions Return void
Name Update
Description Updates the state of the effect and animation associated.
RenderCode
Description This module is a structure that contains a function pointer relating to rendering. This function pointer is associated with an ID, which is utilized by the Renderer as a way to associate certain objects with certain render functions. Render functions are prewritten, and then passed into RenderCodes, which are then loaded into the Renderer. Inside the Renderer, RenderCodes are specified by the objects passed in via ID, and then operate on these objects in order to render their contents. Functions Return static uint
Name GenerateID
Parameters const char *pID
Description Generates an unsigned integer based on the string description/name passed.
111 | P a g e
RenderableObj
Description This interface relates to the rendering data required by the renderer. RenderableObjs are created by the AssetFactory, and are passed to the Geometry Processing module for containment. When in the GeometryProcessing component, these RenderableObjs are sorted and batched to the Renderer, where they are rendered based on the data they contained. Because this is the base class of the renderable hierarchy, this class only contains an ID as to which RenderCode it will use, and a transform to represent it in world space. Child types derived from this class can contain information such as model, texture, material, shader, or effects data. Members Type int
Name n_mRenderFunc
Description Specifies which RenderCode this object will request when it is rendered by the Renderer. The pointer to the transform held by this RenderableObjs respective Object in the ObjectManager.
const VMatrix4*
t_mTransform
Example Usage RenderableObj can be derived into a new class called VertexRenderableObj, which contains a vertex buffer pointer that can be used to batch a set of triangles. When the VertexRenderableObj is passed to the Renderer, it would request a specific RenderCode such as VertexRenderCode via an ID. The object would then get passed into this function pointer, caste to a VertexRenderableObj from a RenderableObj, and then operated on. Module Author Grant Landreth
112 | P a g e
User
UserControl
Description The UserControl class is a sub-core for all of the user input management. It toggles the current state that the user is in, and manages certain specifics about camera control, cinematic, and user input. It is the primary controller for how the user should interact with the program at any given state. Functions Return Input*
Name GetInput
Parameters void
Description Gets a pointer to the current input object. Returns a pointer to the camera object. Gets the current active state for any reference purposes. Gets a pointer to a UserState that is at the passed in index. Sets the current state to the one at the passed in index. Sets the UserState at the specified index to the passed in UserState. Initializes any dynamic memory objects that are used and sets up the class to be able to run. Runs the updates for any stored data. Releases any used dynamic memory and ending any objects that were stored. Processes data in the
Camera*
GetCamera
void
UserState*
GetCurrentState
void
UserState*
GetUserState
int nIndex
void
SetCurrentState
int nIndex
void
SetUserState
int nIndex, UserState* pState
void
Initialize
void
void
Execute
void
void
Shutdown
void
void
ProcessData
void
113 | P a g e
received data queue. void void SetInput SetCamera Input *pInput Camera *pCamera Sets the input pointer. Sets the camera pointer.
Module Author Robert Barnette, Joel Faiella
Frustum
Description A class used in frustum testing to cull out polygons that are not within view of the player. Contains functions used which test intersections with spheres, AABBs, and cylinders. Functions Return const Plane*
Name GetPlanes
Parameters void
Description Returns planes that will be used in checking intersection with polygons. Tests intersection of pSphere with the frustum. Returns true if the sphere is within or intersects with the frustum. Tests intersection of pAABB with the frustum. Returns true if the AABB is within or intersects with the frustum.
bool
TestSphere
const Sphere& pSphere
bool
TestAABB
const AABB& pAABB
Module Author Nick Faletra, Dan Southard
114 | P a g e
Camera
Description This class is used to find information the player should view. The objects rendered on the screen are relative to the cameras position and rotation. The camera will follow the player, but is able to be moved in certain circumstances by the user. The camera is still an object, and can collide with other objects. Camera uses a soft attach system, and is fed commands relating to movement from external systems. This allows the cinematic systems, player character, and world environment to control the camera in the same manner. Functions Return void
Name Initialize
Parameters void
Description Initializes data that the class needs in order to run. Sorts through data sent to it from a sender. Will include information about its next action. Returns a pointer to the cameras transform. Sets a soft attach Boolean. Returns a pointer to the soft attach queue. Returns a pointer to cameras receieved data queue. Applies the cameras transform.
void
ProcessData
void
VMatrix4*
GetTransform
void
void
SetIsSoftAttached
bool bIsAttached
Queue<VMatrix4>*
GetSoftAttachQueue
void
Queue<Transmissible*>*
GetCameraEvents
void
void
ApplyCamera
void
Module Author Joel Faiella
115 | P a g e
Input
Description The Input class possesses a queue that is directly accessed by the UserState contained in the UserControl class in order to gain the current input. The user input is pushed on the queue during the execute phase. There is also an action map stored within the input wrapper that translates the data based on preset user input preferences before it is pushed on the queue. Functions Return Queue<InputEvent*>*
Name GetInputQueue
Parameters void
Description Returns a pointer to the input queue, allowing the user states to hook up to this class and retrieve input when they are enabled. Starts the program and initializes any memory that is used. Moves all input data into the queue and processes any pending input. Shuts down the file and deinitializes any data. Processes the data in received data queue. Sets the window.
void
Initialize
void
void
Execute
void
void
Shutdown
void
void
ProcessData
void
void
SetWindow
W32Window *pWindow int state
void Module Author Robert Barnette
SetCurrentState
Sets the game state.
116 | P a g e
CinematicState
Description CinematicState is one of the possible states that the UserControl class can assume. The cinematic state stores a sequence of actions per each actor in the current scene. When an cinematic event is triggered in-game, the UserControl switches to the CinematicState and locks input for the user. The CinematicState then begins feeding actions to all of the actors in the scene via the Sender interface, emulating a cut scene. Functions Return void
Name Initialize
Parameters void
Description Initializes the state and prepares it for utilization. Plays the cinematic and is responsible for sending actions to the camera and the player. Clears the cinematics local data.
void
Execute
void
void
Shutdown
void
Module Author Dan Southard
117 | P a g e
ProfileMenuState
Description At this menu, the user is able to select a profile to load, create a new profile, and delete old profiles. When a selection is made from this menu, the I/O module is notified and a new profile is created/loaded/deleted from disk. Functions Return void
Name Initialize
Parameters void
Description Initializes data that the class needs in order to run. Uses data sent to update the state the user is in on the menu. Frees any memory that may have been allocated during the life of the class. Parses data sent to it from other classes so it can be used.
void
Execute
void
void
Shutdown
void
void
ProcessData
void
Module Author Rory Collins
118 | P a g e
GameState
Description Gamestate contains any data needed for the game to be played. It contains information on the location of the player, profile data, and transforms of the camera. From here the user would interface with the camera and player character, and would interact with the game world. Functions Return void
Name Initialize
Parameters void
Description Initializes data that the class needs in order to run. Updates relevant game data such as the player and camera positions. Frees any memory that may have been allocated during the life of the class. Processes data from the received data queue. Handle input. Resets the game variables. Update the players variables. Win the game! Lose the game! aw
void
Execute
void
void
Shutdown
void
void
ProcessData
void
void void
ReceiveInput Reset
void void
void
UpdatePlayer
void
void void Module Author Robert Barnette
Win Lose
void void
119 | P a g e
PauseMenuState
Description The state that manages the submenu of GameState when the player pauses the game. It contains information about the current state of the menu, such as the users selection. PauseMenuState would be accessed when the player presses the pause button. Functions Return void
Name Initialize
Parameters void
Description Initializes data that the class needs in order to run. Updates menu information such as the currently selected menu options. Frees any memory that may have been allocated during the life of the class.
void
Execute
void
void
Shutdown
void
120 | P a g e
PrimaryMenuState
Description This menu represents the primary main menu seen by the user at application startup. It is the main hub by which all other game menu components are accessed. Options such as the ProfileMenuState, options menu, and start game would be accessed here. Functions Return void
Name Initialize
Parameters void
Description Initializes data that the class needs in order to run. Updates menu information such as the currently selected menu options. Frees any memory that may have been allocated during the life of the class. Processes data from the receive data queue. Handles input. Reset the menu states variables.
void
Execute
void
void
Shutdown
void
void
ProcessData
void
void void
ReceiveInput Reset
void void
121 | P a g e
Menu
MenuControl
Description This interface is the base class for all controls that are involved with the menu. It contains the base function set required by all menu objects in the hierarchy. It performs no useful functions, and cannot be placed directly into the menu system. Derived types inherit from this interface as to streamline data management and MenuControl passing in the actual menu system. Functions Return int
Name GetControlType
Parameters void
void
Update
void
Description Accessor for the type of control that is currently deriving from the base object. Pure Virtual function. Overriden in the child class if the specified control requires an update.
122 | P a g e
Container
Description The Container interface grants the ability for a MenuControl to contain a list of sub-controls within itself. The additional functions gained through inheritance are aimed at managing, adding, and deleting controls from the container. Functions Return void
Name AddControl
Parameters MenuControl* pControl
Description This allows you to add a control to your container. This allows you to remove a specific control from your container. This allows you to remove a specific control out of the queue based on the address passed in. Get control will return the specific control out of the queue based on an index passed. Updates all of the contained controls.
void
RemoveControl
MenuControl* pControl
void
DeqeueControl
MenuControl* pControl
MenuControl*
GetControl
int nIndex
void
ProcessControls
void
void
Clear
void
Clear deletes all existing controls in the container.
123 | P a g e
Image
Description A panel that displays a texture on a quad. Functions Return void
Name SetImage
Parameters int nID
Description Will set the Image to an ID specific to this image. Will return the specific Image ID
int
GetImage
void
124 | P a g e
Image List
Description The Imagelist is derived from the Image class, and overloads the default behavior of image by adding an array into the operation. Now you can pick the current image off of a list of images. This is useful for setting a particular state based on the image necessary to convey the state. An example, buttons would possess two states, a pressed and depress state, which would be represented by an imagelist. Functions Return int
Name GetNumImages
Parameters void
Description Will return the total number of images in the array. Sets an image based on the index and the ID. Will get the image in the array based on the index passed in. Will set the current background of the Image based on the index.
void
SetImage
int nIndex, int nID
void
GetImage
int nIndex
void
SetCurrentlyDisplayedImage
int nIndex
125 | P a g e
2DAnimation
Description The 2dAnimation class derives from the ImageList class, but overloads the functionality somewhat by flipping between each image at a regular interval. It also works similarly to the component model by storing the float pointer to the global time. That way, all of the interfaces don't have to be dirtied by the excessive and needless float passing when this class is the only one that needs time factored into its update. Functions Return Void Const Float*
Name SetTime GetTime
Parameters Const float* Void fTime
Description Sets the length of the animation Returns the length of the animation.
Void Float
SetSpeed GetSpeed
Float Void
fTime
Sets the speed of the animation. Returns the speed of the animation Updates the animations time, frames, and speed.
Void
Update
Void
PictureBox
Description This class utilizes the functionality of a panel with the addition of a background image. It derives from the Panel class and the Image class in order to gain this functionality. It is functionally no different from the Panel class. Functions Return void
Name Update
Parameters void
Description Updates the panel and all controls contained within.
126 | P a g e
Interactive Control
Description The Interactive Control class denotes that this control can be interacted with by the user. It serves as a base class that all interactive controls derive from. It contains a pure virtual function called Activate which derived controls will override with their own specialized behaviors. Interactive Control also has a value variable whose purpose is dictated by a derived control, for example a buttons value would either be on or off. Functions Return int void void
Name GetValue SetValue Activate
Parameters void int nValue void
Description Returns the value of the control. Sets the value of the control. A pure virtual function that derived classes will override with their own specialized behaviors.
127 | P a g e
Progress Bar
Description Progress Bar is derived from both InteractiveControl and ImageList. What separates Progress Bar from any other InteractiveControls is the way it overloads its Activate function. When activated, Progress Bar will perform functionality related specifically to providing a visual representation of progress. Progress Bar uses the functionality inherited from ImageList to visually demonstrate progress. Progress Bars will most commonly be used to represent loading bars in our game. Functions Return void
Name Activate
Parameters void
Description Performs the functionality related specifically to representing progress on a bar.
Pressable Button
Description Pressable Button is derived from both InteractiveControl and ImageList. What separates Pressable Button from any other InteractiveControls is the way it overloads its Activate function. When activated, Pressable Button will perform functionality related specifically to a button. Pressable Button uses the functionality inherited from ImageList to visually demonstrate the fact that it has been pressed. Pressable Buttons will most commonly be used to transition from menu related states. Functions Return void
Name Activate
Parameters void
Description Performs the functionality related specifically to a button, changing states for example. Update the button. Check for intersection.
void bool
Update PointIntersect
void int nXPos, int nYPos
void
ProcessData
void
Processes the data from received data queue.
128 | P a g e
Slider
Description Slider is derived from both InteractiveControl and ImageList. What separates Slider from any other InteractiveControls is the way it overloads its Activate function. When activated, Slider will perform functionality related specifically to a sliding bar. Slider uses the functionality inherited from ImageList to visually demonstrate the fact that a slider is moving along a bar. Sliders will most commonly be used to modulate both volume and gamma. Functions Return void
Name Activate
Parameters void
Description Performs the functionality related specifically to a Slider, changing the games music volume for example.
129 | P a g e
Memory Map
This memory map outlines the total memory usage expected at runtime. RAM usage is based in loading assets and holding CPU side game data. VRAM data is mostly texture and model data, with some shader code and material data for lighting calculations. RAM(128MB) 2MB executable 64MB level data 16KB scripting data 2MB object blueprints 2MB animation data 4MB gameplay assets 38MB threading 4MB sound banks VRAM(256MB) 12MB model data 24MB texture data 32KB shader code 2MB material data
Total RAM: 116MB, 64KB Total VRAM: 38MB, 32KB
Code Review Plan

Code reviews will happen after the implementation of each core system as described by tasks in the approved schedule. This initial review will be done by someone other than the module author who is familiar with this system and how it should be implemented. If there is no one close to the system, a relevant lead will perform the review. The purpose of the initial review is to make sure that the component is functional and is properly integrated with the main code base. On the first day of code freeze, which occurs 3/4 of the way into the current milestone, the team as a whole performs a comprehensive review of the entire code base and its functionality compared to the previous integration in order to ensure that the previously reviewed systems are still functional alongside the newly created systems. Modules will be reviewed for coding convention standards, commenting and documentation, and whether or not the system abides by the description set down in the tech document. 130 | P a g e
Integration Plan
Alienbrain will be our source control of choice on this project to help maintain code concurrency and unification. Interfacing with source control will follow a specific rule set outlined here. Team members are allowed to check out as many files as necessary to complete their assigned task. No one is allowed to check out a file that is already checked out by another team member. Checkout and Checkin comments will be enforced for major changes, such as new functionality added to the pre-existing base. No member of the team is allowed to leave a meeting with a file checked out. Members may check out files after returning home from a meeting and may resume work at home. Integration is allowed for components that are functional in a local test application or base. No compiler errors and warnings will be tolerated for submission. Integration will be handled by the relevant lead after a component is completed and reviewed according to the Code Review plan. Time will be allotted on the schedule to the relevant leads to allow for integration time. When a critical error is found in the current build, the entire team will be notified of the error. If the error is identified outside of a meeting, it will be discussed immediately at the next meeting. All relevant development on the current code base will halt, and attempts to solve the problem will be made by any team member working on code relevant to the error. Within the time frame of one meeting after the identification of the critical error, if the error cannot be resolved, then a rollback to the previous working version will be called for.
131 | P a g e
Testing Plan
Our internal producer/quality assurance lead will handle management of the bug database for our team. He will assign quality assurance tasks to team members based on bug classification and relevant team members. For example, bug relating to loading code will be distributed to the tech team based on availability. As bugs are identified, they will be added to the database of bug reports, and a weekly bug review will be performed by the quality assurance lead. Bugs will be addressed based on priority. Critical bugs will be worked on immediately, while less-critical bugs will be resolved during code freeze. Rank A bugs will be worked on until resolved. Rank B bugs will be worked on for three to five days at a maximum. Rank C bugs will be pushed off until the polish stage.
Rank A Behaviors that limit the functionality of the engine and hinder development and testing. Ex: Crashes or buggy assets Rank B Instances where systems are not behaving properly and require further inspection. Ex: Erroneous physics or collision checks Rank C Aesthetic bugs or errors that have no impact on game play. Ex: Missing textures or glitchy lighting
132 | P a g e
Game Folder Hierarchy
133 | P a g e
134 | P a g e

Razing Ancients Game Bible

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Razing Ancients Game Bible

Uploaded by

Copyright:

Available Formats

Duck `n Cover Productions

Brian Sorin Internal Producer

Brian Goodsell Lead Artist Grant Landreth Lead Programmer

Production Document ............................................................................. 3

Technical Document ............................................................................. 61

Duck N Cover Productions

Apt. 2766 Winter Park, FL. 32792

Hours Worked per Week

Month One and Two

Month Three, Four, and Five

23 184 % January Work

124 992 Totals

Project Team Total (Hours) Project Team Total (Work Days)

When Things Go Wrong

External Art/Sound Directors

Technical Development Team 2 Members

Gameplay Development Team 2 Members

Quality Assurance Team Floating Members

Modeling Development Team 2 Members

Environment al Development Team 2 Members

The Project Team

Internal Producer (IP) Brian Sorin

Programming Lead (PL) Grant Landreth

Technical Lead (TL) Dan Southard

Gameplay Lead (GL) Joel Faiella

Programmers Nick Faletra, Ryan Raye, Rory Collins, Robert Barnette

Art Lead (AL) Brian Sparky Goodsell

Modeling Lead (ML) Brian Hong

Environmental Lead (EL) Caryn Cook

Testing Lead (QAL) Brian Sorin

Testers The Project Team

External Producer (EP) Don Smith

Keyboard/Mouse Remapping Default Controls 360 Controller Remapping Default Controls

Menu Interface Flow

Credits and Exit

360 Controller Input

How the Player Marks Progress

Detailed Design Breakdown

Loading Screen Help Information

Music Sound Effects Default Accept/Cancel

Gamma Default Accept/Cancel

Controls Mapping Default Accept/Cancel

Credit Sequence Return to Menu

Game Flow Chart

Level One and Two

Opening Level Cutscene

Level One and Two Flow

Player begins traversing the level

Player Progresses through Platforming Section

Player Progresses through Puzzle Area

Player Progresses through Transition Area

Transition to Next Level

Transition from Level Two

Opening Level Cutscene

Level Three Flow

Player begins traversing the level

Player engages the final boss Failure

Levels and Maps

Attributes (Global, For All Levels)

Player Spawn Count Exit Point Count

Environmental Interactions Behaviors

Enemy Spawn Points Enemy Spawn Point Count 0

Ambient Environmental Aspects/Objects in the Level