Hierarchical Timescale System

Hi all,

I am really keen for unity to add a hierarchical-timescale-system.

This would allow for user created timescales to be nested within a structure that still allows for global control, whilst easily granting users fine/custom control over individual objects.

This would also require users to bind GameObjects to timescales. This functionality could be provided in the same section as Tag and Layer, and could default to a global parent timescale, ensuring that there is no change to unity's default behavior.

This approach would solve the majority of requests regarding timescale on this forum, and the hierarchical structure fits in nicely with unity's other systems from a logical standpoint.

This feature makes a lot of sense to me, though i am interested to hear other peoples thoughts and opinions on the matter.

If you agree that it sounds useful you can add your votes here:
https://feedback.unity3d.com/suggestions/hierarchical-timescale-system

Cheers!

 

Can't you already do this with components?

I mean... you only need one "TimeControl" component which provides alternative to Time.deltaTime, and takes into account TimeControl components present on parent objects.

 

Couldn't you implement this yourself? Instead of inheriting directly from MonoBehavior, you could create a base class which implements its own overridable fixed update method, which is call at an interval of time different from that of the base fixed update. Then your behavior components could inherit from that base class and specify the desired interval. You could either make the intervals a desired constant, or a variable porportion of the actual interval achieved by the engine.

 

I feel like this might be a asset store solution rather then a core engine functionality.

The only real place engine intergration would help out is in physics. But I'm not sure the effort to adapt PhysX to work with multiple time scales is really worth the effort. It's a small number of games affected. And it's likely to need to be custom defined for every game anyway, as physics doesn't have a default way to operate with objects interactions at different timescales.

 

What would be the use case for this? I've barely found the need for multiple timescales let alone a whole hierarchy of them. This is also something trivially solved with scripting, there's no need to bother the Unity devs about it.

 

Can you provide a practical example of what you mean, or are trying to accomplish? Is timescale the right word? I honestly don't understand what you are talking about.

 

Some indie puzzle game?

The best I can think of is some slow motion effect.

 

Most likely, but I have no interest.

No. Bad idea. Mono-behavior based solution will require maybe 30 lines of code top. One class, two variables, and maybe 3 methods, and that's it. Your proposed approach is much more complex and will conflict with internal function execution order.

FixedUpdate is not called at regular intervals, but in bursts. See: https://docs.unity3d.com/Manual/ExecutionOrder.html

They won't be able to inherit from base class, because C# does not support multiple inheritance, Interfaces do not allow you to provide implementation for any methods and components HAVE to inherit from MonoBehavior to be used in unity.

 

Something like Timeshift game, maybe. Or a game with with time slowing weapons/effects that affect area.

Thinking about it, while handling it for the purposes of "Update" methods should be trivial, integrating multiple time speeds into Physics most likely will be very difficult.

 

This. It would be challanging for a dev. But it would also be challanging for Unity.

There is no straight forward mathematical answer as to how two objects with different time scales should interact. It's not something that ever happens in real life physics.

In fact, it would probably be so tangled into the physics engine that it would hurt performance for everyone who doesn't use it. Which again makes it a bad idea.

 

Yea, if were for a specific mechanic, I could understand, but the op suggested it would solve other problems? And hierarchal? In what way? I kind of get the impression that they are actually asking for something simple like event chaining or something, but used improper phrasing. Many, especially individual, timescales seems like a bad idea (outside of a specific use case)

 

For a character like The Flash you could move everybody slow at 0.05 * TimeScale when he is off to the races and he is normal speed, or people move at normal speed and The Flash blurs by them at 20*TimeScale..but everybody uses their base animation sets and no other scripting is done? Is that perhaps what type of use he was thinking..warp speed versus regular speeds an inverse of that as well.

 

I've often wanted to be able to easily do things like have different timescales for GUI animations and in-game animations. That's sort of provided by using the unscaled time delta, but I can easily imagine scenarios where you might want to scale both separately. (Pause the main game for a mini-game, and then pause the mini-game or slo-mo it without also effecting the pause menu...)

I think that making it hierarchical is perhaps overcomplicating it, just because it seems to be adding extra opportunities to break things without solving any problems, but I could be wrong there. I personally think that the ability to look up time info from multiple named clocks would do the trick, and that's trivial to implement. The catch is that it's not trivial to integrate with pre-existing things like physics, particle systems or animators.

 

Maybe that was the intent. But as in your example, the timescale is constant, and just uses a modifier. The actual timescale has to be the same for physics/collision to work. I think it was something like speed or rate or duration and not "timescale".

 

That would simplify simple games if UI/everything else had their own clocks so you easily still have animations on the UI. (I use inheritance and an interface for pauseable elements). Still though, that is two timescales, anything more than specific case (and that could get tricky as well if you have world/non-gui ui that is animated). Beyond that, there isn't much practical use for more/many as a general use addition to the core engine. Not to mention the scope of such a change would touch virtually everything in the engine, that could get ugly fast.

 

I was thinking of something like that, the problem is that you need conservation of energy for physics to work between all timeframe. We have access to any physical object data like velocity, etc ... and I think we can manipulate them, just lowering them will dampen the energy, so you need to save the sate of slow down object, compute manually the interval you need in order to maintain the relative energy to the slowdown. Now there is some design to do with inter timescale collision, you would need to intercept all collision pairs that happen between timescale and resolve them manually, generally using the designed energy transfer you want. For example slowdown objects could have bigger "inertia" that push through normal rate and resist to changes (character that walks on bricks of a crumbling building) or on contrary be easily "displaced" in order to rearrange them (think the quicksilver sequence in that Xmen movie), or you could mix and match type of reaction based on player's gullibility (building elements have high inertia and are difficult to displaced, furniture can be easily displace).

 

Sorry I disagree with all your statements, but this one you clearly misunderstand. You don't inherit from Monobehavior and the base class. Just the base class. The base class (and derived class) instances could be *driven by* a mono behavior component. While fixed update is called at different intervals, you always know at what interval, so you can make the mathematical adjustment needed.

Of course, I still don't understand why you need this since you don't really provide a clear explanation above, but good luck with the cause.