1 / 63

Game Development Presentation 2013

Game Development Presentation 2013. Joseph Kenny Peter Corcoran Dean Farrell Kevin Feeney. The concept of our project is a cops and robber style driving game rich in physics and game play.

hanzila
Download Presentation

Game Development Presentation 2013

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Game Development Presentation 2013 Joseph Kenny Peter Corcoran Dean Farrell Kevin Feeney

  2. 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. Concept

  3. 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. Our Original Concept

  4. 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. Group Member Primary Tasks

  5. My Content - Dean Ragdolls Pedestrian system Pickup System Front-end/Backend

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

  7. 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 Implementation

  8. Time consuming • Implement armature in models • “Rigging” them together Importing Models Unity = right handed system Blender = left handed system Difficulties

  9. 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

  10. Original Implementation

  11. Walking animations • Collision detection with different colliders • Following the waypoints correctly • Turning corners Difficulties

  12. Turning corners

  13. 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

  14. Spawn points placed throughout game world (evoke particle prefab) • minimum and maximum spawn delay • Depending on type (once collected) it increases players health. Implementation

  15. Front/Back End Uses iTween motion to move the camera procedurally between clicks.

  16. Main Menu

  17. My Content - Peter Health System Damage Control Multiple instantiations Implementations upon models

  18. Player health • Enemy health • GUI display Health System

  19. Collision upon enemy and buildings effect the players health. • 100 health points given to player • Enemy has 50 health points allocated and is reduced upon collision with the player

  20. 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

  21. 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.

  22. 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. Damage Control

  23. 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 zero • The car will be destroyed and the game will end. Instantiatation

  24. 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. Implementation

  25. Destructible Objects • Waypoint System • Traffic Control • Enemy AI • City and Road planning and creating • Mini Map • Particle system • Game time • And added touches to objects or scenes. My Project Work - Joseph

  26. 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 Destroyable Objects

  27. 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. Waypoint System

  28. 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 Control System

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

  30. 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. • Issues • Kevin expanding upon my AI. Enemy AI

  31. http://www.youtube.com/watch?v=XG6ZuhRX7Jc&feature=player_embeddedhttp://www.youtube.com/watch?v=XG6ZuhRX7Jc&feature=player_embedded Enemy AI

  32. 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 and Road Planner

  33. http://www.youtube.com/watch?v=5X3vx8bZ4Ns&feature=player_embeddedhttp://www.youtube.com/watch?v=5X3vx8bZ4Ns&feature=player_embedded City Terrain Walk - Through

  34. 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. Mini Map

  35. I originally chose to create exhaust fumes using blender but ran into importing difficulties. • Unity has an in built particle creator • Releases fumes randomly from the exhaust pipe. Particle System

  36. 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. Game Time

  37. Day – Night Transition

  38. 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. Car Lights – Finishing Touches

  39. 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. The Sun – Finishing Touches

  40. My Content - Kevin GUI Interface Car Physics AI

  41. 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

  42. 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

  43. 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

  44. Here is the original GUI. GUI Interface

  45. 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

  46. 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

  47. 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 Physics

  48. The car in the air and rotated onto its side and roof. Car Physics

  49. 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

More Related