Finish Your Game: Beating Side-Project Syndrome

New ideas gleam because they're all promise and no problems; your current project looks worse only because you can see it clearly. Beat the cycle mechanically: park new ideas in a file (with a one-jam-weekend pressure valve), shrink the current game's finish line until it's reachable, and add external stakes — a date, an audience, a festival — that make finishing the path of least resistance. That's the short version — the sections below get into the how, the why, and the mistakes worth dodging.

The grass is greener because it's imaginary

Every project follows the same emotional arc: euphoric start, competence-building middle, and a long valley where the remaining work is known, unglamorous, and resistant. New ideas, by contrast, are experienced entirely in the euphoric phase — they haven't earned their valley yet. Switching projects doesn't escape the valley; it resets your position to the start of a new one.

Internalizing this pattern is half the cure: the urge to switch is strongest precisely when the current project is closest to the only phase that matters — done.

Park ideas; don't follow them

Keep an ideas file and grant every shiny new concept a generous entry: write the pitch, the hook, the core loop, everything exciting about it. The act of capturing discharges most of the urgency — ideas demand attention, not necessarily execution. Most entries, revisited a month later, have lost their glow; the few that haven't are genuinely good and will still be good after you ship.

If one won't quiet down, give it a jam weekend — strictly timeboxed. Either it's purged from your system, or it proves strong enough to deserve a slot in the queue. After the current game.

Engineer the finish: shrink the line, add stakes

Make finishing mechanically easier: redefine 'done' down to the smallest version you'd be proud of (cut the cuttable now, not at month nine), work a visible burn-down of remaining tasks so the end feels real, and put external stakes on the calendar — a festival submission, a public date, a playtest group expecting builds. Internal motivation finishes prototypes; external structure finishes games.

And remember what shipping buys: the entire skill set of the last 20% — polish, stabilization, store presence, release — only exists past the point where side-project syndrome usually wins. Each finished game makes the next one dramatically easier to finish. The habit is the asset.

Momentum is a resource — budget it

Progress you can see is fuel. Long stretches of invisible work — refactors, systems with no on-screen result — drain motivation even when they're necessary. Good project plans alternate: one stretch of plumbing, then something you can watch move on screen.

When motivation dips, shrink the loop. Pick the smallest change that makes the game visibly better today. Shipping anything, even a menu fix, restarts the engine.

Decide how you'll know it's working

Every project needs a definition of done that isn't a feeling. Pick the few signals you'll trust — playtesters finishing the demo, crash-free sessions, wishlists per week — and check them on a schedule. Otherwise you'll steer by whichever anxiety is loudest that day.

This is also the honest defence against endless polishing. When the signals say players get through it, enjoy it, and nothing breaks, the feature is done. Move on.

The quiet work that protects all of this

Everything in this post gets undone by an unstable build. A great store page, a clever marketing beat, a perfect jam entry — none of it survives 'crashed twice, refunded'. Stability isn't a feature players praise, but it's the floor everything else stands on.

Give yourself visibility before you need it: crash reports with stack traces, a simple way for players to flag issues from inside the game, and a habit of fixing the top recurring error before adding anything new.

Putting it to work

Don't try to act on all of this at once. Pick the one change that costs you the least and pays the most this week, do it, and see what actually happens before reaching for the next.

Most of this rewards steadiness over intensity. A small improvement made every week, checked against how real players respond, outruns any single burst of effort — in this corner of game development and every other one.

Scope to the hours you really have, then ship the small game that fits them.