Update, FixedUpdate and LateUpdate: Three Clocks in One Engine

A game appears to move continuously, but nothing inside it does. What the player sees is a sequence of still images, each computed from the state of the world at one instant, and between those instants the world does not exist in any meaningful sense. The engine's task is to decide, again and again, how much time has passed and what ought to have happened in it. Unity answers that question not once but in several ways at once, and the answers do not always agree.

The three methods most scripts meet first, Update, FixedUpdate and LateUpdate, look superficially alike. Each is a repeating event function, each is called on every active and enabled MonoBehaviour that defines it, and each seems to mean, loosely, run this code continually. Beneath that resemblance they are tied to different clocks and different moments, and the distinctions are not academic: they decide whether a character jumps when the button is pressed, whether a rolling boulder behaves the same on two machines, and whether the camera glides or shivers.

The way through is to treat them as three clocks kept by the same household. One ticks once per rendered frame, irregularly, as fast as the hardware allows. One ticks at a fixed rate in simulated time, indifferent to the frame rate. One ticks once per frame too, but always last, after everyone else has moved. Knowing which clock a task belongs to, and how the clocks relate, settles most of the questions that otherwise get answered by trial and error.

The frame and its uneven length

Update is called once per rendered frame, and frames are not of equal length. A scene may run at sixty frames per second in an empty field and at forty when a hundred units crowd the screen; a laptop may manage thirty where a desktop manages a hundred and forty four. Code in Update therefore runs a varying number of times per second, and any logic that assumes a fixed number of calls will run faster on fast machines and slower on slow ones.

Time.deltaTime is the remedy. It reports how many seconds the previous frame took, and multiplying a per second quantity by it converts that quantity into the correct amount for this frame. Consider an object meant to travel five units per second. At sixty frames per second, deltaTime is about 0.0167, and the object moves about 0.083 units each frame; at thirty frames per second, deltaTime is about 0.0333 and it moves about 0.167 units. In both cases it covers five units in a second.

Without deltaTime the same object, moved a flat 0.1 units each frame, would cover six units per second at sixty frames and only three at thirty, so the speed of the game would double or halve with the hardware. This is the meaning of frame rate independence, and it applies to everything measured in time: movement, rotation, cooldowns, fading lights, hunger meters. A useful habit is to ask of any number in Update whether it is per frame or per second, and to multiply by deltaTime whenever the honest answer is per second.

The fixed clock of physics

FixedUpdate keeps a different kind of time. Unity's physics engine advances the simulation in steps of equal length, the fixed timestep, set by Time.fixedDeltaTime and defaulting to 0.02 seconds, which is fifty steps per simulated second. Equal steps matter because numerical integration of forces and collisions behaves differently with different step sizes; a simulation stepped unevenly would produce different trajectories on different machines, and stacked objects that rest quietly at one rate might creep and topple at another.

To reconcile the fixed clock with the uneven frame, Unity keeps something like an accumulator of elapsed time. At the start of each frame it adds the frame's duration, then runs FixedUpdate and a physics step for every whole 0.02 seconds the total contains, carrying the remainder forward. At thirty frames per second each frame lasts about 0.0333 seconds, and the pattern of fixed steps runs one, two, two, repeating: five steps in three frames, which is exactly 0.1 seconds of simulation for 0.1 seconds of real time.

The consequence surprises people: FixedUpdate may run zero times in a frame, once, or several times. At a hundred and twenty frames per second, frames last about 0.0083 seconds, and a fixed step falls due only every 2.4 frames on average, so most frames contain no FixedUpdate at all. On a slow frame the reverse happens, and several steps run back to back to catch up. Inside FixedUpdate, Time.deltaTime quietly returns the fixed value, so code that uses deltaTime there still receives the correct interval.

There is a ceiling on that catching up. If a frame takes a very long time, say during a loading hitch, running every owed step could make the next frame even longer, and the game could sink into a spiral where it never recovers. Time.maximumDeltaTime, a third of a second by default, caps how much time a single frame may feed into the fixed loop. When the cap is hit, the simulation simply falls behind real time for a moment, which is far preferable to the alternative of a frozen machine.

Why physics lives in FixedUpdate

Since the physics step follows the FixedUpdate calls, code that talks to the physics engine belongs there. Applying a continuous force with Rigidbody.AddForce, setting a velocity, or moving a kinematic body with MovePosition should happen in FixedUpdate, so that each push corresponds to exactly one simulation step. Placed in Update instead, a force would be applied a varying number of times per step: twice in some steps, not at all in others, and the thrust of an engine would depend on the frame rate.

The mismatch shows up in concrete ways. A boat whose propulsion is added in Update will be faster on a powerful machine than on a modest one, because more frames means more pushes between physics steps. A force applied on a frame with no physics step accumulates and lands in the next step along with the next frame's force. The repair is almost always the same: compute the intention in Update if necessary, store it in a field, and apply it in FixedUpdate, where the simulation can consume it at a steady rate.

One exception confirms the rule. A single instantaneous impulse, such as the kick of a jump or the blow of a hammer, applied with ForceMode.Impulse or ForceMode.VelocityChange, does not depend on how long it lasts, so applying it from Update is not wrong in the way a continuous force is. Even then, many developers prefer to route it through FixedUpdate for consistency, so that everything touching the Rigidbody happens in one place and in one rhythm, and the next reader of the code has fewer exceptions to remember.

Why input lives in Update

Input runs on the frame clock. In the classic Input Manager, Input.GetKeyDown and Input.GetButtonDown return true only during the single frame in which the key went down, and the state is refreshed before each Update. A script that checks GetKeyDown inside FixedUpdate is checking a value that belongs to a different rhythm. On a fast machine, the frame of the key press may contain no fixed step, and the jump is lost entirely; on a slow machine, two fixed steps may share that frame and the jump may fire twice.

The reliable pattern divides the work along the clocks. Update reads the input and records the intention, setting a field such as jumpRequested to true. FixedUpdate checks the field, applies the impulse to the Rigidbody, and clears the field. Continuous inputs like a held movement axis can be read in Update and stored as a vector for FixedUpdate to consume. Every press is noticed because Update sees every frame, and every response is physical because FixedUpdate is synchronized with the simulation.

The newer Input System package changes the details without abolishing the principle. Its update mode can be set to process events during the dynamic update, which is the default, or during the fixed update, and the choice determines when actions such as a button press become visible to scripts. Whichever mode a project uses, the question to ask is the same: on which clock does my code run, and on which clock does the input I am reading arrive? When the answers differ, a small buffer between them is needed.

LateUpdate and the patient camera

LateUpdate runs once per frame like Update, but only after every Update has finished and after the frame's animation has been evaluated. It adds no new clock; it adds a guarantee of order. Unity does not promise the order in which different scripts' Update methods run, so a camera that follows a character in its own Update might move before the character does in one frame and after it in the next, producing a faint, irregular judder that is difficult to diagnose because it depends on chance.

Moving the camera's follow logic into LateUpdate removes that chance. By then the character has walked, the Animator has posed its skeleton, and every object that intends to move this frame has done so. The camera reads final positions and settles itself, and the image rendered immediately afterwards shows the world and the viewpoint in agreement. The same reasoning suits other followers: a health bar that hovers over a unit's head, a torch flame aligned to a hand bone, a laser sight that tracks an animated weapon.

A subtler jitter remains when the camera follows a Rigidbody. The body moves only on physics steps, which do not line up with frames, so from frame to frame it advances in uneven increments, and a camera tracking it faithfully in LateUpdate reproduces that unevenness. Enabling interpolation on the Rigidbody tells Unity to draw the object between its last two simulated positions according to how far the current frame lies between steps, giving the camera smooth positions to follow at the cost of showing the body a fraction of a step behind.

When the clocks are made to disagree

Time.timeScale bends all of this deliberately. Setting it to 0.5 halves Time.deltaTime and makes fixed steps fall due half as often in real time, so the whole game, physics included, runs in slow motion. Setting it to zero halts both: Update continues to run, but deltaTime is zero and FixedUpdate stops being called. Menus and interfaces that must animate during a pause use Time.unscaledDeltaTime instead, which reports real elapsed time without the scaling applied to everything else.

Changing the fixed timestep itself is a heavier decision. A smaller value, say 0.01 seconds for a hundred steps per second, gives more accurate collisions and lets fast objects tunnel through thin walls less often, but doubles the physics cost. A larger value saves processor time and loosens the simulation. Games with few physical objects rarely need to touch the default; games built around precise physics often tune it, and should measure the result with the profiler rather than assume it was free.

The deeper lesson of the three clocks is that a game is two things running side by side: a simulation that must be consistent, and a presentation that must be smooth. The fixed step serves the first, yielding the same trajectory from the same inputs on any machine; the frame serves the second, producing as many images as the hardware can afford. Input buffers, interpolation and LateUpdate are all translators between the two. In the torchlit nights of Crown & Ashes, each flame flickers on the frame clock, indifferent to the physics ticking steadily beneath it.