But it isn’t gratuitous. I’m not even sure that it’s a change? Many moons ago when I wrote my own stuff in C++, I’m pretty sure my Time class worked exactly the same as this one, including that cap on time.
Having uncapped time deltas is just asking for trouble. For instance, when you’re debugging something in your IDE and then resume, you really don’t want the next frame to have a delta of 3 minutes. So you pick a number big enough that it’s unlikely to impact typical working behaviour (i.e. at least twice as big as your slowest acceptable frame rate) and small enough to not cause trouble (i.e. probably less than a second).
And typically in a public forum that would be respected.
My answer is no, that should not be a recommended solution, for reasons already covered.
Your specific use-case was nothing you couldn’t solve by yourself, in your project, exactly like you said you would solve it. And also as a reply to @Elhimp the way this is solved is by writing a simple MyTime wrapper class, to be used throughout the project. No repeats, single point of responsibility, exactly the same static experience as with the API Time class itself.
Let me bore you first with my background. I know you’re all experts, but I’ll keep it short.
I hail from a time where the only GUI for Unity was IMGUI and random solutions on the Asset Store. We used to walk on long uphill snowy trails and fight with wolves on the way to our studios. Seriously, nGui (what is today’s UnityEngine.UI package) was very early in development as a 3rd party asset at the time. It would take a year before that solution would hit the market. I was tasked with writing a complete GUI system for both mouse/keyboard and multitouch devices in under a month, and as someone who already had a decade of experience with complex UI systems, I pulled that off, all while still learning Unity and C#.
One of the things I did very early on, was to separate timing concerns, for a fully-animated project that consisted of real-time gameplay, slow-motion gameplay, in-game HUD, and pausable game menus, as well as music and sfx on top of that.
I’m nowhere near the supposed Einsteins of Unity, but if there was a browser where you could type in “show me the people who need to be shown how to reason about time in games” I like to believe I’d be somewhere among the last pages.
That said, I believe I’m capable of understanding what it’s all about.
The issue I’m having with this is exactly that you’re claiming that there was no change. Yes there was a change. maximumDeltaTime was supposed to be exclusively a physics thing, relevant only for the actual fixed frame computation, which should be a separate thing altogether. Or at least that’s what the docs were saying at the time. But now we’re limiting deltaTime as well?
Point being: Let me sanitize my delta, Update loop is my jurisdiction, if I want it capped I’ll cap it myself, thank you very much.
But don’t take my word on it, surely I got things wrong and backwards, so let’s rewind time shall we?
I’m a user since 3.x, but let’s start from 5.5 for brevity.
No word on it getting applied to deltaTime. In Time and Framerate Management for Unity 5.5, the only maximum that is mentioned is the Maximum Allowed Timestep, which is a property in the Physics (or Time) panel.
I can hear you saying “that was ages ago” so let’s hastily move forward in time
Whoa, this is crazy right? No? All of a sudden we got this mention of deltaTime being affected by maximumDeltaTime, for the first time ever? Let’s also check Time and Framerate Management. Oh it specifically explains that Maximum Allowed Timestep IS the same thing as the maximumDeltaTime value.
And it took Unity how many years to implement / acknowledge this? Let’s see, Unity 1.0 got released in June 2005 and 2019.4 got released in June 2020. So, um, for fifteen years nobody thought it was wise to actually explain that deltaTime, specifically, would be hard-limited in contexts outside of physics? Funny considering that pretty much everything in a modern game engine revolves around the notion of time.
Fast forward to present day explanation
Both these values are subjective measures of time elapsed within your app or game. This means they take into account any scaling of time that you apply. So for example, you could set the Time.timeScale to 0.1 for a slow-motion effect (which indicates 10% of normal playback speed). In this situation the value reported by Time.time increases at 10% the rate of “real” time. After 10 seconds, the value of Time.time would have increased by 1. In addition to slowing down or speeding up time in your app, you can set Time.timeScale to zero to pause your game, in which case the Update method is still called, but Time.time does not increase at all, and Time.deltaTime is zero.
These values are also clamped by the value of the Time.maximumDeltaTime property. This means the length of any pauses or variations in frame rate reported by these properties will never exceed maximumDeltaTime. For example, if a delay of one second occurs, but the maximumDeltaTime is set to the default value of 0.333, Time.time would only increase by 0.333, and Time.deltaTime would equal 0.333, despite more time having actually elapsed in the real world.
The unscaled versions of each of these properties (Time.unscaledTime and Time.unscaledDeltaTime) ignore these subjective variations and limitations, and report the actual time elapsed in both cases. This is useful for anything that should respond at a fixed speed even when the game is playing in slow-motion. An example of this is UI interaction animation.
Although this explains how exactly a FixedUpdate calls sync with the Update calls over time, it fails to explain or even mention why would reducing deltaTime help with any such issue.
Elsewhere I’ve managed to find people complaining (without answers ofc) that deltaTime seems to be capped at a specific value (which from everything said so far looks like 1/3rd but it varies depending on their settings probably), as early as 2014, but much more often after 2020.
So to try and get this over with, and hopefully to make it less fueled with fanaticism, I’ll compromise by saying that I was apparently very lucky for always making my own custom MyTime wrappers for the production code, as this is likely the main reason why I have never stumbled on this issue of having the deltaTime limited (except when a delta should be capped, with motion in the 2nd order and accumulation of forces involved, where this makes sense).
While I’m sure nobody likes teleporting characters, the aim of any time-based software is to be as stable as possible, not to actively pretend that the stability was always there and that hitches do not exist. As I said a couple of times already, let me be the boss of whatever feels right for my game. Not all of us grind our processors to halt with incessant garbage collection. Call it what you want, but imposing the clipped time on all users, without disclosing it timely and properly, definitely goes in my book of the most horrendous design choices made by Unity.
Given that this limitation wasn’t even documented for such a long time, and that seemingly nobody cared to ever even mention such a relationship, nowhere, not even once, is literally mind-boggling to me, and another reason to be even more mindful of deltaTime in the future.
And then most of you gaslighting me how it was always like this, when in reality, it was officially described as such since October 2020. This was only 2.5 years ago. Unlike most of you I haven’t really developed a habit of checking the well-established and omnipresent API every year… Especially not something as staple as Time.
