Devlog · Engine & Netcode
The largest Strider class got its current name and a complete floor-by-floor interior spec in the same stretch — including a geometry conflict that had already survived three previous attempts to fix it.
Blackjack is COGHEIM's largest Strider class, and it took its current name in the same stretch it got its first complete interior spec — 21 decks, from Roof Aerodrome down to Engine Core. Twenty-one decks, twenty-one for blackjack. That one wasn't an accident.
One deck — the Council chamber — had a geometry problem that had already come back across three prior passes at roughly the same 1.2–1.3× ratio mismatch each time. The fix, when it finally landed, was almost embarrassingly simple: the hull doesn't need to be square. Deck 10 is just elongated. Three attempts spent trying to force a symmetric solution onto a problem that only needed permission to be asymmetric.
The actual lesson: a spec problem that keeps recurring in slightly different forms is usually not a spec problem. It's an unexamined assumption sitting upstream of the spec — in this case, that the hull had to be square at all.
Past the headline geometry fix, this pass closed out a list of smaller open questions that had been sitting unresolved: the stairwell locked as interior-only with jogged positions — deliberately the opposite of the Long Climb's exposed panoramic route, so the two vertical-transit experiences don't compete with each other. Deck 4 locked as the Resource Hub, closing an open function slot. Architect slot count locked at exactly three per Syndicate.
One naming payoff made it in on purpose: the Tavern's minigame is blackjack — the card game — specifically because the class is named Blackjack. Small, but that's the kind of detail that only lands if someone notices the opportunity and takes it.
The mid-hop combat lockout mechanic had been coded correctly from the start, but it was effectively inert under the project's old discrete-hop movement model — there was no real in-transit window for it to lock out. Moving to continuous motion made the in-transit window real, which meant the lockout mechanic suddenly mattered, and a stale test in the stairwell spec (written assuming instant-snap movement) needed correcting to drive the actual BeginHop/AdvanceMotion sequence.
Worth flagging plainly: a packing-waste overflow cap bug in the same pass was caught by the test suite, not by re-reading the code. That's the test suite doing its actual job, and it's the right way to catch this class of bug going forward.
Three tries at the same fix means the fix was never the problem. The assumption underneath it was.
← All Devlog Posts