Advanced 3D Graphics for Game Programming- COMP 6761

Tron Light Cycle Arcade Race

Submitted by:

Koushik Kanti Mandal (ID#9738916), Ranjith Karunamurthy (ID#1456830)

1. Introduction:
The goal of this project is to design and develop a 3D interactive computer game application using OpenGL. We tried to design an Interactive First Person Arcade Racing Game using Tron Light Cycle where a player has to complete 2 different tracks within the given time limit to complete the game. The player cannot drive the car outside the road. Collision detection is used to detect if the car collides with the obstacles in the track. The player is allowed to interact with keyboard only.

2. Approach:
At the beginning, an overall design of the game is proposed. Once it is approved, we made the detailed design of the game containing model design of the Deluxe Light Cycle and 3D world environment and the game strategy. We followed object oriented programming (OOP) approach and developed the program accordingly. Every module is developed separately and independently. Later we merged all the modules in our project. As our program is developed based OOP concept, so any further modification and extension is possible without affecting the whole program. Initially, we created our Tron Light Cycle in OpenGL using hierarchical modeling. Car structure and dimension has been chosen based on real world vehicle structure. The movement, speed, acceleration, wheel rotation of the car was calculated maintaining the car physics to give a user the real feeling of racing. The gaming environment was made simple and nice by applying appropriate OpenGL primitives and texture mapping. Two tracks have been developed. For each track different environment is used and different time limit is fixed. The second track is made more difficult than the first one by adding more turns, reducing the time limit and adding fog. Car movement was restricted to go beyond the track by applying the collision detection technique. In addition, every time the gaming state is represented on the screen to let the player know the update state of the game. The other things like finishing the track in a wrong way are controlled by proper checking in the program.

3. Design and Methodology: 3.1. Car Model:

We modeled the car using the OpenGL primitives and we followed the hierarchical modeling approach. Figure 1 shows the overall brief model of our light cycle.

Fig.1: Brief hierarchical modeling of Delux Tron Light Cycle

Fig.2: Car dimension in horizontal and vertical direction

3.2.

Car movement:

Initially the car is positioned at the starting position of the track facing along the positive z-direction. The front wheel angle is very important which is followed by the car body to change its movement direction. The initial direction of front wheel and the car is same i.e. (carDirectionX, carDirectionZ) = (0, 1). As the player wants to move left or right the front wheels angle changes according to the front wheels rotation speed and time. The front wheel rotation is limited to the maximum rotation angle which is fixed as 45 degree in our program. The direction of the car body and other wheels changes according to the front wheel direction.

3.2.1. Angular rotation:

The angular rotation of the wheel is calculated by dividing the car speed by the radius of the wheel. If the angle is more than 360 degree then it is reduced by subtracting by 360 degree. If the angle is negative then it is added by 360 degree.

3.2.2. Camera Movement:

We have used only one camera which is positioned just behind the car. The camera position and look at vector is changed similar to the car direction using the OpenGL gluLookAt() function.

3.3.

Collision detection:

Collision detection is the technique used in games to simulate real life object collision. Collision detection is the most important and interesting technique used in our game. We have used the simple bounding box technique to detect the collision. A bounding box is created using two successive points on the track. At first the unit vector between the two points is calculated and then the perpendicular unit vector is also constructed. Using this two unit vectors the box is made for both inside and outside track. Every time the four car wheels position is updated as the car moves to a new position. At any time if any of the wheels is inside any of the boxes, then the collision is detected. After collision detection the car position is shifted in a collision free position. This is done by placing the car inside the road and aligning with the direction of the edge (which is made by the track points) of the box. The speed of the car is also set to a minimum value.

3.4.

Crossing number update:

We have placed two bounding boxes around the finish line; one is set just before the finish line (Front Box) and another one is set just after the finish line (Back Box). The two boxes are used to check whether a player has finished the track properly or not. Because, otherwise one could easily finish the game by going to the wrong direction first to cross the finish line and then going turning back again to finish the lap. In order to restrict that, we track the previous positions and current positions of the wheels. If the wheels first pass the Back box and then pass the Front box then it is considered as a positive lap count, otherwise the reverse order is considered as a negative lap count. So, one player can only finish the game within the timeline by raising the lap count number to the targeted lap number.

3.5.

Environment Design:

3.5.1. Tracks:
The game has 2 different circuits to be completed by the player in order to finish the game. Both of these tracks have been built and well tessellated using Triangular strips to increase rasterization speed and ensure proper lighting. For each track we used user defined points array, where each point has a directed vector and operations defined. Alternatively, we could have used the curve equation of the track. But this would not allow us to find the points on the track which we need for collision detection. The track is texture mapped with chequered flag which is built by procedural texture mapping technique. Track1: This is the first level in the game. This track is basically elliptical and allows the user with some spine chilling curved corners all through the level, this track designed simple to encourage the player in to playing the game over and over again! This track is built with the parametric ellipse equation with varying x and z values.

X = a cos( ) Z = b sin( )

Fig.3: Track 1 which is used in the level 1 of the game. Track2: This is the second and final level of the game, hence its designed challenging for the user to complete. This track is added some environmental effect-fog to make the user virtually feel like on a real track. This Track is built on an idea to replicate formula one race track of the French Grand Prix- Circuit de Nevers Magny-Cours. The track is built by simplifying the original track and converting it in to a simpler version for our game. The following the Figure shows the skeleton of the simpler track.

Fig.4: the skeleton of the simpler track which is used to make track 2.

The type of Fog that we used for this track is exponential fog, which is defined by,

C = fC i + (1 f )C fog

Where, Ci is the incoming color and Cfog is the fog color and f = e ( density . z )

Fig.5: Track 2 which is used in the level 2 of the game.

3.5.2. Other Environmental elements:

Ground: The Terrain Ground has been designed as one big quadrilateral which is tessellated into small quads. The figure below shows how the points on the quadrilateral are chosen in the anti-clockwise order. The ground is then texture mapped with a grass texture.

Fig.6: Tessellated ground

A cube is added to the environment which looks like concrete blocks. And the cube is texture mapped to give an appearance like concrete bunker.

Fig.7: Concrete bunker

Swimming Pool:
One of the interesting parts of the environment is the swimming pool which is built with bump mapping concept. The area is a big quadrilateral which built with smaller quads. The normal of each vertex in the quadrilateral has been modified by X= DEV * rand () / RAND_MAX, Y=DEV * rand () / RAND_MAX, Z= sqrt(1.0 u * u w * w) where, DEV= Deviation of the normal, rand () = Random Function.

Fig.8: Swimming pool

3.5.3. Animation:
A 3-D application is never completed without animation. In our application we used a key frame animation. We animated a pony, which is built with OpenGL primitives. The figure below shows the key frames of the pony animation.

Fig.9: Pony animation

Motion Blur:
Motion Blur is one of the interesting effects in the game. We used simple motion blur using Accumulation buffer, which basically accumulates the previous frame buffer values with the current frame buffer value. Another way of doing motion blur is using texture mapping, by rendering the object into a texture, we can easily access the precedent frame, and by accessing it, we can render it with a lower alpha value. Doing this in a recurrent mode, we can obtain the desired effect. The only thing needed is a texture used for storing the precedent scene.

3.5.4.

Scene:

The whole scene is contained in a cylinder which is texture mapped with real life scenery to resemble sky. The screen shot below shows the overall scene inside the texture mapped cylinder. Alternatively, we may have chosen sky dome (Sphere) or cube maps. But neither of them suited our scene well.

Fig.10: Scene from the Top

Start

Setting View yes Render Track And Environment for Level 1

Level1

Yes

Restart

Yes Render Track And Environment for Level 2 No

Level 2

Yes

Restart

Render Car

No

Game Paused Update Car No

Yes

Pause Timer & Stop Car Movement

Detect Collision Yes Yes Update Crossing Elapsed Time<= Target Time Yes No No #Lap < Target Laps No

Yes

Change Car to point Correct Direction

Yes No Failure Level=1

Level =1

No

Sucess

Fig 11: Overall Game flow chart

4. Description of running & testing:

Initially we tested our game by ourselves while developing individual parts. We checked it with various machines of different configurations. Once the game was completed we asked some of our friends to test the game and give their comment. This way we found some library files need to be added along with binary executable file to make the game work on all Windows System.

Screen Shots (SS):

Below are the screen shots of different states of the game. SS 1: Beginning of Level 1.

SS2: Level 1 paused.

SS3: Level 1 with motion blurs.

SS4: Level 1 failed.

SS5: Level 1 finished.

SS6: Level 2 initial state.

SS7: Level 2 with Environmental Effects (FOG).

SS8: Level 2 failed.

SS9: Level 2 finished, Game Completed!

5. Challenges Faced:
Making the Cars movement realistic (physics based). Detecting collision and its effect. Determining whether if a lap is actually finished. Designing the Environment to represent the real world. Creating 3D key frame animation in open-gl. Improving Frame Rate by using display lists (for the animation).

Integration of the game modules.

6. Discussion:
The overall approach was to include Object Oriented Concepts to facilitate game extensibility. We used Object Oriented Concepts while coding. This made it easy for us to do any modification, extension and debugging. Car movement is based on vector calculus. This helped in determining the Cars direction, determining collisions and setting the car in correct direction of the track. Initially we tried to use line based collision detection, but it had some shortcomings. In Line Based Collision detection we draw lines from the centre of the track to all 4 wheels of the car. Then we calculate the intersection points for every wheel and check whether the intersection points inside the track or not. But this technique had a problem when the track is parallel to the line connecting the wheel and the center. We used basic collision detection based on bounding box. Here we check centres of the 4 wheels of the Car are colliding with the box containing the track edge points. Though this technique is slow and brute force (i.e. for every position of the car it is checked for collision with all the points on the track edges), we used this because this simple and quick to implement. The figure below shows how the collision is detected and resolved by our bounding box technique.

Figure: Collision is detected.

Figure: Collision is resolved by making the car point the correct direction of the track.

There are various other efficient techniques that we could have used for collision detection, like Tree Based Collision Detection. We did not try to implement them because of limited time.

7. Future Works:
If we were to continue working on the project, we would add more tracks, improve user interaction with the game (Mouse & Joystick), Main Menu for the game, real time physics based car movement (Car Mass, Wind Force, Aerodynamics) and Hierarchical Scene Graph to improve rendering performance of the hardware.

8. Conclusion:
We found that there are a lot of options to apply mathematics and physics in a Car game. Based on the theoretical knowledge gathered from the class and the programming experience earned from the assignments we developed our game. We applied hierarchical modeling, lighting, texture mapping, motion blur, and animation in our project. Besides, we got clear understanding about vector calculus and car physics. Now, we have a clear and deep understanding of 3D computer graphics. We are confident enough to develop a 3D interactive user interface for various applications.

9. References: Nehe Tutorials Video Tutorials Open GL Red Book Motion Blur Techniques Course Website