How building a game with AI actually goes

You install Flockbay, which is a desktop app for Windows and Linux, and you describe the game you want. The app makes your account on first launch, so there is no sign-up in the way. What happens next is not a build. Flockbay asks questions, one round at a time, each with a recommendation and a line on why: 2D or 3D, what the player controls, what the first version is. Then it writes a brief: what gets built first, what comes after, and what is not in this version. Nothing is built until you approve it.

If you asked for something enormous, this is where you find out. A game the size of GTA 6 gets the truth, with real numbers, and a smaller first version you could actually finish. That is less exciting than a fake yes and far more useful.

Approve it and Flockbay builds. In 3D that is terrain sculpted and painted, water, sky and weather, a player controller and the first props, as real nodes in your scene tree. In 2D it is tile ground, a band of scenery behind it and sprites, with the tiles, the edges and the collision following from which cells are ground. It writes the GDScript for the controller, then runs the game, sends input events and reads the debugger to check its own work.

Then you press Play and walk around. This is the moment where most people discover the hills are far too big, which is useful information and is why the world comes first. Say so, or, if it is one hill, flatten it yourself: Sculpt, Paint and Place are buttons around the Godot editor's 3D view, and Godot's undo takes it back.

More on this: AI survival game generator: generated systems, authored land

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." Flockbay 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 get a lot more world built, 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 terrain 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, and tell Flockbay, so the brief moves with you. It is the best thing that happens in this process.

More on this: AI that makes games, described accurately

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 the chat and asset generation come over the network; playing does not.

Money: Flockbay is free, AI included, with free hosted AI every day or your own Claude, ChatGPT, agent or API key, and every world tool. Time is the larger cost.

More on this: AI survival game maker with real terrain and weather

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 does not get the last word on the world either. It builds the world, but placement, pacing and framing are spatial calls, and language is a poor interface for the last metre of a spatial problem. So you judge them by playing, and when a sentence is slower than your hand, you make the change yourself in the editor. A sentence gets you a valley; your hand can get you the exact valley.

What it does is remove the requirement that you learn to program, or to sculpt terrain, 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 asking for more world before you have anything to do in it. Empty terrain is quick and satisfying to get 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.

More on this: AI bullet hell maker: patterns are maths, and maths is code