Have no Event Tick inside my game as of now. Been using Timers with Custom Events that shuts on when performing a specific action and turning off when not. I guess my question is, is this good optimization or am I creating more harm than good performance wise? P.S. I’m new and still learning!
Only have two timers set off by events as of now, don’t have a lot going on. Started using this because I heard Event Tick should be underutilized as much as you can. Also, any feedback how to make more efficient is greatly appreciated!
Honestly I think this is brilliant, reducing the amount of actors running tick is one of the best ways to improve game performance from what I understand , as long as the game is working well with this setup id say keep running it
Thank you! Took a few tutorials and created something using a bit of everything . If any ideas or ways to make even better let me know, i love learning new things!!
the problem aren’t the ticks. the problem is the amount and type of work that you do.
and also how well grouped it is (e.g. having the pawn ticking to do something weird on other actor it’s a bad sign). as well as not ticking when not necessary. which basically is not doing work you don’t need (which is a basic optimization idea).
i like timers and i use them often, but usually for simple things, one off things.
for recurring things i use tick.
the benefit of ticks is that you can control them like:
changing the interval
pausing
choosing to not pause them on game pause
enable/disable ticking when you want.
choosing WHEN to perform the work (pre physics, during, etc.)
running async (in another thread) with bRunOnAnyThread and the cvar tick.AllowAsyncComponentTicks
batching and doing the work in parallel (there are some optimizations for this on 5.x with some cvars (i’ve been experimenting with this)).
prerequisites for ticking (ensuring ticking order among many elements)
Integrates better with the engine. for example the plugin i’ve shared works well with tick intervals out of the box. You can add custom behavior to control your timer but it’s extra code.
Being tick a base functionality of the engine, it also easily generalizes to other classes, plugins, objects, etc. You can easily check for Actor->IsActorTickEnabled without having to cast. That not only is a tiny bit faster, but also reduces the problem of dependencies (which is a real issue in blueprints).
debug tools, visualization, profilers, logs, etc. that timers don’t have.
for this, i think, ticking architecture is far superior to hand made timers when it makes sense. otherwise you’re simply overcomplicating.
what i do to ensure the tick code is as optimal as possible (in general terms) is
try to keep the code grouped where it needs to. (separation of concerns some ppl call it).
that means, i tend to have components that tick and group the data and logic together (which could further increase data locality on the cpu)). (e.g. i have a component that performs some animation, it has its own tick and data)
avoid doing what i don’t need to. cache data. (e.g. instead of using GetActorOfClass every tick, i cache that in a variable).
which are things that could help you in any way you implement it (ticks or timers).
Only time I use the timer as a tick, is when im in the collision box of an item, and want to use physics. Once out of the collision, it turns off. Curious if that counts as a good way to do it lol
With what i mentioned above, using Tick, you can call SetActorTickEnabled / SetComponentTickEnabled (on the actor or component), to tick only when you need it. It’s one single function, as opposed to add a timer and store the timer handle. you can also query for Is*TickEnabled.
having said that. your way is not “bad”. it’s ok too. but personally in this case i’d still prefer using the tick for the reasons i’ve mentioned above.
remember that at some point the engine has the equivalent to a list of things to tick. and a list of things to do a timer. so the overhead you have on a tick and timer are not that different. i’d say the difference is negligible for most cases.
i really love optimization but i think that i’d prefer ticks here.
there are other things like
“how maintainable” is your code, (how easy it’s to make changes)
how easy to make mistakes (for example imagine you forget to store the handle to the timer and then it’s not being cleared)
how well it integrates with the engine. for example the plugin i’ve shared works well with tick intervals out of the box. You can add custom behaviour to control your timer but it’s extra code.
Being tick a base functionality of the engine, it also easily generalizes to other classes, plugins, objects, etc. You can easily check for Actor->IsActorTickEnabled without having to cast. That not only is a tiny bit faster, but also reduces the problem of dependencies (which is a real issue in blueprints).
oh and also i just remembered
ticks have
prerequisites for ticking (ensuring ticking order among many elements)
debug tools, visualization, profilers, logs, etc. that timers don’t.
Some excellent points up there. Tick is very useful (and easily misused, too) - if you need something to be updated every frame, you use Tick. Imagine a situation where the player’s health regenerates only 5x per second using a timer but you want a progress bar to be smooothly updated at up to 144Hz because gamers crave fluidity.
You’d run both - a slow, easy to control timer but use Tick to interpolate the visual aspect. An extreme case scenario, but that’s the gist.
Regarding physics, this has been available for while now:
Do you have a picture of how i would use asynchronous tick in blueprint to only be enabled for a single actor i interact with, and when done it turns off? (Sorry new to this if stupid question)
Yes this is a good approach, ticks are evaluated every frame, using a timer instead so it is only evaluated as often as strictly necessary is a decent approach. And if your actor is not ticking you avoid the tick overhead mentioned in Ari’s video (which doesn’t really matter much because it’s a very small overhead)
For your function i think it might be overkill though, it’s fine to put on tick because all you’re doing is just setting a variable, which is quite cheap.
All the things Ari says in the vid nande linked to about tick are true… And it explained a lot of the reasons why you shouldn’t use tick quite well, while saying you should use tick. Tick should be used responsibly, it exists for a reason.
If you have an action you need to happen every frame, you put it on the tick. You just need to optimize it in such a way that only the parts that need to happen every frame run on the tick so that it won’t slow your game down.
You very much should not use tick if you do not need to use tick. Sometimes you need to use tick.
As simple as walkng up to a phsyics cube to grab and move it, then walking away ( amnesia type physics) should tick be constantly on or turned off only when no longer interacting with an object? Only using it for object, not main gameplay or focus.
It works on per actor basic by default. Since this an experimental feature, dynamic toggling is not exposed to BPs (yet, one would hope). But you can do it via C++.
just for clarity that’s not correct. tick interval allows you to control how often a tick is processed.
and as Everynone said, you can modulate it. meaning you can actually change how often it ticks, while it’s ticking, to perform much much more fine grained control.
Listened to advice given! Using tick enable/disabled when i need it. All blueprints tick auto enabled is turn off as well withing project settings. Used sphere collision to determine if interactable is in range, and one line trace hits tick is turned on
Yeah I wasn’t aware of this feature until the two of you pointed them out, now that I am I will probably be using tick quite a bit more than I used to. Tweaking the tick will quite often be a better approach than using a timer. And the async physics tick seems awesome, If I understand correctly it runs on another thread which can be an extremely powerful optimization.
I disable tick on actors as I create them. Good Habit. In general thinking tick evaluation doesn’t have a huge impact. It’s the accumulative of all ticking actors that have the impact. 100 actors ticking versus 10,000 ticking is huge.
Timers have their place. Say controlling rate of fire on a weapon class. You wouldn’t use tick for this even if you adjust tick frequency. You cannot guarantee a specific amount of time with tick. Under production load you can’t force a tick on an actor. It’ll tick when it can… resource availability.
. If any ideas or ways to make even better let me know, i love learning new things!!
