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.

More on this: What an AI FPS generator can honestly hand you

You describe what you want to Flockbay. It asks what it needs to know, one round at a time with a recommendation for each, and writes a brief before it builds anything: what comes first, what comes after, what is not in this version. A good one reads like the advice above: a player controller and one gun in an empty box first, enemies after, multiplayer not yet. Nothing is built until you approve it.

Then it writes the GDScript into your Godot project. A player 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. It play-tests that before you do: it runs the game, sends input events, reads stdout and the debugger, and captures the viewport.

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.

Once the movement is fun, Flockbay builds the level around it with its world tools: terrain sculpted and painted, buildings and props placed as scene instances, cover where you asked for it. If your shooter is outdoors, that includes water, sky and weather, all as real nodes in the scene tree.

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, so you walk it and say what you found: the sniper perch sees too much, the doorway has one angle too many. Flockbay changes the level to match.

Some calls are faster with your own hand. You walk it and find out that the flanking route nobody uses is invisible from the entrance, so you move it: the same world tools are buttons around the Godot editor's 3D view, acting on the live scene, and Godot's undo takes it back if you were wrong.

Flockbay is a desktop app for Windows and Linux, 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 the chat, asset generation and world data come over the network. Playing what you have built does not.

More on this: An FPS maker that runs the shooter on your own machine

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.

More on this: AI battle royale maker: read the hard part first

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. Flockbay writes that as GDScript in your project, and you judge it by whether the fight has a shape.

The other half is the space: 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, so judge the room as hard as the enemy, and tell Flockbay when the cover is in the wrong place.

More on this: AI shooter game maker: the level and the code, built from one brief