Does AI game making actually work?

Turning a described behaviour into working code. "The lantern keeps the wolves back until it burns out." That is a sentence and an afternoon of programming, and the gap between those is the entire case for the method.

Iterating on feel. Because a change costs a sentence, you try versions you would otherwise have talked yourself out of. This is one of the genuinely underrated effects — it changes which ideas get tested at all.

The tedious middle. Menus, settings, save systems, the fourth variation on a UI panel. Nobody was ever glad to have typed those.

Whole games from a prompt. You get the average of the genre, competent and anonymous, because a prompt does not contain the thousands of decisions a game is made of.

Worlds. A landscape has no correctness test, only whether it is the one you wanted. Describing it precisely enough takes longer than shaping it, and the near-miss results are the most expensive kind of wrong.

Judgement. Nothing will tell you the corridor is boring or the enemy is annoying rather than threatening. Those are the questions that decide whether a game is good, and they require someone to play it and care.

Blind code. An assistant pointed at a project can write script that compiles and references a node that does not exist, because it cannot see your scene. The result is not gibberish, which makes it worse — you spend the afternoon debugging code you did not write. This is a tooling problem, not a model problem, and it is fixed by giving the model a world it can actually inspect.

Accumulated shape. Code written sentence by sentence over weeks develops a structure nobody chose. Everything works, each change costs a little more, and there is no moment where it went wrong.

The ceiling. Tools built on a fixed list of behaviours are fast for a fortnight and then stop, and the wall does not announce itself in advance. Asking what happens when you need something not on the list is the single most useful question to ask any tool in this category.

Ask where the game runs. In a tab, or on your machine. That predicts your performance ceiling more than any feature list.

Ask what you own at the end. A project a standard engine can open, or a document that exists only inside the tool. The second is fine until it is not.

Ask whether the code is written or assembled from a menu. Written means the limit is the engine. Assembled means the limit is the menu, and you will find it.

The game runs on your machine, locally, on the copy of Godot bundled inside the desktop app for Mac and Windows. You own a normal Godot project in a folder. Director 1 writes real GDScript rather than picking from a list, so there is no menu to fall off the end of.

The blind-code failure is what the capability layer exists to address: it gives the model a world it can address by name rather than a folder of scripts to guess from. That is the bet, and it is worth stating as a bet rather than a proof.

And the parts that do not work here either: no whole game from a prompt, no AI laying out your world, no substitute for playing your own game and being honest about it. Building also needs an internet connection. Playing what you built does not.