How building a game with AI actually goes

You install Stage Engine, which is a desktop app for Mac and Windows, and you open a new project. What you are looking at is a builder: a 3D view with terrain tools, not a chat box with a prompt in it.

The first thing you do is make ground. Raise some hills, drop in water, set the time of day and the weather. This takes a few minutes and it is worth doing before anything else, because standing in a place makes the game concrete in a way a description never does.

Then you ask for a character you can control. Director 1 writes the GDScript, you press play, and you walk around your hills. This is the moment where most people discover their hills are far too big, which is useful information and is why you did this first.

You will spend most of it on the walk. Speed, jump height, camera distance, how quickly the character turns. These are small numbers with a large effect and they are wrong at first, always, in every project ever made.

The loop is: play, notice, say. "Too floaty at the top of the jump." "Camera is too close when I back into a wall." Director 1 changes the code and you play again. Nobody expects you to know that the fix is a different gravity multiplier on the descent. You only have to know that it feels wrong.

By the end of the evening you have a character that moves nicely through a landscape. That is not a game, and it is the foundation that decides whether the game is pleasant.

Now you add something to do. An objective, an enemy, an item, a door. Each of these is a request in ordinary language and a revision loop afterwards.

You will also build a lot more world, and you will throw some of it away. This is normal. The first area anyone builds is usually too large and too empty, because empty ground is quick to make and slow to walk across.

Somewhere in this week you will ask for something the first attempt gets wrong in an interesting way, and you will realise the game you are making is slightly different from the one you described on Monday. Follow that. It is the best thing that happens in this process.

By now there is a project with real structure in it. It is a Godot project on your own disk, with GDScript in it that you did not write and do not need to read. If you wanted to hand it to a programmer, you could, and they would recognise everything in it.

The game runs locally on the bundled Godot, so testing is instant and the framerate is your machine's. Building needs an internet connection because Director 1 and asset generation come over the network; playing does not.

Money: free to download, a free plan with usage included, Indie at $10 a month, Pro at $50. Paid plans buy more usage, not a better engine. Time is the larger cost and no plan reduces it.

It does not decide whether the game is good. It cannot, because that is a question about how somebody feels while playing, and the only instrument for measuring that is a person.

It also does not build the world. Placement, pacing and framing are hand work, done by you, because they are spatial problems and language is a poor interface for spatial problems.

What it does is remove the requirement that you learn to program before you are allowed to try. That is a large removal and it is not the same as removing the work.

The first is asking for too much at once. A request that contains an inventory, a crafting system, a hunger meter and a day cycle produces something where you cannot tell which part is wrong. Ask for one, play it, keep it or change it, then ask for the next.

The second is building world before you have anything to do in it. Empty terrain is quick and satisfying to make and it is the easiest way to spend three weeks with nothing playable. Get one loop working in a small area first, however ugly, and expand outward from something that is already fun.

Both patterns come from the same place: the parts that feel productive are not always the parts that make progress.