An adventure game maker where the writing stays yours

Strip an adventure game down and there are three things. Places you want to be in. Things to say and hear. And a set of locks that only open in the right order.

Only the third one is really code. The first is composition — the shape of a room, what you see from the doorway, whether the light makes a corridor feel long. The second is writing. Both of those stay with you, and there is no version of this tool that takes them.

The locks are where people stall. Inventory, flags, dialogue state, an object that behaves differently once you have read the letter. Individually simple, collectively a knot. That knot is what Director 1 is for.

You build environments by hand in the builder. Interiors, exteriors, terrain, weather, the lighting of a specific hour. It works like a level editor: you place, you walk through, you move things until the space reads the way you meant.

Adventure games are unusually sensitive to this. A room that is two metres too wide feels wrong in a way a player will not name but will feel. That is a judgement call and it does not require knowing any code at all, which is why it is the part you keep.

The world can be as large or as contained as the story wants. A single manor with twelve rooms is as reasonable a project as a valley you walk across.

You say what should happen and Director 1 writes the GDScript in your project. An inventory that combines two items. A conversation that remembers what you said an hour ago. A door that stays locked until three separate conditions are true, and gives a different line for each one that is not.

Dialogue systems in particular are a place where people abandon adventure games. Branching, conditions, re-entry, a character who should not repeat the greeting on the fourth visit. All of it is well-understood and all of it is tedious to write.

You never have to read the script. You do have to play the conversation and decide whether it sounds like a person.

A puzzle is only good if it is fair, and fairness is something you can only tell by playing. The tool will happily implement whatever chain of conditions you describe. It cannot tell you that the third step is a leap nobody will make.

So the loop is: describe the puzzle, play it, notice the leap, change it. Handing work back is the normal shape of this, not a sign of failure. Not writing the code does not mean not having an opinion about the puzzle.

There is a related trap in puzzles, which is designing them backwards from a clever solution. A puzzle that is elegant once explained is often invisible while you are inside it, and only playtesting with someone who does not know the answer will tell you which one you made.

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

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

Adventure games are the genre most often abandoned at 60 percent, and the reason is almost always scope rather than difficulty. The idea grows because every new room suggests three more, and there is no natural point at which the design says stop.

The practical counter is to build the whole spine first at the lowest possible fidelity. Every room grey and empty, every conversation one line, every puzzle solved by walking into it. Play that. It takes an hour and it will tell you whether the story holds, which is the only question that matters at that stage.

This is much more achievable when the systems are written for you, because the grey version costs a day rather than a month. Then you fill it in, and you fill in the parts that the playthrough said were weak rather than the parts that were fun to imagine.

None of that is a rule the tool enforces. There are no gates here and nothing will stop you building the cathedral first. It is just what tends to work.