Vibe coding a game, and the part vibe coding is bad at

Behaviour. Rules. State. "When the player picks up the lantern, the wolves keep their distance until it burns out." That is a sentence you can say quickly and code you would spend an afternoon writing, and the gap between those two facts is the entire argument for the method.

It is also good at the parts of programming that are tedious rather than interesting. Wiring, plumbing, the fourth variation on a menu. Nobody gained anything from typing those out.

And it is good at exploration. Trying five versions of a combat feel is a different activity when each version costs a sentence instead of an evening. You end up testing ideas you would otherwise have talked yourself out of.

Anything spatial. "Put a ruined watchtower on the ridge to the north, angled so you see it from the valley path" is a slow, imprecise sentence describing a decision you could have made in four seconds by dragging it. Every spatial instruction is a description of a thing you can already see in your head, translated into words, translated back, badly.

Anything to do with taste. The density of a forest, how long a corridor should feel, whether a room reads as abandoned or merely empty. These are judgements made by looking, and a text round trip is the wrong instrument.

And the well known failure: a pile of generated code nobody understands, where the fifth bug is unfixable because fixing it means understanding the previous four. That is a real risk and pretending otherwise helps nobody.

Director 1 writes the code — GDScript, inside your project, where it lives on disk as a normal Godot project. You describe the behaviour, he writes it, you play the game and say whether it is right. That is vibe coding, done deliberately, for the half of the work where it is the better method.

The world is not vibe coded. You build it by hand in the builder: terrain, water, weather, buildings, characters, placed where you want them because you put them there. There is no path where you describe a landscape and hope. This is a design decision, not a missing feature.

The result is that the vagueness stays where vagueness is cheap. A wrong behaviour is one sentence away from being fixed. A wrong landscape, in a tool that only accepts descriptions, is a negotiation.

The loop is: you play, you find what is wrong, you say so specifically, it changes. Not writing the code does not mean not having an opinion. If you have played games for years, your sense of when something is off is well calibrated even when you cannot name the cause.

Specific feedback gets specific results. "The combat is boring" is a shrug. "I can kite every enemy backwards forever and never take a hit" is a fix. Getting good at this tool is largely getting good at describing what you noticed.

Handing the build back is normal. Nothing about the process assumes you accept the first version.

Stage Engine is a desktop app for Mac and Windows, downloaded and installed, with Godot bundled inside it. When you press play, the game runs locally on your machine. There is no browser preview, no streaming, and nothing rendering somewhere else.

Building needs an internet connection, because Director 1, asset generation and world data all come over the network. Playing the game you built does not. The download is free, there is a free plan, Indie is $10 a month and Pro is $50, and paid plans buy more usage rather than a different engine.