Discorder Project Plan

Project Plan Project: Discorder Author: Charcoal Productions

Version History Version Number 1.0 1.1 2.0

Date 14-09-17 15-01-09 15-04-17

Description Initial version; September submission First revision; January submission Final revision; April submission

Name Maryam Alam

Position Development Lead

Date 15-04-17

Justin LorangerAhluwalia

Game Design Lead

15-04-17

Marvelyn Milan

Artist

15-04-17

Andrew Richardson

Art Lead

15-04-17

Tyler Tremblay

Designer

15-04-17

Sign-Off Signature

Page | 1

Table of Contents Version History ............................................................................................................................................................................... 1 Sign-Off .......................................................................................................................................................................................... 1 Table of Contents ........................................................................................................................................................................ 2 Version Change Log ................................................................................................................................................................... 4 1. Introduction .............................................................................................................................................................................. 5 2. Requirements ............................................................................................................................................................................ 6 2.1 Core Requirements ........................................................................................................................................................... 6 2.1.1 Competitive Cooperation ....................................................................................................................................... 6 2.1.2 Triple Scoring System ................................................................................................................................................. 6 2.1.3 Obstacles .................................................................................................................................................................... 7 2.2 Stretch Requirements ....................................................................................................................................................... 8 2.2.1 Alternate Characters ................................................................................................................................................ 8 2.2.2 Multiple World Aesthetics......................................................................................................................................... 8 2.2.3 Tile-Based Race Randomisation ............................................................................................................................. 8 2.2.4 Coordination Bonuses .............................................................................................................................................. 8 3. Deliverables ............................................................................................................................................................................ 10 3.1 Final Deliverables ............................................................................................................................................................ 10 3.2 Course Deliverables ........................................................................................................................................................ 11 4. Tasks .......................................................................................................................................................................................... 12 4.1. Work Breakdown Structure ........................................................................................................................................... 12 4.1.1 Design ........................................................................................................................................................................ 12 4.1.2 Art ............................................................................................................................................................................... 13 4.1.3 Development ........................................................................................................................................................... 15 4.1.4 Promotional .............................................................................................................................................................. 16 4.2. Schedule .......................................................................................................................................................................... 17 4.2.1. Major Milestones ..................................................................................................................................................... 17 4.2.2. Gantt Chart and Critical Path ............................................................................................................................. 20 5. Resources ................................................................................................................................................................................ 21 5.1. Team Structure ............................................................................................................................................................... 21 5.1a Maryam Alam ............................................................................................................................................................... 21 Experience ......................................................................................................................................................................... 21 Roles .................................................................................................................................................................................... 21 5.1b Justin Loranger-Ahluwalia ........................................................................................................................................... 22 Experience ......................................................................................................................................................................... 22 Roles .................................................................................................................................................................................... 22 5.1c Marvelyn Milan .............................................................................................................................................................. 23 Experience ......................................................................................................................................................................... 23 Roles .................................................................................................................................................................................... 23 5.1d Andrew Richardson...................................................................................................................................................... 24 Experience ......................................................................................................................................................................... 24 Roles .................................................................................................................................................................................... 24 5.1e Tyler Tremblay ................................................................................................................................................................ 25 Experience ......................................................................................................................................................................... 25 Roles .................................................................................................................................................................................... 25 5.2 Hardware .......................................................................................................................................................................... 26 5.3 Software ............................................................................................................................................................................ 26 Page | 2

6. Risk Analysis ............................................................................................................................................................................. 27 6.1. Scope ............................................................................................................................................................................... 27 6.2. Difficulty ........................................................................................................................................................................... 27 6.3. Bottlenecking .................................................................................................................................................................. 28 7. Change Control Policy ......................................................................................................................................................... 29 7.1 Open Communication .................................................................................................................................................. 29 7.2 Versioning ......................................................................................................................................................................... 29 7.3 Physical Storage .............................................................................................................................................................. 29 8. Communication Policy ......................................................................................................................................................... 30 8.1 Team Communication ................................................................................................................................................... 30 8.2 Division Communication ................................................................................................................................................ 30 8.3 Conflict Resolution .......................................................................................................................................................... 30 9. Quality Control Policy ........................................................................................................................................................... 31 9.1 Team Communication ................................................................................................................................................... 31 9.2 Division Communication ................................................................................................................................................ 31 9.3 User Testing ....................................................................................................................................................................... 31

Page | 3

Version Change Log The following is a list of modifications that have been made to the document since its previous iteration:  Added various update notes  Updated schedule to reflect final development schedule

Page | 4

1. Introduction

On a distant world, there exists a game show that dares to ask: is it better to work with your comrades to achieve greater glory, or to stamp out your competitors so that you don’t have to share the bounty? This game is Discorder, a fast-paced paired footrace between mechanised athletes who must brave challenging obstacles, and work with or against their partner in facing them.

Discorder (a play on the words discord and order, two major themes of the game) is a time-trial puzzle/platforming game focused on the concept of competitive team-based play. Two players run through procedurally generated levels, attempting to reach the end as quickly as possible. Throughout the levels are various obstacles that require one player to remove the blockade. However, they may do so in a manner that is helpful, neutral, or hindering to the other player. Players are incentivised to outrun their opponent, while maintaining a low cumulative time.

This document contains the overall project plan of the development of this game, including the main project objectives, development breakdown and schedule, risk analysis, team structure, and management policies.

This is following the completion of the summer term and research phase of the project. As such, the plan has been adjusted to account for the progress and research discoveries made during that term.

Page | 5

2. Requirements 2.1 Core Requirements Core requirements are the main features of the game, to be included as a bare minimum for the completion of the project.

2.1.1 Competitive Cooperation Competitive cooperation is the core theme of Discorder, and stresses player choice in a multiplayer environment. It works on the principle that players participating in the game have both collective and personal goals and that the personal goals inform the collective in a manner that may make them conflicting.

In the scope of Discorder, the collective goal is for two player teams to traverse the race legs in as short a time as possible, while the personal goal is for each player to have the smaller percentage of time spent running the course (in other words, to be faster than the other player).

Throughout the courses, players have the option of helping their teammate through their obstacle in a manner that might help the team reach a higher collective score, but at the cost of giving their teammate a higher portion of the personal score. Alternatively, they may hinder the other player in some way which might allow them to beat their personal score, but at the cost of negatively impacting their scores overall.

Update: In the final version of the game, the terminology of competitive cooperation has been largely replaced with “competitive team-based play”. Fundamentally, this is the same as the description of competitive cooperation outlined above, but has altered terminology to avoid confusion with alternative notions of what is considered “cooperative play”.

2.1.2 Triple Scoring System As was mentioned, the game will operate on more than a single objective at a time. In reality, final scoring in the game will work on three different measures: team completion time, individual times, and each player’s “karma”. The team and individual times influence the final scores (on a ratio of 1/(individual time + total time)), while karma influences the dialogue presented to the player as a thematic component.

Team completion time is the collective score of the team, and is measured by the cumulative time spent by both players to traverse each race leg (i.e. if one player beats the leg in 2 minutes, and the other in 3 minutes, the total time for the leg is 2+3=5 minutes). How fast one player traverses the leg in relation to the other is irrelevant to this score. This can be considered the “cooperative” scoring value, and directly affects the scaling of the final scores. The smaller the collective time is, the larger the scale of the final scores.

Individual completion time is the time a single player took to complete the race. This value is independent of the collective time, but has an equal impact on the final scoring value. Therefore, a player that wishes to beat their race partner from a competitive standpoint must aim to have a lower individual completion time than them. A lower value in this field also directly correlates to a higher end score.

Final scoring values are combined values based on the total completion times of each player individually as well as the team completion time. Because the individual time is considered, this value is different for each player, and therefore indicates which player is the winner of the race from a competitive standpoint. However, Page | 6

because total time is also considered, the final scale of this value is improved the faster both players are together.

The logic of the final score can be equated to a pot that is distributed between both players. The size of the pot is proportional to the performance of both players together, while the distribution of that pot is based on the relative contributions of each player.

Karma measures how each player behaved towards their teammate during the run. Making choices that help the other player or reinforce cooperation increase a player’s “good” karma, while making choices that hinder the other player and promote personal gain over team gain increase a player’s “negative” karma. The final proportion of the two for each player shows if they were more cooperatively, neutrally, or competitively inclined.

Karma provides an additional social dynamic to the game, as the player’s respective karma are reflected in the flavour dialogue played throughout the race. This can inform other player’s choices, and therefore forces players to be aware of the karmic repercussions of their choices, lest they be marked as a vulnerable target or a chronic backstabber by other players. During the course of a race itself, this can impact how the other player might make their choices: a player that has been given a shove by their race mate might be inclined to do the same to them when they get to make their choice.

2.1.3 Obstacles Obstacles encountered in the game will be numerous and varied, as will the means in which they can be responded to. Sessions of the game will be performed through individual legs, which consist of a path with a single obstacle. These obstacles may be something as simple as a series of floating platforms or as complex as a set of oncoming vehicles.

Legs are designed so that the choice player will always be able to make their choice well before their running partner has a chance to reach the obstacle (though if they do reach the obstacle first, it will be set to a passable state; in which case the choice track player has effectively forfeited their choice through inaction).

The choice that is made is between helping the other player positively (in some way making the obstacle easier for them to traverse) or negatively (in some way making the obstacle more difficult or punishing to traverse). Regardless of the choice taken, both players will be able to make it to the end of the leg. The only bearing the obstacles have will be in terms of time spent. In the event that a player takes more than four minutes to complete a leg, the timer will trigger an automatic leg completion, so as not to prevent the game from continuing as a result of one player getting stuck. This failsafe is indicated by the timer changing colour at the 3:30 mark.

Ultimately, both player tracks (the choice track and obstacle track) will be balanced to have an approximately equal base duration, with an approximately equal level of difficulty as any other track, so that no distribution of obstacles will favour one player over the other. Players will also have an equal number of opportunities to be the one making the choice and the one traversing the obstacle. This balance is a crucial component of maintaining the fairness of the game.

Page | 7

2.2 Stretch Requirements Stretch requirements are optional features that are not planned for the core game, but plotted as potential expansions should development remain on schedule. These tasks will not be considered for implementation until the core elements are complete

2.2.1 Alternate Characters Players can choose from different characters, such as a fast but fragile robot or a slow but resilient robot to run the race with rather than just the default character.

Update: As of the final build, this stretch feature has been discarded. There is only one base character in the game.

2.2.2 Multiple World Aesthetics Due to the modelling overlay hierarchy used for the aesthetic of the game, races and obstacles exist independently of their aesthetic. This stretch goal will capitalise on that fact by including multiple alternate world “skins” to each race beyond the default, allowing them to run on diversified fields like space or desert, or even have the race aesthetic randomised from leg to leg.

Update: As of the final build, there are four world aesthetics (urban day, space, desert, and urban night), and each leg is set in one of these four aesthetics (all legs aside from the tower, pistons, and roulette scenes have alternate urban aesthetics, though these only exist within the Unity project and not the actual build of the game).

2.2.3 Tile-Based Race Randomisation As the race is composed of many individual obstacle tiles (called “legs”) that exist independently of each other, the order and selection of legs used may be randomised for each race. A single race must have a minimum of four legs (two obstacles per player), but the pool of legs from which these would be drawn and the order in which they appear is unbound.

An additional stretch component of this requirement is to produce more than the minimum number of legs, so that obstacles are reused as rarely as possible in order to maximise replayability.

Update: As of the final build, there are six legs, four of which are chosen at random (without repetition).

2.2.4 Coordination Bonuses In addition to obstacles, levels will each be separated with a brief period of interaction between the players.

These moments will require that each player chose an action to perform towards the other player. This action might be cooperative (a handshake), offensive (a punch), or defensive (a block). Depending on what actions are taken by each player, a small bonus or deduction is made to their final score.

If both players chose the same action, the effect will be equally distributed to both players (a benefit if both players chose cooperation, a penalty if both chose offensive, and no effect if both chose defensive). If both players choose different actions, the effects will be applied accordingly in a rock-paper-scissors manner Page | 8

(offensive beats cooperative, defensive beats offensive, and cooperative beats defensive), in which case the loser will suffer a penalty and the winner a benefit.

In addition to distribution, the scale of the benefit or penalty will vary based on the timing of both players in performing their actions. The closer players are to synchronising their actions, the greater the effect will be, while uncoordinated actions will be less effective. This encourages players to communicate, which also gives them an opportunity to gauge their teammate’s action or even try and convince them to choose a certain action.

Update: As of the final build of the game, this stretch feature has been dropped. There is only a direct transition from leg to leg once both players finish.

Page | 9

3. Deliverables 3.1 Final Deliverables The following items will have been provided by the end of the project. These will be provided as over the course of development and completion.

Discorder Game As a final deliverable of the project, a fully functional completed version of the game Discorder will be provided. Throughout the development of the game, additional versions, such as the alpha and beta builds, will also be provided as a means of demonstrating progress.

Source Code In addition to the final game, all source code for the game will be fully commented, stored and provided through a common storage and versioning system (Bitbucket). This will include incremental version of the source code as the project is in development, and change logs of major alterations to the code.

Art Assets All graphical and audio assets used in the making of the game, including but not limited to concept art, audio captures (folio and dialogue), models, textures, matte paintings, and animations will be provided through a common cloud storage repository (Google Drive).

Design Documentation All documentation pertaining to the conceptualisation, design, and management of the project will be provided through a common cloud storage repository (Google Drive), or delivered by email to relevant recipients as needed.

Research and Testing Documentation All research gathered over the course of the project, including any major user testing or bug reports, will be provided through a common cloud storage repository (Google Drive).

Website A fully operational website for the project, including a means to access the game (upon the game’s completion), information about the game and the development team, and promotional material for the game, will be provided as an online deliverable. If required, source code and all required files for the website may also be provided.

Promotional Media All promotional media created for the project, including posters, teaser images, a trailer, promotional model, and physical promotional material (such as business cards, pins, t-shirts, etc.), will be provided through relevant channels as required.

Page | 10

3.2 Course Deliverables The following is a list of deliverables that will be provided as part of the Senior Project deliverable requirements.

These deliverables are based on the information provided in the 2014-2015 Senior Project Course Outline.

Research Presentation (September) (Complete) A presentation summarising progress achieved with regards to project research conducted over the summer.

Project Plan (and Presentation) (September) (Complete) This document, including project objectives, tasks, schedule, milestones, risk analysis, team structure and task distribution, management policies, and other pertinent information.

Peer Evaluation #1 (September) (Complete) Individual evaluations of the team from each of the members.

Project Plan Revision (December) (Complete) A revised version of this document with appropriate changes given the project’s development.

Design Document (January) (Complete) A preliminary design document for the project.

Peer Evaluation #2 (January) (Complete) An updated set of individual evaluations of the team from each of the members.

Project Progress Presentation (January) (Complete) A presentation including the updated Project Plan, the Design Document, examples of developed assets, and other evidence of progress.

Project Fair Plan (February) (Complete) A plan for the project fair display and presentations.

Project Trailer (March) (Complete) A project trailer along with relevant promotional material.

Project Fair (April) (Complete) A setup and presentation demonstrating the completed project.

Peer Evaluations #3 An updated set of individual evaluations of the team from each of the members.

Project Closure A full submission of the Project Plan, Design Document, Final Report, and Project Materials (as listed in section 3.1 of this document).

Page | 11

4. Tasks The following indications mark special tasks: (Stretch): This task has a core minimum for completion as well as an optional component that may be repeated later in development (Optional): This task is entirely optional and may be discarded if necessary ***: Denotes a task that has encountered issues that may skew duration values (Added): This is a task that was added to the development schedule following feedback

4.1. Work Breakdown Structure 4.1.1 Design Obstacle Design (Stretch)    

Conceptualise Obstacle: Come up with a premise for an obstacle o Duration: 1 day (each) Conceptualise Obstacle Variations: Devise means by which morality choice alters the obstacle o Duration: 1 day (each) Plan Obstacle Layout: Design and draw/visualise the leg layout with obstacle o Duration: 2 days (each) Choice Obstacles (Added): Design and implement the obstacles on the choice tracks o Duration: 2 days

Narrative Design   

Conceptualise Story: Come up with overall premise for game narrative and integration into the plot o Duration: 1 week Design Characters: Conceptualise and develop characters for narrative relevance and visual design o Duration: 1 week Conceptualise Character Dialogue: Devise and write all dialogue for the game and the circumstances in which they are triggered o Duration: 2 weeks

UI/UX Design  

Conceptualise UI/UX Architecture: Devise the structure of the game menus and HUD o Duration: 2 days Conceptualise UI/UX Layout: Design the visual design for the game menus and HUD o Duration: 3 days

Page | 12

4.1.2 Art Character Assets (Stretch)* Create Character Concept Art: Draw concept art and orthographic sketches of the character o Duration: 1 week  Create Character Model: Model the character in the form that is ready for use in rigging, weight painting, UV mapping, and animating o Duration: 3 weeks***  Rig Character: Rig the model of the character o Duration: 1 week  Weight Paint Character: Add weight painting to the character model o Duration: 3 days  UV Map Character: UV map the character model o Duration: 3 days  Create Basic Character Animations: Create the basic animations for the character, such as walking, running, jumping, and being stunned o Duration: 2 weeks  Create Coordination Action Character Animations (Optional): Produce additional animations for the special interactions included in the coordination actions o Duration: 1 week *Some of these steps may be shortened or removed for new characters in the event that they are built off of pre-existing models. 

Environment Assets (Stretch)  



   

 

Create Environmental Concept Art: Conceptualise and draw the aesthetic plans for the environment o Duration: 1 week Create Obstacle Concept Art: Conceptualise and draw the aesthetic and plans for the race obstacle, with consideration for functionality o Duration: 1 week Create Environmental Models: Model the required assets for the environment, including reusable components o Duration: 1 week Create Obstacle Models: Model the race path and obstacle without environmental overlay o Duration: 1 week Implement Obstacle Animations: Animate obstacles and path where relevant o Duration: 2 weeks Implement Environmental Texturing: Texture the environmental models o Duration: 1 week Implement Environmental Obstacle Overlay: Plan the layout of the environmental models to appear as an overlay to the race path and obstacle o Duration: 1 week Implement Ambient Animations (Optional): Add ambient environmental animations where applicable o Duration: 3 days Implement Ambient Effects (Optional): Add ambient special effects and filters where applicable o Duration: 3 days

UI/UX Assets 

Conceptualise UI/UX Art: Create concept art planning out the visual design of the menu and HUD (in conjunction with conceptualising UI/UX layout) o Duration: 3 days Page | 13

 

Create Menu Assets: Produce graphical assets and animations for use in the menu aesthetic design o Duration: 3 days Create HUD Assets: Produce graphical assets and animations for use in the menu aesthetic design o Duration: 2 days

Audio Assets  

  

Record Foley: Record foley for use as sound effects in the game o Duration: 3 days Record Dialogue (Stretch): Record the audio for character dialogue (this task is largely performed externally, but requires review from the team) o Duration: 3 days Master Foley: Edit and master foley into usable sound effects and assets o Duration: 1 week Master Dialogue (Stretch): Edit and master recorded dialogue for final implementation o Duration: 1 week Collect Music: Retrieve appropriately licensed music for use in the game o Duration: 1 week

Page | 14

4.1.3 Development Networking 



Establish Local Networking: Implement the functionality for two players to play the game on a local network simultaneously and affect each other o Duration: 4 weeks*** Establish Online Networking (Optional): Implement the functionality for two players to play the game together via an internet connection o Duration: 2 weeks

Player Movement 





Implement Player Boost: Implement functionality to affect the player’s speed and movement under specific circumstances o Duration: 1 week Implement Player Stun: Implement functionality to stop player movement under specific circumstances (and include stun animation consideration) o Duration: 2 days Variable Speed: Implement a variable speed for the player based on acceleration o Duration: 2 days

Scoring  



Establish Time Score: Implement scoring functionality to account for player traversal time o Duration: 1 week Establish Concurrent Scoring: Implement scoring functionality to account for individual player traversal time and player time relative to cumulative time o Duration: 2 weeks*** Establish Moral Choice Scoring: Implement scoring functionality to account for choices made by each player throughout the race and cumulative moral score o Duration: 1 week

Asset Implementation (Stretch)  

Implement Graphical Assets: Add graphical assets for characters and environments to the game o Duration: 1 week Implement Audio Assets: Implement audio assets for music, sound effects, and dialogue into the game o Duration: 1 week

UI/UX Development  



Develop Menu Structure: Set up the programmatic structure of the menu component of the game o Duration: 1 week Develop HUD Structure: Set up the programmatic structure of the heads-up display component of the game o Duration: 3 days Implement UI Assets: Add UI graphical and audio assets into the game o Duration: 2 days

Optional Features (Optional)  

Coordination Action: Add coordination action event with appropriate triggers in between race legs o Duration: 2 weeks Alternate Character Selection: Implement ability to select different characters with different functionalities o Duration: 3 days

Page | 15

4.1.4 Promotional Website 

 

Conceptualise Website Structure: Plan the general architecture and visual layout of the promotional website o Duration: 2 days Develop Website Structure: Implement the website plan into a functional skeleton website o Duration: 1 week Add Content To Website (Stretch): Add graphical and promotional content to website o Duration: 1 week

Trailer 

 

Conceptualise Trailer: Plan the general progression and cinematography of the trailer, accounting for required assets o Duration: 2 days Record Trailer: Produce and render the raw trailer footage o Duration: 3 days Master Trailer: Edit the raw footage and include relevant items to create the final trailer o Duration: 1 week

Poster(s) (Stretch) 



Conceptualise Posters: Plan the layout and design of the promotional poster(s), accounting for digital and physical versions o Duration: 2 days Create Posters: Implement the planned poster(s) and create required physical and digital copies o Duration: 3 days

Physical Materials (Stretch) 



Conceptualise Physical Materials: Consider and plan all other physical promotion materials such as shirts, magnets, pins, and trinkets, and prioritise them according to relevance and feasibility o Duration: 2 days Create Physical Materials: Produce or commission physical materials as needed o Duration: 3 days

Page | 16

4.2. Schedule In order to maximise practical scheduling, the project is planned on a twice-a-month milestone system.

Minimum requirements of tasks are scheduled for deadlines in the middle of the month and end of the month.

These tasks respect the overall schedule structure outlined in the original project plan, with deviations occurring only in task duration and dates (the relation between tasks for prerequisites remains unchanged). More specific scheduling of sub-tasks is handled on a case by case basis, to better reflect the current project situation and account for non-linear task breakdowns that occur at the micro-task level.

4.2.1. Major Milestones Green denotes tasks that are on schedule Red denotes tasks that have encountered complete or partial delays Orange denotes tasks that have been shifted back as a result of delays in prerequisite tasks Purple denotes tasks that were dropped from development Blue denotes tasks that were added to the development schedule

September   



Networking: Two players can play a single race simultaneously on different computers via a network connection, and can interact with each other in real time Default Character Model: The main player character (a base used for both players) is fully modelled and rigged Preliminary Obstacle Plans: A set of at least four obstacles are completely designed and ready to be pushed to modelling and implementation, including the modifications that occur based on player choice UI Architecture: All menus and HUD architecture is planned

October     

Concurrent Two-Player Race: Two players can play a single race and have their respective scores and choices tied to themselves independently First Obstacle: The first obstacle is modelled and has relevant animations Default Level Assets: The environmental and overlay models and assets are complete Text/Dialogue: All menu, game, and character text/dialogue is complete and ready for recording where applicable UI Plan: All menus and HUD visual layout and design is planned and ready for implementation

November    

Menu and Game Flow Code: Basic menu, win and failure states, and other in-game transition sequences are implemented, so that the game is functionally fully playable Obstacle-Specific Assets: Assets specific to the first created obstacle are complete Foley: All base Foley audio is recorded, mastered, and ready for inclusion in the game HUD UI: All HUD menu assets are complete and ready for implementation

December       

Model Implementation: All created models and assets are put into game Secondary Character Models: All secondary character models are complete Dialogue: All character preliminary dialogue is recorded Menu UI: All menu assets are complete, including transition animations Second Obstacle: The second obstacle is modelled and has relevant animations Project Plan: Project Plan is revised for re-submission Design Document: A fully formatted design document is created for submission Page | 17

End of Fall 

Beta: A fully functional moderately polished (demo) version of the game with two complete legs of a race (Note: a full race has a minimum of four legs)

January 



Mid-January o Networking: Two players can play a single race simultaneously on different computers via a network connection, and can interact with each other in real time o Concurrent Two-Player Race: Two players can play a single race and have their respective scores and choices tied to themselves independently o Beta: A fully functional moderately polished (demo) version of the game with two complete legs of a race (Note: a full race has a minimum of four legs) o Project Progress Presentation: A report on the progress of the project, including re-evaluation of these milestones, is complete and presented Late-January o First Obstacle: The first obstacle is modelled and has relevant animations o Obstacle-Specific Assets: Assets specific to the first created obstacle are complete o Website Design Concept: A conceptual design for the promotional website is created o Early Marketing: Preliminary marketing efforts including screenshots and early game assets are created o User Testing (Stretch): The Beta (and subsequent versions) of the game is tested with users to identify and remove any usability issues and bugs o Foley: All base Foley audio is recorded, mastered, and ready for inclusion in the game o Game Soundtrack: Initial research complete o Third Obstacle: The third obstacle is modelled and has relevant animations o Additional Obstacle Plans (Stretch): Additional obstacles are designed and ready to be pushed to modelling and implementation; this task may be repeated ad infinitum

February 



Mid-February o Project Fair Plan: A plan for the project fair is complete and submitted o Dialogue: All character preliminary dialogue is recorded o Early Marketing: Preliminary marketing efforts including screenshots and early game assets are created o HUD UI: All HUD menu assets are complete and ready for implementation o Second Obstacle: The second obstacle is modelled and has relevant animations Late-February o Default Character Model: The main player character (a base used for both players) is fully modelled and rigged o Secondary Character Models: All secondary character models are complete o HUD UI: All HUD menu assets are complete and ready for implementation o Game Soundtrack: Initial research complete o Game Soundtrack: Complete and implemented o Menu UI: All menu assets are complete, including transition animations o Third Obstacle: The third obstacle is modelled and has relevant animations o Project Fair Plan: A plan for the project fair is complete and submitted o Fourth (+) Obstacle (Stretch): The fourth obstacle is modelled and has relevant animations; following this, subsequent levels may be created as stretch-goals o Alternate Level Aesthetics (Stretch): Alternative environmental and overlay models and assets are complete; following this, subsequent level aesthetics may be created as stretch-goals Page | 18

March 



Mid-March o Foley: All base Foley audio is recorded, mastered, and ready for inclusion in the game o Menu UI: All menu assets are complete, including transition animations o Second Obstacle: The second obstacle is modelled and has relevant animations o Game Soundtrack: Complete and implemented o Third Obstacle: The third obstacle is modelled and has relevant animations o Fourth Obstacle: The fourth obstacle is modelled and has relevant animations; following this, subsequent levels may be created as stretch-goals o Project Trailer: A project trailer and promotional image for the game are created and made available for distribution o Website: A full version of the promotional website for the game is complete o Additional Dialogue Mastering: All recorded dialogue mastered and implemented o Project Fair Plan: A plan for the project fair is complete and submitted o Alternate Level Aesthetics (Stretch): Alternative environmental and overlay models and assets are complete; following this, subsequent level aesthetics may be created as stretch-goals o Additional Obstacle Plans (Stretch): Additional obstacles are designed and ready to be pushed to modelling and implementation; this task may be repeated ad infinitum Late-March o User Testing (Stretch): The Beta (and subsequent versions) of the game is tested with users to identify and remove any usability issues and bugs o Additional Obstacle Plans (Stretch): Additional obstacles are designed and ready to be pushed to modelling and implementation; this task may be repeated ad infinitum o Fifth Obstacle: The fifth obstacle is modelled and has relevant animations o Sixth Obstacle: The sixth obstacle is modelled and has relevant animations o Alternate Level Aesthetics (Stretch): Alternative environmental and overlay models and assets are complete; following this, subsequent level aesthetics may be created as stretch-goals o Complete Project: All final game and project components complete and packaged for final submission o Variable Speed: The character moves based on acceleration, rather than a fixed movement velocity o Choice Track Obstacles: All choice tracks in the game feature minor obstacle challenges o Alternate Player Characters (Stretch): Alternative playable characters with unique traits and statistics are modelled, animated, and implemented o Coordination Action Mechanic (Optional): Planned, animated and implemented o Additional Dialogue (Stretch): Additional dialogue recorded; following this, further dialogue may be recorded as stretch-goals o Additional Dialogue Mastering: All recorded dialogue mastered and implemented

April 

Mid-April o Project Fair: All necessary equipment and setup for project fair presentation complete o Complete Project: All final game and project components complete and packaged for final submission

Page | 19

4.2.2. Gantt Chart and Critical Path Due to the shift in schedule structure towards a milestone-centric system, the specific duration of individual tasks is less closely monitored for the purpose of scheduling. Therefore, the Gantt Chart and Critical Path have been removed to avoid confusion. It should be noted that while the date scheduling of these components is no longer accurate, the overall task breakdown and hierarchy remains accurate, and the general task estimates remain relatively close to their originally conceptualised periods, with the exception of certain tasks that were partially delayed due to technical challenges. These components may be viewed in the previous version of this document, and the Gantt Chart with full breakdown may be viewed here.

Page | 20

5. Resources 5.1. Team Structure The Charcoal Productions team consists of five members. Each member is a student of the IMD program and as such possesses skills and experience in all fields relevant to the development of this project. However, to enhance team efficiency, each member will primarily work on a set of specific aspects of development. These aspects are collected into divisions, which are comparable to departments of a more formal game company.

These consist of Game Design (conceptualising game mechanics, features, and narrative, maintaining a coherent design for the game overall), Development (programming, game mechanic implementation), Art Design (concept art, asset creation, animation, sound design, theming), and Promotion (marketing, website design, presentation).

Work on the game will be compartmentalized and distributed according to their division, and each division will be managed by a “Lead�, who will act as primary records keeper and manager for their division. Project management will be handled by collectively gathering this information through regular meetings and communication, and will account for any tasks relevant to the project as a whole or to matters too large for the division itself to handle.

Update: More specific outlines of tasks undertaken by each team member can be found in the Project Closure document.

5.1a Maryam Alam Experience Maryam has extensive experience with web development and design and programming in several contexts.

She is passionate about web design and has explored development through HTML5, CSS3, JavaScript and PHP. By implementing these skills in many projects in the IMD program, as well as during her work with the Ministry of Environment, she has learned how to adapt to each situation and solve problems actively and preventatively.

These skills will allow Maryam to promote the game by designing and coding a website to showcase the project. Maryam is also adept at programming in several languages, including C++ and C#. She has led several projects with a core programming role and will act as the development lead.

Roles Development Lead As the lead developer on the project, Maryam will be responsible for the bulk of the game’s programming. She will be responsible for ensuring consistency and functionality within the project code, and will contribute to its development in all fields.

Promotion Maryam will assist with the promotional aspect of the project primarily through development and maintenance of the project website.

Page | 21

5.1b Justin Loranger-Ahluwalia Experience Justin has worked extensively in project management and design, having led several projects through his time in BIT. In addition, his work on documentation and records with QNX and the Ottawa Hospital have given him further insight with regards to effective records-keeping and scheduling, while his time working at Carleton University has given him experience in developing both in a team and individually. Justin has a passion for game design, and as such will act as manager of the team and design lead for the project. He will also act in a supporting role for the art and programming divisions, providing assistance as needed.

Roles Project Management Lead Justin will be responsible for keeping regular team meetings, evaluating project progress in all aspects, delegating tasks, and producing relevant documentation.

Game Design Lead As lead, Justin will be in charge of overseeing the design of the project, including conceptualisation, game structure, adherence to the Project Plan and Design Document, user testing, and overall cohesion of the project’s design.

Art and Development Support Justin will provide additional support to the artistic design and development divisions as required by the teams.

The exact responsibilities entailed in this support will depend on the circumstances under which the support is requested.

Page | 22

5.1c Marvelyn Milan Experience Marvelyn possesses a great deal of interest in 3D modelling and animation, skills which she has honed through various projects in the IMD program. Her knowledge of 3D concepts such as lighting, rigging, and animation will serve as valuable contributions to the overall polish of the game. In addition, her experience in visual design and aesthetics make her an excellent candidate for working on a variety of other artistic elements that will be included in the game, including the user interface and character designs. Through her various class projects, she has specialised in artistic development, but is also capable of multitasking and undertaking roles in various divisions, making her an asset in supporting the game design and promotion divisions wherever necessary.

Roles Art Design Marvelyn will work heavily on concept art, modelling, and animation for the game, with a special focus on environments and obstacles.

Game Design Due to her work on the game environments, Marvelyn will work closely with the design team to ensure that obstacles and race leg models properly reflect their designs (or are modified in the event that a problem is found in the design).

Promotion Support Marvelyn will assist as needed in the creation of promotional materials for the project, such as posters.

Page | 23

5.1d Andrew Richardson Experience Andrew has extensive experience with many forms of design, visual art, 3D modelling, motion capture, photography, and video. Since his early years in secondary school he has designed logos and worked as a typesetter for small businesses, art programs, and academic departments. Andrew gained experience in UI design through the IMD program at Carleton and has designed and developed interfaces for video games and web applications. In addition, Andrew possesses knowledge regarding the ever-important aspect of user experience (UX); the methods in which users enjoy and immerse themselves in a game or application.

As a practicing 3D modeller, rigger, and animator, Andrew has over three years of experience with modelling software such as Maya, ZBrush, and motion capture with Vicon. His abilities will assist the team during the development process and will ensure polygonal and animated accuracy in modeled assets and environments.

Andrew has been a professional photographer for over four years and has extensive experience with portraiture, product photography, and sports photography. In addition, Andrew has been working with video as an extension of photography for two years and has been the lead cinematographer for several productions.

His knowledge regarding framing and composition translates directly to virtual environments.

Roles Art Design Lead As art design lead, Andrew will be responsible for overseeing all aesthetic work put into the project. He will be in charge of ensuring a consistent audio-visual style and creating models and animations for characters and environments.

UI and UX Design In addition to general art, Andrew will be responsible for conceptualising and creating the user interface and user experience aspects of the game, including the game’s menus and HUD, as well as other experiencerelated components of the game’s design.

Promotion Lead As promotion lead, Andrew will be responsible for ensuring that all promotional material for the project remains consistent with the project itself, particularly with regards to artistic and informational fidelity. He will work on creating posters, models, and website components for this purpose. He will also be in charge of planning and structuring presentations and other publicity facets related to the project in conjunction with Justin.

Project Management Due to his responsibilities, Andrew will be acting as second in command with regards to project management, acting as support for Justin and replacement in the event that Justin is unable to perform his duties in this regard.

Page | 24

5.1e Tyler Tremblay Experience Tyler has a keen interest in video game mechanics and design, and has used his time in the IMD programme to enhance his conceptualization skills. He has worked in Unity and performed programming tasks for projects such as in Design Studio 3 involving new technologies and interaction methods, including Kinect interaction.

Tyler will use his skills in design and development to conceptualize and implement the game’s systems.

Roles Game Design Tyler will be responsible for creating design material for the project, particularly with regards to scripting/dialogue, path/obstacle design, and mechanics planning. He will be working closely with the art division to ensure that the design of the game is properly translated into the assets of the project.

Development Tyler will assist with research and development with Maryam, contributing primarily to networking optimisation and obstacle mechanic implementation.

Promotion Tyler will provide assistance with regards to the creation of physical promotional materials, such as business cards, pins, t-shirts, and other paraphernalia.

Page | 25

5.2 Hardware Computer Discorder will be developed as a PC game, and as such the PC platform (with keyboard and mouse) will be the primary piece of hardware required for the project.

Network The nature of the game will require a minimum of a local network setup in order to function. With successful implementation, the game will be functional through an internet-based network, and as such will require a corresponding network connection for online play.

5.3 Software Unity Unity version 4.3.4f1 will be the primary software and build used for the development of the project. This is keeping consistent with the version used in the Carleton lab computers, and therefore will avoid version compatibility issues.

Unity Pro Unity Pro will be used as a secondary complement to the project in order to use the enhanced UI and graphical tools provided by the software as well as to remove the Unity watermark from the final deliverable.

Unity Pro will be used separately from the main project to avoid version compatibility issues, but the final version of the project will be imported into Pro for final polish and delivery.

Update: As of the final build, Unity Pro was not used so as to avoid accessibility conflicts with team members that do not own it.

Autodesk Maya Maya 2015 will be the primary modelling tool for the project, and will be used to create the game’s 3D assets.

Adobe Suite The Adobe Suite, most notably Photoshop, Illustrator, InDesign, Premiere, After Effects, Audition, and Dreamweaver, will be used as the default tools for conceptual, 2D, audio, and web asset development.

Google Drive Google Drive will be used as the primary repository for project documentation and asset storage. In addition, Docs and the related productivity software provide within drive will act as the primary tool for writing documentation and text-based files.

Bitbucket Bitbucket will serve as the primary versioning repository tool for the purposes of coding and development. All game code will be stored there as a consistent storage medium to be used by all members of the team.

Microsoft Office Though Google Drive will be used as the primary documentation tool, Microsoft Office (particularly Word and Excel) will be used as a secondary tool for these purposes.

Facebook, Skype, and Google Hangouts Facebook, Skype, and Google Hangouts are all used as means for communication between the team in addition to regular team meetings. This ensures that all team members can be reached through various means as needed.

Page | 26

6. Risk Analysis 6.1. Scope As with any major development project, the subject of scope is a serious one, and incorrectly scaling could prove significantly hazardous to its effective completion. This is relevant both in terms of initial scope and flexibility of that scope (to account for the potential need to either decrease or increase further into production).

In order to mitigate potential scope issues, initial development will be focused around a smaller more secure scope of a single functional level layout (four legs) and simplified assets and environments. To allow for an expansion of the small scope however, modularized stretch goals will be implemented where possible, so as to allow for their progressive inclusion into the game as further progress is made.

The most notable modularization would be the inclusion of additional levels and obstacles to pull from, so that maps could be varied for each game session. Because each level would be self-contained (much like a procedurally generated tile system), this is potentially a limitless expansion goal, so that once main development is complete, the scope of levels could be expanded indefinitely to fit whatever additional time is available. Other aspects, such as selectable characters and the inclusion of the coordination mechanic to break up monotony, have been included in the schedule under the assumption that progress remains on schedule. In the event that progress is delayed, these elements may be cut from the project, whereas they may be added even earlier if the project proves to be ahead of schedule.

6.2. Difficulty Linked directly to scope, the difficulty of certain implementations may be too complicated or otherwise impractical to include in the game. Though the main objectives listed are relatively fundamental, certain means of including them (such as networking) may provide additional difficulty upon implementation that could impede other tasks.

As there is little that can be done during development to effectively solve issues with difficulty, this risk has primarily been addressed during the research and planning phase. During research, an emphasis was placed on researching and testing the functionalities available through the chosen engine(s) (Unity and Unity Pro).

Tasks and implementations have been prioritized according to their difficulty and importance to the core project, ensuring that time in development is first funnelled towards features that need to be present and can be implemented easily, while more complex nonessential tasks are left for later development should time allow.

While unlikely, in the event that a core component of the game is found to be impossible or otherwise too impractical to implement, the team will assess the matter immediately and determine if it is cause for a revaluation of the game’s objectives or even a change in development tools. In this event, the issue will be found early, and as such the danger of work being wasted is reduced greatly.

Page | 27

6.3. Bottlenecking While tasks may be modularised, there remains a likelihood that at least some tasks will depend on the completion of others, and so the possible issue of one task bottlenecking others may arise. This could lead to schedule delays being amplified due to a single challenge, and if unchecked could harm progress on an exponential level.

To address the danger of bottlenecks in production, every team division consists of at least two team members, and every team member is assigned to multiple divisions. This means that any problem encountered may have at least two people immediately able to address it. In the event that the task can be resolved, but will take time and cannot be divided amongst more than one person, any team members that are bottlenecked may have tasks from two division pools to draw from, ensuring that no member should at any point be unable to work on the project in the event that a bottleneck occurs.

Furthermore, supplementary to the division members are members designated to provide support to other divisions in the event that the latter’s progress is in some way impeded that can be alleviated with additional human resources. The additional redundancy in knowledge and skills between team members will allow the team structure to shift according to what is needed to maintain an efficient schedule.

Page | 28

7. Change Control Policy 7.1 Open Communication Consistency of information is accomplished through the employment of multiple forms of communication & file sharing, each for a specific purpose relevant to the project. While no formal access or change procedures are in place, this is replaced by the heavy use of team communication and the team division structure mentioned in part 5.1. Facebook is used for general team communication and meeting planning, while Skype and Google Hangouts are used for direct communication between team members and team meetings (in the event that one or more team members cannot be present in person). Google Drive is used for the purpose of documentation and general file storage. Bitbucket is used to store development material such as project files and source code.

7.2 Versioning Files and project components that have versioning as a consideration are dealt with through the repositories used, as they have built-in versioning features. However, to supplement this regular communication and documented meetings keep track of major changes in the project, while code commenting is used to properly identify the significance of code, so that it may be read and understood by any and all team members as necessary.

7.3 Physical Storage As an additional safety precaution, documents and project files will be collectively stored in multiple physical storage devices owned by different members of the group and regularly updated as backups, to be used to restore the project should something arise that compromises the files stored online.

Page | 29

8. Communication Policy Because the project is a team effort, communication is essential to ensuring that all team members are working effectively and maintaining the same core vision of the game. Without effective communication, there are definite risks of overlapping or conflicting work, misunderstandings of objectives, misplacement of resources, and a general lack of organization.

8.1 Team Communication The risks of team-wide communication is addressed primarily through regular (at present weekly every Monday morning, though this may be changed as needed) meetings. These meetings consist of all team members, and are used to update the team on overall and individual progress, address significant issues with development, and designate subsequent tasks to be completed by the next meeting. This ensures that all team members are aware of each other and of the project’s status as a whole. These meetings are also documented through meeting minutes stored on the common Google Drive, so that any member may review what was discussed in a given meeting. This is the same method used during the summer term, and has proven effective in maintaining consistent rapport within the team.

8.2 Division Communication In addition to team-wide meetings, division (Game Design, Development, Visual Design, and Promotion) specific meetings are conducted by their respective leads as necessary for team members working within these divisions to pool their work, identify problem areas (and address them if they are not serious enough to require team intervention), and make decisions regarding the direction of the work being taken. These meetings permit each division to work independently of the full team under normal conditions so that team meetings are not slowed by division-specific matters.

8.3 Conflict Resolution In order to ensure that any conflict that occurs during development does not hinder the project, a conflict resolution procedure has been devised by the team. In the event that a conflict occurs, the matter is to be brought up either at the next available meeting (if the matter is not serious), or directly to Justin or Andrew as soon as possible (if the matter is urgent) for resolution. If the conflict in question relates to a choice about the game’s development and the major responsible parties cannot agree on a method of proceeding, the decision is to be put to a vote during either the next project meeting or an emergency resolution meeting. If a tie occurs during the vote, the deciding vote lies with Justin (and in the event that he is unavailable, Andrew).

This decision is then to be respected by all members for the continuation of the project.

Page | 30

9. Quality Control Policy 9.1 Team Communication As with change control, quality control is first and foremost dealt with through consistent team communication.

Every team meeting includes a period dedicated to each team member demonstrating any relevant deliverables they may have produced, such as a development build, art asset, or design file. These are viewed by the entire team, and any team member may provide input regarding the item should it have any problems.

This ensures that team divisions and their work are not isolated from the overall team. However, other policies have been put in place to supplement this measure.

9.2 Division Communication In addition to the larger team meetings, division meetings or discussions are expected to occur regularly, even if they are informal. Members of each division are expected to share their files openly with each other, and make an announcement on the appropriate channel when they have made a file available (this is usually done through a message and link to the file on Facebook or Skype). Members of a division are responsible for inspecting the work of their fellow division members, and verify that the item meets the appropriate quality requirements. For example, the art team may share model files to ensure that they are not corrupted and possess an acceptable number of polygons, while the development team may share code components to be added and tested in the main file to ensure functionality. This is a regular process used to identify major issues before implementation.

9.3 User Testing User testing is planned to begin as of January (assuming all progress is completed on schedule and the beta version of the game is complete), and will consist of the team’s designers providing the beta build of the project to various potential users so that usability testing and bug testing may occur. At this point, the core components of the game will have already been implemented, and so any additional development will consist of relatively few significant changes that might jeopardise the integrity of the project. Testing will then continue throughout the subsequent months with each new addition to the game to ensure that the project remains stable.

Update: As of the final build, small scale informal user testing was performed during the month of March.

Page | 31