Most runners end the same way: you crash or cross the line, a panel slides in, and you press retry. That works, but it throws away the best moment to show players what their run produced. In CGT Rocket X Racer, a fan-made rocket-car runner that plays in a desktop browser, we tried to make the end of a run feel like a delivery instead of a game-over screen. This post covers how that end sequence is put together, the constraints a browser build puts on it, and the trade-offs we made.
Fan-made Ā· Desktop-only Ā· Not affiliated with Tesla.
What the run produces
The end screen only means something if the run feeds into it. During a run you collect five part types: body, chip, motor, thrust and energy. The number of cars you can build equals the lowest of the five counters. The HUD shows your weakest counter in red, so you always know which part is holding you back. This rule matters for the end screen. Since the number of cars depends on your weakest part, a row of finished cars directly shows how balanced your collecting was, not just how far you got.
The sequence, step by step
The end of a run happens in several steps rather than one hard cut.
Arrival. The route alternates between indoor factory halls and open air, and it finishes by flying into an end garage. The car brakes and hovers there, and the camera orbits around it. That orbit gives the player a moment to look at the car before any numbers appear.
Results. The results screen draws a stock-style price line over your run, with dips where you took damage. A line chart is easier to read at a glance than a table of numbers. You can see a clean stretch, a bad collision and a recovery without reading anything.
Delivery. After the results, the scene moves to the front of the garage, where a row of cars lifts off together. This is the payoff: the parts you collected become a group of vehicles leaving the factory, not a number in a corner.
The garage decision. From there the player can go into the garage, browse the skin picker (ten skins), and press CONFIRM to save a choice and apply it to the car.
Why a fleet and not a single car
A single car taking off looks like any victory animation. A row of cars taking off together says something different: you built these. Linking the visuals to the cars-built rule keeps the screen honest. It also gives players a clear reason to change how they play next time. If the row looks short, the red counter on the HUD already showed which part to look for.
There is a readability reason too. During the run, the side nozzles and the always-on underbody hover jets are the main sign that the car is flying rather than driving. Reusing the same thruster language for the lift-off at the end ties the end screen to the feel of the run, so no new visual vocabulary has to be learned.
Browser constraints shaped the design
The game is built in Godot and exported to the web. Two decisions from the rest of the project directly limited what the end screen could do.
Compatibility renderer. Everything uses Godot's Compatibility renderer, which runs on more machines in the browser but gives up some heavier lighting and post-processing. So the end screen cannot depend on expensive effects for impact. It depends on motion instead: a camera orbit, a group lifting together, and thruster effects reused from gameplay.
No-threads web template. The web build uses the no-threads template, so it runs on a plain static host without the special cross-origin headers threaded builds need. The trade-off is less room for parallel work. That pushes us to keep the end sequence light. It reuses vehicle assets and effects already loaded for the run instead of loading a separate showcase scene with its own large assets.
Effects in the right place. We spend effects where players actually look. During development the side nozzles were moved back behind the front wheel arch, and a check tool confirms every mist emitter sits exactly on its marker in the model. The same discipline applies to a row of cars: if emitters drift off their markers, the mistakes repeat across every car in the row and get much easier to spot.
Fairness upstream, payoff downstream
An end screen that celebrates the run only works if players believe the run was fair. The hazards along the way are giant presses and sweeping robot arms, plus several debuffs. An automated audit tests every press pattern across its full cycle at several speeds. Pickups are never placed inside an obstacle's motion, and indoor arm patterns always leave a safe lane. When players trust that a missing part was their own mistake, a short row at the end works as motivation instead of feeling unfair.
Pacing: keeping it skippable in spirit
Runners live on quick retries, and a long outro gets in the way. We keep the end sequence in short, separate steps (arrival, results, delivery, garage), so each step does one job and players always know what they are looking at. The results chart carries the information. The lift-off is the reward. The garage is the next decision.
What we would tell other browser devs
- Connect the end screen to a rule the player already understands. Ours is "cars built = lowest part counter".
- Under the Compatibility renderer, motion and camera are cheaper than post-processing and read better anyway.
- Reuse in-run assets for the outro so a lightweight web build doesn't have to load a showcase scene.
- Use tooling to check effect placement. Small offsets multiply when you show many vehicles at once.
- Show performance as a shape, not a spreadsheet. A line with dips is quick to read.
We are still tuning the order and timing of these steps, and feedback from people building web runners is very welcome.
If you want to see the sequence yourself, the fan-made game runs in a desktop browser at www.cgt.monster.
Fan-made Ā· Desktop-only Ā· Not affiliated with Tesla.
