Drug Runner

Game Roadmap

 

 

First Draft

January 7th 2002

 

 

 

 

 

andrew nealen alan woo connie fung cynthia lim james haslam serif askin

Table of Contents

1 Quick Reference *

1.1 Required Features *

1.2 Optional Features *

2 Components and Related Features / Tasks *

2.1 Game Architecture *

2.2 Front-End / Gameflow Module *

2.3 Player Vehicle AI/Controller *

2.4 Police Vehicle AI/Controller *

2.5 Triggers *

2.6 Mission Logic *

2.7 World Rendering / Representation *

2.8 Cartoon Rendering *

2.8.1 Dynamic Object Cartoon Rendering *

2.8.2 Static / World Object Cartoon Rendering *

2.9 Camera Control Module *

1.5.1 Implementing a Basic Camera Class *

2.10 HUD Module *

2.10.1 Making the camera aware of its environment *

2.11 Collision Detection/Resolution Module *

2.11.1 Dynamic Object – World Object Collision *

2.11.2 Dynamic Object – Static Object Collision *

2.11.3 Dynamic Object – Dynamic Object Collision *

2.11.4 Collision Detection Culling *

2.12 Physics Module *

2.13 Sound Module *

2.14 Input Module *

2.15 Level Design *

2.16 Art Acquisition / Pipeline *

2.17 Vehicle Animation *

2.18 Obstacle Vehicle AI/Controller *

2.19 Particle System *

2.20 Decal System *

2.21 Boss Vehicle and Character Animation *

2.22 Joypad Support *

2.23 Voice Overs *

3 Resource Allocation *

3.1 Game Architecture *

3.1.1 ARCH_1 The timer class *

3.1.2 ARCH_2 The controller base class *

3.1.3 ARCH_3 The mini-kernel (process control) *

3.1.4 ARCH_4 The model base class *

3.1.5 ARCH_5 The model database *

3.1.6 ARCH_6 The object factory *

3.1.7 ARCH_7 The type database *

3.2 Front End / Gameflow Module *

3.2.1 GF_1 Game modes screen/menu *

3.2.2 GF_2* Personal profile screen/menu *

3.2.3 GF_3 Screen layout (clock, money, HUD) *

3.2.4 GF_4 Ingame pause screen/menu *

3.2.5 GF_5* User input feedbacks (such as dialog boxes, beeps) *

3.2.6 GF_6 Help windows, tutorials *

3.3 Player Vehicle AI/Controller *

3.3.1 PLAI_1 Player vehicle controller (acceleration, brake, gear) *

3.3.2 PLAI_2 Player vehicle datatype and initialization (location, state, engine sound) *

3.3.3 PLAI_3 State controller (browsing, mission, racing) *

3.4 Police Vehicle AI/Controller *

3.4.1 PVAI_1 AI world representation *

3.4.2 PVAI_2 Implementation of the police vehicle datatype *

3.4.3 PVAI_3 Police vehicle controller with basic low-level movement interface *

3.4.4 PVAI_4 Implement logic to travel in random path *

3.4.5 PVAI_5 Implement logic to determine if player is in line of sight *

3.4.6 PVAI_6 Implement logic to travel to player's last location *

3.4.7 PVAI_7 Chase mode trigger including any special effects *

3.4.8 PVAI_8 Chase mode controller state *

3.5 Triggers *

3.5.1 TRIG_1 Trigger classes *

3.5.2 TRIG_2 Collide triggers *

3.5.3 TRIG_3* enter_exit triggers *

3.6 Mission Logic *

3.6.1 MISN_1 Mission class and triggers *

3.6.2 MISN_2 Mission Factory *

3.6.3 MISN_3 Integration. *

3.6.4 MISN_4 First complete mission in real world. *

3.6.5 MISN_5 Mission asset acquisition. *

3.6.6 MISN_6* Boss mission *

3.7 World Rendering *

3.7.1 REND_1 Rendering state included in each model *

3.7.2 REND_2 Spatial index and gateway *

3.7.3 REND_3 2-D "development only" renderer *

3.7.4 REND_4 First 3-D renderer with stationary camera *

3.7.5 REND_5 Improved 3-D renderer with camera control incorporated *

3.7.6 REND_6* Renderer culling/index optimization *

3.8 Cartoon Rendering *

3.8.1 CEL_1 Dynamic cartoon rendering of all vehicles using technique described in the technical design document. *

3.8.2 CEL_2 Rendering of all static/world objects with cartoon textures and thick lines on corners of buildings *

3.8.3 CEL_3* Implementation of pre-computed lightmaps according to the directional light source in the world, which also lights the dynamic objects. *

3.9 Camera Control *

3.9.1 CAM_1 Position the camera behind the player car with overhead view *

3.9.2 CAM_2 Reposition the camera at a different location *

3.9.3 CAM_3 Move the camera at a fixed speed (car speed) preserving the angle and distance from the car *

3.9.4 CAM_4* Define a (say, spherical) bounding volume for the distance between the camera and the car *

3.9.5 CAM_5* Determine whether and world objects (static/dynamic) fall into this bounding volume *

3.9.6 CAM_6* Detect whether the camera will likely pass through that object(s), If so, avoid the object by reposition the camera at a different point *

3.9.7 CAM_7* Add vibrations to the camera class *

3.9.8 CAM_8* Accelerate / decelerate the camera that will introduce a lag between the car and the camera in order to create better game immersion *

3.9.9 CAM_9* Make a smooth transition during repositioning for obstacle avoidance *

3.10 HUD Module *

3.10.1 HUD_1 Implement HUD datatype *

3.10.2 HUD_2 Display transparent map *

3.10.3 HUD_3 Display mission locations *

3.10.4 HUD_4 Display player vehicle location *

3.10.5 HUD_5 Display police vehicles location *

3.10.6 HUD_6* Display boss location *

3.10.7 HUD_7 Game data display (health, time, information text) *

3.11 Collision Detection/Resolution Module *

3.11.1 COL_1 Detect collision between dynamic and world object *

3.11.2 COL_2 Resolution of the collision between dynamic and world object by translation along surface normal of world object *

3.11.3 COL_3 Detect collision between dynamic and static object using bounding spheres *

3.11.4 COL_4 Trigger a collision event of the type required for the static object (this event may in turn trigger graphics events and/or sound events) *

3.11.5 COL_5 Detect collision between two dynamic objects using bounding spheres *

3.11.6 COL_6 Simple resolution of the collision by translation along the surface normals of the two bounding spheres at the contact point *

3.11.7 COL_7* Detect exact point of collision between dynamic and world object on both objects *

3.11.8 COL_8* Resolution of the collision between dynamic and world object by translation and rotation of dynamic object *

3.11.9 COL_9* Detect exact point of collision between dynamic and static object on dynamic object *

3.11.10 COL_ 10* Resolution of the collision between dynamic and static object by translation and rotation of dynamic object as it hits the static object *

3.11.11 COL_11* Detect exact point of collision between two dynamic objects using tight oriented bounding boxes *

3.11.12 COL_12* Resolution of the collision between two dynamic objects by translation and rotation of both dynamic objects *

3.11.13 COL_13* Uniformly subdivide the world map into a grid and only perform collision detection against objects within adjacent cells, thereby culling out all other objects *

3.11.14 COL_14* Apply further collision detection optimizations *

3.12 Physics Module *

3.12.1 PHYS_1 Basic car model computations using simple euler integration *

3.12.2 PHYS_2 Compute turning of vehicle using angular velocity around center of mass *

3.12.3 PHYS_3 Export the interface so it can be used by the individual vehicle controllers to determine the trajectory of the controlled vehicle given the current state *

3.12.4 PHYS_4 Enable side-slip to make car handling more realistic *

3.12.5 PHYS_5* Include suspension to visualize hard turns more realistic *

3.12.6 PHYS_6* Differentiate between different surface properties (pavement, grass) *

3.13 Sound *

3.13.1 SND_1 Sound Class *

3.13.2 SND_2 Sound Database, Factory and Loader. *

3.13.3 SND_3 Sound and sound driver. *

3.13.4 SND_4 Sound Support classes *

3.13.5 SND_5 Testing *

3.13.6 SND_6 A.I Integration. *

3.13.7 SND_7 Sound asset acquisition *

3.13.8 SND_8* Triggering *

3.13.9 SND_9* Trigger Integration *

3.14 Input Module *

3.14.1 INP_1 Define/map keyboard keys and mouse clicks/moves *

3.14.2 INP_2 Implement input (initialization) class *

3.14.3 INP_3 Implement input manager class *

3.15 Level Design *

3.15.1 LEV_1 Initial test level *

3.15.2 LEV_2 Extended level *

3.15.3 LEV_3 Complete Level *

3.16 Art Acquisition / Pipeline *

3.16.1 ART_1 Initial "test" art objects. *

3.16.2 ART_2 .obj file loader *

3.16.3 ART_3 Integrate loader with type database *

3.16.4 ART_4 Replace hardcoded objects with file-loaded ones. *

3.16.5 ART_5 Vehicle and Building acquisition *

3.16.6 ART_6 Police and Pedestrian Vehicle acquisition *

3.16.7 ART_7* Misc art. *

3.16.8 ART_8* Increase number of buildings *

3.16.9 ART_9* Boss model *

3.17 *Vehicle Animation *

3.17.1 VAN_1* Animation texture acquisition *

3.17.2 VAN_2* Texture loading/texture coordinates *

3.17.3 VAN_3* Rendering and model support for animation *

3.17.4 VAN_4* Controller use of animation *

3.17.5 VAN_5* Variable animation speed *

3.17.6 VAN_6* Controller use of variable animation speed *

3.18 *Obstacle Vehicle AI/Controller *

3.18.1 OBST_1* Obstacle vehicle datatype, controller, and specialized collision trigger *

3.18.2 OBST_2* Placement in game level *

3.18.3 OBST_3* Sound effects incorporated into trigger *

3.18.4 OBST_4* Visual effects *

3.18.5 OBST_5* Damage calculation logic *

3.18.6 OBST_6* Controller AI for moving vehicle *

3.19 *Particle System *

3.19.1 PART_1* Particles for skidding and car damage *

3.19.2 PART_2* Particles for object – object collisions *

3.19.3 PART_3* Particles for run-over fire hydrants *

3.19.4 PART_4* Particles for exploding dynamic/static objects *

3.20 *Decal System *

3.20.1 DEC_1* Decals for skid/brake marks on the pavement (which is a world object) *

3.20.2 DEC_2* Decals on world objects (walls, roads) for collisions/explosions *

3.20.3 DEC_3* Decals for killed bosses (blood on the pavement) *

3.21 *Boss Vehicle and Character Animation *

3.21.1 BOSS_1* Boss vehicle model and controller, including panic mode trigger *

3.21.2 BOSS_2* Trigger for boss character creation *

3.21.3 BOSS_3* Boss character model and controller *

3.21.4 BOSS_4* Boss character animation incorporated into controller *

3.21.5 BOSS_5* Vehicle damage and boss roadkill decals *

3.21.6 BOSS_6* Boss character animation art (more sophisticated) *

3.22 *Joypad Support *

3.22.1 JOYP_1* Detect that the computer has a joy pad *

3.22.2 JOYP_2* Assign joy pad keys/buttons to input events *

3.22.3 JOYP_3* Calibrate (software calibration) joy pad buttons if required *

3.23 *Voice Overs *

3.23.1 VO_1* Recording and editing of sound clips *

3.23.2 VO_2* Incorporate clips into sound system *

4 Work Allocation Table *

 

  1. Quick Reference

    2. This quick reference provides a common spot where the star features and optional features of the yet-to-be-developed game. The intent is that, upon later revisiting this document, one can quickly assess whether the team is on-track as far as these deliverables go. A useful tracking and evaluating tool.

    1. Required Features
    1. Optional Features
  1. Components and Related Features / Tasks
    1. Game Architecture

As can be taken from the technical design document, the game will be based on a low-level process management architecture with some low-level datastructures. The implementation of this architecture is structured as follows (all required features).

 

 

These features must be implemented and used as early as possible during development so the rest of the development team can use them for their implementation.

 

    1. Front-End / Gameflow Module

The front-end / gameflow module basically controls the flow of sequence in the entire game. The front-end side connects initial screens to the actual gameplay. The gameflow side identifies whether the player succeeds in a level in the game, fails a level, pauses, resumes, or exits the game.

This module allows the user to configure the game features / controls, to set-up player information, to get help about the game, and to interact with and exit from the game.

 

 

 

    1. Player Vehicle AI/Controller

The player vehicle constitutes the central part of the game since the player controls it and everything else revolves around it. The vehicle moves forward/backward, and left/right. The vehicle can be in three different states, namely, browsing, mission, and racing.

 

 

 

    1. Police Vehicle AI/Controller

Police vehicles will be placed randomly in the world. At any time of the game, a police vehicle can be in two different states: 1) patrolling state, and 2) chasing state. Different logic is required for the two states.

 

 

    1. Triggers

Triggers are a key requirement of the mission logic. Pursuing the triggers about the world is a primary goal of the game. Some triggers are visible (mission-related) while others may simply be an invisible bounding box to collide against. In either sense, activating a trigger changes the state of the game, be it a sound state or a mission logic state.

 

 

    1. Mission Logic

The mission logic defines the relationship between the triggers and other game items such as the bank account, the countdown timer and the health of the player. The actual number of missions will be determined by the amount of time available. There are regular missions and boss missions. These are both outlined in the technical design document.

 

 

    1. World Rendering / Representation

World rendering depends on the world representation. More specific rendering features like cartoon rendering and animation are described in following sections. A two dimensional, birds-eye view renderer may be created before work begins on the three-dimensional renderer, so AI developers can use it to visualize controller behaviour as early as possible.

 

 

    1. Cartoon Rendering

      2. The cartoon rendering, or cel shading, is subdivided into the rendering of the dynamic objects, which are dynamically cel shaded, and the static/world objects, which are shaded using cartoon textures and lightmaps (optional).

      1. Dynamic Object Cartoon Rendering

All dynamic objects will be rendered using a 2D texture gradient and thick boundary lines as described in more detail in the technical design document.

 

 

      1. Static / World Object Cartoon Rendering

The static and world objects will be rendered using cartoon-like textures and thick lines at building corners. This must be implemented by the art department. The scene will be much more realistic, if the directional light could pre-generate lightmaps on the world objects, but this will be an optional feature.

 

 

 

    1. Camera Control Module

This task implements a basic game-play camera and represents a third person view of the game. The camera will have three different positions for a better viewing experience. It will not be allowed to pass through solid objects, and optionally will change its distance and angle with respect to the player car according to driving situation, such as bumps, acceleration, etc.

1.5.1 Implementing a Basic Camera Class

 

 

 

    1. HUD Module

The HUD displays various objects' location within the city to help the player navigate.

 

 

 

      1. Making the camera aware of its environment

 

 

 

    1. Collision Detection/Resolution Module

      2. The game architecture differentiates between world objects, static objects and dynamic objects. This is important for the following sections.

       

      1. Dynamic Object – World Object Collision

The most basic of all collisions is the collision between a dynamic object and a world object, like a building. Basic collision detection/resolution is a mandatory feature and must not be omitted. For testing purposes, it must be able to activate/deactivate this feature in debug mode (developer mode).

 

 

      1. Dynamic Object – Static Object Collision

Static objects are for example lampposts, hydrants and trees. These collisions are generally not resolved, as they generally destroy the static object, but can trigger graphic effects such as explosions and/or particle effects. In a second iteration, we might add a bit of collision resolution to these collisions (optional).

 

 

      1. Dynamic Object – Dynamic Object Collision

These collision happen between obstacle vehicles (which are in themselves an optional feature of the game) and police vehicles. These collisions require the most sophisticated kind of detection/resolution.

 

 

      1. Collision Detection Culling

In the initial version of the game, a brute force method will be applied, testing all objects against all objects in the world. This might be sufficient, as there are only a limited amount of objects per map. This method will naturally not scale well with larger world sizes and more objects. Should it be the case, that our level structure requires a more sophisticated approach, then we will implement a culling scheme by which the world is divided into uniform cells which are tested against each other, but not against all other objects in the world.

 

 

 

    1. Physics Module

The physics module is basically a helper class, which is used by the vehicle controllers to compute the motion of the dynamic objects. The initial car model used is of basic nature, but fit enough to convey the feeling of driving an actual car. The model can be tweaked to tune the gameplay experience and will load an external configuration file at runtime to initialize itself. This textfile can be edited by the game designer(s) during the testing phase.

 

Important note: The more complex the physics module operates, the more state variables mmust be added to the vehicles state representation (the vehicle ‘model’ in the model-view-controller architecture, see the technical design document).

 

 

 

    1. Sound Module

Fairly self explanatory what this does.

 

 

    1. Input Module

Input module receives keyboard and mouse inputs, and generates/activates events. The input here means external/user input (not the inputs between program modules)

 

 

 

    1. Level Design

The level design defines the way the world has been configured. Placement of buildings, initial placement of vehicles, and world textures are considered as part of the level design

 

    1. Art Acquisition / Pipeline

The art acquisition consists of everything from obtaining the art assets themselves to getting them into the game by way of various loaders and databases

 

 

    1. Vehicle Animation

Vehicle animation will be restricted to texture animation. Specific examples of vehicle animation that we plan to incorporate into our game are: flashing siren lights on police vehicles (in chase state); rotating wheels on all vehicles. Vehicle animation is a secondary feature, but a fairly important one.

 

 

    1. Obstacle Vehicle AI/Controller

Obstacle vehicles provide much of the game's urban atmosphere. Obstacle vehicles are either stationary or moving in very simple paths; upon collision an obstacle vehicle blows up, triggering visual and sound effects (which can be as simple or elaborate as we have time to implement). Collision with obstacle vehicles causes a very small amount of damage (if any) to the player (or police) vehicle, so the opportunity to wreak havoc at minor cost should add to the fun.

 

 

    1. Particle System

The particle system is a wholly optional feature and can be added/implemented at any time during development. It can be seen as eye candy and is not necessary for the gameplay mechanics.

 

 

    1. Decal System

The decal system is a wholly optional feature and can be added/implemented at any time during development. It can be seen as eye candy and is not necessary for the gameplay mechanics.

 

 

    1. Boss Vehicle and Character Animation

The boss vehicle, in terms of its "cruise mode" behaviour, is pretty much the regular obstacle vehicle (it too can be either stationary or moving in a simple path). However, it appears on the HUD map, and it takes at least a few hits of damage before exploding. The boss vehicle also has a "panic mode" that is triggered by the first collision of the player vehicle. In panic mode, the boss vehicle should move away from the player vehicle, using similar line-of-sight rules and path logic to those that govern police vehicle "vision" and behaviour in pursuit mode. When the boss vehicle is destroyed, a special trigger brings up the boss character.

 

Boss characters require their own controllers, but the necessary physics to support movement of boss characters is pretty much limited to collision detection. A boss character moves at some constant speed, in the direction away from the player vehicle (similar to the boss vehicle in panic mode), and is represented by a billboard animation with a spherical bounding volume. Upon collision with anything in the world, the boss character could stop moving horizontally and "gibber" by wobbling up and down instead (he’s panicking after all). Upon collision with the player vehicle, the boss character is replaced by a decal of roadkill on the pavement, or some other visual effect.

 

 

    1. Joypad Support

The joy pad support is a wholly optional feature and can be added/implemented at any time during development. It can be used for better and more realistic car control replacing some keyboard inputs.

 

 

    1. Voice Overs

Voice over is a secondary feature that can be added later in the development to enhance the text based dialogues.

 

 

  1. Resource Allocation

    2. All duration estimates are based on approximately 10 hours per week per person in the development team. Features marked with a * are optional.

     

    1. Game Architecture
      1. ARCH_1 The timer class

        2. Key figures: Andrew Nealen

        Duration: 0.5 weeks / 5 hours

        Placement: Start before Milestone 1

        Dependencies: none

         

      2. ARCH_2 The controller base class

        3. Key figures: Andrew Nealen

        Duration: 0.5 weeks / 5 hours

        Placement: Start before Milestone 1

        Dependencies: none

         

      3. ARCH_3 The mini-kernel (process control)

        4. Key figures: Andrew Nealen

        Duration: 0.5 weeks / 5 hours

        Placement: Start before Milestone 1

        Dependencies: ARCH_2

         

      4. ARCH_4 The model base class

        5. Key figures: Andrew Nealen

        Duration: 0.2 weeks / 2 hours

        Placement: Start before Milestone 1 and come up with a semi-final interface for basic rendering and base member variable access as soon as possible.

        Dependencies: ARCH_7

         

      5. ARCH_5 The model database

        6. Key figures: Andrew Nealen

        Duration: 0.5 weeks / 5 hours

        Placement: Start before Milestone 1

        Dependencies: none

         

      6. ARCH_6 The object factory

        7. Key figures: Andrew Nealen

        Duration: 0.5 weeks / 5 hours

        Placement: Between Milestones 1 and 2

        Dependencies: Models and controllers (ARCH_4, ARCH_2)

      7. ARCH_7 The type database

      Key figures: Andrew Nealen

      Duration: 0.5 weeks / 5 hours

      Placement: Between Milestones 1 and 2

      Dependencies: none

       

    2. Front End / Gameflow Module
      1. GF_1 Game modes screen/menu

        2. Key figures: Connie Fung

        Duration: 0.5 weeks

        Placement: Between Milestones 2 and 3

        Dependencies: none

         

      2. GF_2* Personal profile screen/menu

        3. Key figures: Connie Fung

        Duration: 0.5 weeks

        Placement: Milestone 5

        Dependencies: none

         

      3. GF_3 Screen layout (clock, money, HUD)

        4. Key figures: Connie Fung

        Duration: 0.5 weeks

        Placement: Between Milestones 2 and 3

        Dependencies: none

         

      4. GF_4 Ingame pause screen/menu

        5. Key figures: Connie Fung

        Duration: 0.5 weeks

        Placement: Between Milestones 2 and 3

        Dependencies: none

         

      5. GF_5* User input feedbacks (such as dialog boxes, beeps)

        6. Key figures: Connie Fung

        Duration: 0.5 weeks

        Placement: Milestone 5

        Dependencies: none

         

      6. GF_6 Help windows, tutorials

      Key figures: Connie Fung

      Duration: 0.5 weeks

      Placement: Between Milestones 3 and 4

      Dependencies: Most of game flow and input, and mission basics (GF_1, GF_3, INP_1, MISN_5)

       

       

    3. Player Vehicle AI/Controller
      1. PLAI_1 Player vehicle controller (acceleration, brake, gear)

        2. Key figures: Serif Askin

        Duration: 1 week

        Placement: Between Milestones 1 and 2

        Dependencies: Model framework and base controller and object factory (ARCH_4, ARCH_2, ARCH_6); player vehicle datatype (PLAI_2)

         

      2. PLAI_2 Player vehicle datatype and initialization (location, state, engine sound)

        3. Key figures: Serif Askin

        Duration: 1 week

        Placement: Before Milestone 1

        Dependencies: none

         

      3. PLAI_3 State controller (browsing, mission, racing)

      Key figures: Serif Askin

      Duration: 1.5 weeks

      Placement: Between Milestones 1 and 2

      Dependencies: Basic vehicle controller (PLAI_1)

       

    4. Police Vehicle AI/Controller
      1. PVAI_1 AI world representation

        2. Duration: 1 week

        Key Figures: Alan

        Placement: Before Milestone 1

        Dependencies: Model database (ARCH_4, ARCH_5)

         

      2. PVAI_2 Implementation of the police vehicle datatype

        3. Duration: 0.5 weeks

        Key Figures: Alan

        Placement: Before Milestone 1

        Dependencies: none

         

      3. PVAI_3 Police vehicle controller with basic low-level movement interface

        4. Duration: 0.5 weeks

        Key Figures: Alan

        Placement: Between Milestones 2 and 3

        Dependencies: Base controller (ARCH_2) and physics module (PHYS_1, PHYS_2, PHYS_3) as well as PVAI_2

         

      4. PVAI_4 Implement logic to travel in random path

        5. Duration: 0.5 weeks

        Key Figures: Alan

        Placement: Between Milestones 1 and 2

        Dependencies: PVAI_1 – PVAI_3

         

      5. PVAI_5 Implement logic to determine if player is in line of sight

        6. Duration: 0.5 weeks

        Key Figures: Alan

        Placement: Between Milestones 2 and 3

        Dependencies: Player vehicle datatype (PLAI_2), PVAI_1 – PVAI_3

         

      6. PVAI_6 Implement logic to travel to player's last location

        7. Duration: 0.5 weeks

        Key Figures: Alan

        Placement: Between Milestones 3 and 4

        Dependencies: PVAI_1 – PVAI_3

      7. PVAI_7 Chase mode trigger including any special effects

        8. Duration: 0.5 weeks

        Key Figures: Alan

        Placement: Between Milestones 3 and 4

        Dependencies: Base trigger (TRIG_1)

         

      8. PVAI_8 Chase mode controller state

      Duration: 0.5 weeks

      Key Figures: Alan

      Placement: Between Milestones 4 and 5

      Dependencies: Vehicle movement, vision, and ability to move to player’s last location (PVAI_4 – PVAI_6)

       

    5. Triggers
      1. TRIG_1 Trigger classes

        2. Description:

        Create an abstract trigger class that goes into the model database. The trigger class will be subclassed heavily. For instance, there will be sound triggers, mission triggers, etc. Some triggers (such as mission triggers) will be visible and have a model, others (such as ambient sound triggers) will be invisible, yet still go in the model database, for they will be collidable.

         

        Duration: 0.5 weeks

        Key figures: Serif

        Placement: Between Milestones 1 and 2

        Dependencies: none

         

      2. TRIG_2 Collide triggers

        3. Description:

        This is a subclass of the trigger class. This trigger has a simple rectangular bounding volume. The trigger is "activated" upon collision with this bounding volume. It will be up to the collision detection system to detect collisions with this trigger and activate.

         

        Duration: 0.2 weeks

        Key Figures: Serif

        Placement: Milestone 3

        Dependencies: Base triggers (3.5.1 TRIG_1), collision detection (COL_5)

         

      3. TRIG_3* enter_exit triggers

      Description:

      This is a subclass of the trigger class. This trigger has a simple rectangular bounding volume. The trigger is "enter_activated" upon entering the bounding volume and "exit_activated" upon leaving the bounding volume. It will be up to the collision detection system to detect these two conditions and activate this trigger accordingly.

      The primary use of this trigger will be for use with ambient sounds, where activation will activate/deactivate the sound. (It is thus an optional feature)

       

      Duration: 0.5 weeks

      Key figures: Serif

      Placement: Optional Component (for ambient sounds)

      Dependencies: base trigger (3.5.1 TRIG_1), collision detection (3.11.4- COL_4)

       

    6. Mission Logic
      1. MISN_1 Mission class and triggers

Description:

Design and implement a mission class. "Mission Triggers" (a subclass of collide triggers) must also be inplimented are used to either activate a mission or satisfy some (or all) of a mission’s requirements.

Note: missions may be created and destroyed based on the "countdown timer" in the game

Mission triggers can either activate a or satisfy some (or all) of an activated missions requirements.

Types of mission triggers:

After all mission requirements are fulfilled (triggered), the mission is destroyed.

 

Duration: 1 week

Key Figures: Alan

Placement: Between Milestones 1 and 2

Dependencies: 3.5.1- TRIG_1, timer (ARCH_1)

 

      1. MISN_2 Mission Factory

        2. Description:

        All missions will be hardcoded into the game. The mission factory is the place where this is done. Also, the mission factory is the place where the interdependencies of mission requirements (ie one doesn’t appear until another is completed) is established. Design and implement a factory such that new missions can be cleanly added to the game.

         

        Duration: 1 week

        Key Figures: Alan

        Placement: Between Milestones 1 and 2

        Dependencies: 3.6.1- MISN_1

         

      2. MISN_3 Integration.

        3. Description:

        Get a single mission to work in the 4x4 world. This includes adjusting the timer if need be, killing the player off for an incomplete mission, and crediting/deducting the player’s bank account.

        After the factory is completed, create a "test mission" with 2 mission triggers (begin mission and only 1 mission requirement). The triggers are to be placed in block (1,1) and (2,2) of the initial test level.

         

        Duration: 2 weeks

        Key Figures: Alan

        Placement: Between Milestones 2 and 3

        Dependencies: 3.6.2 - MISN_2

      3. MISN_4 First complete mission in real world.

        4. Description:

        Once the test mission has been verified to work properly, the next step is to get a moderately complex mission (one with one Accepting mission trigger and at least two mission requirements triggers where they must be done in some order) to work in the 10x10 world.

        A mission description must be developed. The audio description of the missions must now be included and used (even if the audio art itself is just a placeholder)

         

        Duration: 1 week

        Key Figures: Serif

        Placement: Between Milestones 2 and 3

        Dependencies: 3.6.3 MISN_3

      4. MISN_5 Mission asset acquisition.

        5. Description:

        Make at least 3 more missions including, storylike description and audio description, (even if the audio part is just a placeholder). Put them all in the mission factory so that they are working when the game starts up.

         

        Duration: 0.5 weeks

        Key Figures: Serif

        Placement: Between Milestones 3 and 4

        Dependencies: 3.6.4- MISN_4

      5. MISN_6* Boss mission

Description:

This mission is slightly different than the previous missions because of two facts:

It does not have an accepting trigger. It is automatically accepted when the final "normal" mission has been completed. Its only requirement trigger is a moving "boss" model! This mission must be done differently than the others.

 

Duration: 1 week

Key Figures Serif

Placement: Optional Component

Dependencies: 3.6.5- MISN_5, 3.16.9- ART_9, boss vehicle and character animation (BOSS_4)

 

    1. World Rendering
      1. REND_1 Rendering state included in each model

        2. Duration: 0.5 weeks

        Key Figures: Cynthia

        Placement: start before Milestone 1

        Dependencies: model (ARCH_4)

         

      2. REND_2 Spatial index and gateway

        3. Duration: 1.5 weeks

        Key Figures: Cynthia

        Placement: Milestone 1 (mid January)

        Dependencies: model (ARCH_4)

         

      3. REND_3 2-D "development only" renderer

        4. Duration: 1 week

        Key Figures: Cynthia

        Placement: between Milestones 1 and 2 (late January)

        Dependencies: Rendering state (REND_1)

         

      4. REND_4 First 3-D renderer with stationary camera

        5. Duration: 3 weeks

        Key Figures: Cynthia

        Placement: between Milestones 1 and 2 (late January into February)

        Dependencies: Rendering state (REND_1)

         

      5. REND_5 Improved 3-D renderer with camera control incorporated

        6. Duration: 2 weeks

        Key Figures: Cynthia

        Placement: Milestone 2 (mid to late February)

        Dependencies: First 3-D renderer (REND_4), camera control module (CAM_3)

         

      6. REND_6* Renderer culling/index optimization

      Duration: 0.5 weeks

      Key Figures: Cynthia

      Placement: between Milestones 3 and 4

      Dependencies: first renderer (REND_4)

       

    2. Cartoon Rendering
      1. CEL_1 Dynamic cartoon rendering of all vehicles using technique described in the technical design document.

        2. Duration: 0.5 weeks

        Key Figures: Andy

        Placement: Between Milestones 2 and 3

        Dependencies: None

         

      2. CEL_2 Rendering of all static/world objects with cartoon textures and thick lines on corners of buildings

        3. Duration: 0.5 weeks

        Key Figures: Andy

        Placement: Between Milestones 2 and 3

        Dependencies: None

         

      3. CEL_3* Implementation of pre-computed lightmaps according to the directional light source in the world, which also lights the dynamic objects.

      Duration: 1.0 weeks

      Key Figures: Andy

      Placement: Between Milestones 3 and 4

      Dependencies: None

       

       

       

    3. Camera Control
      1. CAM_1 Position the camera behind the player car with overhead view

        2. Key figures: Serif

        Duration: 0.2 weeks

        Placement: Between Milestones 1 and 2

        Dependencies: Basic rendering (REND_4)

         

      2. CAM_2 Reposition the camera at a different location

        3. Key figures: Serif

        Duration: 0.2 weeks

        Placement: Between Milestones 1 and 2

        Dependencies: Basic rendering (REND_4)

         

      3. CAM_3 Move the camera at a fixed speed (car speed) preserving the angle and distance from the car

        4. Key figures: Serif

        Duration: 0.2 weeks

        Placement: Between Milestones 1 and 2

        Dependencies: Basic rendering (REND_4 ) and player vehicle (PLAI_1)

         

      4. CAM_4* Define a (say, spherical) bounding volume for the distance between the camera and the car

        5. Key figures: Cynthia Lim

        Duration: 0.2 weeks

        Placement: Between Milestones 4 and 5

        Dependencies: REND_4 and PLAI_1

         

      5. CAM_5* Determine whether and world objects (static/dynamic) fall into this bounding volume

        6. Key figures: Cynthia Lim

        Duration: 0.2 weeks

        Placement: Between Milestones 4 and 5

        Dependencies: CAM_4, basic rendering and player vehicle (REND_4, PLAI_1)

         

      6. CAM_6* Detect whether the camera will likely pass through that object(s), If so, avoid the object by reposition the camera at a different point

        7. Key figures: Cynthia Lim

        Duration: 0.2 weeks

        Placement: Between Milestones 4 and 5

        Dependencies: CAM_5, collision detection (COL_1)

         

      7. CAM_7* Add vibrations to the camera class

        8. Key figures: Cynthia Lim

        Duration: 0.2 weeks

        Placement: Between Milestones 4 and 5

        Dependencies: CAM_1 – CAM_3

         

      8. CAM_8* Accelerate / decelerate the camera that will introduce a lag between the car and the camera in order to create better game immersion

        9. Key figures: Cynthia Lim

        Duration: 0.2 weeks

        Placement: Between Milestones 4 and 5

        Dependencies: CAM_1 – CAM_3

         

      9. CAM_9* Make a smooth transition during repositioning for obstacle avoidance

      Key figures: Cynthia Lim

      Duration: 0.2 weeks

      Placement: Between Milestones 4 and 5

      Dependencies: CAM_1 – CAM_3

       

    4. HUD Module
      1. HUD_1 Implement HUD datatype

        2. Duration: 0.2 weeks

        Key Figures: Alan

        Placement: Between Milestones 1 and 2

        Dependencies: None

         

      2. HUD_2 Display transparent map

        3. Duration: 0.5 weeks

        Key Figures: Cynthia

        Placement: Between Milestones 2 and 3

        Dependencies: HUD_1. Can make use of work done on 2-D "in house" renderer (REND_3).

         

      3. HUD_3 Display mission locations

        4. Duration: 0.2 weeks

        Key Figures: Cynthia

        Placement: Between Milestones 2 and 3

        Dependencies: HUD_1 and mission trigger placement (MISN_3)

         

      4. HUD_4 Display player vehicle location

        5. Duration: 0.2 weeks

        Key Figures: Cynthia

        Placement: Between Milestones 2 and 3

        Dependencies: HUD_1 and player vehicle (PLAI_1)

         

      5. HUD_5 Display police vehicles location

        6. Duration: 0.2 weeks

        Key Figures: Cynthia

        Placement: Between Milestones 2 and 3

        Dependencies: HUD_1 and police vehicle (PVAI_2)

         

      6. HUD_6* Display boss location

        7. Duration: 0.2 weeks

        Key Figures: Cynthia

        Placement: Between Milestones 4 and 5

        Dependencies: Boss vehicle (BOSS_1)

         

      7. HUD_7 Game data display (health, time, information text)

      Duration: 1 week

      Key Figures: Cynthia

      Placement: Between Milestones 3 and 4

      Dependencies: HUD_1 and game data/player logic; also fonts

       

       

    5. Collision Detection/Resolution Module
      1. COL_1 Detect collision between dynamic and world object

        2. Duration: 0.5 weeks

        Key Figures: Andy

        Placement: Between Milestones 2 and 3 (February)

        Dependencies: Bounding volumes (ART_1) and world geometry (LEV_1)

      2. COL_2 Resolution of the collision between dynamic and world object by translation along surface normal of world object

        3. Duration: 0.5 weeks

        Key Figures: Andy

        Placement: Between Milestones 2 and 3 (February)

        Dependencies: COL_1

         

      3. COL_3 Detect collision between dynamic and static object using bounding spheres

        4. Duration: 0.2 weeks

        Key Figures: Andy

        Placement: Between Milestones 2 and 3 (February)

        Dependencies: None

         

      4. COL_4 Trigger a collision event of the type required for the static object (this event may in turn trigger graphics events and/or sound events)

        5. Duration: 0.2 weeks

        Key Figures: Andy

        Placement: Between Milestones 2 and 3 (February)

        Dependencies: Collision triggers (TRIG_2)

         

      5. COL_5 Detect collision between two dynamic objects using bounding spheres

        6. Duration: 0.2 weeks

        Key Figures: Andy

        Placement: Between Milestones 2 and 3 (February)

        Dependencies: None

         

      6. COL_6 Simple resolution of the collision by translation along the surface normals of the two bounding spheres at the contact point

        7. Duration: 0.2 weeks

        Key Figures: Andy

        Placement: Between Milestones 2 and 3 (February)

        Dependencies: None

         

      7. COL_7* Detect exact point of collision between dynamic and world object on both objects

        8. Duration: 0.2 weeks

        Key Figures: Andy

        Placement: Between Milestones 4 and 5

        Dependencies: None

         

      8. COL_8* Resolution of the collision between dynamic and world object by translation and rotation of dynamic object

        9. Duration: 0.2 weeks

        Key Figures: Andy

        Placement: Between Milestones 4 and 5

        Dependencies: None

         

      9. COL_9* Detect exact point of collision between dynamic and static object on dynamic object

        10. Duration: 0.2 weeks

        Key Figures: Andy

        Placement: Between Milestones 4 and 5

        Dependencies: None

         

      10. COL_ 10* Resolution of the collision between dynamic and static object by translation and rotation of dynamic object as it hits the static object

        11. Duration: 0.2 weeks

        Key Figures: Andy

        Placement: Between Milestones 4 and 5

        Dependencies: None

         

      11. COL_11* Detect exact point of collision between two dynamic objects using tight oriented bounding boxes

        12. Duration: 0.2 weeks

        Key Figures: Andy

        Placement: Between Milestones 4 and 5

        Dependencies: None

         

      12. COL_12* Resolution of the collision between two dynamic objects by translation and rotation of both dynamic objects

        13. Duration: 0.2 weeks

        Key Figures: Andy

        Placement: Between Milestones 4 and 5

        Dependencies: None

         

      13. COL_13* Uniformly subdivide the world map into a grid and only perform collision detection against objects within adjacent cells, thereby culling out all other objects

        14. Duration: 1.0 weeks

        Key Figures: Andy

        Placement: Between Milestones 4 and 5

        Dependencies: None

         

      14. COL_14* Apply further collision detection optimizations

      Duration: unknown

      Key Figures: Andy

      Placement: Between Milestones 4 and 5

      Dependencies: None

       

    6. Physics Module
      1. PHYS_1 Basic car model computations using simple euler integration

        2. Duration: 0.5 weeks

        Key Figures: Andy

        Placement: Between Milestones 2 and 3

        Dependencies: none

         

      2. PHYS_2 Compute turning of vehicle using angular velocity around center of mass

        3. Duration: 0.5 weeks

        Key Figures: Andy

        Placement: Between Milestones 2 and 3

        Dependencies: none

         

      3. PHYS_3 Export the interface so it can be used by the individual vehicle controllers to determine the trajectory of the controlled vehicle given the current state

        4. Duration: 0.1 weeks

        Key Figures: Andy

        Placement: Between Milestones 2 and 3

        Dependencies: none

         

      4. PHYS_4 Enable side-slip to make car handling more realistic

        5. Duration: 0.5 weeks

        Key Figures: Andy

        Placement: Between Milestones 3 and 4

        Dependencies: None

         

      5. PHYS_5* Include suspension to visualize hard turns more realistic

        6. Duration: 0.5 weeks

        Key Figures: Andy

        Placement: Between Milestones 4 and 5

        Dependencies: None

         

      6. PHYS_6* Differentiate between different surface properties (pavement, grass)

      Duration: 0.5 weeks

      Key Figures: Andy

      Placement: Between Milestones 4 and 5

      Dependencies: Surface properties in world (LEV_1), point location queries (ARCH_4)

       

    7. Sound
      1. SND_1 Sound Class

        2. Description:

        Design and implement class that will hold a single sound. A sound can be continuous or have a duration.

         

        Duration: 0.5 weeks

        Key Figures: Connie

        Placement: Between Milestones 2 and 3

        Dependencies: none

      2. SND_2 Sound Database, Factory and Loader.

        3. Description:

        Design a container to hold all the different sounds. Design and implement a factory that wil, on game initialization, load sounds from disk into their "sound" objects and store them in the container. This may involve using a sound loader class.

         

        Duration: 1 week

        Key Figures: Connie

        Placement: Between Milestones 2 and 3

        Dependencies: SND_1

      3. SND_3 Sound and sound driver.

        4. Description:

        Design and implement a driver that can play the sound objects. Some sounds, such as ambient sounds, do not terminate on their own so the driver must also accept commands for "stop playing a sound" as well, by either fadeout or immediate stop. Must contend with limited resources (can only play so many sounds at the same time). This can all be tested independent of gameplay itself, but should be compiled into the main project as soon as possible for peer suggestions.

         

        Duration: 2 weeks

        Key Figures: Connie

        Placement: Between Milestones 3 and 4

        Dependencies: SND_1

      4. SND_4 Sound Support classes

Description:

Once sounds and their driver have been established as working support classes must be developed for system-wide communication. Such classes include:

 

Duration: 1.5 weeks

Key figures: Connie

Placement: Between Milestones 4 and 5

Dependencies: SND_3

      1. SND_5 Testing

        2. Description:

        Testing the sound dispatch mechanism by hardcoding a sound event and dispatching it should be done. This is still independent of the game itself. This tests everything from the manager all the way on down to the driver.

         

        Duration: 0.2 weeks

        Key Figures: Connie

        Placement: Between Milestones 4 and 5

        Dependencies: 3.13.4- SND_4

      2. SND_6 A.I Integration.

        3. Description:

        Sound events are often called by the A.I. We must ensure that the A.I has a clean mechanism to do so. For instance, when a collision is detected between car and a building then a sound event is created and dispatched. Must work with the A.I crew to ensure that this is done cleanly.

        Duration: 0.8 weeks

        Key Figures: Connie

        Placement: Between Milestones 4 and 5

        Dependencies: 3.13.5- SND_5

      3. SND_7 Sound asset acquisition

Description:

Various sounds must now be obtained by stealing them off the web or creating them with a microphone. These sounds are to be saved to disk in .wav format and loaded into the sound database at load time.

Sounds include the following:

Duration: 0.5 weeks

Key Figures: Connie, James (who thinks this could be fun), whoever else wants to join in

Placement: Between Milestones 4 and 5

Dependencies: 3.13.2- SND_2

 

      1. SND_8* Triggering

        2. Description:

        Sound events may be either dispatched by the A.I. in response to some condition (such as a collision), or through collision with a trigger. In this case, it is the trigger that decides what sort of sound event to dispatch.

        A "sound trigger" must be designed and implemented. For ambient noises, when the player vehicle enters a bounding box "the trigger" then one sound is dispatched, when the player leaves a bounding box then the terminate sound event is dispatched. Therefore a subclass of enter-exit triggers will be used in this case. There may be other cases where a collide trigger may be appropriate. And yet other cases where simply having the AI dispatch the call directly is appropriate.

         

        Duration: 0.5 weeks

        Key Figures: Connie

        Placement: Optional component (for ambient sounds)

        Dependencies: 3.13.5- SND_5

      2. SND_9* Trigger Integration

Description:

The newly created sound triggers must be placed in the 10-10 world. This will be done by placing them in the worldrep base by modifying the worldrep’s factory (the level factory) and hardcoding it in there. If we happen to have tones of time (ha, ha) then the triggers may be placed in the level defintion file and loaded on game startup.

 

Duration: 0.5 weeks

Key Figures: Jimmy, Connie

Placement: As late as possible (optional component)

Dependencies: 3.13.8- SND_8

 

 

    1. Input Module
      1. INP_1 Define/map keyboard keys and mouse clicks/moves

        2. Duration: 0.5 weeks

        Key Figures: Connie Fung

        Placement: Before Milestone 1

        Dependencies: None

         

      2. INP_2 Implement input (initialization) class

        3. Duration: 0.5 weeks

        Key Figures: Connie Fung

        Placement: Before Milestone 1

        Dependencies: None

         

      3. INP_3 Implement input manager class

      Duration: 1 week

      Key Figures: Connie Fung

      Placement: Between Milestones 1 and 2

      Dependencies: None

       

       

    2. Level Design
      1. LEV_1 Initial test level

Description:

Creation of the WorldRep class, into which objects will be loaded.

Create an initial level factory class (no loading the level in from file yet!).

Hardcoded buildings and cars are needed first, in order to place them.

 

Duration: 1 week

Key Figures: Jimmy

Placement: Milestone 1

Dependencies: Hardcoded test objects (ART_1)

 

      1. LEV_2 Extended level

Description:

Make the beginnings of the actual level to be used in the final version of the game. This is to be a city of size 10x10. With the following characteristics.

Other tasks to accomplish:

Duration: 2 weeks

Key Figures: Jimmy

Placement: Before Milestone 1

Dependencies: LEV_1

 

      1. LEV_3 Complete Level

Description:

Create the actual level that will be published in the video game. This will be a "work in progress", evolving as more art resources are added to the project.

Work includes:

Duration: 1.5 weeks

Key Figures: Jimmy

Placement: Between Milestones 3 and 4

Dependencies: LEV_2

 

    1. Art Acquisition / Pipeline
      1. ART_1 Initial "test" art objects.

        2. Description:

        A hardcoded building and vehicle will be put into the type database, and made available to the model database and image map. The building and vehicle will be just squares with the sides coloured instead of textured. This should be done as early as possible to give the renderer and the leveldesign/worldrep something to test against.

         

        Duration: 3 hours

        Key figures: Jimmy

        Placement: Prior to milestone 1

        Dependencies: Models (ARCH_4)

      2. ART_2 .obj file loader

        3. Description:

        A loader for .obj file formats will be provided to us. Get this code to compile into our project and understand how it works. Its details may influence the design of the type database somewhat and may even provide good ideas to the renderer. (Ie- "vertex list" – based design.. See opengl spec 1.2)

         

        Duration: 5 hours

        Key Figures: Jimmy

        Placement: Between Milestones 2 and 3

        Dependencies: Models (ARCH_4)

         

      3. ART_3 Integrate loader with type database

        4. Description:

        Get the loader to load models directly into the type database.

         

        Duration: 3 hours

        Key figures: Jimmy

        Placement: Between Milestones 2 and 3

        Dependencies: 3.16.2- ART_2

      4. ART_4 Replace hardcoded objects with file-loaded ones.

        5. Description:

        At this point, the square buildings and vehicles that were previously hardcoded, are now replaced by file-loaded equivalents. This tests the loader without breaking anything else, because the output to the renderer should be the same.

        Duration: 3 hours

        Key Figures: Jimmy

        Placement: Between Milestones 2 and 3

        Dependancies: 3.16.3- ART_3

      5. ART_5 Vehicle and Building acquisition

        6. Description:

        Art assets for vehicles and some buildings must be acquired. This involves finding .obj files on the web or making your own in Milkshape 3D. Have these loaded in from a file into the type database and test them on the renderer, by replacing the previously hardcoded rectangles with these babies. The artwork for these models is what will appear in the final model. Priority: the automobile first, then as many buildings as can be done in the allotted time.

         

        Duration: 15 hours

        Key Figures: Jimmy

        Placement: Between Milestones 2 and 3

        Dependencies: None

      6. ART_6 Police and Pedestrian Vehicle acquisition

        7. Description:

        Using Milkshape 3d or the web, get or make .obj files for police and pedestrian vehicles. Have them loaded from a file into the type database. Create models for them in the model database if not already done so.

         

        Duration: 5 hours

        Key figures: Jimmy

        Placement: Between Milestones 3 and 4

        Dependencies: None.

      7. ART_7* Misc art.

        8. Description:

        Trash cans, trees, fire hydrants and whatever other static objects you come across. Load them into the type database. Create models for them in the model database if not already done so.

         

        Duration: 5 hours

        Key figures: Jimmy

        Placement: Optional Component

        Dependencies: None

         

      8. ART_8* Increase number of buildings

        9. Description:

        As time permits, produce a variety of buildings to put in the world. This will make the city look not so boring

         

        Duration: 10 hours

        Key figures: Jimmy

        Placement: Optional Component

        Dependencies: None

      9. ART_9* Boss model

      Description:

      Get the animation frames for the boss.

       

      Duration: 4 hours

      Key Figures: Jimmy

      Placement: Optional Component. Final milestone

      Dependencies: None

       

       

    2. *Vehicle Animation
      1. VAN_1* Animation texture acquisition

        2. Duration: 2 weeks

        Key Figures: Jimmy

        Placement: Between Milestones 2 and 3 (February)

        Dependencies: none

         

      2. VAN_2* Texture loading/texture coordinates

        3. Duration: 2 weeks

        Key Figures: Jimmy

        Placement: Between Milestones 2 and 3 (February)

        Dependencies: VAN_1

         

      3. VAN_3* Rendering and model support for animation

        4. Duration: 2 weeks

        Key Figures: Cynthia

        Placement: Between Milestones 3 and 4 (late February)

        Dependencies: VAN_1, VAN_2

         

      4. VAN_4* Controller use of animation

        5. Duration: 0.5 weeks

        Key Figures: Alan

        Placement: Between Milestones 3 and 4 (late February)

        Dependencies: VAN_3

         

      5. VAN_5* Variable animation speed

        6. Duration: 0.5 weeks

        Key Figures: Cynthia

        Placement: Between Milestones 4 and 5 (March)

        Dependencies: VAN_3

         

      6. VAN_6* Controller use of variable animation speed

      Duration: 0.5 weeks

      Key Figures: Cynthia

      Placement: Between Milestones 4 and 5 (March)

      Dependencies: VAN_5

       

       

    3. *Obstacle Vehicle AI/Controller
      1. OBST_1* Obstacle vehicle datatype, controller, and specialized collision trigger

        2. Duration: 0.25 weeks

        Key Figures: Alan

        Placement: Between Milestones 4 and 5

        Dependencies: Model database, base controller (ARCH_2, ARCH_5), vehicle art (ART_6)

         

      2. OBST_2* Placement in game level

        3. Duration: 0.25 weeks

        Key Figures: Alan

        Placement: Between Milestones 4 and 5

        Dependencies: Level design (LEV_1), model database (ARCH_5), vehicle art (ART_6)

         

      3. OBST_3* Sound effects incorporated into trigger

        4. Duration: 0.25 weeks

        Key Figures: Alan

        Placement: Between Milestones 4 and 5

        Dependencies: Sound event system and sound assets (SND_6, SND_7), OBST_2

         

      4. OBST_4* Visual effects

        5. Duration: 0.25 weeks

        Key Figures: Alan

        Placement: Between Milestones 4 and 5

        Dependencies: Particle system (PART_4), OBST_1

         

      5. OBST_5* Damage calculation logic

        6. Duration: 0.5 weeks

        Key Figures: Alan

        Placement: Between Milestones 4 and 5

        Dependencies: OBST_1, police vehicle (PVAI_9)

         

      6. OBST_6* Controller AI for moving vehicle

      Duration: 1 week

      Key Figures: Alan

      Placement: Between Milestones 4 and 5

      Dependencies: OBST_5, physics module (PHYS_1, PHYS_2)

       

       

    4. *Particle System
      1. PART_1* Particles for skidding and car damage

        2. Duration: 1 week

        Key Figures: Jimmy

        Placement: Between Milestones 4 and 5

        Dependencies: None

         

      2. PART_2* Particles for object – object collisions

        3. Duration: 1 week

        Key Figures: Jimmy

        Placement: Between Milestones 4 and 5

        Dependencies: None

         

      3. PART_3* Particles for run-over fire hydrants

        4. Duration: 1 week

        Key Figures: Jimmy

        Placement: Between Milestones 4 and 5

        Dependencies: None

         

      4. PART_4* Particles for exploding dynamic/static objects

      Duration: 0.5 weeks

      Key Figures: Jimmy

      Placement: Between Milestones 4 and 5

      Dependencies: None

       

       

    5. *Decal System
      1. DEC_1* Decals for skid/brake marks on the pavement (which is a world object)

        2. Duration: 0.5 weeks

        Key Figures: Jimmy

        Placement: Between Milestones 4 and 5

        Dependencies: None

         

      2. DEC_2* Decals on world objects (walls, roads) for collisions/explosions

        3. Duration: 0.5 weeks

        Key Figures: Jimmy

        Placement: Between Milestones 4 and 5

        Dependencies: None

         

      3. DEC_3* Decals for killed bosses (blood on the pavement)

      Duration: 0.5 weeks

      Key Figures: Jimmy

      Placement: Between Milestones 4 and 5

      Dependencies: None

       

    6. *Boss Vehicle and Character Animation
      1. BOSS_1* Boss vehicle model and controller, including panic mode trigger

        2. Duration: 1 week

        Key Figures: Serif

        Placement: Between Milestones 4 and 5 (March)

        Dependencies: model database (ARCH_4, 5), collision trigger (TRIG_2), police vehicle logic (PVAI_4, 5, 6), collision detection (COL_5)

         

      2. BOSS_2* Trigger for boss character creation

        3. Duration: 0.1 weeks

        Key Figures: Serif

        Placement: Between Milestones 4 and 5 (March)

        Dependencies: Base trigger (TRIG_1)

         

      3. BOSS_3* Boss character model and controller

        4. Duration: 0.5 weeks

        Key Figures: Serif

        Placement: Between Milestones 4 and 5 (March)

        Dependencies: model database and controller framework (ARCH_2, 4, 5)

         

      4. BOSS_4* Boss character animation incorporated into controller

        5. Duration: 0.25 weeks

        Key Figures: Serif

        Placement: Between Milestones 4 and 5 (March)

        Dependencies: BOSS_3

         

      5. BOSS_5* Vehicle damage and boss roadkill decals

        6. Duration: 0.1 weeks

        Key Figures: Serif

        Placement: Between Milestones 4 and 5 (March)

        Dependencies: Decals (DEC_2, DEC_3)

         

      6. BOSS_6* Boss character animation art (more sophisticated)

      Duration: 0.2 weeks

      Key Figures: Serif

      Placement: Between Milestones 4 and 5 (March)

      Dependencies: None

       

       

    7. *Joypad Support
      1. JOYP_1* Detect that the computer has a joy pad

        2. Duration: 0.3 weeks

        Key Figures: Serif

        Placement: Between Milestones 3 and 4

        Dependencies: None

         

      2. JOYP_2* Assign joy pad keys/buttons to input events

        3. Duration: 0.3 weeks

        Key Figures: Serif

        Placement: Between Milestones 3 and 4

        Dependencies: None

         

      3. JOYP_3* Calibrate (software calibration) joy pad buttons if required

      Duration: 0.3 weeks

      Key Figures: Serif

      Placement: Between Milestones 3 and 4

      Dependencies: None

       

    8. *Voice Overs
      1. VO_1* Recording and editing of sound clips

        2. Duration: 1.5 weeks

        Key Figures: Connie

        Placement: Between Milestones 4 and 5

        Dependencies: None

         

      2. VO_2* Incorporate clips into sound system

Duration: 0.4 weeks

Key Figures: Connie

Placement: Between Milestones 4 and 5

Dependencies: Sound Module

 

  1. Work Allocation Table

 

Team

 

Jan

 

 

Feb

 

 

 

Mar

 

 

Member

14

21

28

4

11

18

25

4

11

18

25

Andy

ARCH_7

ARCH_5

ARCH_3

PHYS_1

PHYS_2

COL_1

COL_3

CEL_1

CEL_3*

COL_7*

COL_11*

 

ARCH_4

ARCH_2

ARCH_6

 

PHYS_3

COL_2

COL_4

CEL_2

PHYS_5*

COL_8*

COL_12*

 

 

 

 

PHYS_4

COL_5

 

PHYS_6*

COL_9*

COL_13*

 

 

 

 

COL_6

 

COL_10*

COL_14*

 

 

 

 

 

 

 

 

 

 

 

 

Alan

PVAI_1

MISN_1

MISN_2

MISN_3

MISN_3

PVAI_2

PVAI_4

PVAI_6

PVAI_8

OBST_1*

OBST_4*

 

HUD_1

 

 

PVAI_3

PVAI_5

PVAI_7

VAN_4

OBST_2*

OBST_5*

 

 

 

 

 

OBST_3*

OBST_6*

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Cynthia

REND_1

REND_2

REND_3

REND_4

REND_4

HUD_2

HUD_7

REND_5

REND_5

VAN_3

HUD_6*

 

 

 

 

HUD_3

 

 

REND_6*

VAN_5*

 

 

 

 

HUD_4

 

 

CAM_4*

VAN_6*

 

 

 

 

HUD_5

 

 

to

 

 

 

 

 

 

 

 

 

 

 

CAM_9*

 

Jimmy

LEV_1

ART_1

LEV_2

ART_2

ART_5

ART_5

ART_6

LEV_3

ART_7*

PART_1*

DEC_1*

 

 

LEV_2

 

ART_3

VAN_1*

VAN_1*

LEV_3

 

ART_8*

PART_2*

DEC_2*

 

 

 

ART_4

VAN_2*

VAN_2*

 

 

ART_9*

PART_3*

DEC_3*

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Connie

INP_1

INP_3

SND_1

SND_2

SND_3

SND_3

SND_3

SND_3

SND_4

SND_5

SND_7

 

INP_2

 

 

GF_1

GF_3

SND_4

GF_6

SND_6

SND_8*

 

 

 

 

 

 

SND_9*

 

 

 

 

 

 

VO_1*, 2*

 

 

 

 

 

 

 

 

 

 

 

GF_2*, 5*

Serif

PLAI_2

TRIG_1

PLAI_1

PLAI_3

PLAI_3

MISN_4

TRIG_2

TRIG_3*

BOSS_1*

BOSS_2*

MISN_6*

 

 

 

 

CAM_1

MISN_5

JOYP_1*

to

 

 

 

 

 

CAM_2

 

JOYP_2*

BOSS_6*

 

 

 

 

 

CAM_3

 

JOYP_3*