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

A side scroller looks like the easy option. Two directions, a floor, some gaps. In practice it is the genre with the least room to hide. Every jump arc is fully visible to the player, every gap is measured by eye, and a movement system that is slightly wrong is obvious within one screen.

Compare that with a 3D game, where a loose jump can pass unnoticed because the player is dealing with a camera and a third dimension. Side scrollers offer no such cover. They are simple to start and demanding to finish.

That makes iteration speed the deciding factor, which is what Flockbay is arranged around.

Making a project asks one question first: 2D or 3D, shown as two pictures, with no default and nothing created until you pick. Pick 2D and the genre is already on screen. There is a 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 pressing. Seconds, not a tutorial, and the first screen you get to have an opinion about is one you did not have to build.

Widening that ground is dragging across it. Ground is a tile layer built from a coverage map: you drag to lay cells, drag to erase them, and the tiles, the edges and the collision all fall out of which cells are ground. You never go looking for the right corner piece. Whether ground stops a walker is declared per material, so in a side scroller the block you paint is solid the moment it appears and the jump you have been arguing about has somewhere to land. Paint the same cells in a different order and you get the same level, and a rebuild never reshuffles an edge you already accepted.

Everything standing in that screen is placed by hand at an exact position, turn and size, and most of it comes out of the Catalogue: 55,073 of its 60,648 objects are sprites, searchable by name with a picture of each. A sprite sits on its own drawn bottom-centre rather than the middle of its file, so a crate stands on the ledge instead of hovering by however much transparent margin the file happens to carry.

A good deal of how the body feels is already there as controls rather than code. Walk and run speed, how long it takes to reach a speed and how long it takes to lose it, air control, gravity, jump apex, body size, step length. "Make it heavier" is a handful of numbers moving, not a rewrite, and the walk cycle advances by distance travelled rather than by a timer, so the legs stay with the speed instead of skating out from under it.

The rest Director 1 writes as GDScript in your Godot project: the fall that is faster than the rise, coyote time, jump buffering, wall behaviour, ledge forgiveness. Every one of those is a number that changes how the game feels, and none of them are things you should have to name in advance.

You will not tune any of it by reasoning. You will tune it by jumping onto the same ledge forty times and saying it still feels heavy. That is a real specification here and it is one you can give without reading a line of code.

The camera deserves the same attention, and gets less of it in most projects. In a flat project you frame it by dragging three boxes on the running game: what is in view, the dead zone the player can move around inside before anything scrolls, and the limits the view will not pass. The limits follow the ground you paint until the first time you drag them yourself. A side scroller with a bad camera plays badly even when the controller is right.

You lay out the level in the builder rather than describing it. Placing platforms is faster by hand, and it is where the design happens: what the player is taught in the first screen, what the third screen tests, how far the checkpoint is from the hard part.

Godot handles both 2D and 3D, and side scrollers exist in both. A 2.5D side scroller — 3D geometry with the camera locked to one axis — is a 3D project with a constrained camera rather than a flat one, and it is a real choice if you want terrain, water and weather sitting behind the plane the player runs along. It is the other option, not the recommended one. When the game is the jump, which in this genre it usually is, flat is the shorter road to finding out whether the jump is any good.

A desktop app for Mac and Windows, installed on your machine, with Godot bundled so the game runs locally. Consistent framerate matters unusually much in a genre where the player is timing jumps, and running locally is what gives you it.

Building needs an internet connection, because the model, asset generation and world data all come over the network. Playing what you built does not. There is no browser version.

Free to download, and the builder itself is free. Indie at $10 a month unlocks the AI assistance — gameplay logic from Director 1, plus texture, sound, prop and rig generation — and the free plan lets you try it first.

In a side scroller the player learns entirely by moving right and finding out what happens. Whatever is in the first screen teaches them the rules, so it teaches them something whether you designed it to or not. A gap that can be cleared without thinking teaches that gaps are free.

The classic sequence is introduce, repeat, complicate, test. Show the mechanic somewhere safe. Ask for it again. Combine it with something known. Then demand it under pressure. That structure is decades old because it works, and it is invisible to players, which is the point.

You author that by placing the level yourself, which is why the builder puts layout under your hands. It is also why you should build a few screens and play them before adding a second mechanic. A side scroller that teaches one thing well is better than one that introduces five and explains none.

How far the player is sent back matters as much as how hard the jump is. The same sequence can be a satisfying challenge or an infuriating one depending entirely on whether failing costs three seconds or ninety, and this is the single most common thing new side scroller designers get wrong.

Generous checkpointing lets you build harder content, because attempts are cheap and the player stays in a rhythm. Sparse checkpointing makes ordinary content feel punishing. Decide which game you are making, then place them deliberately rather than at convenient intervals.