Chat to game, and the part chat is bad at

Behaviour. "The guard should notice you if you run, but not if you walk, and forget about you after ten seconds unless he saw your face." That is one sentence and it is a precise specification. Writing the code for it takes considerably longer than saying it, which is exactly the condition under which conversation is the right interface.

Rules, conditions, state, timing, edge cases. All of these are things language handles well, because language is what people use to think about them in the first place. You do not picture a cooldown. You state it.

This is what Flockbay is for. You describe behaviour, it writes the GDScript into your project, you play the result, you say what is wrong. The revision loop is the interface, not a fallback when the first attempt misses.

More on this: Make a game from text: where writing works and where it stops

Space. "A clearing about forty metres across with a ruined tower on the north side, slightly uphill, and a stream that passes on the east but not close enough to reach the tower." That is a laborious sentence, it is still ambiguous, and whatever comes back will be wrong in some way you then have to describe again.

A chat with world tools behind it gets most of that right: a clearing, a tower, a stream, as real terrain and props. What comes back wrong is the last metre, and describing the last metre is where conversation breaks down. Moving it yourself takes ninety seconds and is exactly right by definition. There is no translation step, no ambiguity and no round trip. Anyone who has tried to specify a level in prose knows this, and any tool that insists on it is optimising the impressive half rather than the useful half.

The same applies to composition and pacing. Whether a ridge line reads well, whether the walk between two points is too long, whether the doorway is visible from where the player enters. These are looked at, not described.

More on this: An AI game generator from text, and what text is actually good at

In Flockbay the chat starts with a brief: questions one round at a time, a recommendation for each, and nothing built until you approve it. Then Flockbay builds the world with world tools and writes the code for everything that behaves. In 3D that is terrain, water, weather, lighting, buildings and characters; in 2D it is tile ground and sprites at an exact position, rotation and scale. Then it plays the game to check its own work.

Your hands come in where looking beats describing. The same world tools are buttons around the Godot editor's own 3D and 2D view, acting on the live scene, with Godot's undo. A ledge two tiles further out than it should be is the same kind of problem as a clearing forty metres across, and it is solved the same way, by looking and dragging. A sentence gets you a valley; your hand gets you the exact valley.

It also produces a better conversation. When the world already exists, you can say "make the door at the top of the tower need the key from the stream" and mean something specific, rather than trying to establish the geography and the mechanic in the same paragraph.

More on this: AI adventure game maker, with the AI in the right place

There are exactly two ways things happen. Flockbay builds it, or you do it yourself with the same tools by hand. There is no arrangement where you ask for something and the tool quietly does something adjacent and does not tell you.

That matters for trust more than it sounds. If a request cannot be met the way you asked, you should be told what actually happened rather than handed a result that looks plausible.

Flockbay is a desktop app for Windows and Linux with Godot bundled inside it. Your game runs locally, on your machine, at your framerate, and nothing is streamed.

Building needs an internet connection because the chat, asset generation and world data all come over the network. Playing what you built does not.

Flockbay is free, AI included: free hosted AI every day, or your Claude or ChatGPT plan, your own agent, or an API key.

More on this: Create a game with AI, and keep the part that makes it yours

Say what should happen and under what conditions, and be specific about the edges. Not make the enemy smarter, but: it should stop chasing if it loses sight of me for three seconds, and go to where it last saw me rather than where I am now.

Say what should not happen too, when it matters. The unstated assumptions are where first attempts go wrong, and stating one is cheaper than a round trip.

Then play it before deciding. A behaviour that reads correctly can feel wrong, and a behaviour that sounds crude can feel excellent. The written description is not the thing you are judging.

When something is wrong, describe the symptom rather than diagnosing the cause. What you noticed while playing is reliable information; a guess about which value needs changing usually is not, and it narrows the search in the wrong direction. It is the same skill as describing a fault to a mechanic. Say what it does and when, not what you think is broken, and you will get there faster.