Text to game, taken apart into the four things a game is made of

Take a real sentence: "a game where you run a lighthouse on a cold coast and something is wrong with the boats". That is a good idea and it is roughly two per cent of a game.

Underneath it there is a coast, which has a shape. There is a lighthouse, which has an interior and a stair and a light that has to do something. There are boats, which arrive on a schedule and behave in a way that is meant to be unsettling. There is a night length, a fuel supply, a reason to sleep and a consequence for not.

None of that is in the sentence, and none of it can be deduced from it, because a different person writing from the same sentence would build a different game. The sentence is the seed, not the specification.

World: the coast, the rocks, the light on the water, where the cottage sits relative to the tower. Built by hand, by you, in the builder. Terrain, water, weather and time of day are direct manipulation, because a description of a coastline is a worse instrument than a mouse.

Systems: the fuel, the schedule, the light's rotation, whether a boat that gets too close does something. Described in words, written by Director 1 as GDScript inside your project. Words are the best possible instrument for this and always were.

Content: what the boats look like, what the radio says, the lines you wrote. Assets come from generation, from the web, or from you, and simple geometry can be built directly when that is the honest fastest route to playing.

Feel: whether the night is long enough to be dreadful, whether the stairs take too long to climb, whether the light is bright enough. That is judged by playing, and it stays with you throughout.

It would be easier to sell a chat box that produces a whole game from a paragraph. The reason not to is that the resulting game is always someone else's: it is a template with your nouns in it, and the moment you want it to be specifically yours you have no instrument except more paragraphs.

Building the world by hand is slower on the first evening and much faster by the third, because every adjustment costs a drag instead of a negotiation. Having the code written costs nothing at any point, because there is no spatial precision to lose.

That is the argument. Use text where text is exact, use your hands where your hands are exact.

You build a bit of coast. You ask for the light to rotate and for fuel to drain. You play it, and the fuel drains too fast, so you say so. You play again and the night is boring, so you ask for a boat.

It is not a generation step followed by a result. It is a conversation with a game you keep going back into, and the useful thing you bring to it is impatience with what is not right yet. Handing the work back is the normal loop rather than a failure.

Not on the code. The two common stopping points are having no second idea after the first thing works, and having a first idea so large that nothing works for weeks.

The first is solved by playing what you made and noticing what is missing. A world you can walk around generates its own next questions, and they are better questions than the ones you had before it existed.

The second is solved by cutting. One place, one mechanic, one reason to be there. The full game does not go away by being postponed, and the small version is what tells you whether the full one is worth building.

Stage Engine is a desktop app for Mac and Windows. It is downloaded and installed, and it ships with Godot inside it, so your game runs locally on your own machine rather than in a tab or on a server.

Your project is an ordinary Godot project on your disk. Godot is open source, so the folder opens without this app.

Building needs an internet connection, because Director 1, asset generation and world data all come over the network. Playing what you built does not. The download is free with a free plan, Indie is $10 a month and Pro is $50 for more usage.