Knowing when a game is finished

Most small games are not abandoned because they are hard to build. They are abandoned because they never reach a state that feels finished, and the list of things that could still be added never runs out. The discipline that matters is not knowing how to add more; it is knowing when to stop.

The browser sets a harsh deadline

A game in a page has a few seconds to justify itself. The player arrived with nothing invested, can leave with a single tap, and has no installation or purchase making them give it a second chance. That asymmetry is the design constraint: whatever the game is, it has to be apparent almost immediately.

This is why games here tend to have one mechanic. A second mechanic is not automatically depth; it is frequently the point at which a player stops being sure what they are supposed to be paying attention to.

A definition of finished

For this catalogue, a game is finished when four things are true, and the list is deliberately short.

• A first session can succeed. Not a first session that teaches — a first session in which an unfamiliar player does something and gets a result. If the opening minute is a tutorial, the game is not finished.
• Restarting is instant. Failure has to be cheap, because in a game played in one-minute sessions, a slow restart is the entire cost of losing.
• The score is legible. The player has to understand what they are being measured on without being told, which usually means a single number and a best score beside it.
• Nothing is left that the player would notice. There is a difference between the things a developer knows are missing and the things a player can feel. Only the second list is real.

The cut list does the work

Every game here had features removed rather than added in its final pass: a settings screen, a level select, a second enemy type, an animated title. None of them was hard, and none of them made the first minute better. Removing them made the file smaller, the start faster and the game easier to understand, which is the trade this kind of game should always take.

Polish that matters, and polish that does not

The polish worth spending time on is feedback: a flash when something is hit, a small burst of particles when it is destroyed, a screen shake on impact, a tone on every meaningful event. That is the layer that makes a simple mechanic feel like it has weight, and it is the layer players actually perceive as quality.

The polish not worth spending time on is furniture: menus, settings, credits, an options screen for a game with no options. A small game that opens straight into play is more finished than one with a title screen it does not need.

Ship it and look at the numbers you can trust

Once a game is out, the useful signal is not how long people played — with no analytics on this site, that number does not exist and should not be invented. It is whether the game is understandable, which is answered by watching one person open it for the first time and say nothing. If they hesitate, the game has a problem, and it is almost never the problem the developer expected.