AI 2D game generator: the code is generated, the game is not

Generating code is a solved-enough problem. A character controller, a tilemap collision fix, a dialogue box that queues lines, a boss with three phases — these are specified problems with known-good implementations, and a model writes them reliably.

Generating a game is not. A 2D game is a stack of small feel decisions, and a prompt does not contain them. What comes back from a one-shot "make me a platformer" is a demo: it runs, the character jumps, and there is nothing in it you would play twice.

Flockbay draws the line where it actually falls. Director 1 generates the GDScript in your project. You lay out the scenes and decide whether the result is any good.

A 2D project here does not open empty. Creating one asks a single question with two pictures — 2D or 3D, no default, nothing made until you pick. Choose 2D and press play, and there is a sky colour, a band of scenery along the horizon, ground with a ledge in it and a platform floating above, and a person who walks, falls and jumps under the keys you press.

That changes what generation is being asked to do. A request against a running game is a much smaller request than a request against nothing. "Make the jump heavier" has a jump to be heavier than. "Add a dash that cancels into a wall slide" has a character and a wall to attach it to.

The failure mode of one-shot game generation is that the model has to invent the context as well as the code — what the world is, what the character is, what any of it is for — and inventing context is where the result stops being yours. Handing it a world that already exists and a person already standing in it removes most of the inventing.

The unglamorous parts. Input buffering so a jump pressed four frames early still fires. Coyote time so stepping off a ledge does not feel like a betrayal. Slope handling that does not launch you. Screen shake that decays properly.

Every one of those is a known technique with an annoying implementation, and every one of them is where a hobby project stalls. Asking for them is a sentence each. Writing them yourself is a week.

It is also good at the systems that are boring rather than hard. Save and load. A pause menu that actually pauses physics. A settings screen that persists. Nobody wants to write those and every game needs them.

Where it is least trustworthy is the category that is easy to generate and easy to get subtly wrong: a timer that drifts, a random number generator that is not seeded reproducibly, a score that rounds differently on two machines. These come back looking finished. Being explicit about what you want is what keeps them from becoming month-three mysteries.

Layout, art direction and judgement — and all three have real controls rather than a prompt box. Ground is painted: you drag to say which cells are ground and drag again to take it back, and the tiles, the edges and the collision all follow from that coverage rather than from you placing anything by hand. Paint the same cells in a different order and you get the same world.

Sprites go down at an exact position, turn and size with the mouse. Each sits on its own drawn bottom-centre rather than the middle of its file, so a crate stands on the floor instead of hovering by however much transparent margin the image carries, and a thing lower down the screen draws in front of a thing higher up.

The camera is three boxes you drag on the running game: what is in view, the dead zone the character moves around inside before the camera follows, and the limits the scroll will not cross. That is deliberately not something you ask for. A camera is judged rather than specified — you can see in one second that the dead zone is too generous, and you would struggle to say it in a paragraph.

How the person moves is a set of controls too: walk and run speed, how long it takes to reach that speed and how long to lose it, air control, gravity, jump apex, body size, step length. So "it feels floaty" is a retune of numbers that already exist rather than new code. You do not need to know which number. Being non-technical means you do not write the code, not that you cannot tell when a jump is wrong.

And side-on and top-down are not two templates you choose between. Declare gravity and down is a direction, so steering is horizontal and a jump is available; declare none and the same body steers on both axes with nothing to jump away from. Asking for behaviour in a top-down game is the same kind of ask as in a platformer, because underneath it is the same code.

The Catalogue holds 60,648 objects and 55,073 of them are sprites — 90.8% — searchable by name, each with a picture of itself before you take it. For a flat world that is the ordinary way to get art. After it comes bringing your own, whether you drew it or found it, which is just as legitimate.

Generation is the smallest of those routes and it is worth being exact about its size. Director 1 can make a single flat still image when you ask for one. It cannot make an animated character: there is no multi-frame sprite generation and no animation editor in the builder. If your game needs a six-frame attack, those frames come from the Catalogue or from you. That is a genuine hole and this page is not going to paper over it.

Whichever route a piece of art came from, you are told which. That matters if the game is ever going to be sold.

Working with stand-in art for the first few sessions is not a compromise. It is how you find out whether the game is fun before you spend anything on how it looks — and the scene you start from is already exactly that: some ground and a person, standing in for a game you have not decided yet.

Flockbay is a desktop app for Mac and Windows with Godot bundled inside it, so your 2D game runs locally when you press play. No browser, no streaming. What you end up holding is an ordinary Godot project in an ordinary folder.

Generation itself needs an internet connection, as do Director 1 and world data. Building is online; playing what you built is not.

Describing behaviour well is a skill and it is not a technical one. The useful version is to describe what the player experiences rather than what the code should do. "The dash should feel committal — once it starts I cannot steer out of it, and there is a moment at the end where I am vulnerable" is a better request than any attempt to name variables.

Being specific about the exception cases helps more than being specific about the main case. What happens if the player dashes into a wall. What happens if they dash off a ledge. Those are the parts that get invented if you do not say, and an invented decision is a decision you did not make.

When something comes back wrong, saying what is wrong is enough. You do not need to diagnose it. "The dash goes too far and I keep overshooting the platform" is a complete and actionable report.

This is the loop the whole tool is arranged around, and it treats you as the person who knows what the game should feel like, because you are.