I am currently working on a speed-running style game, and need an accurate timer for score tracking on leaderboards etc. At the moment i am using a timeline to keep track of time and then simply using a trigger at the end of the level to stop the timer. This works fine, but i have a few issues with it.
Firstly, the game has to be capped at 60 fps in order to keep scoring fair, since allowing players to go higher essentially means they will be able to trigger the ending earlier despite potentially technically being slower than someone playing at a lower fps. I would like to uncap the fps in my game whilst maintaining a fair scoring system. Secondly, because the fps is capped at 60, this means that scores can only be a multiple of .016 of a second, which isn’t as accurate as i would like, as i already have a few of my shorter levels with tied times despite only having a hand full of testers.
The obvious solution to this would be a sub-tick timer that will work accurately regardless of the fps. Before posting here, i asked around several UE4-oriented discords that i frequent and spoke to a few people about it, many of which told me they think it would be impossible. I have a theory on how to achieve this however, but i am unable to work my head around the actual math behind it, which is where i need and would greatly appreciate some help.
My theory could also be complete nonsense, or a much easier method to achieve the same thing could exist, so if you believe either of these are true, i would also really appreciate your response.
My idea is that i can continue to use the timeline and trigger to stop the time, and the on the same frame, calculate the penetration distance of the players character into the trigger using the current velocity and direction, and then calculating the time it would have taken to travel that distance given the current fps. That time can then be subtracted from the end time provided by the timeline to get the true time that the level would have ended.
The players character is a simple sphere with a varying radios (which will need to be taken into consideration), and the ending trigger is a cylinder that extends into the sky which should hopefully make for easier calculations, although they are still above my head… xD
The way i think of the calculation working is basically just calculating the distance from where the ball currently is inside the trigger, to where the ball would initially start touching the trigger (taking into account all axis) taking into account the direction the ball is travelling. Then using the velocity (and taking into account the current fps), calculating how long it would have taken to travel the calculated distance. Then its just a simple case of subtracting that from the original time.
Il provide some terrible paint drawings also to hopefully help people visualize the idea a little easier.
Lastly, thanks for anyone who took the time to read this far and especially to anyone who tries to help out. <3 i really do appreciate it!