Everything that moves in a game comes down to three arrows: where the object is, which way and how fast it is going, and how that velocity is changing. That goes for a ball, a car, a grenade and the camera. A game does not see motion as a smooth line. It nudges objects in small steps, one frame at a time. This page follows those steps and shows how they add up to motion. It also explains why everything is multiplied by the frame time, why jump height can change from computer to computer, and why physics needs an even clock of its own.

Why this matters

If you move objects with whatever numbers look right on your own machine, the game behaves differently on other computers. On a fast one the character runs twice as fast, on a slow one the grenade falls short, and after a one-second hitch the ball drops through the floor. All of these bugs have one source: how the game turns smooth motion into steps.

This is the first lesson of the “Physics for games” course. You will need vectors as steps and multiplying a vector by a number. For the engine’s view of a whole frame, see the lesson “Frame and tick.” This page is about the math of motion.

Three arrows: position, velocity, acceleration

Picture someone walking across fresh snow, and every half second we mark where they are standing. That leaves a chain of footprints, and the footprints tell you everything about the walk.

• Position is where a footprint lies. It is a point, and a vector leads to it from the origin of the world.
• Velocity is how much the position changes per second. It is a vector too: it has a direction (where the object is going) and a length (how fast). Footprints left every half second and 1.5 m apart mean 3 meters per second, or 3 m/s. The length of the velocity vector is the speed, which a speedometer shows. The direction is where the wheels point.
• Acceleration is how much the velocity changes per second. A falling ball gains 9.8 m/s of downward speed every second. That is the acceleration due to gravity: 9.8 meters per second per second, or 9.8 m/s².

The chain runs one way: acceleration changes velocity, and velocity changes position. To give an object a push, the game changes its velocity. To pull it down, the game applies a constant acceleration.

Acceleration means any change in velocity, not just speeding up. Braking is acceleration against the motion. Turning is acceleration sideways. A car can drive around a circle with the speedometer fixed on one number, but the direction of its velocity keeps changing, and you feel yourself pressed against the door. On a circle of radius r at speed v, the acceleration points toward the center and equals v² / r.

How to read the footprints

The gap between two neighboring footprints is the speed times the time between them. If the gaps are equal, the speed is constant. If they grow, the object is speeding up, and they grow by the same amount each time. For example, start from rest with an acceleration of 2 m/s² and leave a footprint every 0.5 s. The footprints land at 0, 0.25, 1, 2.25 and 4 m, so the gaps are 0.25, 0.75, 1.25 and 1.75 m. Each gap is 0.5 m longer than the one before, and 0.5 m is exactly the acceleration × (0.5 s)².

In a turn, the gaps are equal but the velocity arrows rotate. There is acceleration, even though the speedometer does not move.

A game moves in steps

Think of a flip book. On each page the little figure has moved a bit farther, and when you flip through the pages fast, he runs. A game works the same way. Sixty times a second it nudges everything a little and draws a new picture, a frame. The time between the previous frame and this one is called delta time, written Δt. At 60 frames per second, Δt = 1/60 ≈ 0.0167 s, which leaves 16.7 ms for the whole frame.

Every frame the game makes two updates. They are the two relationships we read off the snow, now run the other way:

velocity = velocity + acceleration × Δt     // acceleration changes velocity
position = position + velocity     × Δt     // velocity changes position

All of these are vectors, and the game handles each axis on its own. A ball moves at velocity (4, 3) m/s and the frame lasts 0.02 s, so the position shifts by (0.08, 0.06) m. In the same frame, gravity (0, −9.8) m/s² changes the velocity by (0, −0.196) m/s, and the ball’s path bends down a little more.

When a character moves where the thumbstick points, normalize the direction to length 1 first, and only then multiply by the speed. Otherwise the character runs 1.41 times faster along the diagonal (1, 1). That is the trap from the vectors lesson.

Why multiply by Δt

The most direct way to move a character is by 5 cm every frame. But the number of frames per second depends on the computer:

Without Δt, a hero runs almost five times faster on a powerful computer than on a weak one, and slows down whenever a pile of explosions drags the frame rate down. With Δt, you set the speed in meters per second, and each frame takes its share of it: a short frame makes a short step, a long frame a long one. Over one second the steps always add up to 3 meters.

Integration: steps instead of a smooth line

Building motion out of small steps is called integration: you recover the distance from the velocity, and the velocity from the acceleration. The simplest method is the one above, Euler integration. It makes one assumption: the velocity stays constant for the whole frame. A real ball changes its velocity continuously, but in a game the velocity changes in jumps, once per step. That introduces an error, and the size of the error depends on the step length.

The order of the two lines matters

You can run the two lines in either order, and the results differ:

• Explicit Euler: update the position first, using the old velocity, then update the velocity. The step uses the velocity from the start of the frame.
• Semi-implicit Euler: update the velocity first, then update the position using the new velocity. The step uses the velocity from the end of the frame.

Test them on a throw. A ball is tossed straight up at 7 m/s, and its true peak height is exactly 2.5 m. Here is what each method gives with different numbers of steps per second:

On the way up the ball is slowing down, so its velocity at the start of each step is larger than at the end. Explicit Euler steps with the larger velocity and overshoots. Semi-implicit Euler steps with the smaller one and falls short. The error is proportional to the step length: halve the step and you halve the miss. At the top of the arc it equals g × Δt × t / 2, where t is the time to rise. At 30 steps per second that is 12 cm.

For a game, this means jump height depends on the frame rate. Take semi-implicit Euler, as engines do: a ledge at 2.45 m is reachable at 144 frames per second (2.48 m) and out of reach at 30 (2.38 m). With explicit Euler it is the other way around: on a slow computer the jump comes out higher, not lower. Either way, the height depends on the frame rate. Multiplying by Δt does not save you here: it evens out the average speed, but not the error of the step.

So why do engines use semi-implicit Euler, if it makes errors too? Because it is stable. Explicit Euler adds a little energy at every step: a spring swings wider and wider, and a satellite spirals away from its orbit. Semi-implicit Euler holds the amplitude of the swing and stays on its orbit. The lesson on springs goes into detail.

distance = (v₀ + (v₀ + aΔt)) / 2 × Δt = v₀Δt + aΔt² / 2

Fixed timestep

If the result depends on the step length, make the step always the same. That is a fixed timestep: the physics runs in even steps, say 1/60 s each, separately from the frames. Frames arrive whenever they can, and physics keeps its own clock.

The time accumulator

Picture a piggy bank, which programmers call an accumulator. Every frame drops a coin into it: that frame’s own delta time, so the coins come in different sizes. Physics spends time only in identical banknotes of 16.7 ms. As long as the bank holds enough for one banknote, physics takes a step.

accumulator = accumulator + frame_time
while accumulator ≥ step:
    physics step of length step
    accumulator = accumulator − step

Take 40 frames per second (25 ms each) and a step of 16.7 ms. The first frame runs one step and leaves 8.3 ms. The second frame brings the total to 33.3 ms, which is two steps and nothing left over. After that it is one step again. At 144 frames per second (6.9 ms each), a step happens every two or three frames, and the frames in between run no physics at all. In one second there are always exactly 60 steps.

This gives you three things:

• The same result everywhere. A jump has the same height on every computer, and the ledge is reachable for everyone or for no one.
• Replays. The same inputs on the same steps produce the same game. Replay recordings rely on this, and so do networked games, where the computers have to arrive at the same outcome.
• Stability. Springs, stacks of crates and vehicles are tuned for one step length, so they do not blow up when a frame happens to be long.

Smoothing between steps

The accumulator comes at a cost. At 144 frames per second with 60 physics steps per second, the ball stands still for two or three frames in a row and then jumps, so the motion looks jerky. The fix is interpolation: the game remembers the last two steps and draws the object somewhere between them. The fraction comes from the accumulator: leftover / step. With 4 ms left out of 16.7, you draw the object 0.24 of the way from the previous step to the latest one.

The picture now lags behind the physics by at most one step, 16.7 ms. The eye does not notice that, but it notices jerky motion at once. Only the drawing is smoothed. Physics, collisions and hits stay on their own steps.

The spiral of death

The accumulator makes up for a slow frame by running extra steps, and that is the trap. Suppose drawing takes 5 ms, while one physics step takes 20 ms to compute and covers 16.7 ms of game time. Every step makes the frame longer, a longer frame puts more time into the accumulator, and more time means more steps. The frames grow: 25 ms, 25, 45, 45, 65, 85, 105… The game sinks: frames come less and less often until it freezes. This is the spiral of death.

There are two safeguards, and both give up some game time:

• At most N steps per frame. The extra time in the accumulator is thrown away. The game starts to run slower than real time, like slow motion, but it does not freeze.
• At most N seconds per frame. After a long load or a pause, the game puts at most, say, a third of a second into the accumulator instead of 5 seconds at once.

A step that is too long

Even a fixed step can be too long for a fast object. A bullet flies at 300 m/s, so in one 1/60 s step it jumps 5 m. A 20 cm wall falls between the two positions, no collision happens, and the bullet passes straight through. This is called tunneling. If the physics steps by the frame time, one half-second hitch produces a half-second step, and a falling crate shoots through the floor. The lesson on why fast bodies fall through shows how to catch and fix this.

Trajectory: where the grenade lands

A thrown object has a constant acceleration: gravity, pulling it down. So horizontally it moves steadily, like the footprints with equal gaps, and vertically it moves like the tossed ball: up, slower and slower, and back down. Together that makes a parabola. The path of an object is called its trajectory.

For constant acceleration there is an exact formula for the position at any moment. It is the same trapezoid as in “Under the hood”:

position(t) = start + velocity₀ × t + acceleration × t² / 2

A grenade leaves the thrower’s hand at 20 m/s, at an angle of 45°. Split the velocity into two axes with sine and cosine: 14.1 m/s forward and 14.1 m/s up. The grenade climbs for 14.1 / 9.8 = 1.44 s and rises 10.2 m. The whole arc lasts 2.89 s, and in that time the grenade travels 14.1 × 2.89 = 40.8 m forward. On level ground, a throw at 45° goes the farthest. You can hit the same spot with two different angles, a flat shot and a lob, for example 30° and 60°.

Aiming: drawing the arc in advance

The dotted trajectory line you see when aiming a grenade launcher uses the same formula. The game plugs in t = 0, 0.05, 0.1 s… and connects the points. Between each pair of neighboring points, it checks whether the segment touches a wall or the ground, and draws the landing marker there.

There is a catch: the grenade itself flies in physics steps, while the arc is computed exactly. With semi-implicit Euler at 30 steps per second, the grenade lands 30 cm short of the marker. To stop the preview from lying, either compute the arc with the same steps the physics uses, or move the throw by the formula instead of the physics.

In engines and Blender

Where it breaks

• Everything runs faster on a powerful computer and slower on a weak one. The motion is applied per frame, without Δt. Specify speed per second and multiply by Δt.
• A jump sometimes reaches the ledge and sometimes does not. Physics steps by the frame time, so the step error varies. Use a fixed timestep.
• Objects stutter at a high frame rate. The physics runs on a fixed timestep with no smoothing. Turn on render interpolation.
• The game gets slower and slower under load and finally freezes. The spiral of death: a physics step takes longer to compute than it lasts. Cap the steps per frame and simplify the physics.
• After a hitch, a crate fell through the floor. One huge Δt. Cap the frame time and use substeps.
• The aiming marker does not match the landing spot. The arc is computed by a formula, and the grenade by steps. Compute both the same way.
• A spring swings wider and wider and flies off. Explicit Euler adds energy. Use semi-implicit Euler and a shorter step.

Connections: the same idea in other fields

• Game feelDesigners set the height and length of a jump through the takeoff velocity and gravity, and often make the fall faster than the rise. How controls feel
• NumbersAdding up small steps is the same kind of accumulation that makes a clock drift by tens of minutes. The clock that drifts
• SoundSound also lives in even steps: 48,000 samples per second, like the fixed timestep of physics. Sound as data
• ShadersWaves and wind in a material do not accumulate steps. They compute the position directly from the time, like the parabola formula. Waves: sine over time
• NetworkingIdentical physics steps let different computers arrive at the same outcome. Networking: who is right

Key points

• Position, velocity and acceleration are three vectors. Acceleration changes velocity and velocity changes position, each per second.
• Turning is acceleration too: the direction of the velocity changes, even if the speedometer does not.
• A game moves everything in steps: velocity += acceleration × Δt, position += velocity × Δt. Δt converts “per second” into “per frame.”
• Euler integration makes an error proportional to the step. Semi-implicit Euler (velocity first) is stable, which is why engines use it.
• A fixed timestep gives the same physics on every computer. The time accumulator decides how many steps to run in a frame, and its leftover smooths the drawing.
• A step that takes longer to compute than it lasts drowns the game in a spiral. A cap on steps per frame trades freezing for slowing down.
• Under constant acceleration the path is a parabola, and its exact formula with t²/2 draws the aiming arc.