Simply put, Time.deltaTime is going to be imprecise. It represents a time slice since the last frame flip. Within a short interval it is accurate enough to base calculations upon, but for long time scales where you accumulate a count of time with multiplication, it will be inaccurate. How inaccurate may well depend on various situations, but think about a single slice of time. Let’s say the frame rate is 60fps, where Time.deltaTime should be about 0.01667 seconds. If, however, the value is off a little and you multiply that by 720, that magnifies the error of this time slice, somewhere close to 1000 (or 30000 in part of your example discussion).
Time.deltaTime still works because from one frame to the next, what error might appear in one frame may be consumed by a counterpart in the next. This only works frame to frame. Within a frame, if Time.deltaTime is multiplied by a large value, it fails.
What is required, instead, is to track wall clock time. Work only on an accumulated time from Time.deltaTime, never perform a multiplication on a time slice as you’re doing. Only accumulate Time.deltaTime, not Time.deltaTime * factor (especially where factor is way above 10 or 20).
When you need to schedule a real time event for the future, base that on Time.time, which is the seconds since the application started, a wall clock or stop watch type of accounting of time. If, for example, Update is to schedule an event 600 seconds out, calculate with something like:
expirationTime = Time.time + 60.0f;
and consider it an expiration. Accumulate with something like:
ct += Time.deltaTime;
and then compare with something like
if ( ct >= expirationTime ) .....
In this way you’re accumulation of ct (current time) allows for Time.deltaTime to be imprecise within a single frame, but to “normalize” over several frames (which it does), an then compares reasonably with a wall clock time (which Time.time represents).
With that said, there’s another issue you should learn to recognize. You’ve repeated code here, where you convert seconds into seconds, minutes, hours, days…Any time you see repeated code like this, something is hinting to you that you’re missing an opportunity to organize your code into either objects or methods. There should be only one place to fix bugs, not several. There is no good reason to repeat code, especially in an object oriented language like C#.
For something very simple, like limiting a rotation to less than 180 degrees, you can put this concept into a method, instead of repeating code that tests for >180 (and/or < -180). Let a function do that, returning the limited result. You could choose to do that for this conversion of seconds into wall clock representation (minutes, hours, days…). However, you probably notice there are several variables that would have to be returned, meaning they should be declared with ref or out as parameters to the function. That is a bit uncomfortable, but it is better than repeating code.
A better way is to create a class that has members for seconds, minutes, hours, days…then create it from seconds. Let the class fill out the form, calculating what you have here, and then use these members wherever you need to interpret seconds as wall clock representation - in all future projects, not just this one.
That is the essence of object oriented programming, to notice when an object is hinting to you that it should exist. To create objects that handle small but repeatedly useful tasks. A primary example is Vector3 from Unity’s framework. If you didn’t have Vector3, you’d have to keep three values around for x, y and z, and you’d have to repeat the linear algebra operations for all the things Vector3 does, like normalizing, finding the length, rotation by quaternion, etc. Instead of repeating code, Vector3 wraps up most of the necessary concepts of linear algebra into the class. Programmers can then use linear algebra even if they don’t know what that is.
. THANKS