AI 2D game maker: what a working session actually looks like

Making a project asks one question before anything else: 2D or 3D, shown as two pictures. There is no default and nothing is created until you pick one. Pick 2D and what opens is not an empty grid. There is a sky, a band of scenery along the horizon, ground with a ledge cut into it, a platform floating off to one side, and a person who walks, falls and jumps under the keys you are already pressing.

So the session does not open with setup. It opens with an opinion: the jump is floaty, the ledge is too far out, that platform wants to be lower. Having something to be wrong about is the useful state to be in, and most tools make you spend an afternoon earning it.

Widening the ground is dragging across it. Ground is a tile layer built from a coverage map — you drag to lay cells, drag to erase them, and the tiles, the edges and the collision all fall out of which cells are ground. You never pick a corner piece out of a palette. Paint the same cells in a different order and you get the same world, and a rebuild never reshuffles the edges you already accepted.

Then you ask for the behaviour. A character who runs, jumps and wall-slides. Director 1 writes the GDScript and you press play. The run is fine. The jump is heavy. The wall slide catches on the corner. You say those three things, they change, and somewhere around the fourth pass the movement feels like the thing you had in your head — which is the point at which the room starts to matter, because now you can tell whether it is laid out well.

That is the whole loop. Build, ask, play, judge, repeat. Nothing in it requires reading a line of code, and all of it requires having an opinion.

It would be easy to build the opposite tool: one where you describe the level in a chat box and the AI generates the layout. It has been tried and the results are legible. Generated levels feel like nobody chose anything, because nobody did.

Layout is cheap to do by hand and expensive to describe. Code is expensive to do by hand and cheap to describe. Putting each on the right side of that line is the design.

The same logic explains why there is no template menu. A template is a level somebody else laid out around a feel somebody else tuned, which means you inherit two sets of decisions and can adjust neither comfortably.

They fall out of one declaration. Say the world has gravity and down becomes a direction: steering is horizontal, and a jump is a thing you can have. Say it has none and the same body steers on both axes and there is nothing to jump away from. Same code underneath, and no menu anywhere that makes you tell it which genre you are in.

Whether ground stops a walker is declared per material, for the same reason. A platformer's solid block and a top-down dirt path can be painted with identical strokes, and only one of them stops anybody. Drawing and physics are separate decisions, which is why a top-down room here is not a side-on room with the gravity switched off and the best hoped for.

Feel is controls rather than a rewrite. Walk and run speed, how long the body takes to reach a speed and how long it takes to lose it, air control, gravity, jump apex, body size, step length. "Make it heavier" is a handful of numbers moving, not new code. The walk cycle advances by distance travelled rather than by a timer, so the legs stay with the speed instead of skating out from under it.

A save system that survives being closed mid-level. A settings menu with remappable keys. Enemies with a state machine that does not deadlock. An achievement that fires exactly once. None of these are interesting to build and all of them are the difference between a prototype and a game. Asking for them is a sentence, and that is the practical reason the AI half earns its place.

The camera is the exception, and it is worth knowing why. You do not ask for it, you drag three boxes on the running game: what is in view, the dead zone the player can move around inside before anything scrolls, and the limits the view will not pass. The limits follow the ground you paint until the first time you drag them yourself, after which they are yours. Framing is taste, and taste is faster with a cursor than with a paragraph.

Add to that the things that only show up on someone else's machine: a resolution you did not test, a controller that maps its buttons differently, a frame rate that is double yours and quietly breaks anything tied to frames rather than time. Asking for these to be handled properly at the start is far cheaper than discovering them from a stranger's bug report.

Everything written goes into a normal Godot project on your own disk. There is no proprietary format and no server holding it. If you want to open it in Godot yourself, or hand it to somebody who codes, that works without an export step.

The engine underneath being open source is not a footnote. It means the ceiling on your project is Godot's ceiling rather than ours.

That also means nothing here is a one-way door. If you outgrow the tool, or you want to work with someone who codes, the project comes with you and keeps working. There is no export step and no conversion, because there was never a proprietary format to convert from.

Flockbay is a desktop app for Mac and Windows. Godot ships inside it and your game runs locally when you press play. There is no browser version.

Building needs an internet connection because Director 1, generation and world data come over the network. Playing what you have built does not.

The temptation is to sort out the look first, because the look is the part you can picture. It is usually the wrong order. A game with perfect sprites and a bad jump is a bad game that took longer to find out about.

Coloured rectangles are a legitimate way to work for the first stretch. They are honest about what has been decided and they make it obvious when the movement is carrying the game rather than the art. Once the feel is right, the art has something to serve.

When you do get to it, most of what a flat game needs is already in the Catalogue: 55,073 of its 60,648 objects are sprites, searchable by name with a picture of each. You place one by hand at an exact position, turn and size. A picture sits on its own drawn bottom-centre rather than the middle of its file, so a crate stands on the ground instead of hovering by however much transparent margin the file happens to carry, and draw order follows that same point, so the thing lower down the screen is in front.

Director 1 will generate a single flat picture when you ask for one. It will not generate an animated one — no frames, no sprite sheet. That is a gap worth naming here rather than on the day you need a walk cycle for a boss: anything that has to move through drawn poses is your art, an artist's, or the web's. Whichever route an asset took, the tool says which rather than blurring them, and that matters if the game is going to be sold.

Plenty of finished 2D games have deliberately simple art. Simple is a style as well as a stage.