How small should your first game be?

Small enough to finish: one action, one screen, one way to win or lose, played in a few minutes. Here is how to cut a bigger idea down to that size.

Small enough that you can finish it: one thing the player does, one screen, one way to win or lose, and a whole game that takes a few minutes to play. If you can build that in a weekend, or in two weeks of evenings, it is the right size. An AI coding assistant gets you to a playable version sooner, but it does not change the answer, and this article explains why. To cut a bigger idea down, write the game as one sentence, keep only what that sentence needs, and move everything else to a list called "later".

What does a small game look like?

Use four limits.

• One action. The player moves, or jumps, or matches, or aims. One of them.
• One screen, or one level that repeats and gets harder.
• One way to win or lose. A score to beat, a timer, or lives that run out.
• A few minutes from pressing start to seeing the result.

Two public yardsticks show that a game inside these limits is a real game.

The first is a game jam. In the Compo category of Ludum Dare, one person makes a game from scratch in 48 hours; the Jam category gives 72 hours and allows teams. Its rules describe the ideal entry as a game played in the browser, in a few minutes, alone. That is how the rules page read on 9 October 2026.

The second is a tutorial. MDN's 2D breakout game had eleven lessons on the same day: a canvas, a moving ball, walls, a paddle, game over, a field of bricks, a score and a win, extra lives, and then animations, buttons and some randomness. That list is a good picture of what "complete" means at this size.

Why does small still matter when an AI writes the code?

Because writing the code was never the whole job. An assistant shortens the writing. Three things stay with you.

You still have to play every change. Somebody has to start the game after each change, try it, and decide whether it is better than before. That somebody is you.

Features multiply. A new feature has to work with every feature that is already there. Three features make three pairs that can clash. Six make fifteen. Twelve make sixty-six. The checking grows much faster than the list of features.

A request touches more than it names. "Add a shop" sounds like one task. It changes the score, the pause screen, the controls and what gets saved, and each of those has to be checked afterwards, whoever wrote the code.

A small game is one you can keep in your head. You can describe a change exactly, read what came back, and notice what it broke.

What does each extra feature cost later?

It costs again every time you add a platform or a language. We saw this with KittenGalaxy, the shooter hosted on HeapPlay.

When we added touch controls, the work was counted per screen, not per game: the menu, the name entry, the flying, the shop, the maths challenge and the game-over and ending screens each needed their own controls. When the game was put into ten languages, every screen was checked in each of them, as the game's page records.

Neither job was a mistake. But both were sized by the number of screens the game already had. A game with one screen pays that price once.

How do you cut an idea down to that size?

1. Write the game as one sentence: what the player does, and how it ends. For example: "You steer a ship left and right and shoot invaders until your lives run out."
2. List everything else you imagined. Bosses, a shop, two players, a story. Write it all down, so that nothing is lost.
3. Keep only what the sentence needs. If the sentence stays true without a feature, the feature goes on the "later" list. It is postponed, not deleted.
4. Cut content before you cut the idea. One kind of enemy, not five. One wave that speeds up, not twenty levels.
5. Fix the time before you start. A weekend, or two weeks of evenings. When you fall behind, cut something from the game and keep the date.

Here is that example after the cut.

How do you hold that size while working with an assistant?

• Put the one sentence and the "later" list in a file in the project, and point the assistant to it at the start of every session.
• Ask for one item at a time, and play the game before you ask for the next.
• Save a working version before each request, as a commit in version control, so that a bad change can be undone.
• When a change brings more than you asked for, take the extra out. Features nobody asked for are scope too.

How do you know it is finished?

Decide before you start, and write it down. A first game is finished when:

• a stranger can start it from a link without a word from you;
• the controls are shown on the screen;
• it can be lost, and started again without reloading the page;
• you have played it from start to end on every device you say it supports, and you say which devices you have not tried.

Then put it where people can play it. A game this small is still a game: HeapPlay's submission rules ask for a real, playable game with an official link, and set no minimum size. You can submit it without an account, and an editor looks at every submission before it appears.

What happens to the "later" list?

It becomes your plan, in an order you no longer have to guess. Once people play the small version, what they say tells you which item to take first. Add that one, release it as a new version, and listen again.

Common questions

How long should a first game take? There is no measured answer. Pick a limit you can keep, then fit the game to it. Ludum Dare gives its entrants 48 or 72 hours.

Is a clone of a classic good enough? As practice, yes: you already know what "finished" looks like. Before you show it to others, change one thing so that it is yours.

Should my first game be my dream game? Make its smallest playable piece first, and keep the rest on the "later" list.

Can I start bigger because an AI assistant writes the code? You will reach a playable version sooner. The playing, the checking and the deciding are still yours, and they grow with every feature.

Is a three-minute game worth publishing? Yes, if it is complete. Players can rate and review it, and verified developers can record each new version and what changed.