Top Ace Finally Gets the Boss Fight I Predicted It Would Need
A boss encounter built through the same gun-heat and barrel-roll systems every regular dogfight already uses, plus a real Aircraft Roster.
Ten days ago I wrote that Top Ace shipped with zero bosses and that I already suspected that wouldn't stay true, since an endless dogfighter with escalating squadron variety but no singular named threat felt like it was missing a capstone. Today it gets one: full boss encounters with their own health bar and attack patterns, plus an Aircraft Roster screen — a real plane database — sitting alongside the existing Hangar & Upgrades depot.
Retrofitting bosses meant respecting systems that weren't built expecting them
Gun heat, barrel-roll invulnerability, and the CRT radar were all tuned against regular squadron encounters, and a boss fight has to respect all three without secretly breaking any of them or requiring a boss-specific exception layered awkwardly on top. A boss encounter that ignores gun-heat mechanics, for instance, would create a strange inconsistency where the resource management that matters everywhere else in the game suddenly stops applying the moment a boss appears. I built the boss health bar and attack patterns to operate through the exact same combat systems every regular encounter already uses, rather than introducing a parallel boss-only rule set that would make the capstone fight feel disconnected from the game leading up to it.
The threat pulse had to telegraph danger without breaking the radar's existing language
A pulsing threat warning for incoming boss attacks needed to sit alongside the CRT radar's existing bogey-tracking language rather than introducing a visually unrelated warning system competing for attention on the same screen. I designed the pulse to read as an escalation of the radar's existing visual vocabulary — the same kind of signal a player already trusts for tracking regular threats, just intensified for something boss-scale — rather than a completely new UI element bolted on that a returning player would have to learn from scratch the first time a boss actually appeared.
The Aircraft Roster had to earn a second dedicated screen, not just duplicate the Hangar
The Hangar & Upgrades depot already shows upgrade paths for your own aircraft. The Aircraft Roster is a genuinely different screen — a plane database with stats for every flyable aircraft, framed more like a reference encyclopedia than a shop. Building both meant being honest about what each screen is actually for: the Hangar is where you make decisions about your current loadout, the Roster is where you go to understand the wider cast of aircraft in the game, including ones you might not currently be flying. Collapsing them into one combined screen would have meant every upgrade decision competed for the same space as reference browsing, which are different mental modes a player shouldn't have to context-switch between constantly on the same page.
Player stat tracking had to mean something once bosses existed
Tracking kills, accuracy, and survival time became a meaningfully richer signal the moment bosses entered the picture, since a boss encounter tests a different combination of those stats than a regular squadron does — sustained accuracy under pressure matters more against a single tough target than raw kill count does. I made sure the stat tracking added today captures that distinction rather than lumping boss performance into the same undifferentiated totals as regular squadron combat, since a player's actual skill against a boss is a genuinely different, more specific thing to measure than their overall survival time across an entire run.
A boss needed its own attack vocabulary, not a bigger regular enemy's moveset
Scout, interceptor, and dive-bomber attack patterns were all designed around brief, single-pass engagements — an enemy appears, attacks, and is dealt with in a relatively short exchange. A boss fight needs to sustain tension across a much longer encounter, which meant building a genuinely new set of attack phases rather than just giving an existing enemy type a larger health bar and calling it a boss. A health bar alone doesn't create the feeling of an escalating, multi-phase fight; distinct attack patterns that change as the fight progresses do, and that's where most of the actual design effort for the encounter went.
Supply drops and the escalating atmosphere had to still matter during a boss fight
Supply parachutes and the sky's shifting cloud atmospheres were both built as ongoing, ambient parts of a regular run, and a boss encounter risked overriding both — locking the sky into one fixed boss-arena look, or removing supply drops entirely for the sake of a cleaner, more controlled fight. I kept both active rather than suspending them for the encounter, since a boss fight that suddenly strips away every other system running throughout the rest of the game would read as a different game bolted onto this one, rather than the natural, escalating conclusion of the same continuous run a player has been flying the whole time.
Was I right to wait ten days instead of shipping bosses on day one?
Reading back my own launch post, I said I'd rather ship the core dogfighting loop solid first and let a boss stand on top of a feel that already worked, rather than delay launch chasing a feature I hadn't earned the confidence to build correctly yet. Ten days of watching how gun heat, barrel rolls, and the radar actually get used in real dogfights gave me a much better sense of how a boss fight should stress those same systems than I would have had guessing at it before a single squadron encounter had ever been played for real.
I think this is becoming a genuine pattern across everything I build now, not a one-off decision specific to this game: ship the core loop, watch how it's actually used, then build the capstone on top of real evidence instead of a launch-day guess. Blink, Perfect Color, and now Top Ace have all followed some version of this same shape, and I don't expect that to stop being the default approach any time soon, even when the wait between launch and payoff is longer than I'd initially guess it needs to be.
More from the Devlog