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

You open a project and lay down a room. Some ground, a couple of platforms, a door on the right, a place the player starts. Ten minutes with a cursor.

You ask for 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. You play again. Somewhere around the fourth pass the movement feels like the thing you had in your head, and that is the point at which the room you built 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.

A save system that survives being closed mid-level. A settings menu with remappable keys. A camera that behaves at the edge of the room. 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. That is the practical reason the AI half earns its place.

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.

Stage Engine 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 and asset generation 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, sprites and tiles can be generated, sourced, or made by you, and the tool tells you which route it took rather than blurring the distinction. That matters because you need to know what you are actually holding, particularly 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.