Describe a game, then build the half description cannot reach

Compare two instructions. "When the player steps into water, they slow down and the camera drops closer." And: "the rocks along the shore should be a bit more scattered, and that one is too big."

The first is precise. It has a trigger, a condition and two effects, and a machine can turn it into code that does exactly that. The second is not an instruction at all; it is a gesture pointed at a screen. Read it back in a week and you cannot reconstruct which rock.

Almost every disappointment with describing a game to an AI comes from that second category. The tool is fine at behaviour and hopeless at arrangement, and the arrangement is most of what a world is.

In Stage Engine you describe behaviour to Director 1, and it writes the GDScript into your project. Rules, systems, states, consequences. What happens when you pick the thing up. What the guard does when it loses you. How the day changes the world. What a save file contains.

You can be as detailed as you like or start rough and correct by playing. Rough is usually faster: get the mechanic in the game, hold it in your hands, and then say the actual thing you want, which you normally cannot articulate until you have felt the wrong version.

The code lands in your own project, and the project is a real Godot project. You are not asked to read the script. You are asked to run the game and say whether the water felt right.

The world is built by hand in the builder. You raise terrain, draw a lake outline, set weather, place buildings and characters, and move the rock that is too big by moving it. Nothing about that requires code, and nothing about it goes through a text box.

This is deliberate and it is not a limitation waiting to be lifted. Direct control is simply the right instrument for spatial work, in the same way a text description is the right instrument for a rule. Two paths, kept separate: Director 1 writes code, you use the builder. There is no quiet third path where a description silently rearranges your scene.

The game runs locally. Stage Engine is a desktop app for Mac and Windows and it ships with Godot inside, so pressing play starts your game on your machine at your machine's framerate. No streaming, no browser tab, no waiting for a queue.

That short loop is what makes description workable at all. You say a thing, you play it within a minute, and you know immediately whether the sentence you wrote meant what you thought it meant. The revision is the work, not the failure.

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

Name the trigger, the actor and the outcome. "When the player enters the cave, the torch lights and the ambient sound drops" is buildable. "Make the cave spooky" is a mood, and moods are yours to construct out of light, sound and pacing in the builder.

Ask for one behaviour at a time. A paragraph containing six systems produces six things you cannot individually judge. One thing, play it, then the next.

And describe the effect, not the implementation. You do not need to know how a state machine works to say that the enemy should hesitate before charging.

It happens, and it is almost never because the words were unclear. It is because you asked for the implementation you imagined instead of the outcome you wanted.

If you say the enemy should have a three second cooldown, you get a three second cooldown, and the fight is still boring. What you actually wanted was a gap where you feel safe enough to move. Say that, and the number becomes a thing to tune rather than a guess you have committed to.

The habit worth building is to describe the feeling you are chasing alongside the mechanic. You have every right to that judgement, and it is the input nobody else can supply.