Placement Tracking
The placement tracking system was an important task to get done early on in the project as it is the core gameplay mechanic of a racing game and required a lot of iteration. Designed with optimizations and easy access in-mind the placement system became something that was easily modified without requiring edits in other code. Throughout the project I worked closely with the AI team to use a singular spline set for both systems.
The idea of the placement system was to update a data set for each kart in the race and then have the other systems access that data to do whatever it was that they needed to do with it. Every update the placement system would check each kart’s position around the track and would then sort the karts’ laps and positions to determine their place. An optimization we made to tracking placement was to only update it every few frames rather than every frame.
In order for the placement system to work with splines and fit within the parameters of the track designs, there would need to be a way to track placement while on a shortcut. The shortcut could have a different path and direction than the main track. The solution to this problem that we came up with was to use multiple splines and then range map the distance along the shortcut spline onto the portion of the main spline that was traveled instead of the shortcut.
Originally the two parameters that the placement system would sort each kart by was their distance on the spline and their lap number. However, this became a problem when the player would go backwards across the lap seam, where the spline started and ended. To fix this problem I made it so that placement was based on total distance traveled around the track and lap number. Every update I had to compare each kart’s current position to its last position and add that difference to the total distance traveled.
This created a special scenario when the kart would go from 100% of the track being completed to 0% as it crossed the finish line for each lap. To handle this I would check to see if the kart was within a certain tolerance to the end and start and depending on which direction the kart was traveling I added a negative or positive value to the total distance traveled.
Towards the end of the project this behavior was creating a hard to distinguish bug when the kart was respawning further than the tolerance value after it crossed the lap seam. The fix was simple, just increase the crossing tolerance to a percentage of the track’s length, and as long as the tolerance is less than 50% of that length the lap crossing will be detected correctly.