Paper Flight: One Button, Two Genuinely Different Feels
A tap-to-flap and a held glide from the same input, a hard failure state instead of a soft fade, and a deliberately cheerful tone under real difficulty.
Tap to flap, glide on thermals, dodge storm clouds and chimneys, collect scotch tape to keep your wings intact. An endless paper airplane flight built on a single input — tap — which meant almost the entire design effort went into making one button feel like it has real depth and range, rather than spreading complexity across a wider control scheme.
One button had to support two genuinely different feels
Tapping to flap and holding for a gentle thermal glide both come from the exact same input, and getting both to feel intentional rather than like one core mechanic with an accidental secondary behavior took real tuning. A short tap needed to read as a deliberate, punchy wing-flap; a held press needed to read as a completely different, smoother glide state, not just "the flap animation stretched out." That meant building genuinely separate physics responses keyed off press duration rather than one motion curve that happens to look different depending on how long you held it — the two states had to feel like different pilot choices, not one mechanic wearing two timings.
Wing durability needed a hard failure, not a fade-out
Health degrading from obstacle hits could have ended in a gradual performance penalty — sluggish flapping, reduced glide — as durability ran low, easing a player out of a run rather than cutting it off. I went with a hard failure state instead: your paper plane starts with a fixed health total, and running out ends the run outright, full stop, no soft landing. A gradual degradation model sounds more forgiving on paper, but it actually muddies the moment-to-moment stakes of every obstacle — if a hit only ever nudges you toward a slow fade, no single collision feels consequential. A hard failure keeps every chimney and storm cloud meaningfully dangerous throughout the entire run, not just once durability happens to already be low.
Scotch tape had to be worth detouring for, without becoming mandatory
Repair pickups needed real pull without becoming something a run can't survive without collecting constantly. I tuned base wing damage from obstacles low enough that a reasonably careful run rarely needs tape at all, which means grabbing it is a genuine bonus for a strong run rather than a required resource a cautious player is forced to chase down repeatedly. That distinction — repair as a comfortable cushion versus repair as mandatory maintenance — changes how the whole economy of risk feels. I wanted skilled, careful flying to be self-sufficient, with tape as a reward for engaging with riskier flight paths near hazards, not a tax everyone has to pay regardless of how well they're flying.
Four obstacle types needed different read-and-react windows
Storm clouds, chimneys, birds, and drifting hot air balloons aren't interchangeable hazards with different sprites — each needed its own timing profile for how much warning a player gets before it becomes a real threat. Chimneys are static and fully visible well in advance, which rewards route planning. Birds move and require more reactive tracking. Balloons are large, slow, and mostly about giving them a wide berth rather than threading a tight gap. Building genuinely different spatial reasoning demands into each obstacle type, rather than reusing one collision hazard with reskinned art, is what keeps a run from feeling like the same dodge repeated with different sprites drawn on top.
Golden stars and wind tunnels had to stay optional detours, same as Alchemy Drop's gold runes
Collectible stars and wind tunnel boosts needed the same discipline I've applied to optional pickups elsewhere on this site: worth detouring for, never worth risking the run over. A star tucked close to a storm cloud should tempt a confident pilot without punishing a cautious one for skipping it. That balance only works if the base score from just surviving and flying well stays healthy enough on its own — if collectibles carried too much of the total score, skipping a risky one would feel like leaving real points on the table rather than making a sensible safety call, which would quietly push every player toward greedier, riskier lines than the core flying itself should actually reward.
Why the color palette had to stay cheerful under real difficulty
As runs get harder, the obstacle density climbs, and I made a deliberate choice to keep the overall visual tone bright and cheerful rather than letting the game darken or turn more ominous the way difficulty escalation often does visually in other games I've built. A paper airplane soaring through a sunny sky is meant to feel gentle and optimistic regardless of how demanding the actual obstacle pattern gets underneath that tone, which is a genuinely different emotional register than something like Top Ace's escalating WWII atmosphere or Blink's increasingly tense reflex gauntlet. Difficulty and mood don't have to scale together, and this felt like the right game to prove that deliberately.
Of everything I've shipped recently, this is the calmest one, and I mean that as a compliment to the design rather than a knock on its ambition. Not every game needs escalating tension or dread to be worth returning to repeatedly. Sometimes a gentle, cheerful loop with real underlying skill underneath it is exactly the right shape for a game, and I think this one earns that gentleness rather than settling for it out of a lack of other ideas.
This also shipped the same day as a genuinely difficult decision about an existing game and a technical tool expansion, which meant holding a calm, cheerful new release in my head alongside two much more serious pieces of work at the same time. Keeping each one's actual tone distinct while building all three back to back in the same stretch of hours turned out to be its own small discipline worth naming here, one I don't think I'd have noticed clearly if I only ever worked on one single thing at a time, start to finish, before moving to the next.
More from the Devlog