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. Flockbay takes the guess out from two sides: questions before it builds, and the editor after.

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

You describe the game to Flockbay. It asks questions one round at a time, each with a recommendation: how big the clearing is, whether the forest is dense or open, whether the guard patrols at night. Then it writes a brief: what gets built first, what comes after, what is not in this version. Nothing is built until you approve it.

Then it builds. The world goes in with world tools, as real nodes in the scene tree: terrain, water, sky, weather, plants, props and characters. The behaviour goes in as GDScript in your Godot project: inventory rules, combat, dialogue triggers, day and night, what a switch does, what happens when the timer runs out. Then Flockbay runs the game, sends input events and reads the debugger, to check its own work before you see it.

You then play it and correct it in sentences. "It should not trigger if you are already carrying the lamp." "The clearing should be twice as wide." That is the right shape for text and it works.

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

Some calls are pure taste: exactly where the rock sits at the edge of the clearing, which way the path bends. Describing that in a paragraph is slower than dragging it, and less accurate, because by hand you 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.

So the same world tools are buttons around the Godot editor's own 3D and 2D view. In a 3D game that is Sculpt, Paint, Plants, Place, Water, Sky, Weather, Player controller, NPCs and Camera. In a 2D game it is Paint, Place and Player controller: the tiles, the edges and the collision follow from which cells are ground, so painting the same cells in any order draws the same world. Make the one change, and Godot's undo takes it back if you change your mind.

None of it is required. A sentence gets you a valley; your hand can get you the exact valley.

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

Flockbay is a desktop app for Windows and Linux. 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 every world tool is free. 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: 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 a brief you approved and a game you play and correct than with any amount of prompt engineering aimed at a tool that has to invent your entire game from one paragraph. Ask for something enormous and Flockbay says so, and offers a smaller first version it can actually build.

The upside is that what you end up with is actually yours: a Godot project, on your disk, with a world you judged 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.