AI game prototyping, on an engine the prototype can survive on

Standard practice is to prototype in something quick and rebuild in something serious. That is sensible when the quick tool produces a format nothing else can read, and it costs you the whole prototype every time.

It also distorts what you learn. A prototype in a small flat tool teaches you about a small flat version of your game. If your idea depends on scale, distance, weather or a landscape you can get lost in, the prototype cannot tell you whether it works, because those are exactly what the quick tool removed.

Stage Engine collapses the two. What you make is a Godot project from the first minute, running natively on the bundled Godot, so a prototype that turns out to be good does not need to be re-made anywhere else.

Behaviour comes from description. You say what should happen and Director 1 writes the GDScript in your project. Prototyping is mostly systems work — the loop, the failure state, the thing the enemy does — and systems work is exactly what is slow to write by hand.

World comes from your hands. Terrain, water, weather and buildings, placed directly in the builder. Rough is fine and rough is the point at this stage. You are answering a question, not decorating.

And you play it immediately, locally. No build queue, no export step to check something obvious.

The most common prototyping mistake is building the parts you already know work. If you are confident the combat is fine and unsure whether the traversal is boring, then the prototype is the traversal, with placeholder everything else.

This tool makes that discipline easier to hold, because the surrounding systems can be described in a sentence and stop consuming attention. You spend the session on the uncertainty rather than on the scaffolding around it.

It also makes it cheap to build the same idea twice, two different ways, and play both. That comparison answers questions no amount of discussion does.

A prototype does not tell you whether the game will hold for twelve hours. It tells you whether the core is interesting for ten minutes. Those are different questions and only one of them is answerable this early.

It also will not tell you whether the game looks good, because at this stage it does not. Judging art direction off a prototype is a reliable way to kill a good idea.

Desktop app for Mac and Windows, Godot bundled inside. Free to download with a free plan; Indie is $10 a month and Pro is $50 for more usage.

Building needs an internet connection because Director 1 and generation are online. The prototype you built runs locally, so you can playtest it anywhere, including in front of someone on a bad connection.

The failure mode at this stage is not building badly. It is enjoying the prototype phase and never leaving it, because prototypes are fun and finishing is not.

A prototype has done its job when it has answered the question you built it for. Write the question down before you start, and when you can answer it, stop and decide: continue this into a game, or discard it and ask the next question.

Discarding is a legitimate outcome and a cheap one here, because the answer cost you an evening. Most ideas should die at this stage and the ones that survive are worth the year.