Knowing when a game is finished
Games · 2026-07-02 · 6 min read · 1289 words
By ESPYCRUX, Studio
An endless arcade game has no end state, which means it has no natural moment where the work stops. We have hit that problem five times. Here is what "finished" turned out to mean, and why the answer applies to a lot more than games.
Most software tells you when it is done. There is a feature list, and the feature is either there or it is not. You can hold a specification next to the thing and compare them.
An endless arcade game will not do that for you. There is no final level, no win condition, no credits sequence. There is a loop that continues until the player fails, and the loop can always be tuned a little more. The difficulty curve can always be smoother. The scoring can always feel slightly better. Nothing anywhere in the game says stop.
We have now built five games and run into this five times. The problem never entirely goes away, but it does become manageable once you stop treating it as a question about the game and start treating it as a question you have to answer yourself, in advance.
Why endless things are hard to finish
Two properties combine badly.
The work is continuous rather than discrete. Adding a level is a task with an end. Making the difficulty curve feel right is a dial, and dials have no last position. You can always move it, you will always be able to justify moving it, and each individual adjustment is genuinely a small improvement.
Improvement is real but decelerating. This is what makes it a trap rather than an obvious mistake. You are not imagining that the game got better — it did. But the tenth tuning pass improves it far less than the second, while costing the same evening, and there is no signal inside the work that tells you which pass you are on.
Put together: a task with no end, that continues to feel productive, indefinitely. That is a good description of how a project quietly fails to ship.
Deciding "finished" before starting
The only thing that has reliably worked for us is defining what done means before the game exists — while you are still capable of being objective about it, because once you are inside a difficulty curve you are not.
It does not need to be elaborate. It needs to be written down and it needs to be falsifiable.
| Bad definition | Why it fails | Better version |
|---|---|---|
| "When it feels good" | Never false; always one pass from truer | "When five people finish a run without asking how it works" |
| "When it's fun" | Unmeasurable, and you are the worst judge | "When two testers replay unprompted" |
| "When the difficulty is right" | A dial, not a state | "When the median first run lasts between X and Y" |
| "When it's polished" | Infinite surface | A written list of the polish items, agreed before starting |
The right-hand column shares one property: someone other than you can tell whether it is true. That is the whole trick. A definition of done that only you can evaluate will move every time you evaluate it.
The last row deserves emphasis. Deciding in advance which polish items count, and treating that list as closed, is the difference between finishing and drifting. New polish ideas will occur to you. They go on a list for a future version; they do not join the current one. Otherwise the definition of done grows faster than the work does.
Shipping four adequate things beats perfecting one
This is the argument that actually resolved it for us, and it is not really about quality standards.
We are building short games in order to build toward something considerably more ambitious. We are not ready for that yet, and the honest route to being ready is to finish small complete things first. Five finished games taught us more than one unfinished ambitious one would have — and crucially, they taught it in public, against real players, rather than in a private branch where the feedback is only ever your own opinion.
An unfinished game teaches you almost nothing you did not already know. Its problems are the ones you already noticed. A shipped game tells you things you would never have predicted: that people misread a control, that the thing you were proudest of goes unnoticed, that a mechanic you nearly cut is what people talk about.
So the calculus is not "is this game as good as it could be?" It is "will another week on this teach me more than starting the next one?" — and after the first few passes, the answer is almost always no.
The first one is tuition, and that is fine
Our first game was Neon Dodge. Building it taught us how input should feel, how to structure a loop, how scoring should read, what breaks under pressure. Very little of that is game design; most of it is learning the medium.
That is worth accepting rather than resisting, for one specific reason: it removes the pressure for the first thing to be the best thing. A team that expects its first release to be its strongest will keep polishing it, because it is not yet as good as they imagined. A team that expects the first one to be tuition ships it and applies the lesson to the second.
Being clear, since this is easily misread: the first game is not the worst game. Neon Dodge asks for steadiness rather than reflex, and there are players who prefer it to everything else we have made. It cost the most to build per unit of game, because most of the cost was learning — but that is a statement about the build, not the result.
What "finished" is not
It is not "no longer worked on." A shipped game still gets fixes. Finishing is about the initial release having a defined edge, not about the game becoming immutable.
It is not "no known problems." There will be known problems. Some of them you will decide to live with. Writing them down and choosing not to fix them is a completely different act from not having noticed them, and only one of those is a shipping decision.
It is not "as good as it could be." Nothing is ever that. If your bar is the best possible version, you have set a bar that recedes exactly as fast as you approach it.
The version that never got there
We have one project on the network that has not been finished — a storefront that exists as an empty installation and nothing more. It sits on our main site, named, marked in development, with no link on it, because there is nothing worth sending anyone to.
It is there partly as an honest roadmap and partly as a reminder. It is the clearest evidence we have that starting is easy and finishing is not, and it stays visible for exactly that reason.
The same logic produces the entry for iCourier on the games hub: named, described, marked unfinished, with no play link. A visible roadmap with nothing clickable behind it is more useful than either hiding the work or linking to something broken.
The general form
None of this is really about games. Games just make the problem unusually visible, because they lack the artificial edges most software has.
Anything without a natural completion point has the same shape: a design system, a documentation site, a personal project, an internal tool that is never quite ready. All of them can absorb unbounded effort while continuing to improve slightly, and all of them need the same intervention.
Decide what done means before you start. Make it something another person could verify. Close the list. Then ship it and start the next thing, because the next thing is where the learning is.
ESPYCRUX Games is at game.espycrux.com — five finished games, and one that is not.
Tags: game design, shipping
ESPYCRUX — ESPYCRUX is a small product studio based in India, building focused web applications and writing about the engineering behind them. Articles are written by whoever did the work, and published under the studio name. Reach the studio at admin@espycrux.com.