Car Game Final Year Project

Kanad Institute of Engineering &
Management
Simulating Car Racing Game by Applying Path
finding Algorithms
Submitted by
BITHIKA BARIK 25200111002
MANAS KARMAKAR 25200111005
RISHABH SINGH 25200111007
VIVEK NASKAR 25200111014
In particular fulfillments for the requirements of the degree of
BACHELOR OF TECHNOLOGY
In
COMPUTER SCIENCE & ENGINEERING
awarded by the
WEST BENGAL UNIVERSITY OF TECHNOLOGY
May 2015

ACKNOWLEDGEMENT
We express our sincere gratitude to our college Kanad Institute of
Engineering & Management, Durgapur for providing us an
opportunity to undertake and complete such an interesting project
report.
We are very thankful to our respected Director, Prof. Dr. S. N.
Chaudhuri, M.Sc, Ph.D., for the confidence he had on us regarding
this project. We are very much obliged to our respected Chairman,
Mr. Pradip Kr. Agasthy, Secretary, Mr. S. N. Jaiswal and our
Principal, Dr. Anil Baran Adhikari, B.E, PGDCA, Ph. D, for
inspiring and motivating us to bring out a successful project.
We are very grateful to our respected faculty, Mr. Barun Kumar
Das who was our backbone and our guide throughout this project.
Without his assistance we wouldn’t have completed this project within
a short period of time.
It would be really very unfair without the mention of our friends and
families. The immense love and moral support they have given is truly
unmeasurable.

CERTIFICATE
This is to certify the project entitled “Simulating Car Racing
Game by Applying Path finding Algorithms” is a bona fide work
carried out by the following students:
BITHIKA BARIK , Roll no. – 25200111002
MANAS KARMAKAR , Roll no. - 25200111005
RISHABH SINGH , Roll no. – 25200111007
VIVEK NASKAR , Roll no. – 25200111014
Has prepared their FINAL YEAR PROJECT according to the
regulations of Bachelor of Technology degree course in CSE in Kanad
Institute of Engineering and Management and the students have
fulfilled all the requirements for submission of the project work.
………………………………………. …….………………………..
Prof, (Dr.) S. N. Chaudhuri Dr. Anil B. Adhikari
Director Principal
KIEM, Mankar (Burdwan) KIEM, Mankar (Burdwan)
……………………………………….
Mr. Barun Kumar Das
Project Guide
Dept. of CSE
KIEM, Mankar (Burdwan)

PROJECT REPORT ON
“Simulating Car Racing Game by Applying
Path finding Algorithms”
Has successfully completed by
BITHIKA BARIK (Roll no. - 25200111002)
MANAS KARMAKAR (Roll no. - 25200111006)
RISHABH SINGH (Roll no. - 25200111007)
VIVEK NASKAR (Roll no. - 25200111014)
Under the esteemed guidance of Mr. Barun Kumar Das.
Faculty of Computer Science & Engineering dept.
Kanad Institute of Engineering & Management,
Mankar

INDEX
S/no. Topics Page no.
Abstract 1
1 Introduction 2
2
2.1
2.1.1
2.1.2
2.1.3
2.2
Game Design
Game Design and Concepts
Initial Concept
Seceond Iteration
Final Concept
Devlopment Process
3
3
3.1
3.2
3.3
3.4
Game Engine
Game Framework
Unity 3D
Car Physics
Advance Car Physics
5
6
7
4
4.1
4.2
The Game Camera
Basic Camera
Smooth Camera
8
5 The Other Camera 10
6
6.1
6.2
6.3
Materials And Methods
Implementing The A*algorithm
The First modified A*algorithm : reducing
waypoints by a line-of-sight algorithm
Dynamic path finding algorithm for random
obstacles avoidance
10
12
13
13
7 Designing The Car Model 14
8
8.1
Creating Terrain
Basic Concept
25
25
9
9.1
9.2
Track Design
Add Road Marker
Insert Road Marker
35
36
36
10
10.1
10.2
10.3
10.4
Coding
AI Script
Path Finding Script
Car Camera Script
Speedometer Script
39
39
42
53
55
11 References 58
12 Conclusion 59

1 | P a g e
ABSTRACT
This bachelor thesis describes a case study, where we are focusing on
developing a 3D racing car game, using a process based upon agile
development; an evolutionary development method.
The thesis will cover implementation of real-time graphics, physics
engine, network support, as well as sound effects and background
music.
In the end, our case study will show that this development process was
an appropriate choice for our game development project.

2 | P a g e
1. Introduction
Developing software applications is a time-consuming process, and with
time-consuming processes come high costs. During the last years, several
software development methodologies, often known as agile software
development, have become widely used by software developers to address this
issue. Many different development methodologies can be more or less good,
depending of the task and application type.
One of the software development methodologies is the evolutionary software
method, which, as the name hints, takes on an evolutionary approach to the
problem, and allows the project to evolve through different stages of the
project. Our case study will show how well this evolutionary approach worked
on our project where we choose to develop a 3D graphic computer game. Some
requirements for the computer game were given from the beginning, such as:
3D graphics – The game must contain 3D models, and render these in the
game. 3D environments were never a requirement, and platform games with
2D environment could still open up for 3D objects.
Impressive result – The game result must impress whoever plays the
game. It should last long, and make the players come back and play it over
and over again.
Graphical effects – To achieve an impressive result, we would need to add
modern graphical effects, such as real-time rendered soft shadows, motion blur,
and ambient occlusion.
Working with these requirements, we decided to use Unity 3D as our platform to
develop our 3D game with. This decision was made with regard to that the platform
had many in-built tools and provided a good framework for us to get started with
the development as fast as possible. The fact that Unity 3D also used javascript as
development language was also in consideration, since we wanted to learn this
newly developed javascript language.
The requirement for the game to contain 3D graphics introduced an interesting
challenge for the project group, since all had none or little experience in 3D
modelling. Spending time learning how to model proper 3D models for our game
was therefore necessary. During the research to find out what 3D modelling
program to use, we found that we could use different studios to create models that
we could later import to our game project. The complete game contains models
made in both Blender and 3D Studio MAX.
With these choices made, we soon had our development environment set to use
Unity 3D supporting the framework, and Blender and 3D Studio MAX for modelling
the graphical components. For some of the sound effects we also made use of Adobe
Audition 2.0.

3 | P a g e
2. Game Design
2.1. Game Design and Concepts
In this project, we were left free to decide what type of game we wanted to develop.
The suggestion was that a racing game would be suitable, since such a game usually
do not depend on advanced assets, e.g. animated models. After some
brainstorming, it was decided that a racing game should be developed. However,
there were two different racing game ideas, which will be described below.
In compliance with our development process, the game concept evolved, as more
and more features were added. To further explain how the game concept evolved,
the development has been divided into three parts.
2.1.1. Initial Concept
Our first concept had a game play similar to Remedy’s game in 1996, called Death
Rally1, where each player had a car equipped with a weapon, and the goal was to
hunt down the opponent’s cars. The other idea was to create a simple race track
where players could collect coins in order to win. Since the first idea involved much
greater work than the latter one, it was decided that the first idea were to be given a
low priority, whereas the second were to be given a high priority.
2.1.2. Second Iteration
We decided that a joint solution would be best, where players are able to collect
coins and then use the money to make upgrades. Example of upgrades was better
weapons, faster engine, and heavier car body. These upgrades would be similar to
the concept of levelling, something that many players appreciate. It was also decided
that the racing track should be a garage or a store-house, filled with containers,
boxes, and miscellaneous objects suitable for that environment. Since driving a real
car around a garage is virtually impossible, it was decided that we should make
remote controlled cars instead.
2.1.3. Final Concept
We kept most of the ideas from the second iteration with one exception for the death
rally concept. It appeared that our first instinct, to give this idea a low priority, was
right and in this last iteration, the idea was dropped. However, a racing game where
players only may collect coins and nothing more, sounded a bit boring. Influenced
by games like Super Mario Kart, it was decided that power-ups should be added.
There are a number of different power-ups, and they could be divided into two
groups; those that affect the car that hit the power-up, and those that affect the
opponents’ cars. A more profound description of the different power-ups follows.
In addition to the other improvements, one change was made to the points system.
It should be possible to collect three types of coins, worth 50, 100 and 200 points.
2.2. Development Process
In a software development project, the resulting product is required to fulfil many
different qualities. Examples of such quality requirements are:

4 | P a g e
robustness, availability, maintainability, dependability and usability. To meet such
varying demands, it is important to base the work on a well prepared strategy. In
software engineering, the term for such a strategy is commonly known as software
process, which is built on one or several software process models.
What Is a Software Process Model?
A software process model is a theoretical philosophy that describes the best way of
developing software. Based on one or several models, a software process is formed
providing guidance on how to operate. A software process model may also be
described as an abstract representation of a soft-ware process. The concept of the
process model is similar to an abstract java class, which cannot be instantiated, but
it can be implemented by another class, thus providing basic guidelines for that
other class.
A model may for example demand customer involvement, but it does
not state exactly how. A process implementing that model should
involve the customer in the process’ activities, but is free to choose
how.
There is not only one type of process model, but two. The first one is the most
common, and described above. The second type of process model is called a process
paradigm, which is a model even more general than an ordinary process model.
Such a model does not hold any details on how the activities that lead to the
completion of a project should be performed, but what it does hold is basic
guidelines of how to develop software, and assumptions about what sort of project
could benefit from implementing a particular model. With this in regard, one can
conclude that a process paradigm provides a framework that may be adapted to
form a process which suits a particular project.
There are three major process paradigms that are commonly used today in software
engineering practice; the waterfall model, component-based software engineering
and evolutionary development.
The Waterfall Model
The Waterfall Model is recommended for large and complex systems that have a
long life-time2. Some systems which carry these attributes are also critical systems.
This means that if a fault would occur, it may result in:
Threat to human life (death or injury)
Economic loss
Environmental damage
It is believed that the waterfall model would be an appropriate choice when
developing a critical system, since the model emphasizes on thoroughness.
The basic concept is to take all the activities and treat them separately. One activity
is always followed by another, in the same way water travels down some falls. This
description becomes even more obvious when looking at a visualization of the
model.

5 | P a g e
1. Requirements definition:
All requirements on the system are found by talking to system users. Example
of requirements can be services, constraints and goals, such as “We want a
webpage that color-blind people can enjoy”.
2. System and software design:
In this activity, the overall architecture of the system is established.
3. Implementation and unit testing:
The software is implemented in units which also are tested.
4. Integration and system testing :
The units are merged together into a complete system. Further testing is
required.
5. Operation and maintenance:
The system is delivered to the customer and put into operation.
“Bugs” are almost always found, and therefore the system required bug-
fixing and maintenance.
In each of the activities described above, one or several documents are
produced. The idea is not to start on a new activity until the documents
belonging to the previous activity is signed off, but in practice, this is not
how it is done. Instead most of the activities overlap and all the
documents feed information to the different activities. Although these
documents provide a good overlook.
3. Game Engine
3.1. Game Framework
To save time in our development process, we choose to use Unity 3d, when
developing our game.
3.2 .Unity 3D
Unity is a cross-platform game engine developed by Unity Technologies and used
to develop video games for PC, consoles, mobile devices and websites. First
announced only for Mac OS, at Apple’s Worldwide Developers Conference in

6 | P a g e
2005, it has since been extended to target more than fifteen platforms. It is now
the default software development kit (SDK) for the Wii U.
Unity Pro is available for a fee and Unity Personal has no fee; it is available for any
use to individuals or companies with less than US$100,000 of annual gross
revenue. On March 3, 2015 with the release of Unity 5.0, Unity Technologies made
the complete engine available for free including all features, less source code and
support. Unity is noted for an ability to target games to multiple platforms.
Five versions of Unity have been released. In 2006 at the 2006 WWDC trade
show, Apple, Inc. named Unity as the runner up for its Best Use of Mac OS X
Graphics category.
3.3 Car Physics:
In this scene, we want to start to affect the player’s car through the use of forces
and torques (angular forces) rather than position and rotation directly. This has
several advantages including more realistic motion, but more importantly, we
don’t have to multiply movements by Time. The deltaTime when working with
physics because forces are already time independent. Once again, start by opening
up the Basic Setup scene, then click on Car Control -> 4 Physics -> carcontrol.js
and examine it in the Inspector panel.
In this section we will build the first version of a raycast car. A raycast car is a car
which slides over the ground. Its wheels don’t spin as at drives forward; in this
respect it is actually more like a snowmobile than a car. Every frame we apply a force
to move it forward. It doesn’t move sideways because we will use a Physic Material
with anisotropic friction. Anisotropic friction is a necessary part of a game involving
motion because it allows you to have different friction values for forward or
sideways motion. When moving sideways we will use a much higher friction value
than forward. This will make the car tend to slide forward instead of sideways and
follow the front wheels when they are rotated. We’ll use a simple, three-step process
to build the first version of a raycast car for the player to control. First, we want to
create colliders for the car: add a box collider to the car body of Player Car, then add
raycast colliders to each of the four wheels. These are added to an object by selecting
the object in the Scene view or the Hierarchy panel, and then selecting Component
-> Dynamics from the menu bar. A raycast collider simply uses a ray for collision
detection instead of a volume shape; i.e., a sphere. Also attach a RigidBody with a
mass of 10 to the Player Car. Second, create a Physic Material and set it up as shown
in the following screenshot. Rename it WheelMaterial and move it to the 4 Physics
directory. Assign this new material to all the 4 wheels using drag and drop.

7 | P a g e
3.4. Advanced Car Physics:
In this section we’re going to improve the raycast car. The main change we’ll make
is that we will now rotate the wheels instead of applying a torque to the entire car to
make it rotate. Start by opening up the Basic Setup scene, and adding a box collider,
raycast colliders, and a RigidBody to the various Player Car parts as we did on page
12 in the previous section. Save as... the scene now in the 5 More Physics directory
naming it simply Physics. Now create and save two new Physic Materials – one for
the back wheel named BackWheel, and one for the front wheel named FrontWheel.
These will give us more control over the car handling, because we can tweak and
fiddle with the friction values for the front and back wheels as separate entities in
the Inspector. Set these up using the values as shown in the smaller Physic Materials
setting screen shot in the left sidebar on page 12. Notice how we refined the values
we’ve assigned the Physic Materials by adding a springy contact to the wheel’s
physics material to make it soft. This is done by enabling the use Spring flag, and
setting spring to 25 and damper to 5. Feel free to play around with these values to
get the dampers in your car right. We can now Run this scene and watch the
improved motion of our car. Now let’s tackle the script associated with this scene:
PlayerCar.js. There’s two things in this script that will give the car better physics in
this section. 1) In the script we will now tweak the center of mass and inertia tensor
so that the car has a lower center of mass (to prevent it from flipping over too easily).
2) We remove the torque from the car because we’ll modify the rotation of the
wheels based on the input horizontal axis instead of torque. When we attach this
script to the player car, the four declared variables will have to be connected in the
Inspector so that the script knows which variable is associated with which wheel
(shown at top left).
Figure: Car physics with while collider

8 | P a g e
4. The Game Camera:
The goal of this shorter section is to create and manage a camera to follow the
player’s car as it races around the track. In a racing game, one of the most common
camera views is from a third-person perspective; that is, behind and slightly above
the player. This project will show you how to create one of these cameras and then
to move it along in a fluid manner with the player car. In more advanced games
you might wish to set up numerous cameras to capture the action from different
angles. This more complex camera work is done by enabling and disabling various
cameras based on user input.
4.1. Basic Camera:
Let’s start by first simply getting the main camera positioned above and behind the
player car. Open our previous scene’s Physics.unity scene. Camera Control Scripts
-> 1 Basic Follow Camera and name the file Camera. This scene contains all of the
elements and scripts from the previous section of the tutorial. Now attach the
Camera.js script to the main camera. The Camera.js script has a distance and
height variable that we will be able to modify from the Inspector, but also a
"target" variable that we will need to assign to the player’s car. Connect this
variable to the player car object the same way we connected the wheel control
variables to the wheel objects of the car object.
The Camera.js script is very simple:
1. We set up variables for height, distance and target.
2. We use the function LateUpdate in this script to make sure that this particular script
runs after any other scripts that are run during a frame.
3. It gets the position and direction of the car to position itself.
4. It places itself a specific distance and height behind the target using variables. In this
instance we’ve specified in the script that behind means along the negative z-axis of the
target. Then we move the camera upwards by height, so the camera looks down on the car.
5. We rotate the camera to always look at the target. Run the scene and drive the player
car to see the camera in action. Neat! But this is a very simple solution. What we’d really
like to see is the camera reacting better to the motion of the player car. We need to create
and use a camera script that smoothes out the motion of the camera as it follows the car.
4.2. Smooth Camera:
Start again by opening the Physics.unity scene.Camera Control Scripts -> 2
Smooth Camera and name the file Smooth Camera. This time, attach the Smooth
Camera script to the main camera. Connect the target variable to the car object as
we did in the previous scene and Run the scene to see the camera react more

9 | P a g e
smoothly to the car’s movement. What’s now happening is that this camera script
smoothes out rotation around the y-axis and height, while still maintaining a static
horizontal distance. This method gives you a lot of control over how the camera
behaves because you can tweak lots of the variables. For every of those smoothed
values we calculate a wanted value and the current value. Then we smooth it using
the Lerp function.
The Smooth Camera.js script is very simple.
1. We set up variables for height, distance and additionally for damping.
2. We calculate both current and wanted rotation and height for the camera.
3. We dampen the height and rotation by using the Lerp function (explained below).
4. We convert our rotation calculation from degrees into radians so that the Quaternion
interface understands it.
5. In this part we finally position the camera where we want it and point the camera to
always look at the target. Run the scene and drive the player car to see the improved
camera in action. Notice that we’re using specifically the Mathf.LerpAngle to damp the
rotation around the player car’s vertical (y) axis, and using Mathf.Lerp to damp the height.
It also uses some other basic functions built into Unity such as EulerAngles, Time.
deltaTime and others. Most of the rest of the script uses basic variables and functions to
move the camera with the car. It’s now time to add opponent vehicles and program them
to race around the track against the player. Otherwise known as the "cool stuff."
Figure: Main camera inspector

10 | P a g e
5. The Other Cars and AI:
This section is where the fun begins. Up until this point we’ve been focusing on
getting a car under the control of the player and also to set up a simple camera that
will smoothly follow the car along a race track. But this is a "racing" game – we
certainly need some other cars on the track that will race around the course trying
to beat us. It will be the most difficult to date as the scripts in this section are more
advanced than anything we’ve looked at so far, mainly because we need to create a
method for opponent cars to drive themselves around the track. To begin the
section we’ll start by creating a car that drives itself around the race track. This car
will be duplicated in the scene to create multiple opponent cars.
Many different types of pathfinding problems exist. Unfortunately, no one
solution is appropriate to every type of pathfinding problem. The solution depends
on the specifics of the pathfinding requirements for any given game. For most racing
game, the artificial intelligence (AI) for opponent characters is needed to find there
path . In our paper, we focus on the car racing game, which can be seen as a kind of
pathfinding problems.
In a car racing game, pathfinding is one of the most important problems. Poor
pathfinding can make game characters seem very headless and artificial. Handling
the problem of pathfinding effectively can go a long way toward making a game
more enjoyable and immersive for the player. The A* algorithm provides an effective
solution to the problem of pathfinding and it also be one of the most popular
algorithm used for the game’s development . Assuming a path exists between the
starting point and the ending point; then the A* algorithm guarantees to find the
best path. Although the A* algorithm is efficient, it still can consume considerable
CPU cycles, especially if you want to simulate pathfinding for a large number of
game characters. The chief shortcoming of the A* algorithm in a racing game is that
it can not solve the problem of random dynamics obstacles avoidance.
In this project, we will first study the A* algorithm in a car racing game, and then
proposes two modified A* algorithm to do pathfinding. After that, we propose a
more general dynamic pathfinding algorithm to solve the problem of random
dynamics obstacles avoidance. All the three algorithms are able to find the path for
a car racing game and can save the most import resource in game, CPU cycles.
6. Materials and Methods:
For a car racing game, the most common artificial intelligence is waypoint
navigation by carefully placing points (nodes) in the game environment to move the
game- controlled characters between each point. The major drawback of this
method is that these waypoints need to be manually setup, and it is a time
consuming work. Meanwhile, these waypoints will depend upon the speedway
track; different speedway track requires different configuration waypoints. In
addition, the number of waypoints and the location of waypoints are also different

11 | P a g e
due to human factors. In order to overcome these problems, we propose two
modified A* algorithms to solve them. Finally, a more general dynamic pathfinding
algorithm which can solve the random obstacles avoidance problem in a racing
game is also proposed. In our paper, we will use the A* algorithm, to find the
shortest path while avoiding the obstacles. The A* algorithm uses path scoring to
determine the best path from the starting node to the destination node. To actually
score each node, A* basically adds together two components. First, it looks at the
cost to move from the starting node to any given node. Next, it looks at the cost to
move from the given node to the destination node.
Equation (1) shows the equation used for scoring any given node. This equation
computes each node's score by adding the cost of getting there from the starting
location to the heuristic value, which is an estimate of the cost of getting from the
given node to the final destination.
f(n) = g(n) + h(n) (1)
where g(n) is the total distance; it has taken to get from the starting position to the
current location. h(n) is the estimated distance from the current position to the goal
destination. A heuristic function is used to create this estimate on how far away it
will take to reach the goal state. f(n) is the sum of g(n) and h(n). This is the current
estimated shortest path. The pseudo code of A* algorithm is shown as Fig. 1
add START to OPEN list while OPEN not
empty
get node n from OPEN that has the lowest f(n) if n is GOAL
then return path
move n to CLOSED
for each n' = CanMove(n, direction) g(n') = g(n) + 1
calculate h(n')
if n' in OPEN list and new n' is not better, continue
if n' in CLOSED list and new n' is not better, continue remove any n'
from OPEN and CLOSED
add n as n's parent add n' to OPEN end for
end while
if we get to here, then there is No Solution
.
Fig. 1. Pseudo code of A* algorithm

12 | P a g e
6.1. Implementing the A* algorithm
Because the first step in pathfinding is to define the search area, we need some way
to represent the game world in a manner that allows the search algorithm to search
for and find the best path. In our game, we use the trick of color collision to do the
collision detection. Using this trick you first need to make a collision detection map,
as shown in Fig. This can be done easily by using any image processing software
(e.g., Photoshop), and then changes the track to the color which users want to set it
as the collision detection color (e.g., block color). Everything else in the collision
detection map, where the cars are not allowed to drive, you just need to paint them
to white (or any color just do not use the track color black). Ultimately, the game
world is simplified by placing 1280*782 nodes, throughout the game environment.
White color nodes represent obstacles and other colors nodes represent the nodes
which can be passed. After that, we have divided our search area into a 1280*782
square grid. This particular method reduces our search area to a simple two
dimensional array. Each item in the array represents one of the squares on the grid,
and its status is recorded as passable or un-passable. The path is found by figuring
out which squares we should take to get from node A to node B. Once the path is
found, the game-controlled car moves from the center of one square to the center of
the next until the target is reached.
In the implementation of our A* algorithm, each time step only four adjacent
nodes (up, down, right and left) will be checked, as shown in Fig. 2. In Fig. 2 the
blue node represents the current node and the green nodes are the adjacent nodes.
In addition, the image size of car is 18*12 pixels and moving speed is two pixels per
time frame. The racing game uses the default frame rate setting in XNA (60 frame /
sec). Therefore, the maximum linear velocity of the car is equal to 120 pixels per
second.
Fig. 2. The current node and the adjacent nodes in A* algorithm

13 | P a g e
6.2. The first modified A* algorithm: reducing waypoints by a line-of-
sight algorithm
As you known, the more nodes placed in the game world the slower the
pathfinding process. If we simplify the search area by using fewer nodes, the
pathfinding work will save many CPU cycles. In our study, we first used the
original A* pathfinding algorithm to find the best path between the start waypoint
and the end waypoint.
After that, we refine above found path by considering a line-of-sight algorithm to
further reduce the number of nodes.
To implement this, the mathematical formula of the Pythagoras Theorem for
triangles is used. It first calculates the way length (distance) between the two
different nodes. If there is no obstacle across the way, then no collision occurs, as
shown in Fig. 3 the waypoints (1, 2) and waypoints (1, 3). Because the waypoint 2
is between the waypoint 1 and 3 and there is no collision occurs, we can remove
the waypoint 2 using the shortcut 1-> 3 instead of the path 1-> 2-> 3. This line-of-
sight process will continue until the end waypoint reached.
Fig. 3. Modified A* algorithm by a line-of-sight algorithm
6.3. Dynamic path finding algorithm for random obstacles
avoidance
In order to generalize the pathfinding algorithm in a racing game solves the
dynamic obstacles avoidance problem. We have recently proposed a dynamic
pathfinding method. Two collision detection points are put in front of the car’s right
side and left side, as shown in Fig. 4. Where the variable y is the half width of car,
that is 6 pixels, and the collision detection distance x is an adjusted variable
indicated the distance from the car center to the center of the two collision detection
points.

14 | P a g e
Fig. 4. Collision detection points of car
How do we actually perform the collision detection in this algorithm? It is easy.
We just need to put several color detection points in front of (or around) the moving
car. Anytime, if the position of the car’s color detection point its color is the same as
the track color (black), then no collision occurs. Otherwise, if the position of the
color detection point its color is white (or not the track color), indicating the car is
leaving the track, which means the car needs to turn a direction to keep the car
inside the track. In our game’s implementation, we will calculate the car’s position
in advance. If in the next time frame the collision is detected. We just simply turn a
default setting radian for the car to avoid collision. In other words, when the
detection point of left front touches the edge of track, the car will turn in a clockwise
direction. Otherwise, the car will turn in a counterclockwise direction, if the
detection point of right front touches the edge of track. In order to make the game-
controlled car look more natural and smooth, the car’s rotation speed is set to 0.25
radians (14.3 degrees) in this study.
Figure: New collision detection points when two original collision
detection points are activated at the same time
7. Designing the Car Model:
For designing the car required for the game, we had to sketch out a blueprint
which would fulfill all the requirements for the game.
First we need to get hold of some blueprints of the car that we want to model. We

15 | P a g e
tend to use www.the-blueprints.com.
Once we have the blueprint we opened Photoshop (or equivalent imaging
program). Then pressed Ctrl+O to bring up the open window, and on finding our
blueprint, we opened the file. The window looked similar to the one below.
Next using the marquee tool (shortcut M) we created a selection box around the
top view of our chosen car. (See below image)
Once selected we pressed Ctrl+C to copy the selection then Ctrl+N to open a new
document. Then pasted the selection into that new document.

16 | P a g e
After doing that we moved onto the next view, which was
going to be the side view. To do that we simply moved the
existing selection box to the bottom of the wheels, and then
right clicked (RMB) and choose the option “Transform
Selection Tool”. Then we moved the top of the box down so
that it was just above the top of the car then we pressed
enter to confirm the change. We copied the selection and
pasted it to the same document as the top view we did.
Using that method, we did the same for the Front and Rear
views also.
Then we had all four views in a single document as individual layers we saved them
as Individual JPG files. To do this hide the side, front and rear views so that all we
saw the top view. We pressed Ctrl+Shift+S to open the saved document. Before
saving we made sure that we had changed the file type to JPEG and
called it something like “Top” or “Top View”.
We did that
for all four
views to make
sure that we
could only see
one image at a
time.
After we saved them as individual image we saved them as a PSD (Photoshop’s
native file type) file as well.

17 | P a g e
Then we opened
3Ds Max.
We started by creating the planes. In the top viewport we created a plane of any
size. In the modify panel, we changed the size of the plane to match the size (In
pixels) of the top view for the car. Our image size was 2662x1386. (Note: in 3ds
Max the length value is the second number we would see in the explorer window.
In our case length is 1386 and our width value is 2662)

18 | P a g e
Now we had our first plane we needed to create 3 more. There was more than one
way of doing this but we found this way to be the quickest. We pressed the snap
rotation button (Circled in the image below) then pressed the “select and rotate”
button (Shortcut E).
Holding Shift we rotated the plane on the X-axis (the red one) we needed to rotate
90 degrees.

19 | P a g e
Continue to do this until you have 4 planes that look similar to the
image below.
Then we had the 4 planes set up, we wanted to add the blueprints to
them. We opened the Materials window (Shortcut M), then clicked
the small box next to diffuse (right) which opened a new window
(below). We double clicked on “Bitmap” to “Open file” window. Then
we navigated through our file and found our blueprints then double
clicked on one of them.

20 | P a g e
Then we had our blueprints in 3ds Max
changed the name of the material (for the
front image we called the material “Front” or
“Front View” and changed the Self-
Illumination to 100 (see left). We repeated
this for each of the views.
Once we had all four images in 3ds Max we made
sure the “Visible in Viewport” (Right: Right Circle) was
clicked on. We choose the plane we wanted to add
the image to (In our example we used the top view)
and clicked “Add Material to Selected”. Our screen
should look similar to the one below.

21 | P a g e
We did this for all four planes. After this was done we selected all four planes and
right clicked, then we choose “Object Properties” to open a new window. Then we
unchecked “Show Frozen in Gray” and “Renderable”. Next we checked “Backface
Cull” (this made the back of the planes invisible).

22 | P a g e
Then we converted all four planes to editable polygon.
After selecting one plane (front, side or rear) and we checked
the “Preserve UVs” box (right). This allowed us to move edges
of the plane without affecting the image.

23 | P a g e
Then we changed to sub-object mode and selected Edge (box with a picture of a
triangle). On the side view of the car we selected the top (or bottom) edge and moved
it down (or up) until no white remained. We were careful not to cut off the top of the
car. Then repeated the process for the other views, getting rid of any white parts.
Once our planes had no white borders it was time to move them into position. Using
the “Select and Move” tool we moved the side view back to the edge of the top view.
The front and back views went to either end of the top view. (Note: Front view
should be positioned at the rear end of the car and the rear view at the front end).
Then we moved the top view down to the bottom of the side view (See below).

24 | P a g e
Then we selected all planes, right clicked and selected “Freeze Selection”.
Then we saved the file and modelled our car.

25 | P a g e
8. Creating Terrain
8.1. Basic Concepts
A. Coordinate Space
Three axes X, Y and Z – based on the Cartesian coordinate system
(René Descartes, 1637)
B. User Interface
File > New Project
We don’t have to import any of the packages at this point, but do specify
the save to location in the dialog window. We kept all our project related
assets in this location to avoid missing files and broken links later in the
game development process.
File > Save Scene as…
Window > Layouts > 2 by 3

26 | P a g e
User Interface Components (see screenshot on previous page):
1. Scene: This is where you will place any visual assets in your Unity
environment. It will update in real-time when you are previewing the game.
Note the manipulator on the top right; this allows you to switch between a
number of standard views. We are currently in the perspective view (toggle
between isometric (2D) and perspective (3D)). Although this doesn't matter
too much, it allows us to view our scene with a vanishing point, which is the
standard way Unity games will display.
2. Game: When you're not actively running the game, it will show a rendering
of how the game will look, ignoring graphical effects that need to be computed
at run-time, from the point of view of the main camera. When you're
previewing the game, you'll be playing through this window. Since our scene
is currently empty, all this window is showing is the background color.
3. Hierarchy: This lists all the objects in the currently loaded scene, and any
children they may have. Children are objects that can be thought of as
subordinate to the parent object; wherever the top object moves, they'll
follow, keeping the current offset they have to this object. This is an
important concept for Unity beginners to understand; we'll cover it more in
detail later and in the workshops.
4. Project/Assets view: This is a list of all custom assets for our game,
including graphical assets, sound, scripts (more on these later), prefabs
(pre- assembled game objects), and much more. Our current game is
currently using only one empty scene (titled “myFirstScene”).
5. Inspector: Since we currently don't have any objects selected in the
Hierarchy or the Project/Assets view, it's completely blank. The inspector
allows us to look at and tweak individual settings of various game objects and
assets, as well as adjust some global settings. The Inspector is content-
sensitive and changes its parameters based on which game object/asset is
selected. This is also a place to show you your project settings and
preferences by choosing them from the Edit menu.
6. Graphical icons for moving the scene and its contents. The hand
allows us to pan around the scene; when combined with other scene camera
controls, Unity becomes very easy to navigate (see below). The icon on its
right, which looks like four arrows, allows you to move a selected object
around. We call this transforming the object. The next icon allows for rotation
of the object, and the final one allows for uniform scaling of the object.

27 | P a g e
7. Playback bar. This allows us to play, pause, and stop running our game in
the Unity editor. This is the quickest and easiest way to test and tweak the
game.
C. Navigating the scene window
The scene view is what allows us to look around and move the visual assets we
import into Unity. It's how you'll assemble your levels and place important things
like lighting, trigger zones, audio, and much more. Being able to control the
camera is important if we want to do anything at all with it.
Hand Tool (shortcut Q): drag around in the scene to pan our view.
Holding down alt+drag will rotate the view, Ctrl.+drag will allow you to
zoom. It is important to remember that this doesn't move anything in the
scene, just your point of view.
Translate Tool (shortcut X): active selection tool, enables to drag an
object’s axis handles in order to reposition it.
Rotate Tool (shortcut E): using handles to allow us to rotate an object
around either of its axes.
Scale Tool (shortcut R): works the same as the previous two tools, allows
scaling of an object.
D. Our First Unity3D Scene
Now that we can look around the scene, let's learn a few ways we can place things
in it. First we'll take a look at the basic game objects Unity can create without
importing external assets. Unity 3 has geometric primitives (cubes, spheres,
planes, capsule, etc.), lights, particle systems, cameras, and more that it can
create without needing external assets. To access these, go to the top menu bar,
select Game Object ->Create Other and make a choice. To begin with, try making
a simple scene with a cube (functioning as a floor), a sphere, and a light. There's
three different types of light - for now, a directional should work just fine, as light
travels in rays with the direction of the arrows of the light, a good way to simulate
the sun in Unity.
Start by creating a cube:
Game Object > Create Other > Cube

28 | P a g e
We can already use the Inspector window (after selecting the cube in the
hierarchy) to modify its scale properties: Scale: X: 25, Y: 1, Z: 25 and to translate
it Position: X: 0, Y: - 10, Z: 0
Now we just need to move our camera a little back and point it downward to see
the newly created box (it looks more like a plane now, see screenshot on the
following page – we changed the view in the Scene window to left-isometric)
Position: X: 0, Y: 0, Z: -25; Rotation: X: 20, Y: 0, Z: 0;
Tip: If we would like to remove a game objects from the hierarchy/scene –
select them press command+delete or go to Edit>Delete.
E. Basic lights
See: http://docs.unity3d.com/Documentation/Components/class-Light.html
• Directional lights are placed infinitely far away and affect
everything in the scene, like the sun.
• Point lights shine from a location equally in all directions, like a light bulb.
• Spot lights shine from a point in a direction and only illuminate objects
within a cone - like the headlights of a car.
• Area lights (only available for lightmap baking) shine in all directions to

29 | P a g e
one side of a rectangular section of a plane.
We create a directional light source to illuminate the box in the Game window:
Game Object > Create Other > Directional Light
We should also move the light source a little back, up and tilt it downward to
see its effect on the box object:
Position: X: 0, Y: 10, Z: 20; Rotation: X: 30, Y: 180, Z: 0;
See the change in how the light affects the visual appearance of the
box by experimenting with different angles and directions of your
light source: For example:
Position: X: 0, Y: 10, Z: -20; Rotation: X: 30, Y: 0, Z: 0;

30 | P a g e
F. Basic Physics and Materials
First, create a sphere and place it above the ground plane:
Game Object > Create Other > Sphere
Position: X: 0, Y: 2, Z: 0; Scale: X: 4, Y: 4, Z: 4
Since there is a main camera that comes with every scene, you could hit the play
button now and view your scene. Unfortunately, it will be entirely static. You
can't control the movement of the camera and none of the scene is moving itself.
It would be nice if the sphere would behave as we expect it to from our
observations in the real world – it would fall down and bounce (to a certain
extend) when hitting the ground plane. We can simulate this behavior thanks to
Unity3D’s built-in physics engine.
The first thing we need to do is to give the sphere a rigid body component.
Select the sphere and go to: Component > Physics > Rigid Body.
Hit the play button and you see how the sphere is falling, but not bouncing.
In the next step we create a physic material, which will provide the material
properties to make the game object bouncy:
Asset > Create > Physics Material

31 | P a g e
Then drag the newly created physics material from the Asset window onto the
“Sphere” game object in the Hierarchy window (or directly onto the sphere in the
Scene window).
We experimented with the properties of the physics material to make it behave
like a rubber ball – from the default settings, we changed Bounciness to 0.8 and
Bounce Combine to Maximum (for more information on the properties of physic
materials see: http://docs.unity3d.com/Documentation/Components/class-
PhysicMaterial.html).
Hit the play button and see how the sphere is bouncing similar to a rubber ball.
We started experimenting with different heights from which the ball is falling as
well as different angles of the box to see what response they create in the
behavior of the sphere.
G. Creating Materials:
Assets->Create->Material
We will see the new material in you Project/Assets window and its properties in
the Inspector window. In order to change its color double click the color swatch
next to Main color and choose a different color. We apply the material to a game
object by simply dragging it from the Project window onto the game object in

32 | P a g e
the Hierarchy window (like you did when you applied the physics material
above). We can then start tweaking the material’s properties by experimenting
with different shaders from the shader drop-down menu in the Inspector
window.
Another way to change the visual appearance of game objects is to use 2D
textures. A good overview of 2D texture features in Unity is in this chapter of
the software’s documentation: http://unity3d
.com/support/documentation/Components/class-Texture2D.html. I hope we
can take a closer look at textures in one of the following workshops.
H. Using the Terrain Editor and Prefabs (First Person Controller)
After we have learned how to create simple primitive geometries in Unity3D
and attach physics properties to them, let’s explore how we can use prefabs to
move around a virtual environment interactively, using a first person point of
view.
We also create a terrain, so we have a very basic environment to explore. We
can use Unity’s Terrain editor to do this – we start with a simple plane, which
can be easily turned into a topographical landscape.
Note: In 2004 the art ensemble Futurefarmers created Fingerprint Maze a very

33 | P a g e
charming interactive artwork by automatically generating a terrain from
audience member’s fingerprint scans. Visitors were then able to navigate
through their own fingerprint terrain in a first person perspective, see
http://www.futurefarmers.com/survey/fingerprint2.php
First create a new Scene and save it. Then create a terrain:
GameObject > Create Other > Create Terrain.
Access its heightmap resolution by selecting the Terrain in the Hierarchy
window and then working with its resolution properties in the Inspector
window.
I also moved the camera up and over a little, this helps you seeing the original
plane for the terrain a little better: Position: X: 500, Y: 100, Z: 0
I changed the view in the Scene window to top view by clicking on the view
manipulator icon in the Scene window’s top right corner (top-isometric).

34 | P a g e
Now, using the Raise/Lower Terrain tool in the
Inspector window (make sure the Terrain is selected
in the Hierarchy window), I can simply “draw” on
the top view of the ground plane in the Scene
window to create certain terrain features.
I used Brush Size: 70 and Opacity: 90 to create
shapes that are immediately visible, but you can
fine-tune these settings based on what we have
created.
We also already created a directional light (Position: X: 500 Y: 150 Z: 500 and
Rotation: X: 20 Y: 80 Z: 0) so the terrain’s features would look a little more
dramatic.

35 | P a g e
Experiment also with some of the other terrain paint tools, such as “lower terrain
height”, “set terrain height” and “smooth terrain height.”
To see a larger version of your terrain for working on it select the Scene window
and press the “space” bar – this will maximize the window (hitting the space bar
again allows you to return to the regular 2 by 3 layout).
This time we created a terrain manually by “drawing” on the ground plane.
However, you can also import heightmaps to create terrains from actual
images/maps/drawings.
9. Track Design
Select New EasyRoads3D Object from the EasyRoads3D Menu. A dialog
window will appear where you can name the new road object. The new road
object will be added to the hierarchy panel after clicking the Create
Object button.

36 | P a g e
In the property Inspector you will
see the EasyRoads3D toolbar:
9.1. Add Road Markers
Add road markers by activating the Add Markers toolbar tab. Move the mouse to
the position where you want the road to start and click the left mouse button
while holding the [shift] key.
Continue adding markers according the shape of the desired road. We will see
that the road system will create surfaces representing the road and the affected
surrounding which are configurable in General Settings.
9.2. Insert Road Markers
Insert road markers works similar as adding road markers but instead of adding
the marker at the end of the road, it will insert the marker between the 2 closest
markers to the mouse position. Make sure you are in Insert Markers mode by
activating the Insert Markers toolbar tab!
NOTE: In order to add or insert markers make sure is active!
Additional Marker Functions
When two markers are selected you will see the below buttons in the Inspector:

37 | P a g e
Align XYZ: This will align all markers
between the two selected markers on a
straight line
Align XZ: This will align all markers
between the two selected markers on the x
and z-axis
Align XZ Snap Y: This will align all
markers between the two selected markers on the x and z-axis and snap the y
position to the terrain height at that position.
Average Heights: This will average the heights of all markers between the two
selected markers.
Procedural Object Editor Window:
For procedural objects we defined the shape of the object in the Procedural
Object Editor Window. This window will open when we click the button "Edit
Geometry" on the right of the Object Type combo box. This button will become
visible when "Procedural Mesh Object" is selected.

38 | P a g e
The editor window gives a 2D representation of the shape of the procedural
geometry. We can define any shape we want:
1. Add new vertical positions by double clicking on the stage there where we
want to position the new point. Points will be connected to give a clear idea of
the shape.
2. Move points by selecting them (the point turns red) and dragging it while
keeping the mouse down.
3. Delete points with the "Backspace" or "Delete" key.
Controls / Hot Keys:
 [Shift] click: Select and drag or delete multiple points
 [Control] double click: Insert a point between the two closest points
 Z key: Zooms the grid so all the points are clearly visible
 R key: Resets the zoom and positioning to the original values
 Mouse down: and drag, will move the grid
 [alt] drag stage on Y-axis, Mouse scroll, [Command] & drag, right mouse
button & drag: Zooms in / out on the grid.
Side Object Geometry Controls:
1. Selected Index: When we select a point the associated index value will be
displayed in the ComboBox. The purpose of this is become explained in the
NOTE here below.
2. Close Geometry: When checked, the first and last point will connect.
3. Trace Object: if we added a Start or / and End object to the associated slots
in the Object Manager this object will appear here. It can be used to
analyze the geometry and automatically define the shape of the procedural
geometry accordingly. Make sure that those vertices used to connect the start
and end assets with the procedural with each other are at position 0 on,
depending on our modeling application, the y-axis or z-axis.
4. Trace On: Depending on the rotation of the asset we may have to switch
between x-axis, y-axis and z-axis until we clearly see the shape that the
procedural geometry should have. By default objects are traced on the z-axis
when opening the editor window and no points are stored yet for this side
object.
5. Auto Connect: Below the situation is described where we can clearly see
that the dots are positioned correctly but they do not connect in the right
order. Auto Connect will be enabled when we select the first point, from this it

39 | P a g e
will connect all points according the closest neighbor. Depending on the
geometry structure it may simplify reordering of point indexes.
6. Mirror Horizontally: This mirrors the shape horizontally and is useful
when correcting the shape of a duplicated side object or when it turns out that
tracing the geometry of the start or end asset results in a flipped shape.
7. Mirror Vertically: This mirrors the shape vertically.
8. Flip Faces: It may happen that the normal point in the wrong direction, we
will notice this when rendering the side object. This button will flip the faces
so it will appear correctly. This feature is also available in the Side Object
Inspector.
10. Coding
10.1. AI Script:
var centerOfMass : Vector3;
var path : Array;
var pathGroup : Transform;
var maxSteer : float = 15.0;
var wheelFL : WheelCollider;
var wheelFR : WheelCollider;
var wheelRL : WheelCollider;
var wheelRR : WheelCollider;
var currentPathObj : int;
var distFromPath : float = 20;
var maxTorque : float = 50;
var currentSpeed : float;

40 | P a g e
var topSpeed : float = 150;
var decellarationSpeed : float = 10;
function Start () {
rigidbody.centerOfMass = centerOfMass;
GetPath();
}
function GetPath (){
var path_objs : Array = pathGroup.GetComponentsInChildren(Transform);
path = new Array();
for (var path_obj : Transform in path_objs){
if (path_obj != pathGroup)
path [path.length] = path_obj;
}
}
function Update () {
GetSteer();
Move();
}
function GetSteer(){

41 | P a g e
var steerVector : Vector3 =
transform.InverseTransformPoint(Vector3(path[currentPathObj].position.x,tran
sform.position.y,path[currentPathObj].position.z));
var newSteer : float = maxSteer * (steerVector.x / steerVector.magnitude);
wheelFL.steerAngle = newSteer;
wheelFR.steerAngle = newSteer;
if (steerVector.magnitude <= distFromPath){
currentPathObj++;
if (currentPathObj >= path.length)
currentPathObj = 0;
}
}
function Move (){
currentSpeed = 2*(22/7)*wheelRL.radius*wheelRL.rpm * 60 / 1000;
currentSpeed = Mathf.Round (currentSpeed);
if (currentSpeed <= topSpeed){
wheelRL.motorTorque = maxTorque;
wheelRR.motorTorque = maxTorque;
wheelRL.brakeTorque = 0;
wheelRR.brakeTorque = 0;

42 | P a g e
}
else {
wheelRL.motorTorque = 0;
wheelRR.motorTorque = 0;
wheelRL.brakeTorque = decellarationSpeed;
wheelRR.brakeTorque = decellarationSpeed;
}
}
10.2. Path Finding Script:
var path:Array;
var rayColor:Color=Color.red;
function OnDrawGizmos()
{
Gizmos.color=rayColor;
var path_objs:Array=transform.GetComponentsInChildren(Transform);
path=new Array();
for(var path_obj:Transform in path_objs)
{
if(path_obj!=transform)

43 | P a g e
path[path.length]=path_obj;
}
for(var i:int=0;i<path.length;i++)
{
var pos:Vector3=path[i].position;
if(i>0)
{
var prv=path[i-1].position;
Gizmos.DrawLine(prv,pos);
Gizmos.DrawWireSphere(pos,0.3);
}
}
}
Car control script:
#pragma strict
var WheelFL : WheelCollider;
var WheelFR : WheelCollider;
var WheelRL : WheelCollider;
var WheelRR : WheelCollider;

44 | P a g e
var wheelFLTrans:Transform;
var wheelFRTrans:Transform;
var wheelRLTrans:Transform;
var wheelRRTrans:Transform;
var lowestSteerAtSpeed:float=50;
var lowSpeedSteerAngle:float=10;
var highSpeedSteerAngle:float=1;
var deccelarationSpeed:float=20;
var currentSpeed:float;
var maxReverseSpeed:float=50;
var topSpeed:float=200;
var backLightsObject:GameObject;
var idleLightMaterial:Material;
var breakLightMaterial:Material;
var reverseLightMaterial:Material;
var maxTorque:float=250;
var braked:boolean=false;
var maxBrakeTorque:float=100;
private var mySidewayFriction:float;

45 | P a g e
private var myForwardFriction:float;
private var slipSidewayFriction:float;
private var slipForwardFriction:float;
function Start () {
rigidbody.centerOfMass.y=0.0;
//rigidbody.centerOfMass.x=0.4;
//rigidbody.centerOfMass.z=0.4;
SetValues();
}
function FixedUpdate () {
Controle();
handBraked();
}
function SetValues(){
mySidewayFriction=WheelRR.forwardFriction.stiffness;
myForwardFriction=WheelRR.forwardFriction.stiffness;
slipForwardFriction=0.4;
slipSidewayFriction=0.8;
}

46 | P a g e
wheelFLTrans.Rotate(WheelFL.rpm/60*360*Time.deltaTime,0,0);
wheelFRTrans.Rotate(WheelFR.rpm/60*360*Time.deltaTime,0,0);
wheelRLTrans.Rotate(WheelRL.rpm/60*360*Time.deltaTime,0,0);
wheelRRTrans.Rotate(WheelRR.rpm/60*360*Time.deltaTime,0,0);
wheelFLTrans.localEulerAngles.y=WheelFL.steerAngle-
wheelFLTrans.localEulerAngles.z;
wheelFRTrans.localEulerAngles.y=WheelFR.steerAngle-
wheelFRTrans.localEulerAngles.z;
backLights();
WheelPosition();
EngineSound();
}
function Controle(){
currentSpeed=2*22/7*WheelRL.radius*WheelRL.rpm*60/1000;
currentSpeed=Mathf.Round(currentSpeed);
if(currentSpeed<topSpeed && currentSpeed>-maxReverseSpeed && !braked){
WheelRR.motorTorque=maxTorque*Input.GetAxis("Vertical");
WheelRL.motorTorque=maxTorque*Input.GetAxis("Vertical");
}

47 | P a g e
else{
WheelRR.motorTorque=0;
WheelRL.motorTorque=0;
}
if(Input.GetButtonUp("Vertical")==false){
WheelRR.brakeTorque=deccelarationSpeed;
WheelRL.brakeTorque=deccelarationSpeed;
}
else{
WheelRR.brakeTorque=0;
WheelRL.brakeTorque=0;
}
var speedFactor=rigidbody.velocity.magnitude/lowestSteerAtSpeed;
var
currentSteerAngle=Mathf.Lerp(lowSpeedSteerAngle,highSpeedSteerAngle,speed
Factor);
currentSteerAngle*=Input.GetAxis("Horizontal");
WheelFL.steerAngle=currentSteerAngle;
WheelFR.steerAngle=currentSteerAngle;
//WheelFL.steerAngle=10*Input.GetAxis("Horizontal");

48 | P a g e
//WheelFR.steerAngle=10*Input.GetAxis("Horizontal");
}
function backLights(){
if(currentSpeed>0 && Input.GetAxis("Vertical")<0 && !braked){
backLightsObject.renderer.material=breakLightMaterial;
}
else if(currentSpeed<0 && Input.GetAxis("Vertical")>0 && !braked){
backLightsObject.renderer.material=breakLightMaterial;
}
else if(currentSpeed<0 && Input.GetAxis("Vertical")<0 && !braked){
backLightsObject.renderer.material=reverseLightMaterial;
}
else if(!braked){
backLightsObject.renderer.material=idleLightMaterial;
}
}
function WheelPosition()
{
var hit:RaycastHit;

49 | P a g e
var WheelPos:Vector3;
if(Physics.Raycast(WheelFL.transform.position,-
WheelFL.transform.up,hit,WheelFL.radius+WheelFL.suspensionDistance)){
WheelPos=hit.point+WheelFL.transform.up*WheelFL.radius;
}
else
{
WheelPos=WheelFL.transform.position-
WheelFL.transform.up*WheelFL.suspensionDistance;
}
wheelFLTrans.position=WheelPos;
if(Physics.Raycast(WheelFR.transform.position,-
WheelFR.transform.up,hit,WheelFR.radius+WheelFR.suspensionDistance)){
WheelPos=hit.point+WheelFR.transform.up*WheelFR.radius;
}
else
{
WheelPos=WheelFR.transform.position-
WheelFR.transform.up*WheelFR.suspensionDistance;
}
wheelFRTrans.position=WheelPos;

50 | P a g e
if(Physics.Raycast(WheelRL.transform.position,-
WheelRL.transform.up,hit,WheelRL.radius+WheelRL.suspensionDistance)){
WheelPos=hit.point+WheelRL.transform.up*WheelRL.radius;
}
else
{
WheelPos=WheelRL.transform.position-
WheelRL.transform.up*WheelRL.suspensionDistance;
}
wheelRLTrans.position=WheelPos;
if(Physics.Raycast(WheelRR.transform.position,-
WheelRR.transform.up,hit,WheelRR.radius+WheelRR.suspensionDistance)){
WheelPos=hit.point+WheelRR.transform.up*WheelRR.radius;
}
else
{
WheelPos=WheelRR.transform.position-
WheelRR.transform.up*WheelRR.suspensionDistance;
}
wheelRRTrans.position=WheelPos;
}

51 | P a g e
function EngineSound()
{
audio.pitch=currentSpeed/topSpeed+1;
}
function handBraked(){
if(Input.GetButton("Jump")){
braked=true;
}
else{
braked=false;
}
if(braked){
WheelRL.brakeTorque=maxBrakeTorque;
WheelRR.brakeTorque=maxBrakeTorque;
WheelRL.brakeTorque=0;
WheelRR.brakeTorque=0;
SetSlip(slipForwardFriction,slipSidewayFriction);
if(currentSpeed<1 && currentSpeed>-1){

52 | P a g e
}
else{
if(rigidbody.velocity.magnitude>1){
SetSlip(slipForwardFriction,slipSidewayFriction);
}
else{
SetSlip(1,1);
}
}
}
}
function SetSlip(currentForwardFriction:float,currentSidewayFriction:float)
{
WheelRR.forwardFriction.stiffness=currentForwardFriction;
WheelRL.forwardFriction.stiffness=currentForwardFriction;
WheelFL.forwardFriction.stiffness=currentForwardFriction;

53 | P a g e
WheelFR.forwardFriction.stiffness=currentForwardFriction;
WheelRR.sidewaysFriction.stiffness=currentSidewayFriction;
WheelRL.sidewaysFriction.stiffness=currentSidewayFriction;
WheelFL.sidewaysFriction.stiffness=currentSidewayFriction;
WheelFR.sidewaysFriction.stiffness=currentSidewayFriction;
}
10.3. Car Camera Script:
#pragma strict
var car : Transform;
var distance:float=6.4;
var height:float=7.4;
var rotationDamping:float=3.0;
var heightDamping:float=2.0;
var zoomRacio:float=0.5;
var DefaultFOV:float=60;
private var rotationVector:Vector3;
function Start () {
}

54 | P a g e
function LateUpdate () {
var wantedAngle=rotationVector.y;
var wantedHeight=car.position.y+height;
var myAngle=transform.eulerAngles.y;
var myHeight=transform.position.y;
myAngle=Mathf.LerpAngle(myAngle,wantedAngle,rotationDamping*Time.delta
Time);
myHeight=Mathf.Lerp(myHeight,wantedHeight,heightDamping*Time.deltaTim
e);
var currentRotation=Quaternion.Euler(0,myAngle,0);
transform.position=car.position;
transform.position-=currentRotation*Vector3.forward*distance;
transform.position.y=myHeight;
transform.LookAt(car);
}
function FixedUpdate () {
var localVilocity=car.InverseTransformDirection(car.rigidbody.velocity);
if(localVilocity.z<-0.5){
rotationVector.y=car.eulerAngles.y+180;
}

55 | P a g e
else{
rotationVector.y=car.eulerAngles.y;
}
var acc=car.rigidbody.velocity.magnitude;
camera.fieldOfView=DefaultFOV+acc*zoomRacio;
}
10.4. Speedometer Script:
#pragma strict
// Arrow object
private var m_arrow:blindGUITexturedContainer;
// Arrow shadow object
private var m_arrowShadow:blindGUITexturedContainer;
// Car object
private var car:GameObject = null;
// Initialization
function Start() {
// Get "Car" game object
car = GameObject.Find("barun1");
// Then "Arrow" from child of current object

56 | P a g e
var goArrowTransform:Transform = this.transform.FindChild("Arrow");
if (goArrowTransform) {
m_arrow =
goArrowTransform.gameObject.GetComponent(blindGUITexturedContainer);
}
// And "ArrowShadow" form child
var goArrowShadowTransform:Transform =
this.transform.FindChild("ArrowShadow");
if (goArrowShadowTransform) {
m_arrowShadow =
goArrowShadowTransform.gameObject.GetComponent(blindGUITexturedConta
iner);
}
}
// At every frame
var speed:float = 0.0f;
if (car != null) {
// Get Car's rigid body
var carRigidBody:Rigidbody = car.GetComponent(Rigidbody);
// Get speed of car in car's coordinate system

57 | P a g e
var relativeVelocity:Vector3 =
car.transform.InverseTransformDirection(carRigidBody.velocity);
// Set Z as speed of car
speed = relativeVelocity.z;
}
if ((m_arrow == null) || (m_arrowShadow == null)) return;
// Set speed angle. 0 is -135 degrees. 160 is 135 degrees.
// Speed arrow angle = (135-(-135))/160 * speed - 135
speed = -135.0f+(Mathf.Abs(speed)/47.0f)*270.0f;
// Set angle to arrow and shadow
//m_arrow.speed = speed;
//m_arrowShadow.speed = speed;
m_arrow.m_angle = speed;
m_arrowShadow.m_angle = speed;
}

58 | P a g e
11. References
We have gone through certain books, done some research work using
internet, understanding the technologies being used in our project work.
The following references are:
 http://vimeo.com/album/150503
 http://www.futurefarmers.com/survey/fingerprint2.php
 http://unity3d .com/support/documentation/Components/class-
Texture2D.html
 http://unity3d .com/learn/tutorials/modules
 http://unity3d .com/learn
 http://catlikecoding.com>Catlike Coding>Unity
 http://unity3dstudent.com/
 http://cgcookie.com/unity

59 | P a g e
12. Conclusion:
The most common artificial intelligence in a racing game is waypoint
navigation by carefully placing waypoints (nodes) in the game environment to
move the game-controlled characters between each point. This is a very time
consuming and CPU intensive problem. Using the A* algorithm can effectively
solve the path finding problem in a static racing game environment; therefore, we
present two modified A* algorithm instead of putting waypoints by hand and
minimum the lap time. Finally, we propose a more general dynamic algorithm
which can solve the random obstacles avoidance problem in a racing game. All the
three algorithms are able to find the path for a car racing game and can save the
most import resource in game, CPU cycles.

Car Game Final Year Project

More Related Content

What's hot

Viewers also liked

Similar to Car Game Final Year Project

Car Game Final Year Project