Gap Hopper — keeping an endless runner honest

The challenge

An endless one-tap runner lives or dies on a single question: when the player misses, do they blame themselves or the game? Get that wrong and nothing else matters, because a player who feels cheated stops playing and cannot tell you why.

The difficulty is that "endless" and "fair" pull in opposite directions. The run has to keep getting harder or it gets boring, but every increase in speed shortens the window the player has to read the next gap. Push it too far and the game stops being a skill test; hold back and there is no reason to keep playing past the first minute.

Shipping on Android adds a constraint that browser games do not have. The game has to hold a steady frame rate across a wide range of real phones, many of them several years old, because a dropped frame at the moment of a jump reads to the player as the game stealing their input.

Shipping on Android rather than the browser also changed what "finished" meant. A store listing is permanent and public: a one-star review citing stutter or a missed tap stays visible to every future visitor, and unlike a web build there is no silent redeploy to fix it. The margin for a performance problem at launch is much smaller than it looks.

Our approach

Every gap is placed so it is on screen for longer than a worst-case human reaction time before the player must commit. As the run speeds up, the spacing opens up with it, so the reading window stays roughly constant even as the game gets faster. The player is pushed on execution, never on information.

The input is a single tap with a forgiving window at the edges, because the difference between a fair runner and a frustrating one is usually a few frames of tolerance that the player never consciously notices.

Visually the track is built for one job: making the next gap obvious. Bright, flat, high-contrast shapes, with detail kept out of the lane the player is actually reading. Decoration that competes with the gap is decoration that costs a run.

Performance was treated as a design constraint rather than an optimisation pass. The game holds its frame budget on mid-range Android hardware, because a stutter at the moment of a jump is indistinguishable from a bug to the person holding the phone.

The tap window was given deliberate tolerance at the edges. A few frames of forgiveness is the difference between a runner that feels responsive and one that feels like it is stealing inputs, and it is a difference players feel without ever being able to name it.

Performance was treated as a design constraint rather than an optimisation pass at the end. The game holds its frame budget on mid-range hardware, because a dropped frame at the moment of a jump is indistinguishable from a bug to the person holding the phone — and on a store listing, that reads as a one-star review rather than a technical note.

The result

An endless runner where the losses read as the player's own — the gap was always visible long enough to react to, so the lesson is learnable rather than arbitrary.

Live on Google Play, free, with one-tap controls that work the same on any Android phone.

The same reflex-fairness rule drives our browser titles, so the approach is portable across platforms rather than tied to one build.

Gap spacing opens up as speed rises, so the reading window stays roughly constant through a run — the player is pushed on execution, never on information.

The tap window carries deliberate frame tolerance, which is what separates a runner that feels responsive from one that feels like it is ignoring input.

Live on Google Play, free, with one-tap controls that work the same on any Android phone.

The same reflex-fairness rule drives our browser titles, so the approach is portable across platforms rather than tied to one build.