The whole genre lives in the jump

Nobody reads your platformer description. They press right, they press jump, and they decide. Gravity, jump height, the acceleration curve, how much control you keep in the air, whether a jump pressed slightly before landing still counts. Get those wrong and the level design cannot save it.

The reason so few first platformers feel good is not taste, it is iteration count. When changing gravity means editing a script you barely understand, you try three values and settle. Feel comes from trying thirty.

Flockbay changes the cost of an iteration. You say the jump is floaty at the top, Flockbay changes the code, you play it again. Thirty iterations is an afternoon.

More on this: Make a first person game where the world holds up close

Every good platformer has a handful of forgiveness mechanics that players never notice and would miss instantly. Coyote time, so a jump still works a few frames after leaving the ledge. Input buffering, so a jump pressed just before landing fires. Variable jump height tied to how long the button is held. Corner correction, so clipping a ledge nudges you around it instead of stopping you dead.

Naming them is not required. Describing the problem is enough: "I keep falling when I swear I pressed jump on the edge." That is a solvable, well-understood problem and Flockbay writes the GDScript for it in your project.

You do not need to read the script to know whether it worked. You need to play it. That loop is the design process, not a workaround for not coding.

Once movement feels right, a platformer is a sequence of small spaces that each teach or test one thing. The gap that shows you the jump distance. The first enemy you must jump over rather than around. The room where the two combine.

That sequence is not something to describe in a sentence and hope. You place it, play it, move the platform two units left, play it again. The builder is a builder for exactly this reason.

Which kind of space you are placing is settled before the project exists. Making one asks 2D or 3D, shown as two pictures, with no default and nothing created until you pick one. Neither is the reduced version of the other.

Pick 2D and the project opens already playable: sky, a band of scenery along the horizon, ground with a ledge cut into it, a platform floating off to one side, and a person who walks, falls and jumps under the keys you are already pressing. Seconds, not a tutorial. Moving that ledge two units left is dragging across it — ground is a tile layer built from a coverage map, so the tiles, the edges and the collision all fall out of which cells you covered, and a block you paint is standable the moment it exists.

Pick 3D and you get that side's own tools instead: terrain from elevation, water, weather, time of day. The flat world has a shorter list — ground, what is beyond it, the person, and the things you place — because water and weather have nothing to describe in a world with no depth. That is the honest scope of a flat world rather than a smaller advantage.

Nothing this genre is judged on sits on the missing part of that list. Walk and run speed, how fast the body reaches a speed and how fast it loses it, air control, gravity, jump apex, body size and step length are controls on the character body. Thirty iterations of the jump is thirty small moves rather than thirty rewrites.

More on this: AI side scroller game maker: one axis, a lot of precision

Flockbay is a desktop app for Windows with Godot bundled inside. Press play and your game runs locally at your own framerate, which for a genre that lives on frame-accurate input is the right way round.

Your project is a real Godot project. It is not a save file only this tool can read, and Godot is open source.

Building needs an internet connection, since the chat and asset generation come over the network. Playing does not. Free to download, and building by hand stays free. Flockbay is free on your own AI: your Claude or ChatGPT plan, your own agent, or an API key. Flockbay builds from a library of ready-made objects, or with Godot's own shapes.

More on this: Racing games are won or lost on the car, not the track

A platformer camera is doing constant quiet work. Leading the character in the direction they are moving so you can see what is coming. Lagging slightly on landing so a fall does not lurch. Holding still in a small room instead of drifting. Looking down when you hold down.

Get it wrong and players will tell you the jump feels bad, because they cannot see the camera and they can see the character. It is one of the most common misdiagnoses in the genre.

It is also code, so it changes when you describe the problem. If a section feels claustrophobic, say so and let the camera pull back before you start rebuilding the level. Testing the cheap fix first is usually right.

More on this: AI top down game maker: the camera that shows everything