AI that makes games, described accurately

There is a version of this idea where you type a sentence and receive a game. It has been demonstrated many times, and what comes out is always the same kind of thing: small, flat, and playable for about two minutes. That is not a stage on the way to something better. It is what happens when a sentence is asked to carry information a game needs.

A game is thousands of decisions. Where the door is. How long the corridor feels. Whether the enemy should arrive before or after the player finds the weapon. A prompt contains almost none of that, so a system generating from a prompt is making all of those decisions arbitrarily, and arbitrary decisions produce arbitrary games.

None of which means AI is not useful here. It means the useful application is not the one in the demonstration.

Writing code. This is the part that has changed most, and it has changed enough to remove the single largest barrier in game development. Director 1 writes GDScript directly into your Godot project: movement, combat, inventory, saves, enemy behaviour, interfaces, whatever your game needs. You describe it in plain language.

Producing assets. Models, textures, sounds and images to fill a world with. Not a replacement for an artist, but a fast source of material to build with and to judge.

Iterating. This is the underrated one. The value is less that code appears and more that changing it costs almost nothing, so you actually revise instead of living with the first version because rewriting it would take a week.

The world. You build it by hand in the builder — terrain, water, weather and buildings in a 3D project, painted ground and placed sprites in a flat one. That is where taste operates and it is faster to do than to describe.

The judgement. You play the game and say whether it is right. Not writing the code does not mean not having an opinion about the result, and the opinion is the scarce resource in the whole process.

The idea, the pacing, the reason anyone would care. Those have not become automatable and there is no sign that they are about to.

Creating a project asks which kind of game you are making, shown as two pictures. There is no default and nothing is created until you pick one. It is the same app either way: same builder, same Director 1, who is told the flat world's own tools rather than a shortened version of the round world's.

Pick 3D and you get the things that only mean anything with a third axis — terrain raised from elevation, water, weather, a time of day, a sky. Pick 2D and you get something already running before you have done anything: a sky colour, a band of scenery along the horizon, ground with a ledge cut into it, a platform off to one side, and a person who walks, falls and jumps under the keys you press. Seconds, not a tutorial.

A flat world then has four things to work with, and they are its own rather than borrowed. Ground is a tile layer built from a coverage map: you drag to lay cells and drag to erase them, and the tiles, the edges and the collision all fall out of which cells are ground. Beyond it is the sky colour and that one band of scenery. Then the person, whose walk, run, air control, gravity and jump apex are controls you turn rather than code you rewrite. Then objects placed by hand, mostly out of a Catalogue where 55,073 of the 60,648 entries are sprites.

Where that stops is worth saying plainly, because most tools would not. There is no flat answer to water and no flat answer to weather; those are questions the 3D side answers and asking a flat project for them is asking for something that is not there. Director 1 will generate a single flat picture on request and will not generate an animated one — no frames, no sprite sheet — so a walk cycle in drawn poses is still somebody's hand work.

You build something, ask for behaviour, press play, and the game runs locally on the copy of Godot bundled with the app. Ten seconds later you know whether it worked. You say what is wrong in ordinary words. It changes. You play again.

That loop is the entire product. Everything else is infrastructure to make the loop short.

Flockbay is a desktop app for Mac and Windows. It is downloaded and installed, not a browser tool, and your project is an ordinary Godot project. Building needs an internet connection because the model, asset generation and world data come over the network; playing what you built does not.

The download is free and the free plan is real: the whole builder in either kind of project, playtesting and publishing cost nothing, and there is a limited trial of the AI features. Indie at $10 a month unlocks the AI assistance — gameplay logic from Director 1, and texture, sound, prop and rig generation. There is no team, per-seat or enterprise pricing, because it is a desktop app.

The reason to say that plainly is that this is a field with a lot of overstatement in it. If you download this expecting a machine that produces finished games, you will be disappointed, and we would rather you knew that before installing anything than after an evening of trying.

If instead you have a game in mind and the programming is the thing standing between you and it, that barrier is gone. What is left is the design work, which is the part worth doing.

It is worth being explicit about how the work is divided, because a lot of tools in this space are vague about it. There are two paths in Flockbay. Director 1 does what it can, which is writing code and producing assets. Or you use the manual controls in the builder and do it yourself.

There is no path where you ask for something and the system quietly does a different thing that sort of resembles it. If a request cannot be met, you find out, and you get the manual route instead. That is less magical and considerably less annoying than discovering three hours later that you were misled.

The practical effect is that you always know which half of the game you are responsible for. The code is handled. The world, the pacing and the verdict are yours, and they are the interesting half anyway.