AI shooter maker: the genre that lives or dies on feel

Ask ten people what makes a shotgun feel good and you will get ten answers, all of them vague and all of them correct. Recoil that recovers just slowly enough. A fire rate that fights you a little. Damage falloff that punishes the wrong range without announcing it. Hit reactions that confirm the shot before the damage number does.

None of that survives being written down as a requirement. All of it is obvious within a couple of seconds of holding the weapon. That is the awkward truth about shooters, and it decides how a tool for making them should work.

Stage Engine is arranged so the loop between changing a number and firing the gun again is short. Director 1 writes the code, you play it immediately, and you say it is too floaty or too heavy. That is a legitimate specification here, and it is the one you can actually give.

Movement and camera control. Weapon behaviour, spread, reload, ammo and switching. Hit detection and damage. Enemy perception, cover use, retreat, flanking. Health, respawn, waves, objectives, the score screen. All of it is GDScript inside a real Godot project on your disk.

You do not need to read it. You do need to play it and be difficult about the result, because a shooter that nobody was fussy about plays exactly like one.

Level layout is where shooters are actually designed, and you do that by hand in the builder. Cover placement, sight lines, the height advantage that costs something to reach, the corridor that forces a decision. Terrain, water, weather and buildings all go in directly.

This is the part that cannot be automated without the result reading as a generated box with objects in it. Players cannot name what is wrong with such a level, but they stop playing it. A hand-built arena is the difference.

Asset generation is there while you build, and you can bring your own models and sounds because it is a standard Godot project.

Stage Engine is a desktop app for Mac and Windows. It installs on your machine and bundles Godot, so your shooter runs locally at your hardware's framerate. For a genre where input latency is part of the design, that is not a detail.

Building requires an internet connection, since the model, asset generation and world data come over the network. Playing what you built does not. There is no browser build and no streaming.

Free to download with a free plan. Indie is $10 a month, Pro is $50, and the difference is usage.

An enemy is not really a character. It is a question the weapon has to answer. A fast one asks about tracking, a shielded one asks about positioning, one that closes the distance asks whether you have the discipline to reload early. Design them that way and a small roster carries a whole game.

Designed the other way, as a list of monsters with different health totals, you get an encounter that is only ever about pointing at things. Players describe this as repetitive without being able to say why, and adding more enemy types makes it worse rather than better.

Because behaviour here is written code rather than a preset, an enemy can be exactly the question you want to ask. Describe the pressure it should apply, play it, and adjust until the fight is about the thing you intended. That is more iterations than you expect and each one is cheap.

The lazy way to make a shooter harder is to give enemies more health, and it makes the game worse every time. Bullet-sponge enemies stretch the same encounter out rather than changing it, and players read it immediately as padding.

The alternative is to change the situation: less cover, an angle you have to give up something to hold, a second enemy arriving from where you retreated last time. That is level and encounter work rather than a number, and it is what separates a shooter people finish from one they abandon on the third level.