Who writes the code in Stage Engine?
Director 1 writes the code. It writes GDScript into your own Godot project, on your own disk, and you never have to open a script to get a game working. Your half of the job is building the world by hand and deciding whether what comes back is right.
The one-line answer
Director 1 writes the code. Stage Engine is a desktop app for Mac and Windows, made by Flockbay, and Director 1 is the AI inside it. You say what should happen in plain language, and it writes GDScript into your project, in a file on your own disk, in the format used by Godot.
That is the whole of the code question. There is no visual scripting graph to wire up, no menu of behaviours to assemble a game out of, and no point where the tool announces that you have reached the part requiring a language. If you can describe what should happen, that is the input.
What Director 1 does not do is build your world. That half is yours, and it is a deliberate division rather than something missing.
Your half is the world
You place things. Terrain gets sculpted, water takes an outline you draw, weather and sky are settings you set, and every building, prop and character goes where you put it. The builder behaves like a level editor rather than a chat window, because for this part of the work a viewport and a mouse beat a sentence.
The reason is that describing a landscape in words is slower and worse than making one. "A ridge running north with a village in the lee of it" is a sentence to write, a sentence to interpret, and thirty seconds to do by hand. Taste does not survive being turned into a paragraph and handed over.
Code is the opposite. "The lantern goes out in the rain and the player has to relight it" is exact in one line and tedious as a sequence of clicks. So that part goes to Director 1, and the split follows the shape of the work rather than a marketing idea about what AI should do.
What non-technical means here
It means you do not write the code. It does not mean you cannot judge the result, and that distinction matters more than anything else on this page.
You play the game. You are the one who notices that the jump feels heavy, that the enemy gives up chasing too early, that the door opens but the sound belongs to a different door. Nobody else is in a position to notice, because it is your game and the standard is yours.
So the loop is: ask, play, say what is wrong, ask again. Handing work back is the normal state of this tool, not a sign that something failed. A first result that is close and wrong is the expected result, and the fix is a sentence about what is wrong rather than an evening in a text editor.
The code is visible, not hidden
Director 1 writes into your project, not into a box we keep. The scripts are GDScript files in a folder on your machine, readable by anyone who reads code, in the format used by an engine that is open source and widely known.
You are not asked to read them and plenty of people never will. But the option costs nothing to keep open, and it changes what is possible later: you can hand the project to a programmer, put the folder in version control, back it up like anything else, or open it in Godot yourself.
A tool that wrote your code somewhere you could not see would be a tool that owned your game. This one does not, and that is worth more the more time you put in.
Why not a menu of behaviours instead
The usual alternatives are a menu or a graph. A menu ships a fixed set of behaviours and you assemble a game from them, which is quick to start and has a ceiling shaped exactly like the menu. A graph of nodes and connections composes much better, and it is programming with a different notation, so it hands back the conceptual work you were trying to avoid.
Writing real script has neither problem. There is no list to run out of, and there is no notation to learn, because the thing you supply is a description of what should happen.
The cost is that written code is written rather than assembled, so getting it right sometimes takes a round or two. That is the trade, and it is why the judging half of the job matters as much as it does.
What Director 1 will not do for you
It will not build the world. There is no path where you describe a landscape and one quietly assembles itself behind your back, and there is not going to be one. The world is a person's work, in the builder, with the manual controls.
It will not decide whether the game is good. It has no opinion worth having about whether your village feels lonely enough or your combat is satisfying, and a tool that claims otherwise is guessing on your behalf.
And it will not work without a connection. Director 1 runs over the network, along with asset generation and world data, so building needs internet. The game you have built runs locally on the copy of Godot inside the app and needs nothing.
Questions
- Does Director 1 write the whole game?
- It writes the code. The world is yours to build by hand in the builder, and judging the result is yours as well.
- What language does it write?
- GDScript, which is Godot's own language, in ordinary script files inside your project.
- Do I have to read the code?
- No. Most people building here never open a script. It is readable if you want it, which is a different thing from being required.
- What do I do when the result is wrong?
- Play it, say what is wrong, and ask again. That is the intended loop rather than a failure of it.
- Is Director 1 a separate product?
- No. Director 1 is the AI inside Stage Engine, the desktop app for Mac and Windows from Flockbay. It is not a plugin for another engine and it is not sold on its own.
- Can I use my own AI instead?
- Yes, over MCP, on the paid plans. Your agent runs on your own machine with your own model and credentials, and Director 1 stays available alongside it.