Defold 1.12.0 introduced one of the most impactful improvements for physics-heavy games: the reworked script callback order, that clearly separates now a fixed-timestep simulation from frame-timestep gameplay logic, and adds a dedicated “late pass” stage for e.g. camera or visual alignment.
As of Defold 1.12.0, the engine update loop now runs Lua script callbacks in this high-level order:
fixed_updateupdatelate_update
Between these stages (and between all internal component-type updates), Defold dispatches and flushes posted messages, and all transforms are updated whenever needed.
Let’s go through what each type of update is useful for and how to utilize them in the best way, especially if you are working on games with physics simulations.
Fixed Update
Fixed Update, introduced earlier and used mostly in physics based games, since 1.12.0 runs before the update loop. It might be executed 0 to several times per frame to correctly calculate the physics simulations, when the delta time between frame updates is different than the fixed timestep defined in project settings. This means your physics interactions can become more rate-stable. Fixed updates on physics objects with your optional Lua fixed_update() callbacks in scripts are independent of the frame rate, so even if frame time fluctuates, you are ensured your physics simulation steps are not missed before next frame render.
Two important notes, before diving into details:
- Input is handled before the whole Update Loop.
on_input()belongs to the Input phase, which runs before Fixed/Update/Late Update. - Per-object order is not guaranteed for neither
fixed_update(),update(), norlate_update(). Design as if objects could be updated in any order.
How to use Fixed Update?
A robust pattern for physics-based games might now look like this:
- read input as usual (input is handled before update callbacks),
- store intent (key inputs, axis movement, jump pressed, etc.),
- apply the intent to collision objects inside the
fixed_update()(force/torque/velocity, etc.). - do the rest regarding visual representation in
update()and eventuallylate_update()if needed
With fixed timestep enabled, you can now treat fixed_update() as your consistent simulation step, while still keeping update() purely frame-driven. This should reduce the classic issues when physics behavior subtly changes across devices due to varying dt.
When to use Fixed Update?
Use the fixed_update Lua function for anything that must be stable at a fixed cadence, regardless of framerate:
- applying forces / torques / impulses
- setting velocities and accelerations
- stepping deterministic movement that should not vary with frame pacing
- feeding a physics-based controller from buffered input
Important to know: fixed timestep improves stability compared to variable dt updates, but it does not guarantee cross-platform “bitwise determinism” for a physics simulation (floating point and platform differences still exist), so remember about it, when making physics-heavy games.
How to enable Fixed Update?
Fixed Update is disabled by default. If you need to enable it, check those settings in your game.project file:
Physics→Use Fixed Timestep- to enable/disable Fixed UpdatesPhysics→Max Fixed Timesteps- to define maximum number of stepsEngine→Fixed Update Frequency- to set up the frequency [in Hertz]
Update
Update is the regular, frame-timed callback. It didn’t change itself, so in Defold 1.12.0 it is called exactly once per engine frame, but note, it’s called after all fixed_update() steps (if enabled) and before late_update(). The dt you receive here as a parameter is the variable delta time since the previous frame, so this is the right place for logic that should naturally run once per rendered frame, not once per physics step.
When to use Update?
Do here everything else related to your game, that is needed to be called once every frame, like for example:
- animation state machines
- all visual components updates (sprites, models, meshes, etc)
- positions, rotations and scales updates
- UI updates
- non-physics gameplay systems that should tick once per rendered frame
Of course, we strongly advise to only do here stuff that must be done each frame. If you are making a turn-based game, or any other system of your game is not needed to be run each frame, convert it into a reactive system with proper use of messaging system or input system.
Late Update
Late Update is new in Defold 1.12.0 and runs once per frame, after all update() callbacks. As noted, Defold dispatches in-game messages between all these stages, which makes late_update() Lua callback an ideal place for reacting after everything is settled. You can think of Late Update as your final pass before rendering. It happens at the end of the engine update loop, just before the render script is called.
When to use Late Update?
This is where physics-based projects can get an immediate quality bump, as following can be performed here based on final positions for the frame:
- camera updates (following, shake, dead-zones, smoothing, etc.)
- snapping visuals to physics bodies to reduce “one-frame behind” feel
- last-pass transform adjustments (e.g. look-at, simple constraints, tweaks that should not feed back into simulation)
You can safely update game object transforms in late_update(), because components update internal transforms after script execution, and the engine performs a final transform update at the end of the update loop, if needed.
Do not use late_update() for simulation. If something must affect the physics step deterministically, keep it in fixed_update(). Use late_update() to make what the player sees match what the simulation already decided.
For more details, we advise you to study the Application Lifecycle manual that was updated to match the changes:
Examples
Recently @JuLongZhiLu shared an example for late update:
And it presents one of the most common usage of late updates - camera following the characters. So, when you make all your characters updates in update(), then simply in late_update(), where you are guaranteed, that all update()callbacks were already executed before, take the final position of the character (or multiple characters, if you want to center camera between them) and calculate the final position of the camera.
Here you can also check out a short, nice example to quickly detect fixed-step “bursts”:
function init(self)
self.fixed_steps_this_frame = 0
end
function fixed_update(self, dt)
self.fixed_steps_this_frame = self.fixed_steps_this_frame + 1
end
function update(self, dt)
if self.fixed_steps_this_frame > 1 then
print("fixed steps this frame:", self.fixed_steps_this_frame)
end
self.fixed_steps_this_frame = 0
end
This will print how many times per frame the fixed step update was called, so you can determine whether you’re hitting multiple fixed steps in a single rendered frame.
Interpolation
As @aglitchman presented, it’s possible to create a custom component that, when just added to a game object, interpolates transforms between fixed update states for smooth movement, and there is an open source project with it:
And this gives some really nice results:
Do you have any other tricks for physics based games? What’s else worth noting when making those?
P.S. Game from the top banner is “Bounce Ball” by WeDoYouPlay , you can check it out on Poki:
