What Tick actually costs, why Blueprint makes it worse, how to tier tick rates, and the event-driven alternatives.
Tick runs every frame for every actor and component that has it enabled. Cost scales with count multiplied by per-frame work, so thousands of ticking actors — especially in Blueprint — is a classic performance killer.
Both tick once per frame by default — the same frequency. The difference is overhead.
Blueprint Event Tick runs through the Blueprint VM, a bytecode interpreter, making it roughly 10–50× slower than equivalent C++ for the same logic. The cost comes from per-node virtual calls, parameter marshaling, and graph traversal.
So keep any genuinely per-frame work in C++, not Blueprint.
// C++ constructor
PrimaryActorTick.TickInterval = 0.1f; // ~10x/sec instead of every frameIn Blueprint: set ActorTickInterval in the Details panel, or call Set Actor Tick Interval at runtime.
| Rate | What belongs there |
|---|---|
| Every frame | Things the player directly perceives — traces, movement |
| 0.1–0.2s | Perception checks, threat assessment |
| 0.5–1.0s | Squad coordination, pathing decisions |
| 2–5s | Ambient and idle-state decisions |
PrimaryActorTick.bCanEverTick = false; // constructor — never registers
SetActorTickEnabled(false); // runtime togglebCanEverTick = false is cheaper than a runtime toggle, because the actor is never registered with the tick system at all — there's nothing to skip over each frame.
Disable tick when it isn't needed, rather than leaving it on by default.
Prefer reacting to events over polling every frame:
OnHitEvent Tick on top of them is a common and avoidable perf problem.
Answer out loud before re-reading the chapter.