Runner Game Physics Explained

"Physics" in a runner game means four small systems that never touch each other. None of them is a physics engine, and all four are simpler than they look.

1. The scroll

The character does not move horizontally. In Ninja Dash the ninja stays at x = 150 for the whole run, and the world moves past her:

var move = speed * dt;
for (var i = 0; i < obstacles.length; i++) obstacles[i].x -= move;

Objects that pass the left edge are deleted; new ones are added off the right. Background layers scroll at fractions of the same distance for parallax depth.

The practical consequence for a player: the only variable you ever need to judge is where the obstacle is, because the ninja is always in the same place.

2. Gravity and the jump

The only genuine physics in the game, and it is a two-line integration:

vy += GRAVITY * dt;
py += vy * dt;

With Ninja Dash's numbers — a take-off velocity of 880 px/s against 2,400 px/s² of gravity — the arc works out to an apex of about 161 pixels and 0.73 seconds of air time.

Holding the jump key applies an extra −1,500 px/s² for up to 0.16 seconds, which is the variable jump height that lets one button produce a range of arcs. Variable jump height explained covers why nearly every game in the genre does this.

Fast-falling is the same mechanism in reverse: pressing Down sets a minimum downward velocity so the character drops immediately.

3. The slide

Sliding is not physics at all. It swaps the character's collision box for a shorter one — 74 pixels down to 40 in Ninja Dash — for a fixed 0.52 seconds, then swaps it back.

Two deliberate design choices are buried in that sentence. The duration is fixed, and it cannot be cancelled. Both exist so that starting a slide is a commitment to the next half second rather than a free action, which is what makes a beam followed closely by a crate a genuine problem.

4. The fixed timestep

The system that makes everything above trustworthy.

Screens refresh at 60Hz, 90Hz, 120Hz, 144Hz. If physics advanced by however long the last frame took, the same jump would produce different heights on different monitors, and collision results would depend on the display.

So the simulation is decoupled from rendering:

accumulator += deltaTime;
while (accumulator >= STEP) {     // STEP = 1/60 second
  update(STEP);
  accumulator -= STEP;
}
render();

Physics always advances in identical 1/60-second increments. Drawing happens once per frame, however often that is. A player on a 144Hz monitor gets a smoother picture and exactly the same simulation as one on a 60Hz laptop.

A cap on the loop count — five steps in this engine — prevents a spiral of death, where a slow frame requests more steps than the machine can complete, making the next frame slower still.

Why fall speed is capped

Falling velocity is clamped — 1,100 px/s in Mystic Ninja — to prevent tunnelling.

At 60 steps per second, an object falling at 1,200 px/s moves 20 pixels per step. If a platform's landing band is 20 pixels deep, the character can be above it on one step and below it on the next without ever overlapping. Capping the speed keeps per-step movement inside the band.

What runner physics deliberately leaves out

Friction and acceleration. The character runs at the scroll speed. There is no ramp-up, because a runner that took half a second to reach full speed would feel unresponsive.

Momentum through jumps. Horizontal position is fixed, so there is nothing to carry.

Rotation. Collision boxes are axis-aligned rectangles. A rotating hitbox would cost more to compute and would make close calls unpredictable.

Realistic gravity. Earth gravity at this scale would produce a floaty, slow jump. These games use two to four times that value because arcade jumps need to be snappy, not accurate.

That last point is worth stating plainly: game physics is not a simulation of reality. It is a set of numbers tuned until the game feels right.

Key takeaways

• The character does not move; the world scrolls past a fixed position.
• Jump arcs come from a take-off velocity and constant gravity, with a short hold window for variable height.
• Sliding swaps the collision box for a fixed, uncancellable duration — that commitment is the point.
• A fixed 1/60-second timestep keeps the simulation identical across refresh rates.
• Fall speed is capped to stop fast objects tunnelling through thin colliders.

Frequently asked questions

Do runner games use a physics engine?

No. A few lines of velocity integration and rectangle overlap tests cover everything a runner needs; a full engine would be far heavier for no benefit.

Why is game gravity so much stronger than real gravity?

Because real gravity feels floaty at this scale. These games use two to four times Earth gravity to make jumps snappy and predictable.

Does a higher refresh rate give an advantage?

No. The simulation runs in fixed steps regardless of refresh rate, so a 144Hz display looks smoother but plays identically.

Why can't I cancel a slide?

Because a cancellable slide would have no cost. The fixed duration is what makes choosing to slide a meaningful decision.