Every game starts as a neat little idea, and then it quietly tries to eat you. After shipping a shelf of small games, we have made peace with the one creature that haunts every single project.
Meet the goblin
The scope goblin is the friendly little voice that turns up about three weeks into any project. It only ever suggests lovely things. “What if the fighter also had a career mode?” “What if the shooter had a crafting system?” “What if the puzzle game had, you know, lore?” None of these ideas are bad. That is exactly the problem. The goblin never pitches rubbish. It pitches your favourite thing, right at the moment you are too invested to say no.
We have met this goblin on PUNCH CHAMPS, on Star Shredders, on PaddleUP!, on Type Fighters, on Cubee, and it is circling Overflow as we type. Finn, our studio shark, has learned to sniff it out. No sharks are harmed in the process. The goblin is another matter.
The two week test
Our main defence is embarrassingly simple. Before any feature goes on the board, we ask one question. Can a player feel the fun of this game in the first two minutes, and can we build a rough version of it in two weeks? If both answers are yes, it is a real game. If the fun needs a tutorial, three unlock tiers, and a lore codex before it lands, we have not found the fun yet. We have found homework.
Small games force this honesty on you. When you only have a few weeks of runway per prototype, you cannot hide a weak core loop behind a pile of content. The loop has to carry the whole thing by itself. That sounds like a limitation. In practice it is the best design filter we own.
Cut early, cut loud
The hardest lesson was learning to cut features out loud, early, and without ceremony. A feature you delete in week one costs you an afternoon. The same feature deleted in week ten costs you a month, plus the three other systems that quietly grew around it while you were not looking.
Here is roughly how we sort the goblin’s gifts these days.
| Keep | Cut, or park for later |
|---|---|
| The thing in the title | The thing you would explain in a footnote |
| One idea done cleanly | Three ideas done politely |
| Fun in the first minute | Fun after the third unlock |
| Anything a new player teaches themselves | Anything that needs a manual |
We keep a “someday” list for the parked ideas so nobody feels their darling was quietly murdered. Some of them grow up into whole new games. That is how a studio ends up with a shelf of small titles instead of one unfinished giant.
Ship the slightly embarrassing version
There is a specific kind of courage in releasing something before it feels ready, because it is never going to feel ready. Every game we have put out went live while some corner of it still made us wince. And every single time, the thing players actually cared about was the core we had been polishing, not the feature we were nervous about leaving out.
Finished and in players’ hands teaches you more in a weekend than another month of private tweaking ever could. You will not get that feedback loop from a game that lives forever in a branch called almost-done.
Small is a strategy, not a consolation prize
It is easy to treat small games as the thing you make until you can afford to build a big one. We have come around to the opposite view. Shipping small, and shipping often, is how a tiny team stays sharp, keeps learning, and keeps the lights on while the bigger ideas (hello, Overflow) get the time they genuinely deserve.
So if the scope goblin is whispering to you right now, do not try to fight it forever. Just make it wait. Write the idea on the someday list, ship the small honest version, and see what players tell you. The goblin will still be there for the next one. It always is.
Now if you will excuse us, Finn has spotted something suspicious near the Overflow backlog. Catch you in the next devlog.
