Free, no code, and still an engine rather than a toy

A game maker gives you assembled parts. A game engine gives you the machinery those parts were built from. The distinction sounds academic until your game needs something the parts do not cover, and then it is the only thing that matters.

Most free no-code products are makers wearing the word engine. They are pleasant, they are genuinely free, and they have a fixed vocabulary of behaviours. When you exhaust that vocabulary there is no next step inside the tool. There is only starting again somewhere else.

The reason that trade exists is that removing code has historically meant removing the ability to express arbitrary behaviour. Menus were the only way anyone knew to do it.

Do not remove it. Write it for the person.

Stage Engine runs on Godot, which is open source and free and is a full engine by any measure. Director 1 writes GDScript into your project when you describe what should happen. Because the output is a general programming language, there is no vocabulary to exhaust. If Godot can do it, your game can do it, and nobody had to anticipate your idea.

You never write a line and you are never required to read one. The project is readable, which is a property of it being real, not an obligation on you.

The download is free for Mac and Windows and there is a free plan. Godot itself is free forever regardless of us. There is no watermark, no export gate, no revenue share and no reduced engine on the free tier.

What is metered is usage of the AI and asset generation, because those run over the network and cost real money every time. Indie is $10 a month and Pro is $50, and that is the only difference between the plans. A product promising unlimited AI for nothing is either about to reprice or is spending someone else's money on you.

The important consequence of that structure: your work is never the hostage. Stop paying and your Godot project is still a Godot project.

You build the world by hand. Terrain, water, weather, buildings, characters, arranged directly in the builder. Spatial work is done by pointing because that is faster and more precise than describing it.

You describe behaviour to Director 1 and it writes the code. Then you play the game and say what is wrong with it. That verdict is the input the entire process runs on, and being non-technical has no bearing on your ability to give it.

The game runs locally on the bundled Godot at your machine's framerate, which is why a world with real terrain and weather is a reasonable thing to attempt. Building needs an internet connection; playing what you built does not.

Before committing months anywhere, take the strangest mechanic in your design and try to build only that. Not the tutorial project. The odd one: the door that only opens when nobody is watching, the enemy that copies your last three moves, the season that changes what the map means.

A tool with a fixed vocabulary will fail that test in a specific way. You will find yourself designing around what is available rather than toward what you wanted, and the compromise will feel reasonable each time until the game is somebody else's.

That test is cheap and it is worth doing on us as well. Ask Director 1 for the strange thing on your first day, play the result, and judge it. If the answer is bad, you have lost an afternoon rather than a season.