The smallest plan that is actually useful

There are two ways to plan a game badly, and almost everybody picks one of them. The first is to write nothing at all, open a project, and start building whatever seems interesting that day. The second is to write forty pages describing every system, every enemy, every menu, and every unlock, then discover four weeks later that the document has already drifted out of date and nobody has opened it since page six.

Both failures share a cause. Neither version answers the question that actually blocks work. When you sit down to build, you do not need to know what the fifth boss drops. You need to know what the player is doing with their hands in the next ten seconds, and whether the thing you are about to make serves that.

A plan is not a specification. It is a filter. Its job is to make it obvious, quickly, which of the twenty things you could build next are the two that matter. A plan that cannot do that is decoration, however long it is.

The version worth writing is short enough to hold in your head and specific enough to argue with. Four answers is usually enough. You can write them in an afternoon, and you should expect to rewrite at least one of them within a fortnight.

Start with a single sentence describing the player's activity. Not the setting, not the story, not the genre. The verb.

The test is whether someone could act on it. "A cosy game about a village" is not a sentence about what the player does. "You walk a delivery route through a village and decide who gets the last parcel" is. The first describes a mood. The second describes hands on controls, a decision, and a consequence.

Good examples are easy to state this way. In Papers, Please you compare documents against a shifting rulebook and stamp approve or deny. In Untitled Goose Game you steal things from people who are trying to work. In Slay the Spire you build a deck while choosing which route through a map you can survive. None of those sentences mention art style, engine, or scope, and all of them tell you what to build first.

If your sentence contains the word "and" more than once, you probably have two games. Pick the one you would still want to make if the other were taken away. You can bring the second one back later, once the first is playable, and you will make a better decision about it then than you can now.

The second answer is the loop: the short cycle the player repeats, and what changes each time round. Write it as three or four steps that lead back to the first one.

Take a survival crafting game. Go out, gather, get into trouble, come home, spend what you gathered, go out further. Take a roguelike. Enter a room, fight, choose an upgrade, enter a harder room. Take a management game. Look at the board, notice the thing that is about to break, spend a limited resource, watch the board react.

Writing the loop forces two useful questions. What makes the player want to go round again, and what makes the next round different from the last? If the answer to the second is "nothing", you have an activity rather than a game, and you will feel it about ninety seconds into the first real playtest.

The loop is also where scope hides. Every step you write is a system you will have to build, tune, and explain. A four-step loop where each step is simple will beat a two-step loop where each step is a hidden iceberg. Count the steps honestly before you commit.

The third answer is the opening, described beat by beat as though you were narrating over someone's shoulder. Where does the player start, what is the first thing they touch, what teaches them the main verb, and what is the first moment they choose something?

This is the part most plans skip, and it is the part that most often decides whether anyone keeps playing. Half Life's opening tram ride is famous because it is the plan for the first five minutes written with unusual care: no controls to learn yet, everything worth seeing framed by a window, and the game's tone set before a single enemy appears. Portal spends its first minutes making sure you understand what a portal does with no way to fail.

Writing the opening as a script exposes assumptions you did not know you had. You will find yourself writing "then they realise they can climb" and have to ask how, exactly, they realise. That question is a design problem, and finding it on a page in the first week is much cheaper than finding it in a playtest in the third month.

Keep it to five minutes. Not the first hour, not the tutorial in full. Five minutes is roughly how long a stranger gives an unfamiliar game before deciding whether to continue, and it is short enough that you will actually finish writing it.

The fourth answer is the one people resist. Name the single element you would keep if you had to throw away everything else. Not your favourite feature. The thing without which the project is no longer the project.

Say it out loud and the rest of the plan reorganises itself. If the answer is the movement, then art can be rough for a long time and levels can be grey boxes, but the movement gets your best weeks. If the answer is the writing, then the combat can be simple and borrowed, and you should not spend a month on a damage formula. If the answer is a single mechanical twist, then everything else in the game exists to give that twist somewhere to happen.

Ico is often described through what its makers removed rather than what they added: the interface, the health bar, the clutter, until only the hand-holding remained. That is the same decision made repeatedly. Something was identified as the thing that could not be cut, and then everything competing with it for attention went.

You will be tempted to name two. Do not. The value of the answer comes entirely from it being singular, because its only real use is settling arguments later, when you are tired and two features both seem important and you need a rule that is not your mood on the day.

A short list of exclusions does more work than a long list of features. Three or four lines is enough: no multiplayer, no procedural world, no branching story, no crafting.

Every one of those lines saves you an argument with yourself in month two. The ideas will come back, because they always do, and they will arrive dressed as small additions. A crafting system is never proposed as a crafting system. It is proposed as "we could let them combine two items", which sounds like an afternoon and is not.

Exclusions also help other people help you. When someone plays an early version and suggests a feature, the list lets you respond with a reason rather than a shrug. Sometimes the right answer is to move something off the list, and that is fine, but it should be a decision rather than a drift.

Be specific about the ones that tempt you personally. Everybody has a system they reach for when the project gets uncomfortable. Naming it in advance makes it harder to sneak back in as procrastination wearing a design hat.

The traditional design document promised a single source of truth. In practice, the long ones fail for reasons that have nothing to do with discipline.

They go stale immediately. The moment something is playable, the game starts telling you things the document could not know, and every one of those things invalidates a paragraph somewhere. Nobody has time to keep forty pages synchronised with a project that changes weekly, so the document quietly becomes a record of what you believed at the start.

They also flatten importance. On a page, the sentence describing your core mechanic and the sentence describing the options menu look the same size. Read six weeks later, there is no way to tell which parts were load-bearing and which were filler written to make the section look complete.

And they invite a specific kind of self-deception. Writing about a game feels like progress, because the page fills up and the ideas sound coherent in prose. Prose is very forgiving. It never tells you that the jump feels floaty or that the second hour is boring. Only the built thing does that.

None of which means writing is useless. It means the writing should be short enough to stay true, and pointed at decisions rather than completeness.

Put the four answers on a single page and keep it where you look at it, not in a folder you open twice a year. One page has a useful property: adding something means removing something, so the page keeps applying pressure long after you wrote it.

Expect to change it. The point of building early is that the game argues back, and a plan that never changes is either extraordinarily lucky or being ignored. When you do change it, change the page rather than keeping the correction in your head, and keep the old sentence visible for a while. Seeing what you used to believe is how you learn which of your instincts to trust.

A useful habit is to reread the page before starting anything that will take more than a day. Ask which of the four answers this work serves. If it serves none of them, you are not necessarily wrong, but you should know that you are choosing to go off-plan rather than sliding there.

The plan should also be readable by someone else in about two minutes. That constraint keeps it honest. Vague sentences survive in your own head because you silently fill in the missing parts. In front of another person, they collapse.

One more thing belongs on the page, and it is not a design question. Write down what the smallest complete version looks like: not a demo, not a slice, but something with a beginning and an end that a stranger could play without you sitting next to them.

Complete is doing a lot of work in that sentence. A game with one level, three enemies, and an ending is a game. A game with nine systems, forty items, and no ending is a project. The first teaches you things the second never will, because only a finished thing exposes pacing, difficulty curve, and whether the loop still holds after the novelty wears off.

Scoping the finishable version is also the honest test of the plan. If you cannot describe it in a paragraph, the plan is still too vague. If describing it takes six months of work, the plan is too big, and the fix is usually to cut content rather than systems, because content is where the hours actually go.

The four answers plus the exclusions plus the finishable version fit comfortably on one page. That page is the whole of what planning owes you before you start. Everything after it is learned by building, playing, and being honest about what you found.