Voice to game: what talking can and cannot build

Flockbay does not ship voice input. There is no microphone button and no spoken conversation with the app. If you came here expecting to talk to a game engine and watch a game appear, that is not what this is.

What does work is your operating system's own dictation. macOS and Windows both let you speak into any text field, and describing a behaviour to Flockbay happens in a text field. If typing is slow or painful for you, that route is available and it is the same route you would use for email.

Everything below is about which parts of making a game speech is actually suited to, because that turns out to be the more interesting question than whether a microphone icon exists.

Rules and reactions are naturally spoken things. "When the player runs out of torches the wolves stop keeping their distance." That is one breath, it is unambiguous, and writing the code for it would take an afternoon.

Flockbay takes exactly that kind of description and writes the GDScript inside your project. You do not read the code. You play the game and say whether the wolves behave the way you meant, and if they do not you say what was wrong.

Speaking also tends to make people more specific, oddly. Typed instructions get compressed into "make the AI better". Spoken ones drift toward the story of what happened: "I stood behind the wall and they just queued up in the doorway". That second version is much easier to act on.

Try dictating the position of a watchtower. You will end up saying something like "on the ridge, north of the lake, angled a bit so you can see it from the path" — thirty words for a decision your hand makes in two seconds by dragging it, and it still will not land where you meant. Flatness does not rescue it either: "the platform two cells left and one up, and make the gap only just jumpable" is a sentence nobody wants to say twice.

This is why the world in Flockbay is built by hand, whichever kind of world you picked — and you do pick, because a new project asks 2D or 3D before it makes anything, with no default. In a 3D project, terrain, water, weather, buildings and characters go where you put them. In a 2D one you drag to say which cells are ground, and a sprite sits at the exact position, turn and size you gave it. Both happen in a builder that behaves like a level editor. Not because voice was too hard to implement, but because for spatial work every kind of description is a worse instrument than a pointer.

The same applies to taste. How dense a forest should be, how long a corridor should feel, whether a room reads as abandoned. Those are judgements made by looking at the thing, and no phrasing shortcut exists.

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

You build a place. You ask for a behaviour. You press play and the game runs locally on your machine, because Godot ships inside the app. You notice something is wrong, you go back, you say what.

That last step is where you matter most. Not writing the code has nothing to do with not knowing what is good — years of playing games leaves you with a well calibrated sense of when something is off, even when you cannot name the cause. Naming the cause is the part being handed over.

Handing a build back is the normal way this works, not a failure. Nobody expects you to accept the first version of anything.

Flockbay is a desktop app for Windows. You download and install it, and what you make is a real Godot project on your own disk rather than a file only one tool can open.

Building needs an internet connection because the chat, asset generation and world data all come over the network. Playing the game you already built does not. If you rely on dictation, note that your system's dictation may have its own network requirement depending on how it is configured.

The download is free and so is the platform. Flockbay is free on your own AI: your Claude or ChatGPT plan, your own agent, or an API key. Flockbay builds from a library of ready-made objects, or with Godot's own shapes.