Most scope problems don’t announce themselves. You design a system that makes sense on paper, start building, and then somewhere in the middle (usually closer to the deadline than you’d like) it becomes clear that what you planned and what you can actually deliver aren’t the same thing.
That’s exactly where my brother Morgan Hunt and I found ourselves on day three of the Flame Game Jam 2026.
The Flame Game Jam 2026 is Blue Fire’s annual game jam for Flame, the open-source 2D game engine that runs on Flutter. This year’s ten-day edition featured one revealed theme and one required diversifier—a constraint or implementation challenge chosen from a list.
This was my first time competing as a duo; in previous years, I’d entered solo. Morgan owned the technical foundation (game logic, sector calculations, and the procedural generator), while I took frontend development and UI.
When the theme dropped as “Big Brother,” we began brainstorming. We ran through the obvious directions (surveillance thrillers, dystopian aesthetics) and landed on something more interesting: a social commentary on AI dependency, wrapped in mechanics inspired by Plague Inc. You play as an LLM. Your goal is to spread AI dependency across the globe before an anti-AI organization shuts you down. We called it Suppressed Intelligence.
Our planned game design would include four sector stats, three upgrade trees, a procedurally generated news report pushing pro- or anti-AI headlines every 15 seconds (our chosen diversifier), and a resistance organization that mobilized once you’d made enough of an impact. For the visual identity, I landed on a Windows 95 aesthetic.
The Moment You Have to Choose
By day three, we still lacked a playable build and were running out of time. The mechanics existed in pieces, but the pieces weren’t connected into anything a player could experience.
This is a moment every team faces in time-boxed work. The call you make in that moment determines whether you ship something people can actually engage with, or something that technically exists.
We narrowed to a single upgrade tree (AI Infiltration) and removed two of the four sector stats. The core gameplay loop stayed intact: players pop AI bubbles to infiltrate connected regions while managing the news headline carousel. The game we shipped was smaller than the game we designed, and it was better for it.
What We Should Have Aligned on Earlier
We’d gone into the game jam with a general idea of what each upgrade tree would do, but not the specifics. When it came time to actually build the upgrade system, Morgan and I had to stop and define things that should have been established before coding began.
This cost us time we didn’t have.
The lesson isn’t that you need exhaustive specs before you build. It’s that the communication between system pieces needs to be agreed on before anyone starts building them in parallel. Like the variables, the interactions, and the cause-and-effect relationships.
In a 10-day sprint, two days of misaligned assumptions are a significant tax. In a longer product cycle, the same dynamic compounds.
Playtesting With 24 Hours Left
With a playable game and less than a day on the clock, we sent our build to friends and family who had offered to test it.
The brief was simple: what worked, what confused you, what didn’t work. We got back three clear priorities:
- Players didn’t know how to play. A tutorial wasn’t optional; it was the minimum viable experience.
- The upgrade button blended into the background. Several testers hadn’t discovered it until well into the game.
- The difficulty was too high. Everyone reported losing.
With a handful of bug reports alongside these, we now had three improvements that needed to be done during the last day.
I built the tutorial as a staged system: a UI panel that slides in and pauses the game at key moments rather than front-loading everything at once. It triggers at game start, when the player selects their launch sector, and when AI Dependency hits 15%. The goal was to deliver context when it was relevant, not dump it all on the player before they’d had a chance to understand what they were doing.
Morgan tackled the difficulty curve. When playtesters came back after the fixes, the verdict was clear: significant improvement over the previous version.
We submitted with 8 minutes and 23 seconds to spare.
What Time-Boxed Work Actually Teaches You
A game jam is an extreme version of something product teams navigate constantly. Building something real under real constraints, with ambiguous information, and a deadline you can’t negotiate.
Three things I’ve learned from this experience:
Scope discipline is a skill, not a compromise. The teams that ship well under constraint aren’t the ones who do less; they’re the ones who identify the core loop early and build toward it. Everything else is additive, and additive features earn their way in based on what the core loop still needs.
Pre-build alignment has a cost when it’s skipped. Variables that touch multiple systems, and interactions between components built by different people, need to be defined before anyone starts building. This isn’t process overhead; it’s the minimum coordination that prevents expensive rework later.
Testing with real users, even briefly, changes what you build. We made better decisions in the final day because we got feedback from real people. The tutorial design, the button positioning, the difficulty tuning: these didn’t feel important until our testers brought attention to them.
The game we shipped wasn’t the game we designed, but it was more concise and intentional.
That’s the trade-off at the center of every constrained build: not what we can add, but what is needed to work.
