Big Game Project – Post 4

Fourth week was when we finished most of the smaller things like HUD, main menu and loading screen with screenfading etc.

From last week: Waypoints were used for:

• AI Navigation points
• Player placement
• Lap count
• Wrong-way indicator
• Respawn position/rotation

I explained AI Navigation and will be going more indepth into the AI in the next post.
This post will be about the other things and the systems surrounding those features along with the other things done this week.

Player placement & Lap count

Basic functionality: A Waypointhandler triggers every players waypoints depending on their distance to it, if they are close enough to the next waypoint it triggers and the waypoint after this takes its place.
It also increases a counter for how many waypoints have been passed and how many laps have been completed (when waypoints passed count exceeds the total amount of waypoints a lap has been completed and the next waypoint becomes the first).

Player placement was done by giving each player “points” depending on the number of waypoints passed in total (lapcount * waypoints in total + waypoints passed in current lap) and then sorting their placements based on their points. If two players have the same count then the distance to the next waypoint determines their position. As this uses just basic position – position math it can be weird if the waypoints are not divided properly.

For example: imagine a U turn, place waypoints in both end points of the U and then the distance to the next waypoint for players in the U will not result in the player “leading the race” being closest (1st).

Wrong way indicator

Wrong way indicator was done by checking the rotation between the vehicles forward and the next waypoint and if it was larger than 110 degrees (number got from experimentation) we display the “wrong way” indicator.
that indicator is shown until the degrees drops under 70 degrees (again, experimented).
Playtesters then said that the wrongway-indicator telling them that they were going the wrong way when they fell off the track was annoying, solution to this was using the already existing “grounded-check” from the gravity script that checks if the vehicle should “snap” to the track or not.

Respawn position/rotation

This was done using the waypointhandler mentioned before, every time a player passed a waypoint (when the current waypointtarget changed) I updated the starting position and rotation to the waypoint that was just passed. (I manually rotated every waypoint so they were aligned with the road and facing the right way. This could have been automated with raycasts and such, but I didn’t have the time to create more tools for this when it was as easy as just adjusting the waypoints manually).

Another thing I finalized this week was the Swap mechanic.
I don’t know if I have mentioned it but our game features two parallell tracks that the players can swap between at will.

What it does is raycast straight up from the player and if the ray hits the track above we can swap and that triggers the following:

Rotate the vehicle 180 degrees
Invert the ray for the gravity/rotation systems
Allow for long range snapping

The last one explained:
The gravity snapping you to the track felt unnatural when it happened from extreme ranges (you could fall off the track and move the vehicle in line with the track and you would snap back up no matter how far you fell)
so I nerfed the range of the ray for everything except swaps and respawns in which the ray has a longer range for a set amount of time (About 4 frames if if recall correctly).
That is what was done on week four (I might have made the pause menu this week, I don’t remember exactly when it was done but I will be covering it in the next post anyway)