AI shooter game maker: build the level, get the code written

The common way to begin a shooter is to spend three weeks on a weapon and then build a grey box to fire it in. The better way round is to build a space you want to fight in first, because the space is what determines whether the weapon has anything interesting to do.

Stage Engine leans that direction because the builder is the part you touch directly. You place terrain, buildings, cover and elevation by hand. You decide where a player is exposed, where they can breathe, and where the room forces a choice. That is level design, and it is the half of a shooter nobody can generate for you convincingly.

Once the space exists, the encounter is the question: who is in it, where do they come from, what do they do when you take the high ground. Ask Director 1 for enemies that hold cover and push when you reload, and it writes the GDScript into your project. Play it. If they push too readily, say so.

You will iterate a lot here, and that is the intended shape of the work. Encounter design has never been something anyone got right on paper. It is watched, adjusted and watched again.

The same goes for objectives, waves, checkpoints, ammo economy and difficulty. All rules, all written for you, all judged by you playing them.

A desktop application for Mac and Windows, downloaded and installed. Godot ships inside it, so your game runs locally on your machine. Not in a tab, not streamed. Your project is an ordinary Godot project you can open in Godot itself.

You need an internet connection while building, because Director 1, asset generation and world data all come over the network. You do not need one to play what you have built.

The download is free. There is a free plan, Indie is $10 a month, and Pro is $50. Paid plans buy more usage, not different software.

One good level beats six weak ones and takes a quarter of the time. If you are new to this, aim at a single arena you would replay, with one enemy type that behaves interestingly and two weapons that feel different from each other.

What you learn from that will change what you want the rest of the game to be, which is a good reason not to build the rest of the game first.

A weapon that sounds right feels right, and a weapon that sounds thin feels broken no matter what the numbers say. This surprises people the first time they notice it. You can leave every statistic untouched, change the audio and the hit reaction, and players will tell you the gun was buffed.

The same goes for everything the game says back to you. A hit marker, a stagger on the enemy, screen shake that is present but not seasick, tracers that read at distance, a reload animation with weight. These are cheap compared with the systems underneath and they change the perceived quality more.

So budget time for them rather than treating them as polish for the end. You can generate audio and assets in the app or bring your own, and Director 1 wires the feedback into your project as code. It is worth doing early because it changes what you think of the rest.

Building levels as untextured blocks is a genuine technique and it works, right up until it goes on for months. The problem is that nobody, including you, can judge whether a grey corridor is tense. Space reads differently once it has light, materials and something to look at.

Because you can generate assets while you build, there is less reason to stay grey for long. Get the layout right in blocks, then dress it enough to judge, then keep iterating on both. The point is to keep the level in a state you can honestly evaluate.