When to stop prompting and start building

Asking for a change costs a sentence. Making the change costs the machine a few seconds. That ratio is the whole appeal, and it is also the trap, because a process this cheap has no natural stopping point built into it.

When a change was expensive, the expense did your thinking for you. Nobody spent two days implementing a variation they were not fairly sure about. The cost forced a decision before the work started, which meant the decision got made by somebody, deliberately, at a moment they could point at.

Take that cost away and the decision stops being forced. You can try the fourth variation of the dash without ever having settled what the dash is for, and you can do that indefinitely. The sensation is productive. Something new appears every few minutes. But nothing is being resolved.

What follows is not an argument against describing what you want. It is an argument for noticing the moment it stops paying, because that moment has a shape and it is easy to recognise once you know what to look for.

Describing is a search. You are exploring a space of possible games without committing to any point in it. Search is the right mode when you genuinely do not know what you want, which at the start of a project is most of the time.

Building is a commitment. You put a thing at a coordinate, you decide it is that colour, you say this room comes before that one. Commitments are what turn a pile of possibilities into something that can be judged, because you cannot judge an average of options and you can judge a specific arrangement.

Both modes are necessary and neither is more virtuous. A project that only searches never has a game in it. A project that only commits is one long defence of the first idea anyone had.

The skill is switching at the right time, and the switch is nearly always overdue in one direction. Search feels good and commitment feels risky, so people stay in search. Recognising the signals is mostly a way of making yourself uncomfortable on schedule.

Early on, requests sound like goals. Make the character able to climb. Give the shop a way to sell things back. Add a second enemy type that attacks from range.

Later, if things have gone sideways, they start to sound like corrections to a previous correction. Make it slightly less than the last one. Put it back the way it was but keep the new sound. Try it a bit faster, no, between the two.

That drift is the clearest early warning there is. You have stopped describing a game and started steering a value, and steering a value through sentences is a terrible interface for it. Sentences do not have a slider's resolution, and every round trip adds a translation error.

The move is to go and set the number yourself, wherever it lives, and to feel the change directly rather than describing an amount you cannot name. Two minutes of nudging beats twenty minutes of "a bit more than that".

A useful iteration converges. The second attempt is closer than the first, the third closer than the second, and you can feel the target being approached even if you have not hit it.

A stuck iteration does not converge. Each attempt is a fresh interpretation, wrong in a direction that has nothing to do with the last one. You ask for the room to feel more oppressive and get lower lighting, then get a lower ceiling, then get red walls, then get an ambient drone. Every one is a plausible reading and none of them is what you meant.

That pattern almost always means you are asking for something that lives in a hundred small decisions, not one. Atmosphere is not a setting. It is the sum of the light, the sound, the sightlines, the pace of movement, and what is around the corner. Nobody can deliver it as a single request, because there is nothing single about it.

Three non-converging attempts is a good stopping rule. At three, go and change one of those hundred things yourself, look at the result, and change the next.

Before you send a request, try saying it out loud as one sentence with no conditions in it. If you can, it is likely a good request. If it takes three sentences with an exception in the middle, that is worth noticing.

Long, hedged requests usually mean one of two things. Either you have not decided yet, in which case you are asking someone else to decide for you and you will not like what comes back. Or you have decided about something spatial, and spatial decisions do not survive being flattened into prose.

"The corridor should turn left after the pillars, but not so far that you lose sight of the tower, and the door should be visible from the turn but not before it" is a real design thought. It is also a description of a floor plan, and the fastest way to communicate a floor plan is to draw it.

The test is quick and it saves whole afternoons. Anything that needs a diagram to explain is something you should be arranging directly, not describing.

Check when you last ran the game. Actually ran it, moved around in it, saw it move.

If the answer is more than about an hour, and you have made a dozen requests in that time, you are not developing a game. You are accumulating changes to a thing whose current state nobody has observed. The reason that goes wrong is not that the changes are bad individually. It is that they interact, and interactions are invisible until you play.

There is also a subtler cost. Without a recent play session, your sense of the game is running on memory, and memory smooths things. You remember the version you intended. The build in front of you is the version that exists, and the gap between them widens every time you skip the check.

Play it. Even a two minute pass resets your reference point, and it frequently makes the next four requests unnecessary because the thing you were about to fix turned out not to be the problem.

Building does not have to mean typing code. Most of the decisions that define a game are not code decisions at all, and most of them are made by moving things.

Placement is the biggest. Where the enemies stand, how far apart the platforms are, which way the room opens, what you can see from the entrance, where the health pickup sits relative to the fight. Level design is almost entirely the arrangement of objects in space, and arrangement is a direct manipulation task. Nobody has ever hand-authored a good arena by describing coordinates.

Numbers are the second. Speeds, gravity, jump height, damage, cooldowns, how long a door stays open. These want to be felt, not specified, and the loop of adjust-and-play at ten second intervals is the only way anyone has ever found a good value for any of them.

Ordering is the third. Which room comes first, when the mechanic is introduced, how long before the difficulty rises. This is the structure of the experience and it is yours to decide, because you are the one who has played it in sequence.

None of this is a case for stopping. There is a large class of work where describing what you want is comfortably the fastest route, and it is the class that used to consume most of the week.

Anything that is a mechanism rather than a judgment. Making the door respond to a switch. Saving and loading. Counting the coins. Wiring an event so the music changes when a fight starts. Getting the camera to stop clipping through a wall. This work is structural, it has a right answer, and it is not improved by being agonised over.

Anything you would have had to learn before you could attempt it also qualifies. Half the reason projects die is that a small mechanical obstacle sits between the person and the next interesting decision, and the obstacle is boring enough that they stop coming back.

Read the split this way: describe the mechanisms, decide the experience. The first is work you want done. The second is the thing you are actually making, and it does not delegate.

A shape that holds up: describe once, play once, adjust by hand, then decide whether the next thing is another description or another adjustment.

Describing once means asking for a whole capability rather than a fine change. Playing once means running the game before evaluating anything, no exceptions. Adjusting by hand means the numbers, the placement, and the ordering are yours and you change them where they live.

Then the decision at the end of the cycle: is the next problem missing machinery, or a wrong choice about something that already exists. Missing machinery is a description. A wrong choice is an adjustment. Getting that one question right most of the time is more or less the whole discipline.

The failure mode is not laziness. It is that describing feels like progress at exactly the moments when it has stopped being progress, and the only reliable defence is a habit of checking. Look at when you last played, and look at whether your last three requests were converging. Those two checks catch nearly everything.