ElectroMagRace

Foreword

In this game I took care of everything that concerns with coding, from the very basics up to the Artificial Intelligence of the pilots commanded by the CPU, plus the circuit model.

I would like to dedicate a huge thank to Elena Stambuco that took care of the whole remaining graphical part.

The Circuit Configuration System

To setup the circuit, there are a few components that should be set up in the Unity Editor:

1 - The mesh representing the circuit

2 - The Path in the centre of the circuit - made by Bezier Path Creator package, by Sebastian Lague

3 - A list of optimal waypoints representing the optimal path on the circuit

4 - A list of "speed points"

The system is made in such a way that the following conditions will be satisfied:

1) the order of the waypoints is not relevant - a user can configure the list of the waypoints not taking care at all of the order. The waypoint list will be built at Startup and sorted correctly to reflect the order in which each waypoint appears on the track

2) the order of the speedpoints is not relevant - again, while configuring how fast the pilot can go on each curve, the brake-points and so on, the order is not relevant. At test phase, while testing the configuration, new speed points can be added at will. The speedpoints list will be used at Startup to build the "speed knowledge" of the Artificial Pilot

These conditions ensure that the knowledge of the track of the Artificial Pilot will be fully configurable and customizable just placing the points on the track where they have to be; e.g.: if the pilot must brake until reaches 150 km/h in a certain point before a curve, we just need to put a speedpoint configured at 150 km/h on the track, in the point where the car must reach the desired speed.
The pilot will know how to interpolate the speed reduction from the last speedpoint until the next speedpoint is reached.

The "Speed Knowledge" of the track is finally represented as an Animation Curve, to be evaluated at each Update, that tells the Artificial Pilot how fast should go given its position, represented as the percentage of completion of the circuit.

Modeling the Artificial Pilot behavior

The Artificial Pilot behavior is modeled with a Behavioral Tree - using the package Behavior Bricks, by PadaOne Games

Green nodes represent a sub-tree, defining a behavior tree
Red nodes represent single actions
Yellow nodes represent conditions

In this particular example, that shows the behavioral tree for the Artificial Pilot, the condition nodes are evaluated from left to right in order. The first that applies, defines the behavior that the Artificial Pilot will adopt for the very next future.

In order:

1 - Initialize - executed only once
2 - if you're avoiding an obstacle, continue running
3 - if you have an obstacle ahead, add a waypoint to the list to avoid the obstacle
4 - if you're returning on track, continue running (this manages also the condition: when on track, delete the temporary waypoint to return on track and resume following the waypoint list)
5 - if you're out of track, add a waypoint to return on track
6 - if you have a pilot ahead, behave to try to overtake 
7 - if you have a pilot behind, behave to defend the position and not to be overtaken
8 - run normally - hence: follow the waypoint list as you were alone

Benefits of using a Behavioral Tree

The use of a Behavioral Tree makes much simpler the process of modeling the overall behavior of the Artificial Pilot, being able to refine the sub-behaviors and concentrate only on the single task, not risking to mix code in a giant if-else cascade or implementing a Finite State Machine whose states number can explode if a refinement must be made.

Engine Management

To model the engine behavior, in terms of Torque and Power, an animation curve has been used with real vlaues taken from a real engine, thus describing a Torque/Power curve as if it was in real life.
The Torque curve must be expressed not in RMP, but in meters per seconds, so we have to take a particular gear as a reference, knowing the minimum and the maximum speed of the reference gear.

The second step is to define which is the maximum speed reachable for each gear to extract the corresponding torque multiplier, to simulate a real engine behavior. The correct torque multiplier is derived by the maximum speed reachable by the target gear.

Once done and correctly configured without too much effort, what is interesting is the correspondence we get while comparing the engine performance, having a real-life 0-100 Km/h in 3.7 seconds, that replicates also in the game.

the maximum reachable speed per gear is (in Km/h):
1 - 120
2 - 160
3 - 195
4 - 230
5 - 260
6 - 300
7 - 350

All together

Clean - Without Configuration Elements

With Visible Configuration Elements