AI adventure game maker, with the AI in the right place

Ask anyone who abandoned an adventure project what stopped them and it is rarely the story. It is that the dialogue system got out of hand. A conversation that branches, remembers, re-enters at the right node, gives a different line on the second visit, and unlocks a flag that a door three rooms away is watching.

That is not creative work. It is bookkeeping with a lot of edge cases, and it is exactly the kind of thing Director 1 writes well. You describe the behaviour and it writes the GDScript in your project.

The result is that the parts of an adventure game that are actually about being a writer stay in your hands, and the parts that are about being a programmer stop being your problem.

Adventure games are about being somewhere. A study with the curtains drawn. A ridge where the path forks. A corridor that is deliberately too long. You build these by hand in the builder — terrain, interiors, light, weather, time of day.

This is spatial judgement rather than technical skill, which is why it is the half you keep. A room reads correctly or it does not, and only you can tell.

Worlds can be small and dense or large and open. A twelve-room house is as reasonable a project as a valley, because the game runs on your machine rather than inside a hosted preview that quietly prefers small.

Interaction: looking, taking, using one thing on another, and the refusal lines when it does not work. Inventory with combination and state. Conversations with conditions and memory. Journals that update. Triggers that fire once. Save files that restore all of it correctly, which is the part nobody thinks about until it breaks.

It also writes the movement and camera, because an adventure game where walking feels bad is an adventure game nobody finishes.

None of this requires you to read a script. It requires you to play the game and say when a conversation repeats itself or a door gives the wrong reason for being locked.

The tool will implement any chain of conditions you describe. It cannot tell you whether step three is a leap that nobody will make, because that is a fact about players rather than about code.

So you play your own puzzle, notice the leap, and change it. Being non-technical has nothing to do with this. You are the person best placed to judge whether your puzzle is fair, and handing the work back with a note is the normal rhythm here.

There is one more thing only you can judge, which is whether a puzzle belongs in this story. A mechanically fair puzzle can still be a mechanically fair puzzle that has wandered in from another game, and that is a tonal judgement rather than a design one.

Stage Engine is a desktop app for Mac and Windows with Godot bundled inside it. Your game runs locally when you press play. There is no browser version and no streaming.

Building needs an internet connection, since Director 1, asset generation and world data all come over the network. Playing the finished game does not.

Worth being direct. Generated prose is recognisable, and adventure games are made of prose. A description of a room written by a model reads as a description of a room, whereas a description written by you reads as a description of that room by someone who has an attitude about it. The second is why anyone plays these.

Generated puzzle design has the same problem in a less obvious way. A model will produce puzzles that are structurally valid and unmemorable, because the memorable ones depend on a specific joke or a specific piece of world knowledge that only exists in your game.

So the honest position is that the AI here is infrastructure. It writes the dialogue system, not the dialogue. It writes the inventory, not the joke about what is in it.

If what you wanted was a tool that writes the adventure for you, this is not it, and the ones that claim to be are producing something you would not want to put your name on.