Tick 101 — Implementation approach and optimization tips
Between helping students at my university and hanging around the Unreal Slackers discord and helping with blueprint queries, I noticed people without a programming background are generally either too afraid of ever touching anything related to tick, or use it carelessly to the point where it becomes a performance hurdle. With this in mind, this article should help explain how to effectively use Event Tick.
Event based mentality
- If your implementation’s start and end can be measured, and it’s not the game’s start and end, then your stuff should be event-based
- If your script is contextual within your game world, it is event-based
- If the instigator of your action is known, that action is event-based.
That said, things like
- Custom character movement
- Dynamic camera animations
- Dynamic character audio changes
- Procedural animations
- Feeding actor positions to a post-process material
probably can’t be event-based, as they execute throughout the entirety of the game’s lifespan.
Event-Based doesn’t mean it can’t happen over time
Loop a timeline, and the update pin becomes your temporary Event Tick, it can be started and stopped based on the world context.
A few examples of things that often require to be executed every frame:
- Physics forces (excluding Impulses)
- Value interpolation (lerp, slerp, interp, ease, etc)
And if your code doesn’t need to execute every frame, consider running it every other frame or time via event/function Timers. Some examples of things that happen over time, but probably not every frame:
- Weapon shots
- Data recordings
- Ability cooldowns.
And you have branches on your tick, which don’t do anything for one of the states, then whatever you are running there should be event-based. As you change the boolean from somewhere. And as a general note executing something every frame does not automatically make it framerate-independent! Delta Time (seconds) is for that.
Performance Tips
By default, almost every actor in Unreal has their Tick enabled, which means that any blueprint you create will have its tick enabled, so consider disabling it if you are not going to use it.
Ticking also happens according to tick groups, which can be assigned in code or Blueprints. An actor or component’s tick group is used to determine when in the frame it should tick, relative to other in-engine frame processes, mainly physics simulation. Each tick group will finish ticking every actor and component assigned to it before the next tick group begins. In addition to tick groups, actors or components may set tick dependency, which means that they will not tick until the specified other actor’s or component’s tick function is finished.
Some notes on UI
UMG auto manages its tick by default. The same principles apply here: whatever can, should be event-based. Your game world tells to your UI when stuff is ready, instead of the UI looking for it every frame.
Perhaps the biggest performance saver when it comes to UMG is binds, the less of them you have, the better. Using the event tick of the widget and manipulating multiple objects is more performant than running the same code in multiple binds.
Conclusions
If your code starts and stops contextually, it probably shouldn’t be on Event Tick. There are however exceptions to everything. And while this article explains some neat practices/concepts and methodologies, you do not need to force them early, you sort of grow into that coding style. Iteration time should be your priority early on, not performance. It is quicker to optimize something you know works and suits your purpose than optimizing something early on and handicapping your iteration later when you need to change it
