FPS game maker: the feel comes before the level

Load any shooter you like and walk in a circle before firing a shot. You already know whether it is good. The acceleration, the amount of air control, how much the camera moves when you land, whether strafing feels heavy or light. Players read all of that instantly and forgive very little.

This is why starting with a level is a mistake. A beautiful corridor around bad movement is a bad game with good art in it. Get a character moving through an empty box until the box is fun, and then build the level for the movement you ended up with.

The same applies to the weapon. Rate of fire, recoil, reload timing, the hitscan-or-projectile decision, and the feedback when you connect. Those numbers are found by shooting, not by planning.

You describe what you want to Director 1 and it writes the GDScript into your Godot project. A movement controller with the acceleration and air control you asked for. A weapon with a specific fire rate and recoil pattern. Enemies that hear before they see, take cover, and lose track of you if you break line of sight.

You then play it, and say the thing you noticed. The strafe is sticky. The gun is loud but does not feel like it hits. Reloading takes long enough to be annoying but not long enough to be a decision. Those sentences are the design work, and they are the part that requires a person.

The code lands in your project where you could read it. Nothing requires you to.

Levels are geometry and geometry is placed, not described. In the builder you shape terrain, put up buildings, cut sightlines, decide where cover is and where a player is exposed. If your shooter is outdoors, you have terrain, water and weather to work with directly.

Sightlines are the whole craft of shooter level design. How far can a player see, how many angles cover this doorway, is there a route around. Those are judgements made by standing in the space and looking, which is why the builder gives you direct control and does not ask you to specify a corridor in a paragraph.

Then you walk it in the game and find out that the flanking route nobody uses is invisible from the entrance. So you move it.

Stage Engine is a desktop app for Mac and Windows, and it ships with Godot inside. Press play and the game runs on your machine at your framerate. For a shooter that is the baseline requirement: aiming judgement at thirty inconsistent frames per second in a browser tab tells you nothing about whether your game feels good.

It also makes ambitious scenes reasonable. An outdoor level with terrain, weather and a lot of active enemies is not a browser workload.

Building needs an internet connection because Director 1, asset generation and world data come over the network. Playing what you have built does not.

Godot supports networking and a shooter is one of the harder things to network well. It is not a first-week feature and anyone telling you it is a checkbox is not being straight with you.

A single-player shooter with good movement and enemies worth fighting is a complete game and a much better first target. Add players later, once the thing is fun with one.

People assume the hard part of shooter enemies is intelligence. It usually is not. A genuinely smart enemy is frustrating; what players enjoy is an enemy that is readable, telegraphs, and gives them a moment to react.

So the useful requests are about rhythm rather than cleverness. It should pause before it fires. It should call out when it spots you. It should push forward if you stay still too long. Director 1 writes that as GDScript in your project, and you judge it by whether the fight has a shape.

The other half is the space, which you build by hand. Where the enemy comes from, whether you see it before it sees you, and what you can put between yourself and it. Encounter design is architecture more than behaviour.