I implemented the timer for our game. The start and stop RaceTime events start and stop the timer, which sets the time value into a variable called ActualRaceTime.
After this, I implemented a simple delay to freeze the bike and player inputs so the player was fixed in place before the race started. This worked out perfectly for Kevin to add a starting timedown sound, which greatly adds to the authenticity of the game.
Here we see the physics of the bike being disabled for the CountdownDuration which is a variable to store the countdown duration.
This prevents the player input from registering until after the 3 second delay.
The Tutorial I followed
I go into meticulous detail on how the split times were made in week 6 of my journal, so I will just explain how it works and summarise how it was made here.
The split times in our game are used to give the player feedback as they go down the track. Players compete with their own best time, to try and better their runs. This self-competing nature is common in downhill mountain bikers. While the final time is obviously most important, getting real time feedback on how you did in a section allows the player to better understand where they need improvement as they go.
The final time is what determines whether or not the times the player just made will be saved or not. If a player does better than their current best in several sections but still ends up with a worse time overall, it would not make sense to save the sectional times. So at the end of the race, the overall best time is compared with the final time of the current run, and if it was a better overall time, the section times along with the final time is saved as the new best times to file. These will then be compared to the next time the player does a run. If the player didn't beat their record, then the original best time is simply kept.
As seen in the above blueprint, the finishrace event stops the timer, and the comparison is then made to determine if the times were worth saving.
The save function then very simply takes the times that have been stored as they player did their run, and sets the save file before saving it out.
The load function works similar to this and is called at the beginning of the game being loaded.
I'm firstly really happy with my timer. I think it's really important to the game in terms of the competitive nature. The hardest part to get my head around was how the saving and loading works, and once I did this there was no problem. The timer itself was also really easy to set up for me, and the tutorial I followed at the start is what taught me the most. It took me awhile to figure out how to actually implement it, but the fact that I took the time to plan out how the split time should work on a higher level first helped me stay focused in terms of what it is I had to do. This is the kind of approach I took with most things I went to do, where I try to first understand what steps I have to take to make something work, and then figure out how to actually do it.