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.

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

You write to Flockbay. You describe a rule, a reaction, a system, a failure state, and it writes the GDScript that implements it inside your project. 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.

The other half of Flockbay is a builder. A project is 2D or 3D, picked before anything else exists, and the same builder serves both. In a 3D one: terrain, water, weather, structures, props, characters, which you place, move, scale and look at from where the player will stand. In a flat one: you drag to lay tile ground and drag to erase it, and you put sprites at an exact position, turn and size. It behaves like a level editor because that is the correct shape for this job.

This is the part people are surprised by, having searched for a generator. But 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 somewhere is to put the rock there.

Generation still helps inside the builder: on the 3D side, terrain, assets and world data all come from generation rather than a fixed catalogue. What changed is that generating is a starting point you then shape, not a slot machine you pull until the image matches your head.

More on this: Text to 3D game: the part text is good at, and the part it is not

Flockbay is a desktop application for Windows. 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.

More on this: Vibe coding a game, and the part vibe coding is bad at