Home | How To Play | Technologies | Downloads | Team

Game Concept

Our concept of the game came from all team members' fondness of driving simulations.  We wanted a game where gameplay is fun and easy with good replay value.  Crazy Taxi came to mind.  A game where you race with the clock and maneuver through the city to reach a goal was jus tthe kind of idea we wanted to go with... and so we did!  In the  process of creating the game, we decided the game was too realistic and the look of it was just not exciting enough.  While browsing through our 476 book looking at shaders, we saw an image of a cel-shaded car in a game called Cel Damage.  In a unanymous vote, the team decided we needed cel-shading in our game to give it the kick that it needed.  This change allowed us a more cartoonish look, therefore allowing us to exaggerate the physics of the game to fit that of a cartoon world.  So in the end, by combining the gameplay of Crazy Taxi and the look of Cel Damage, we now have Mad Cab!!!

Crazy Taxi

Cel Damage

MadCab

 

World Architecture

The streets in “Mad Cab” are arranged similar to streets in a big city, that is, they are parallel for long stretches.  When we designing the world for “Mad Cab” we exploited this by creating a two dimensional array of a “tile” data structure. Each tile structure holds a collection of passenger spawn nodes, traffic path nodes as a directed graph, collision geometry, dynamically placed objects such as fire hydrants and trees, and an indexed-face-set mesh used to draw the ground plane and any structures in the region covered by the tile’s

The blue blocks represent passenger spawn locations, and green boxes represent traffic path nodes. The traffic path nodes are connected by the traffic graph edges, each edge is directed from blue to red.
span. Each tile covers a square region and all tiles have the same dimensions, so the tiles that are closest to the car can easily be found by indexing into the two dimensional tile array with the car’s world position divided by the tile edge length.

Traffic

The traffic manager is responsible for handling all of the traffic cars. Each car has a current position, a destination, and a current state. If the car is in a driving state, then it will continuously try to get to its destination. The traffic manager loops through each car and checks if it has reached its destination. If it has, then the manager obtains a new destination
from the cars traffic iterator and assigns it to the car. The traffic manager also handles spawning and de-spawning of traffic. Traffic cars are de-spawned when they get a certain distance away from the car. Once a car is de-spawned, it then becomes available to be re-spawned within the current spawn zone. If a traffic car collides with the player car or other traffic, it is put in a crashed state and is disabled.

Collision Detection

 To detect collisions in our game we use intersection tests. Every frame intersection tests are performed to detected collisions between cars and buildings, and collisions between cars with other cars. If a collision is detected the appropriate collision

response is called. The buildings and other static objects in our game are bounded by a set of arbitrary surrounding vertical planes (you can easily edit the collision planes for any of tiles in the game). Cars are bounded by Oriented Bounding Boxes (OBB). To detect a collision between cars and static object we perform a Oriented Bounding Box vs. Line intersection test. Before the test happens, we first find the nearest world tiles, and then the nearest planes to the car, and only test those. To detect a collision between a car and another car we use OBB vs. OBB intersection test. Before performing the full intersection test we check that the cars are near each other with a simple distance test. After a successful test, the collision impulse and torque are calculated for both cars and applied in the collision response functions.

View Frustum Culling

Mad Cab uses the geometric approach to View Frustum Culling to extract the camera planes. This is done by using the 3 vectors to define the camera and the near and far plane distances. Through multiple cross products and trigonometry the 6 planes of the View Frustum are found. After the 6 planes are found the world objects need to be tested against the View Frustum. Mad Cab has three abstract objects that need to be checked for culling; passengers, traffic and world tiles. Both the passengers and traffic objects are culled using bounding spheres. The world tiles are tested as boxes by using their four planar points that define the tile.

Animation

We created a class to encapsulate all the variables and algorithms needed to produce a simple OpenGL animation. The Animator class is designed to be initialized once, and have it’s update( ) method called once each frame to update its state. The draw operation for the object being animated must be wrapped with calls to the animator’s draw( ) and endDraw( ) methods. The animations that can be produced are rotations, scales, translations, and color, each of these are linearly
interpolated between their start and end values over a duration that is specified when the animator is initialized. The menu text and collision stars are examples of animations in Mad Cab that use the Animator class.

Mesh Simplification

Mesh Simplification is the act of removing polygons from a mesh while preserving its geometric structure. In Mad Cab, traffic vehicles swap from full models to simplified ones when they become a certain distance away from the taxi cab, allowing the user to view the more detailed traffic vehicles up close, and the courser vehicles from afar.

Image of two vehicles driving exactly on the threshold between simplified and non-simplified traffic. The vehicle on the left is simplified, while the vehicle on the right is not.

To determine which polygons should be removed, first the traffic mesh is reorganized into an edge-based structure. Each edge is analyzed for its curvature. Then, based on n number of edge collapses (specified in the application’s metadata), the n most-curvy edges are collapsed. After all computations complete, the data structure is analyzed again to prune any faces that are no longer visible, and the mesh is outputted to a new file.
The following is an image of two vehicles driving exactly on the threshold between simplified and non-simplified traffic. The vehicle on the left is simplified, while the vehicle on the right is not.

Audio

For its audio needs, MadCab uses the FMOD Ex sound system developed by Firelight Technologies. We make use of the sound system’s 3D sound support, allowing sounds to be dynamically placed throughout the MadCab world. As the listener’s position is updated, FMOD handles the fading in and out of the appropriate sounds. FMOD’s virtual voice management system allows many sounds to be played at once and automatically allocates the limited number of
hardware or software voices to the most important sounds to the listener. As shown in the image, only 10 of the 50 currently playing sounds are audible. MadCab’s sound manager initializes the sound system, creates a sound object for each sound, and controls which sounds to play when throughout the game.