Karts, hovercraft, boats: racing is wider than cars

Racing covers rally stages that are point to point, karts with items that change who wins on the last corner, boats where the water is the track, hovercraft that ignore terrain entirely, downhill runs where you have no engine at all, and time trials against a ghost of yourself.

Tools built around a car on a circuit handle one of those and make the rest awkward or impossible. That is the cost of a fixed template: it is excellent until your idea sits slightly outside it, and then it is a wall.

Stage Engine has no vehicle catalogue and no track templates. What a vehicle is, is whatever the code says it is, and the code gets written when you describe it.

A hovercraft that skims water and terrain alike, loses grip in turns, and can boost by venting height. A kart that drifts if you hold the button and rewards releasing it at the right moment. A boat that only turns while the propeller is in the water.

You describe it, Director 1 writes the GDScript in your project, and you drive it. Then you say what is wrong and it changes. Nothing in that sequence involves checking whether your idea is a supported vehicle type, because there is no such list.

The same is true of race structure. Point to point, laps, checkpoints with time extensions, elimination every thirty seconds, a rally with a co-driver calling notes. All rules, all code.

Stage Engine builds worlds with real terrain, water and weather, which is unusually relevant here. Rally lives on surface change and elevation. Boat racing lives on water that behaves like water. Snow, fog and night are not decoration in this genre, they are the difficulty.

You build the route by hand in the builder, then drive it, then move things. Corner placement in a landscape is a judgement made by being there, and it is why the builder is a builder rather than a text box.

Real-world elevation data is available, which is a fast way to get a stage that feels like a real road through real hills.

Stage Engine is a desktop app for Mac and Windows. Godot, open source, is bundled inside it, and your game is a real Godot project that runs locally when you press play. There is no browser version and no streaming.

There are no servers, hosting or matchmaking, so racing against other people over the internet is not something this hands you. AI opponents and time trial ghosts are ordinary things to build.

Building needs an internet connection because Director 1, asset generation and world data come over the network. Playing does not. Free to download with a free plan; Indie is $10 a month, Pro is $50, and those buy more usage.

Racing games have a structural problem: a player who falls behind early has nothing to do for the rest of the race. Every solution to this is a design statement. Rubber-banding keeps the pack close and annoys the good driver. Items that favour the last place make chaos the point. Nothing at all makes it a purist time-trial in company.

Choosing which one you want decides who your game is for, and it is worth deciding deliberately rather than inheriting whatever the first implementation happened to do.

All three are rules, so all three are code you can try. Build one, race it, and notice whether losing was still interesting. That is the test, and it takes a few minutes rather than a rewrite.

Take the audio away from a racing game and it becomes unplayable in a way that surprises people. The engine note is how you know when to shift, the tyre squeal is how you know you are past the limit, and the change in tone off a wall is how you know how close you were.

That makes audio a control input rather than decoration, and worth attention early rather than in a polish pass. A vehicle that sounds like a single looped sample at every speed will feel wrong even when the handling is right.

Audio behaviour is code: pitch tied to speed, layers that fade in under load, a skid sound tied to grip loss. Describe it, drive it, and listen with your eyes closed for a moment. It is the fastest diagnostic in the genre.