1. Advanced 3D Graphics for Game Programming- COMP 6761
Tron Light Cycle Arcade
Race
Submitted by:
• Koushik Kanti Mandal (ID#9738916),
• Ranjith Karunamurthy (ID#1456830)
2. 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. 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
4. 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 wheel’s angle changes according to the front wheel’s 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.
5. 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(θ )
6. 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 it’s 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.
7. 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
8. 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
9. 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.
10. 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
11. Start
Setting View
yes
Render Track
And
Level1 Yes Restart
Environment for
Level 1
Yes
Render Track
And
Level 2 Yes Restart
Environment for
Level 2
No
Render Car No
Pause Timer &
Game Paused Yes Stop Car
Movement
Update Car
No
Change Car to
Detect
Yes point Correct
Collision
Direction
Yes No
Yes
Update Crossing
Elapsed
Time<= Target No
Time
Yes
#Lap < Target
No Laps
Yes
No
Failure Level=1
Level =1 No Sucess
Fig 11: Overall Game flow chart
12. 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.
20. SS9: Level 2 finished, Game Completed!
5. Challenges Faced:
• Making the Car’s 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.
21. 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 Car’s 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.
22. 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.
23. 9. References:
• Nehe Tutorials
• Video Tutorials
• Open GL Red Book
• Motion Blur Techniques
• Course Website
