Chat to game, and the part chat is bad at
Talking to something that builds your game is a good idea for about half the job. The other half is spatial, and describing a landscape in sentences is the slowest way anybody has found to make one.
What chat is genuinely good at
Behaviour. "The guard should notice you if you run, but not if you walk, and forget about you after ten seconds unless he saw your face." That is one sentence and it is a precise specification. Writing the code for it takes considerably longer than saying it, which is exactly the condition under which conversation is the right interface.
Rules, conditions, state, timing, edge cases. All of these are things language handles well, because language is what people use to think about them in the first place. You do not picture a cooldown. You state it.
This is what Director 1 is for. You describe behaviour, it writes the GDScript into your project, you play the result, you say what is wrong. The revision loop is the interface, not a fallback when the first attempt misses.
What chat is bad at
Space. "A clearing about forty metres across with a ruined tower on the north side, slightly uphill, and a stream that passes on the east but not close enough to reach the tower." That is a laborious sentence, it is still ambiguous, and whatever comes back will be wrong in three ways you then have to describe again.
Placing it yourself takes ninety seconds and is exactly right by definition. There is no translation step, no ambiguity and no round trip. Anyone who has tried to specify a level in prose knows this, and any tool that insists on it is optimising the impressive half rather than the useful half.
The same applies to composition and pacing. Whether a ridge line reads well, whether the walk between two points is too long, whether the doorway is visible from where the player enters. These are looked at, not described.
So the split is deliberate
In Stage Engine you build the world with your hands. Terrain, water, weather, lighting, buildings, characters, placed directly in a builder that behaves like a level editor. Director 1 writes the code for everything that behaves.
That is not a limitation working around a missing feature. It is the design, and it follows from which half each side is faster at.
It also produces a better conversation. When the world already exists, you can say "make the door at the top of the tower need the key from the stream" and mean something specific, rather than trying to establish the geography and the mechanic in the same paragraph.
Two paths, and no silent third
There are exactly two ways things happen. Director 1 writes code, or you do something yourself with the manual controls. There is no arrangement where you ask for something and the tool quietly does something adjacent and does not tell you.
That matters for trust more than it sounds. If a request cannot be met the way you asked, you should be told what actually happened rather than handed a result that looks plausible.
The practical shape
Stage Engine is a desktop app for Mac and Windows with Godot bundled inside it. Your game runs locally, on your machine, at your framerate. No browser editor, no streaming, no cloud preview.
Building needs an internet connection because Director 1, asset generation and world data all come over the network. Playing what you built does not.
Free to download with a free plan, Indie at $10 a month and Pro at $50, which buy more usage rather than a different engine.
How to describe behaviour well
Say what should happen and under what conditions, and be specific about the edges. Not make the enemy smarter, but: it should stop chasing if it loses sight of me for three seconds, and go to where it last saw me rather than where I am now.
Say what should not happen too, when it matters. The unstated assumptions are where first attempts go wrong, and stating one is cheaper than a round trip.
Then play it before deciding. A behaviour that reads correctly can feel wrong, and a behaviour that sounds crude can feel excellent. The written description is not the thing you are judging.
When something is wrong, describe the symptom rather than diagnosing the cause. What you noticed while playing is reliable information; a guess about which value needs changing usually is not, and it narrows the search in the wrong direction. It is the same skill as describing a fault to a mechanic. Say what it does and when, not what you think is broken, and you will get there faster.
Questions
- Can I make a whole game just by chatting?
- No, and it would be slower if you could. The behaviour comes from conversation and the world comes from your hands, because each half goes to whichever is genuinely faster.
- Do I need to phrase requests in a special way?
- No. Describe the behaviour the way you would explain it to a person. Precision helps, jargon does not.
- What if the first attempt is wrong?
- You say what is wrong and it is revised. That loop is the normal way to work, not a sign of failure.
- Is the code hidden from me?
- No. It is GDScript in your Godot project. You are not required to read it and nothing stops you.
- Where does it run?
- Locally, on the copy of Godot bundled with the Mac or Windows app.