Why Does Your Game Keep Getting Bigger Until You Cannot Finish It?

The Swarm began, in the team's own telling, with about three months of pre-production. That work produced something interesting enough to go full throttle, with an initial plan of one year of development. The team describes itself as a little indie team finding its place, learning by trial and error. Trouble did not arrive as a single bad decision. It arrived shortly after the initial prototype was approved, on the design side, as an iterative process around some of the main mechanics. Each change felt normal. Games evolve during development, and most of these changes were made because the team was convinced of them. The overall picture seemed to need each change for the game to be what they wanted.

For three to four months, that process kept going. Small changes, none obviously dangerous alone, accumulated until the team was far away from the initial concept. Because the changes arrived one at a time, the problem was hard to spot early. And because the result was genuinely better, richer, more coherent, deep and innovative, with a strong working core, there was no moment when the game felt broken. The failure was not that the game changed. The postmortem is explicit on this: it changed for the better. The failure was that scope changed with it, without anyone realizing, until it had grown out of bounds. The better game, the team concluded, was a game for about twice the team and twice the development time. Neither was available.

The scope problem was already causing headaches when the second blow landed. Building an indie studio from nothing is hard, the postmortem notes, but two difficulties mattered here. Without a dedicated hiring person, finding new talent and running interviews took time and slowed development. Young teams often lack financial support, running on personal savings or part-time jobs, so engagement can depend on passion alone, which is not always enough. Members left for economic or personal troubles, the development was set back, and an already complicated project began to look impossible. In a crisis meeting, the remaining team decided to build a new team and start over, with a new project.

After work on that restart, the team writes that it regretted nothing about canceling The Swarm. It was back on track with a new team and a new project, later than planned, but carrying lessons it calls priceless. The postmortem's sharpest line is worth keeping in spirit: it is better to cancel a project when you realize it will not work than to keep pouring hours into a zombie project you already know will not work as well as you want. That is not quitting at the first difficulty. The Swarm team quit after months of drift, a roughly doubled team and time requirement, and a fragmented team. Cancellation stopped the drift from consuming a new team as well.

Nothing below is presented as what the Evolve Games team did; the postmortem's own tips are only the starting point. The steps are rewritten for your own project, and they stay inside it: no step asks you to touch a live game, someone else's team, or a project you do not control. Scope creep here was not greed or laziness. It was good decisions with no running total. The fix is not to stop improving your game. It is to make every improvement pay a visible price before you keep it.