Make an endless runner where the tuning is the game

There is not much to an endless runner. Something moves forward, obstacles arrive, you jump or you do not. Everyone who has made one knows the code is a weekend and the feel is a month.

The month goes on jump arcs, gap spacing, how fast the speed ramps, how long the grace window is when you press jump slightly early, and how the spawner avoids handing the player an impossible sequence. Get those wrong and a technically complete runner is unplayable. Get them right and a very plain one is hard to stop playing.

Which is why an AI that writes the code is more useful here than it sounds. The code is not the hard part, but it is the part standing between you and the tuning.

Describe the runner and Director 1 writes the GDScript: the endless track, the chunk spawner, the pooling so it does not stutter after five minutes, the difficulty curve, the score and the death. It goes into your project as ordinary code you can point at.

You then do the part that matters, which is playing it. Say the jump feels floaty and it gets less floaty. Say the gaps get punishing too early and the curve softens. That back and forth is the normal way to work, not a sign that something went wrong.

You do not need to be able to write a spawner to know that a run is not fun in its fortieth second. That judgement is the thing you bring.

Most endless runners are built from chunks: a handful of hand-authored track segments that the spawner shuffles. Building those chunks is level design, and you do it directly in the builder rather than by describing it.

That split is deliberate across the whole app. Anything where you can see whether it is right is faster to do with your hands. Anything where the answer is code is faster to describe. A jump sequence is the first kind.

The world around the track is the same. Terrain, sky, weather, buildings going past. Runners live or die on readability, so being able to place things and immediately see whether the obstacle reads against the background is worth more than any generator.

A runner at an inconsistent framerate is a broken game, because the player is timing inputs against motion. This is one genre where where the game runs is not a technicality.

Stage Engine is a desktop app for Mac and Windows and the game runs locally on the copy of Godot bundled with it. Not in a tab, not streamed from somewhere else. You are seeing your machine, which is also what your player will see.

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

The download is free and there is a free plan. Indie is $10 a month and Pro is $50, and both buy more usage rather than a different engine.

A runner is a genuinely good first project on any tool, because the scope is honest and you find out quickly whether you like the loop of describing, playing and correcting.

A runner without a reason to restart is a tech demo. The reason is usually a number, and how you present that number does more work than anything else in the game.

A best score that sits on screen during the run. A near miss that registers. A short pause on death that is long enough to feel the loss and short enough that you press restart before thinking. Those are all code, and they are all things you specify by playing and reacting rather than by planning.

Unlockables and daily variants come later and are usually a distraction until the base run is good. If the fortieth second is not fun, nothing bolted on top will fix it.