On this page
Tune in dependency order
The most common mistake in building one of these is tuning the numbers in the order you notice them. They have a dependency order, and following it turns a week of fiddling into an afternoon.
- Gravity first. It sets the fall-time budget for the whole play area. Everything else is expressed relative to it.
- Flap force second, as a fraction of terminal fall speed. Between 0.65 and 0.9 works; below 0.6 makes bad falls unrecoverable and above 0.95 makes the ceiling trivial to reach.
- Speed caps third. Terminal fall determines how bad a bad situation can get; the rise cap stops a stack of flaps launching the flyer.
- Gap height fourth, derived from how far the flyer travels during one correction at terminal speed. That is your floor; the starting value is typically 35 to 40% above it.
- Scroll speed fifth, from how long a typical altitude change takes.
- Spacing last, from scroll speed and the decision rate you want.
Changing anything early in that list invalidates everything after it. If you find yourself adjusting gravity after you have tuned spacing, throw the spacing away and redo it — the alternative is a game that feels subtly wrong in a way nobody can describe.
The four playtest targets
Every game on this site is tested against the same four numbers before it ships. They are not industry standards; they are ours, and they are what we found produces a game people play more than twice.
| Target | Value | Why |
|---|---|---|
| First-attempt survival | 8–15 seconds | Long enough to learn the control before failing |
| Median run | 35–70 seconds | Long enough to feel like a run, short enough to retry freely |
| Skilled run | 3–6 minutes | There has to be somewhere to get to |
| Visible improvement | Within 10 attempts | If nothing improves in ten tries, players leave |
The first and the last are the ones that get missed. A game where a new player dies in three seconds five times in a row has given them no information, and a meaningful fraction will conclude it is broken rather than that they are new — which is a reasonable conclusion given the evidence they have.
The fourth is subtler. It is possible to build a game that is fair, deep and completely opaque, where a player cannot tell what they did differently between a 20-second run and a 60-second one. Those games get abandoned. Something has to be visibly attributable.
The mistakes that make a flappy game feel wrong
- Additive flaps. If a flap adds to velocity rather than setting it, the optimal strategy is mashing and the ceiling becomes the only obstacle.
- No terminal velocity. Uncapped falls create states where nothing the player does can work — and with one input, there is nothing else to try.
- Unconstrained gap placement. Random placement eventually produces an unflyable sequence, and the player correctly concludes the game cheated.
- Rectangular hitboxes on round sprites. Near misses become deaths, which feels arbitrary even though it is consistent.
- Fixed per-frame movement. Without delta timing, the game runs at double speed on a 144 Hz monitor.
- No frame-time clamp. One browser stall teleports the flyer through a pillar, and the player has no way to understand what happened.
- Difficulty that rises forever. Every run ends at the same wall and skill stops being the variable.
- Snapped rotation. Purely cosmetic, and without the lag the flyer reads as a cursor rather than a creature.
That list is, more or less, the difference between the good flappy games on the web and the large number of bad ones. None of the fixes are difficult; all of them are easy to skip.
One idea per game
The strongest design constraint we use is that each game gets exactly one new idea, and everything else stays at the reference values.
Gap Hunter shrinks gaps and holds speed low. Flappy Rush raises speed and keeps gaps generous. Sky Dodge changes the obstacle and keeps the physics standard. Balloon Escape inverts the control and keeps the obstacles easy.
The reason is teachability. A game that is hard for four reasons at once cannot be improved at, because the player has no way to attribute failure. A game that is hard for one reason produces a clear question — why did that gap beat me? — which has a findable answer.
The flagship is the deliberate exception. Flappy Arcade Ultimate combines everything, and it works precisely because the other twenty-nine taught the pieces separately first.
From idea to published
The process each game here goes through, in order:
- One mechanic, stated in a sentence. "Gravity reverses when you pass through a gate." If it takes a paragraph, it is two mechanics.
- Prototype. Usually under a hundred lines on top of the shared engine. Playable, ugly, no art.
- Tune against the four targets. This is most of the work and it is done before anything is drawn.
- Fairness pass. Can the generator produce something unflyable? Is every change telegraphed? Is anything conveyed by colour alone?
- Controls for both. Desktop and touch verified together, not adapted afterwards.
- Art and sound. Drawn from primitives, synthesised from oscillators.
- Accessibility pass. Pause works, reduced motion respected, focus states visible, canvas labelled.
- Written content. The page copy is written last, by the person who tuned the game, which is why the tips on our game pages quote real numbers.
That last point is the reason this site can say things like "the shutter closes over 1.4 seconds" — we chose 1.4.
Know what your game is for
The final piece of advice is the least technical and the most useful: decide what a player is supposed to get better at, and then make sure the score measures that.
If your game is about accuracy, score accuracy — otherwise a scrape and a centre pass are worth the same and the game silently endorses the scrape. If your game is about survival, score time. If your game is about collection, record the collection rather than the points.
Getting this wrong is invisible and expensive. A game whose scoring points somewhere other than its design produces players who optimise away from the thing that makes it good, and then quite reasonably conclude that the thing was not very good.
Key takeaways
- Tune in dependency order: gravity, flap force, speed caps, gap height, scroll speed, spacing.
- Test against four targets: 8–15 s first attempt, 35–70 s median, 3–6 min skilled, visible improvement within ten tries.
- Most bad flappy games share the same eight fixable mistakes, starting with additive flaps and unconstrained gaps.
- Give each game exactly one new idea so that failure is attributable and the game is improvable.
- Make the score measure the thing the game is about, or players will optimise away from it.