How we built Highway Rush: turning a server seed into a browser runner that feels alive

Highway Rush is a game we built at Raw Fun Gaming: a single character sprints down a highway, its head swelling as it passes through multiplier gates and shrinking when it clips a cone, a stop sign, or a roadblock. At the finish line the head size is cashed out against a column of stop signs. It looks and plays like a hyper-casual mobile runner. It is actually a provably-fair casino game, running entirely in the browser, on Stake.

That one sentence hides the whole engineering story, so let us pull it apart.

The constraint that shapes everything: the run is already decided

On a normal runner, the game is the source of truth — you steer, the physics respond, the score is whatever you earned. On a provably-fair casino game it is the opposite. The moment a bet is placed, a server-seeded math engine has already decided the entire outcome: which gates you will hit, what your head size will be, what you pay out. That result is signed and verifiable — the definition of “provably fair.”

So Unity is not playing the game. Unity is replaying a result it was handed. The whole craft of the client is making a predetermined multiplier feel like a live, breathing run that you are watching unfold for the first time.

That reframes everything downstream:

• No gameplay input may change the outcome. The client takes the seed, derives the exact sequence of events, and renders it. Player “control” is presentation, never causation.
• Determinism is non-negotiable. The same seed has to produce a byte-identical run on our laptops, on your phone, and on the server’s own verification pass. One stray random call in the gameplay path, one frame-rate-dependent physics step, and the replay diverges from the proof. So gameplay randomness comes only from the seeded source; anything cosmetic is kept on a separate private RNG so it can never perturb the deterministic run.
• The client is a pure replayer. A lot of the hardening work was exactly this: hunting down every path where live input, timing, or engine state could leak into gameplay, and cutting it.

The engineering problem is not “build a runner.” It is “make a fixed, server-authored outcome feel earned, tense, and alive — every single time, identically, everywhere.”

Shipping it to the browser — including mobile Safari

Stake games run as WebGL. No native app, no install; the game streams into a browser tab, and roughly two-thirds of players are on mobile Safari / iOS. That platform is the real boss fight.

A few things we learned the hard way:

VFX Graph is out. WebGL has no compute support, so GPU-driven particle systems simply do not render. Everything visual ships as plain CPU particle systems with standard URP particle shaders — old-school, but they build and render reliably on every browser.

Bloom needs a different path. URP’s built-in bloom is unreliable in our WebGL builds, so the glow you see runs through a dedicated renderer feature instead. The editor lies to you here: it renders at the desktop quality tier by default, a different renderer than the tier a WebGL build actually ships with. More than once an effect looked perfect in the editor and vanished in the build.

The Safari shader stall. The first time a browser renders a given shader program, it caches uniform locations on the main thread. On Chrome that is about 0.1ms and invisible. On Safari it is about 3ms per program, with no persistent cache — and a single complex prefab can carry a hundred-plus uniforms across its passes. So the first time a fancy effect appears mid-game, Safari can freeze the main thread for up to three seconds. The fix is a warmup pass: during the loading splash we stage every runtime-spawned prefab off-screen, render it for a few frames so the browser compiles and caches its shaders, then despawn it. The hitch happens where nobody is looking.

The through-line for WebGL is humility: assume nothing transfers from the editor, budget for the worst browser, and pay your costs during the loading screen rather than mid-run.

Making the world feel alive without spending the frame budget

A runner needs a world going past, not just a track. Highway Rush has a low-poly city, birds, a day/night atmosphere, and lanes of background traffic. None of it is gameplay, and all of it has to be nearly free.

The background traffic is a good example. It is a stop-and-go jam of around 80 cars that move like real traffic, play engine audio, and can even physically block the character when it dies — but during the normal run it costs almost nothing:

• Movement is one controller over a flat list of lightweight structs — no per-car scripts. The cars follow a car-following model tuned so a packed lane still creeps instead of gridlocking, with each move committed to a distance rather than a timer so the stop-and-go reads convincingly.
• Audio is a looping engine bed per car whose volume is driven in code — a car is only audible when it is actually moving and within earshot, so out of ~80 cars only a handful ever hold a live voice.
• Physics is deferred entirely: colliders start disabled and only wake up near the character at the one moment they are needed, on their own layer so they never trip the gameplay triggers.

The player can only see, hear, and touch a sliver of the world at any instant, so build every system to spend effort only on that sliver.

On top of that sits the polish that sells a casual game: haptic feedback, colour-matched bursts when the head passes a gate, camera work, and per-car colour variety. Small touches, but they are what make a deterministic replay feel like a game instead of a cutscene.

One engine, two very different games

Highway Rush is not a one-off. It is built on the Raw Fun Gaming engine, a shared Unity codebase that ships two streams of games onto Stake: a slots stream of cluster/tumble “Pop” games, and a burst/casual stream of “Rush” runners, of which Highway Rush is one. The web-to-Unity bridge, the seed and replay plumbing, the WebGL hardening, the shader warmup, the ambient systems — all of it lives in the engine so the next game gets it for free.

A slot game and a highway runner look nothing alike to a player, but underneath they are the same problem: take a signed, server-authored outcome and make it a joy to watch, in a browser, on a phone, provably fairly. Solve that once, well, and you can ship a lot of games.

What is actually special here

Plenty of studios make runners. Plenty make casino games. What made Highway Rush a fun build was the collision of the two: the discipline of provably-fair determinism, wrapped in the presentation language of a hyper-casual mobile game, delivered through the browser to the worst-case device — and made to feel effortless.

If you want to see the result, it is live: Highway Rush on Stake.

Built with Unity 6 (WebGL) on the Raw Fun Gaming engine, for Stake Engine.