An AI game generator from text, and what text is actually good at

Type "a haunted lighthouse on a rocky island" into anything and you will get a haunted lighthouse on a rocky island. It will not be your haunted lighthouse. The cliff will be in the wrong place, the approach will be too short, the light will sweep at a speed that means nothing. You will then spend longer describing the corrections than it would have taken to drag the cliff.

Now type "when the light passes over the player, whatever is following them stops moving". That sentence is complete. There is nothing ambiguous in it, nothing a picture would settle, and writing the code for it by hand would take an afternoon if you have never written GDScript before.

Those two sentences are doing different jobs, and a tool that treats them the same is going to be frustrating in one direction or the other. Flockbay treats them differently on purpose.

You write to Flockbay. It starts by turning your description into a brief, asking about what the sentence left out one round at a time, each question with a recommendation, and it builds nothing until you approve it. Then you describe a rule, a reaction, a system, a failure state, and it writes the GDScript that implements it inside your project and runs the game to check it. The code is real code in a real Godot project, sitting in files you could open if you ever wanted to.

You are not expected to read it. You are expected to press play and decide whether the thing you described is what happened. When it is not, you say so, in the same plain language, and it goes again.

That is the loop. It is not a fallback for when the generation fails. It is how the tool is meant to be used, because you are the only one who knows whether the lighthouse feels haunted.

More on this: Idea to game, without the part in between

Flockbay builds the place too, with world tools that make real Godot data rather than a picture of a world. A project is 2D or 3D, settled before anything else exists. In a 3D one: terrain, water, weather, structures, props, characters. In a flat one: tile ground, and sprites at an exact position, rotation and scale. Your haunted lighthouse gets its rocky island, its cliff and its approach from what the brief says, and Flockbay looks at it from where the player will stand before you do.

This is where text runs out. Every hour anyone has spent trying to prompt a specific landscape into existence has taught the same lesson, which is that the fastest way to put a rock in an exact spot is to put the rock there. So the same world tools are buttons around the Godot editor's own view. Drag the cliff, lengthen the approach, and Godot's undo takes it back if you were wrong.

Generation still helps: pictures, sound and world data can be generated, and props come from a library of ready-made objects. What changed is that a build is a starting point you then shape, not a slot machine you pull until the image matches your head.

More on this: Chat to game, and the part chat is bad at

Flockbay is a desktop application for Windows, macOS and Linux. It ships with Godot inside it, and when you press play the game runs locally, on your hardware, at your framerate. Nothing streams and nothing renders in a tab.

That is the reason the world can be a real world. A generator running in a browser has to keep scenes small to keep the tab alive; a local Godot process does not have that constraint, which is why terrain and weather are a normal thing on the 3D side here rather than an advanced feature.

Building does need an internet connection. The chat, asset generation and world data all come over the network. Playing what you have built does not need one.

Not a finished game. You will get a place that exists, something that moves in it, and a rule you wrote in a sentence that is now genuinely running. That is a much better first hour than most engines offer, and it is not the same as a game.

The gap between that and something worth handing to a friend is filled by you playing it and disliking parts of it. There is no version of this where taste gets automated, and pretending otherwise is how tools end up producing a hundred thousand identical prototypes.

There is a knack to it and it is not prompt engineering. It is saying what should be true rather than how to achieve it. "The gate opens when all three braziers are lit" is a good description. "Add a boolean for each brazier and check them in the gate script" is you doing the job badly on purpose.

Being specific about the failure case helps more than anything else. What happens if the player lights two and leaves? What if they come back an hour later? Most of the back-and-forth in practice is about edge cases that were not in the first sentence, and naming them up front removes a round trip.

And when the result is wrong, describe the wrongness rather than the fix. "It opens as soon as I light the first one" gets you further than guessing at what the code should have said.