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

Write "the guard walks between two points and stops if it hears you" and there is very little ambiguity. Write "there is a clearing with some rocks near the edge of the forest" and you have said almost nothing. How big is the clearing? How near is near? Which edge?

This asymmetry is not a limitation of any particular model. It is a property of language. Rules are naturally sentences. Layouts are naturally drawings, and any attempt to say a layout in words gets longer and less accurate the more precise you try to be.

A tool that takes a paragraph and returns a whole game has to guess at all the spatial parts. It will produce something, and the something will not be your game, and the only way to fix it is to write more paragraphs about where the rocks should go.

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

You describe behaviour to Flockbay. Inventory rules, combat, dialogue triggers, day and night, what a switch does, what happens when the timer runs out. Flockbay writes GDScript in your Godot project that implements it.

You then play it and correct it in the same way — in sentences, because the correction is also about rules. "It should not trigger if you are already carrying the lamp." That is the right shape for text and it works.

Nowhere in this do you type where a tree goes.

The world gets built in the builder, by you, looking at it. In a 3D project that is terrain, water, weather, buildings, props and characters, all placed in a viewport. In a 2D project it is ground painted a cell at a time — the tiles, the edges and the collision fall out of which cells you covered, so painting them in a different order draws the same world — and sprites dragged to the position, turn and size you want. It is level design either way, done the way level design has always been done, minus the part where you first have to learn an engine.

This is faster than describing it, and more importantly it is more accurate, because you can see the result while you are making the decision. A clearing is the right size when it looks right, and you cannot know that from a sentence.

More on this: Make a game with AI and no coding, without a closed toolbox

Flockbay is a desktop app for Windows. You download and install it. Godot ships inside, and the game runs locally on your machine.

Building needs an internet connection, because the chat and asset generation are network services. The game you built plays without one.

Free to download, and the builder is free. Flockbay is free on your own AI: your Claude or ChatGPT plan, your own agent, or an API key.

More on this: Make a 3D game with AI, and know exactly which part the AI did

It is worth saying directly: that is not what this is, and the pages that promise it are describing a demo. You will get further, faster, with the split — you build the space, you describe the rules — than with any amount of prompt engineering aimed at a tool that has to invent your entire game from one paragraph.

The upside is that what you end up with is actually yours: a Godot project, on your disk, with a world you laid out and code you can hand to anyone.

Describe outcomes rather than implementations. "The player should not be able to reach the roof" is clearer and more robust than a guess at how to prevent it, and it leaves room for a sensible solution.

Say what should happen in the failure case. Most ambiguity in a request is about the edge: what happens if the inventory is full, if the door is already open, if the player is mid-jump. Naming the edge up front saves a round trip.

Group related behaviour into one request. A whole interaction described at once tends to come back coherent. The same thing requested in six pieces tends to come back as six pieces that do not quite agree.

More on this: Make a game with AI without giving up the game