Make a game with AI and no coding, without a closed toolbox

The first meaning is a closed system: blocks, behaviour menus, a fixed list of things that can happen. Nothing to learn, and a hard ceiling. When your game needs a rule the menu does not contain, there is no move available. You are not stuck because you lack skill; you are stuck because the option does not exist.

The second meaning is that code gets written and it is not written by you. The ceiling then is not the menu, it is what can be expressed in a programming language, which for practical purposes is everything.

Stage Engine is the second kind. Director 1 writes GDScript in your project. You never open it.

In sentences. "Torches burn out after two minutes and you can relight them from a brazier." "The boat only moves if both crew are aboard." "The music changes when you cross the bridge."

None of those are on any behaviour menu, and all of them are ordinary code. You get them by asking, playing, and saying what is wrong.

The part that surprises people is how much of the work is the third step. First attempts are usually close and rarely right, because rules interact in ways nobody predicts until they are playing. That iteration is the design work, and it is yours.

Everything spatial happens in the builder with your hands. Terrain, water, weather, structures, props, character placement. It looks and behaves like a level editor, and you judge it by looking at it.

This is why the tool does not need to guess at your game. The half of the game that a description would butcher is the half you do directly.

It is a desktop app for Mac and Windows. Downloaded, installed, no browser version. In exchange, your game runs locally on the bundled open-source Godot, on your own hardware.

Building requires an internet connection. Playing what you built does not.

Free to download with a free plan. Indie $10 a month, Pro $50, both more usage rather than more engine.

The uncomfortable version of "no coding" implies you also hand over the judgement. You do not. Nobody else can tell whether your game is fun, and no model has an opinion about it worth trusting over yours.

You play everything. You reject plenty. Handing work back is the normal loop here, not a sign the tool failed. If anything, the people who get the most out of this are the ones with the strongest opinions about what is wrong.

There is a version of no-code where the code does not exist at all, and your game is a configuration file interpreted by a runtime you do not control. Nothing can be inspected because there is nothing to inspect.

Here the GDScript is written into your project as ordinary files. You are not expected to read them. But they exist, which means a friend who does program can help, a problem can be diagnosed, and the project has a life beyond this app.

That difference costs you nothing while things are going well and matters enormously the first time something is wrong in a way you cannot describe.