game development presentation 2013 joseph kenny peter corcoran dean farrell kevin feeney

Game Development Presentation 2013

Joseph KennyPeter Corcoran

Dean FarrellKevin Feeney

Concept

The concept of our project is a cops and robber style driving game rich in physics and game play.

This concept was inspired by the mini game within the hugely successful brand ‘Driver 2’. Where the player outruns the cops whilst driving around a city environment.

Our Original Concept

We had originally started this project we had devised a game based on crash test simulations. Where in a player drives a car into objects and the damage is relative to speed, point of collision and mass.

However due to a group member leaving the group and a severe lack of game play we re-developed the concept.

Group Member Primary Tasks

Kevin – Car Physics/Enemy AI.Joseph – Traffic Control/Enemy AI.Dean – Pedestrian System/Pick ups/back

and front end.Peter – Damage and Health

Systems/Player and Enemy Integration.

My Content - DeanRagdolls

Pedestrian systemPickup System

Front-end/Backend

Ragdolls

• Early games used “procedural deaths”• Collection of rigid bodies tied to a system of constraints• Realistic

Implementation

Models from Blender into Unity Uses Unity’s utility Originally going to be used as passengers in the car Now part of a pedestrian system (shown later) Part of a collision system

Difficulties

Time consuming◦Implement armature in models◦“Rigging” them together

Importing Models Unity = right handed system Blender = left handed system

Pedestrian System

• Utilises a waypoint system• Travels towards each invisible waypoint at a constant force• Turns dynamically to face the origin of next waypoints y coordinate

Original Implementation

Difficulties

Walking animationsCollision detection with different collidersFollowing the waypoints correctlyTurning corners

Turning corners

PickupSystem

• Adds more depth to the demo • Utilises a number of spawn points around the city• Random set of 3 health pickups with a timer

Implementation

Spawn points placed throughout game world (evoke particle prefab)

minimum and maximum spawn delayDepending on type (once collected) it increases

players health.

Front/Back End

• Uses iTween motion to move the camera procedurally between clicks.

Main Menu

My Content - Peter Health System

Damage ControlMultiple instantiations

Implementations upon models

Health System

Player healthEnemy healthGUI display

Collision upon enemy and buildings effect the players health.

100 health points given to playerEnemy has 50 health points allocated and

is reduced upon collision with the player

Displaying the GUI’s works by pixels of 100 representing 100 health points

It transitions from green when full to red when empty under collision circumstances.

The enemy health works similar

Player health is displayed on the main camera for the user to see.

The enemy health works by distance from the enemy to the players position, the closer the enemy gets to the player the more the enemy health comes to focus for the player.

Damage Control

Damage is a local variable to all objects in the game i.e. A building will have more collision damage than a traffic light.

Each object is allocated a script that determines its damage upon the user.

Instantiatation

Upon damage and health deduction to the player different circumstances come upon the car.

After a certain amount of time the car will begin to let off smoke upon damage

As before it will eventually begin to erupt in flames.

As the players health gets reduced to zeroThe car will be destroyed and the game will

end.

Implementation

After car physics and AI physics where created I had to invoke them onto models.

Multiple aspects of the models had to be changed such as wheels, scale, rotation, mass and colliders.

My Project Work - Joseph

Destructible ObjectsWaypoint SystemTraffic ControlEnemy AICity and Road planning and creatingMini Map Particle systemGame timeAnd added touches to objects or scenes.

Destroyable Objects

Created in relation to former game concept.

Used instantiation to replace game objects with prefabs.

Would be used to simulate crashing into a weak brick wall which would destroyed into tiny pieces

Waypoint System

Our city currently contains over 150 waypoints throughout the city for our NPC’s to follow.

They are divided into sections which are sorted and well organised.

Traffic Control System

As NPC’s will be travelling around our city using waypoints there is a high chance they will crash.

A traffic control system is needed. Traffic lights emits 2 states, green and red.The NPC’s recognise the states when

approaching the lights. Hence they stop at red and continue on green.

Traffic

http://www.youtube.com/watch?feature=player_embedded&v=50NKsigY9Jk

Enemy AI

The Cop Car is our Enemy AI.Its purpose is to find you and eliminate

you.I created the initial Enemy AI for the Cop

Car using raycasts to detect up coming obstacles. It would adjust its direction accordingly.

IssuesKevin expanding upon my AI.

Enemy AI

http://www.youtube.com/watch?v=XG6ZuhRX7Jc&feature=player_embedded

City and Road Planner

In order for your game to reach its visual potential we needed a city.

Many avenues to use in terms of modelling, blender, city engine etc.

Our city is created from scaled cubes and textures.

Our road system is optimized for quick getaways such as sharp turns and little alleys.

City Terrain Walk - Through

http://www.youtube.com/watch?v=5X3vx8bZ4Ns&feature=player_embedded

Mini Map

The Mini map is used to aid the player in game

Shows him upcoming traffic lights and roads which may be useful when outrunning the law.

Particle System

I originally chose to create exhaust fumes using blender but ran into importing difficulties.

Unity has an in built particle creatorReleases fumes randomly from the

exhaust pipe.

Game Time

Our game has its own time system which I created.

1 real world second = 1 in game minute.Uses this time system to transition

between day and night. The scoring system is based off the game

time also, as the longer the player stays alive the more points the player gets.

Day – Night Transition

Car Lights – Finishing Touches

The car has a built in headlights, brake lights and reverse light.

The headlights are used to see when its night. The other lights are primarily for realism.

The Sun – Finishing Touches

The sun revolves around the world on its axis to simulate a passing day, dawn and dusk.

This allows even more realism and player enjoyment to the game.

My Content - Kevin

GUI InterfaceCar Physics

AI

GUI Interface

On this project I first worked on a GUI interface. It had sliders and text boxes to enter new values for variables so the user could change values during runtime.

The original idea for the project was to demonstrate a variety of crashes between a car and different wall objects. The original GUI had sliders and text boxes to change the mass of the car and the mass of the walls.

GUI Interface

I had trouble positioning the GUI objects correctly. I realised that the reason why was because I was declaring the Rect values outside the OnGUI() method, so I eventually got it how I wanted it .

GUI Interface

The values for the masses in the script were not being applied and upon investigation I found that through circular logic the values that were being applied ultimately came from the values already present in the inspector panel.

The text values were set from the slider values, the slider values were set from the default values, the default values were set from the rigidbody mass values, and the rigidbody mass values were the values that were already present in the Inspector panel .

So I changed the Inspector panel values to match the code.

GUI Interface

Here is the original GUI.

Car Physics

After I completed the original GUI, I took over making the car physics.

There were several problems. I was originally calculating the velocity,

momentum, and other values to apply to the car using the relevant formulae but after realising that Unity calculated these values itself I changed the code.

Car Physics

Using Niall’s physics code as a base I rewrote the car physics script. Niall’s code was difficult to understand and had flaws in logic which effectively gave the car unlimited acceleration. I used a separate forward and backward acceleration whereas Niall used a single variable. I also discarded the brakingPower variable and the getBrake() method. I introduced direction variables which would check which acceleration to increment or decrement. This code behaved almost identically to Niall’s but was much easier to understand.

Car Physics

I discovered some unusual results when testing the physics. I found that if you set the car mass to a very low value and spun it it would go up on end. While like this it could drive forward into the air by treating the y-axis just like the x-axis or z-axis. Not only could the car fly but it could also drive on its side or on its roof. When on its roof it didn’t seem to have a maximum speed.

I tested these phenomena and found that the car is more likely to take off if it is spun clockwise because the exhaust at the back-right of the car acts as a fulcrum. The bonnet can also act as a fulcrum as long as the car isn’t upside down. Through testing I found that the car didn’t go up on end if its mass was above about 0.165, so I set this as the minimum mass limit.

Car PhysicsThe car in the air and rotated onto its side

and roof.

Car Physics

A persistent problem that occurred was that the car would skid around like it was on ice. I set the car’s centre of mass to -2 on the y-axis. This improved the steering but the car could now take off again and collisions sent it airborne or flipped it over. However, it usually righted itself when it landed.

I made a method that would rotate the car around its axes when the z, x, y or t buttons were pressed. This was useful for testing.

Car Physics

I experimented with drag, angular drag and the car’s mass, as well as the useGravity and centreOfMass variables in an effort to balance the values against each other to improve car steering. The greater the angular drag the slower the car turns but this also results in less skidding. The steering slightly improved. I removed the drag and angular drag as they are not normally used with rigidbodies.

Car Physics

I attempted to use the dotproduct of the forward and turning vectors as a means to counter the sliding. At first I forgot to normalise the vectors so it didn’t have any effect. I used this formula: length = squareroot ( (x*x) + (y*y) + (z*z) ) to normalise the vectors. I later discovered that Unity has these values built in.

I next restructured and changed much of the code to make it more readble.

Car Phsyics

Having decided that the project will be a car chasing game we placed the car in a city.

John helped me fix the sliding by getting rid of most of the code in the script. The getForces() method now directly applies scaled forces to the car instead of using an acceleration value when the buttons are pressed. The dotproduct now works to cancel the sliding.

The pavements were repulsing the car and this could cause the car to drive up the side of buildings. Because of this it became easier to test drive the car outside the city.

Car Physics

Here is the city.

Car Physics

I decided to check if the car’s wheels are on the ground by sending a raycast from each wheel directly down to the ground. Every positive hit increases the wheelCount variable which is used to scale the forces applied to the car.

Car Physics

Here you can see the raycasts coming from the wheels towards the ground.

AIJoe then asked me to look at the enemy and NPC

car AI he had created while he worked on the traffic lights.

I applied the code keeping the player car on the ground to the other enemy and NPC cars.

The enemy car wasn’t using waypoints. Instead it moved toward the player as best it could, avoiding any obstacles it detected along the way with raycasts.

I thought that there might be a chase algorithm that would work so I looked it up. But none of the algorithms I saw took obstacle avoidance into account.

I then looked for search algorithms. A* was the most frequently mentioned. Unfortunately it only works with a static target.

AI

I changed Joe’s enemy car script to try and get it hunting the player more effectively.

Whereas Joe used Quaternion.Slerp() to rotate the car, I used rigidbody.AddRelativeTorque().

With Joe’s script the enemy occasionally tunnelled through buildings to get to the player. I changed this by changing a transform.position increment to rigidbody.AddRelativeForce().

Joe’s script was using one raycast from the front of the car. I added an extra two raycasts from the front and two to the sides.

AI

The two raycasts from the sides of the car were ineffective and the car wasn’t turning enough to avoid collisions. So I went back to Joe’s script and made a new script.

I kept Joe’s turning mechanism, used rigidbody.AddForce() to move the car forward and stuck with three raycasts from the front and one raycast toward the player car.

I changed the angle of the raycasts at the front to lean left on the left side and right on the right side.

AI

Here the camera is behind the enemy. The yellow line points toward the player. The enemy has three raycasts from the front.

GUI Interface

I then created a new GUI Interface that would provide sliders and text input boxes to allow the user to change the value of a scaler used with the rigidbody.AddForce() and rigidbody.AddTorque() methods to effectively increase or decrease the force applied to drive the car forward and to turn it.

There were sliders and boxes for the player car driving force and turning force and the enemy car driving force and turning force.

The enemy turning force value was a scaler used to increase the heading of the enemy car.

Joe created a player score in the DaylightTransition script so I added this value to the GUI.

GUI Interface

Here is the new GUI.