Add a universal time_scale property to Node

[TheDuriel]

Describe the project you are working on

A game which involves slow motion effects or gameplay. General Godot engine projects.

Describe the problem or limitation you are having in your project

This proposal is mainly about the pull request linked below.

There are two 'problems' this feature is intended to solve:

Unification of time properties for Nodes under one property belonging to Node itself. For example animationplayers and streamplayers already incorporate their own time multipliers.

Selective slow motion effects. For example you could set a different timescale for the game world (without requiring the implementation of a custom main loop via propagate_call("_my_process_replacement"), and another value for the UI.) Or shift only specific enemies or objects while keeping the rest at its proper speed.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

The feature adds a time_scale property to Node which multiplies delta locally. The property is also inherited.

Example: A time_scale of 0.5 would multiply Delta by that much. This is cumulative through the Scene. Meaning if a parent and a child have a time_scale of 0.5. The parent would function at 0.5, while the child would function at an effective 0.25. (The exact same way transforms are 'inherited'.)

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

Example implementation: godotengine/godot#29861

If this enhancement will not be used often, can it be worked around with a few lines of script?

Currently selective time scaling requires implementation of a custom _process function via _propagate call in a root objects of the tree. The alternative is to provide a global value for your scale, and to remember to multiply delta in relevant nodes. However neither of these approaches allow you to affect the engine internal time scale for individual nodes or branches of the scene tree.

Is there a reason why this should be core and not an add-on in the asset library?

Modification of the Node class.

[Zireael07]

I imagine it would also help with things such as godotengine/godot#47326 (comment) (animation players/shaders/etc could be stopped by setting time_scale to 0?)

[aaronfranke]

This was discussed on Godot's RocketChat. The consensus is that this change is not necessary, and therefore this proposal is not desired. You can scale time yourself in the script, and other nodes such as particles or animation already support time scaling.
For physics time scaling won't work anyway because the solver will break. So, closing.

[Zireael07]

How do I pause shaders then?

[TheDuriel]

You will need to pass a custom time multiplier into each and every shader. A multiplier to nodes delta would not have done that in the first place.

…

On Tue, Aug 31, 2021 at 9:30 AM Zireael07 ***@***.***> wrote: How do I pause shaders then? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2507 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKRS6UYMQLWBBHAS7KNZKDLT7SAK5ANCNFSM4ZZ54IKQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[ettiSurreal]

This was discussed on Godot's RocketChat. The consensus is that this change is not necessary, and therefore this proposal is not desired. You can scale time yourself in the script, and other nodes such as particles or animation already support time scaling. For physics time scaling won't work anyway because the solver will break. So, closing.

I feel like the real usefulness of this comes from nodes inheriting the time scale of their parents, which i assume would greatly simplify changing local time of a large and unspecified amount of nodes with varying amounts of parents. For example parenting objects to an area that has a modified time scale as they enter it and unparenting as they leave, or slowing down everything but the player.
To make such system and effects through scripts you'd need to implement local time scale to every relevant script in the project, and make it work with many scenarios like an arbitrary parent structure. As a whole this seems like a nightmare to make.

Since i have seen PRs to add time scale to more nodes like timers, i do feel like making a generic node time scale property and moving the time scale of the nodes like particles to it would be some nice future proofing.

Also i assume by the physics solver breaking you meant objects of different time scale interacting. In that case the user could just be told that so they can avoid such situations. There are still use cases of this like local slow-mo areas where you logically won't have objects of different time scale interacting.

I really hope this feature will be reconsidered sometime.

[aaronfranke]

@ettiSurreal I think that would be unlikely. In fact, I think it's more likely to go in the opposite direction. Godot's core types are quite big and complex compared to their equivalents in other engines and it's a big part of why Godot is less efficient. I would be interested in PRs that remove features from core types and leave the features to descendant types. Godot's Object is 408 bytes, while Unreal Engine's UObject is only 56 bytes.

[Zireael07]

@aaronfranke Removing features from core types sounds like a topic for a separate proposal - and it intrigues me why our Object is so large compared to UE's?

[ettiSurreal]

@ettiSurreal I think that would be unlikely. In fact, I think it's more likely to go in the opposite direction. Godot's core types are quite big and complex compared to their equivalents in other engines and it's a big part of why Godot is less efficient.

Interesting to hear, I figured in this specific case it's something most nodes and scripts would benefit from if it were added. And I'm guessing main reason for the size of the core types was avoiding code repetition or versatility?

[Calinou]

What is the path, to re-open this proposal or bring it to consideration again?

There was a pull request adding exactly the feature you're requesting (for the Timer node), but it was rejected: godotengine/godot#34544

You should open a new proposal describing your needs around the Timer node, as this proposal was specifically requesting a time_scale property for any node that extends Node (including Timer).

In Godot, we prefer local solutions, so a time_scale property in Timer is more likely to be accepted than a time_scale property in Node. We try to keep Node and Object as lightweight as possible to reduce performance overhead and memory utilization.

[ettiSurreal]

In Godot, we prefer local solutions, so a time_scale property in Timer is more likely to be accepted than a time_scale property in Node. We try to keep Node and Object as lightweight as possible to reduce performance overhead and memory utilization.

Might aswell throw in a potential idea that could fit into that, though I'm not sure how feasable/helpful it'd be: A dedicated node that controls the time scale of its children.

[TheDuriel]

There is no good way to achieve a local solution.

Per Scene time scale, something that many games do enjoy to use, is not possible without a developer implementing custom time scale implementations for physics, timers, and animations. In many of these cases the solution can not be achieved without hacky workarounds.

Physics for KinematicBodies can be achieved by scaling the delta in your physics integration. This is not possible for RigidBodies.

Timers can not be scaled. And thus can not be used whatsoever.

AnimationPlayer supports time scaling, but when you use an animation tree it does not as far as I can tell.

[TheDuriel]

That's nuts and not acceptable in the slightest.

[jbromberg]

Could a good potential solution here to have a unique time_scale property on each SceneTree? At least in my case, this would basically solve what I'm after.

[rpahut]

a time_scale property in Timer is more likely to be accepted

I feel like proposals shouldn't be subject to probability. Once a missing feature is identified, the only valid reason for rejection might be that the engine is not supposed to have the feature in the first place. So, should not engine allow for individual time scales? Why?

Besides, what good a local solution for a thing like time rate is? All nodes share process(delta), all nodes should have the way to control it. Surely one unified way is easier to implement and maintain that a bunch of different ones.

[rpahut]

For physics time scaling won't work anyway because the solver will break.

Why would it break?
Can't you make it in a way that it doesn't?

[ettiSurreal]

Another thing I wanna add, something i ran into recently.
In my project i have a part where everything goes slow-mo, and i used time_scale for it. However because of that i ran into an issue, since time_scale affects everything, it also slowed down the pause menu, and it would persist if the player would quit off the level. The only solution was to disable the pause menu and add a failsafe that resets the time_scale in my custom SceneLoader autoload. This is a short one-off thing in my project so it's not that big of a deal, but it might become an issue in a project that would rely on it.