Game Mechanics
Runner Game Physics Explained
A runner contains almost no physics. There is no friction, no air resistance, no mass, no collision response. There is gravity, there is velocity, and there is one rule applied every frame - and that is enough to produce every jump arc you have ever seen in the genre.
The rule
Each frame, two additions happen in this order:
- Add gravity to the vertical velocity.
- Add the vertical velocity to the position.
That is it. When you jump, the game sets the vertical velocity to a large negative number - negative because screen coordinates increase downward. Gravity adds a positive amount back each frame, so the velocity shrinks, passes through zero at the top of the arc, and becomes positive as the character falls.
Nobody writes a parabola equation. The parabola emerges from repeatedly adding a constant to a value that is itself being added to a position. This is numerical integration, and it is the oldest trick in game physics.
Why elapsed time has to multiply everything
A naive implementation adds a fixed amount per frame. On a 60Hz display that is 60 additions per second; on a 120Hz display it is 120, and the whole game runs at double speed. This is the single most common bug in amateur browser games.
The fix is to express every rate in units per second and multiply by the elapsed time since the last frame. Gravity becomes 2,400 pixels per second squared rather than 40 pixels per frame, and the game behaves identically on any display.
The elapsed time also has to be clamped. Switch tabs for thirty seconds and the next frame reports a thirty-second gap; stepping the simulation that far in one go would teleport the character through the floor. Capping the step at about a twentieth of a second turns that into a brief catch-up instead.
The four numbers that define a jump
| Quantity | Formula | What changing it feels like |
|---|---|---|
| Peak height | v² ÷ (2g) | How much you clear |
| Time in the air | 2v ÷ g | How floaty the jump is |
| Horizontal distance | speed × airtime | How far you travel |
| Feel | the ratio of v to g | Snappy versus floaty |
That last row is the design lever. A high jump velocity with strong gravity gives a fast, snappy jump with a short hang time. A lower velocity with weak gravity gives the same peak height but a long, floaty arc. Two games can have identical jump heights and feel completely unlike each other.
Variable-height jumping
Holding the button to jump higher is implemented in a way that surprises people: the game applies the full jump velocity on press, then cuts the upward velocity short if you release early.
So you are not adding height by holding - you are declining to remove it. This is why the technique only works during the rising part of a jump, and why releasing after the apex changes nothing at all.
What runners deliberately leave out
- Horizontal acceleration
- The character is usually at full speed instantly. Acceleration adds realism and removes precision, and precision is what a timing game needs.
- Air control
- Most runners give none. Once airborne, your arc is fixed, which makes the jump a single committed decision rather than an ongoing negotiation.
- Friction and drag
- No surfaces to slide on and nothing to slow down. Both would only make the timing less predictable.
- Collision response
- Hitting an obstacle ends the run. There is no bouncing or pushing, because there is nothing after the collision.
Every omission is in service of predictability. A timing game needs the same input to produce the same result every time, and most real physics works against that.
Why speed changes your jumps
In a runner, the character's airtime is fixed by gravity and jump velocity - it does not change with the scroll speed. But the world moves further during that airtime as speed rises, so the same jump clears a wider gap later in a run.
This is why calibration is not a one-off exercise. The press that was correct at the start of a run is not the press that is correct two minutes in, and players who learned a gap early often overshoot it later.
Key Takeaways
- Gravity added to velocity, velocity added to position - repeated every frame - produces the parabola automatically.
- Every rate must be multiplied by elapsed time, or the game runs at different speeds on different displays.
- Clamp the elapsed time, or a backgrounded tab teleports the character through the floor on return.
- The ratio of jump velocity to gravity decides whether a jump feels snappy or floaty.
- Variable-height jumping cuts the upward velocity on release rather than adding height on hold.
Frequently Asked Questions
Do runner games simulate real physics?
Not remotely. They use gravity and velocity and deliberately omit friction, drag, mass and collision response, all in service of predictability.
Why does my jump feel floaty in one game and sharp in another?
The ratio of jump velocity to gravity. The same peak height with lower gravity produces a much longer hang time.
Why can I not steer in mid-air?
Most runners remove air control deliberately, so the jump is one committed decision rather than an ongoing adjustment.
What is delta time?
The elapsed time since the last frame. Multiplying all movement by it is what makes a game run at the same speed on every display.
Why did I fall through the floor after switching tabs?
That is tunnelling from an unclamped time step. Games should cap the step so a long gap produces a brief catch-up instead.
