DEV Community: Raw Fun Gaming

Acting Out a Fight That's Already Over: How Spinblade X Moves Its Spintops

Raw Fun Gamer — Thu, 15 Oct 2026 00:00:00 +0000

In Spinblade X, two spinning tops (four in the melee modes) launch into a bowl and fight until one is left. It looks like a fight. It isn’t one. By the time the launcher’s trigger is pulled, the game already knows who wins, every hit that lands, how hard, when the finishing blow comes, and what it pays.

That is not a shortcut. It is a requirement. Spinblade X is a real-money game, and the outcome of a real-money round can’t depend on a physics engine. The result comes from a pre-computed book of rounds, picked server-side and provably fair, and the 3D battle is a performance of a script it isn’t allowed to change.

So the movement system has two jobs that pull against each other:

Look like real spinning tops. Glancing blows, bounces off at odd angles, the occasional top that backs up the slope and comes screaming back down.
Hit its marks. Every recorded clash has to land on screen, on time, between the right two tops, and the round has to end the way the book says.

This post is about how we hold both. It covers the three layers we ended up with: physics that reads as real, an AI that paces itself to a script, and a few hand-authored moves for the moments that matter most. It also covers how all of that is seeded, which part of the result is guaranteed to be identical, and which part we deliberately let vary. Along the way are four designs we built and threw out, because they are most of how we got here.

What the script actually says

A round in the book is a list of beats, not a list of positions. Trimmed, one looks like this:

{"seed": 302, "multiplier": 4.82, "opponent": 1, "mode": 0, "events": [
  {"type": "Clash", "time": 0.196, "playerTier": 0, "opponentTier": 0,
   "outcome": "Normal", "playerRpm": 4902, "opponentRpm": 4870,
   "multiplierAfter": 0.05},
  ...
  {"type": "Death", "time": 8.497, "victimIsPlayer": false,
   "finisher": "Spin", "playerRpm": 476, "opponentRpm": 0,
   "multiplierAfter": 4.82}
]}

Each Clash says when two tops meet, how each strike rolled (miss, normal or critical), what that did to each top’s Shoot Power, and where the multiplier stands afterwards. The Death says who goes out and how: Spin (ran out of power), Over (knocked out of the bowl) or Burst (shattered).

What the script does not say is where anyone is standing. Our books are generated by a math engine, not recorded in Unity. That is a decision we’ll come back to, because it’s the reason the rest of this post exists.

Layer 1: making tops behave like tops

Before a top can hit its marks it has to move like a top, and the first version didn’t.

Chase where the other top will be, not where it is

The obvious AI is “steer toward the opponent”. Give it to both tops and you get a stable orbit: each chases the other’s tail around the bowl, and after the opening collision they never touch again. Our tops use lead pursuit instead. They aim at where the opponent will be 0.4 seconds from now. Each archetype also hunts at its own speed, from 1.5 m/s for the Defense top to 2.25 m/s for the Attack top, which breaks the symmetry that let the orbit form in the first place.

A bowl that pulls

Real stadiums are curved, so a top left alone drifts to the middle. We don’t simulate that curvature. We fake it with a steady pull toward the centre, which keeps the fight mid-bowl where the camera wants it. Two guards sit on top. A soft wall starts pushing inward at 75% of the radius and ramps up steeply, so a pile-up in the melee can’t shove a top over the rim by accident. There’s also a speed cap , because a top that bounces off one opponent straight into another picks up speed from both. Leaving the bowl is the Over finisher’s job and nobody else’s.

Bounce apart, and not in a straight line

Real tops don’t grind against each other. They hit and fly apart. On every clash the struck top is pushed away at 1.1 m/s and the striker recoils at 70% of that. That alone fixed the “glued together” look, but it left a stranger one. A duel that started mirrored, with the tops on opposite sides of the centre, shuttled back and forth along one straight line, clash after clash, because the push ran exactly along the line between the two centres and the bowl’s pull sent them straight back along it. It looked staged, because it was.

The fix is a small piece of noise. Both pushes are swung off that line by a random 10 to 35 degrees, to a random side, and scaled by up to ±20%:

private Vector3 Scatter(Vector3 direction)
{
    float angle = Mathf.Lerp(clashDeflectDegrees.x, clashDeflectDegrees.y,
                             (float)clashScatter.NextDouble());
    if (clashScatter.NextDouble() < 0.5) angle = -angle;
    return Quaternion.AngleAxis(angle, Vector3.up) * direction;
}

On a mirrored start, the tops’ average distance off that line went from 0.023 to 0.079, in a bowl about 0.6 in radius. That’s small as a number and obvious on screen: they glance off each other now.

Two physics bugs that look like design problems

Two bugs are worth knowing about, because both looked like “the AI is bad” for a while.

One hit, counted four times. Each top is several colliders, so one visible impact fires the collision callback once per collider pair. Every clash was triple- or quadruple-counted until we debounced it: one clash per 0.4 s, shared across both tops.
Equal speeds, no bounce. To avoid counting a hit from both sides, only the faster top resolves it. Our first version used <=, so two tops meeting at exactly the same speed resolved on neither side. Unity doesn’t re-fire OnCollisionEnter on a contact that persists, so there was no bounce, and they ground along together for the rest of the round. Now the slower top yields only when it’s strictly slower, and a persisting contact re-resolves through the same debounced path.

Layer 2: an AI that knows the script

Physics that reads as real is the easy half. The hard half is that the book says the third clash happens at 2.84 seconds, between these two tops. Free-running physics doesn’t care.

The answer we settled on we call beat-bound theatre. The tops are still physical, AI-driven bodies, but the AI paces itself to the record:

After a touch, a top backs off briefly, then drifts and holds a loose distance from its partner instead of chasing.
Half a second before the pair’s next recorded clash, it starts the approach. In a melee it aims at that beat’s partner, not the nearest top, because a touch with the wrong top binds nothing.
A real touch within 0.35 s before the beat claims it on the spot: the spark, the damage numbers, the sound and the HUD update all land on that contact.
If no touch has come by 0.35 s after the beat, it fires anyway, on the clock. The visuals are gated on the tops actually being close, so nothing sparks across an empty bowl.
A top with no beats left holds off for good. A touch the record never made would be a hit the player sees and the payout doesn’t include.

One rule keeps it consistent: a touch can’t claim a beat while an earlier beat of either top is still pending. Energy and combo are computed from the order of a top’s strikes, so beats have to be consumed in order or the meters on screen drift from the book.

The result: the on-screen timeline stays within about a third of a second of the record, and most beats land on a real touch rather than a clock tick.

Watch the clip (video)

A GRAND MELEE round replayed from the book: four tops acting out a record they can't change. The feed on the left is that record, beat by beat.

Layer 3: custom moves for the moments that matter

Pursuit, bounce and pacing give you a plausible fight. They don’t give you a climax. Beat-bound theatre treats the killing blow like any other clash, so the round’s biggest moment looked like the round’s most ordinary one. Three things are hand-authored.

The charge run

Watch real Beyblade and the big hits come from distance: a top swings wide, climbs the stadium wall and comes back down with everything it has. So before a killing blow, the striker makes a charge run. It backs away from its partner up its own side of the bowl, swung about 35° off to one side so both the climb and the return are curves, then charges back down to land 0.1 s after the beat, inside the binding window.

The interesting part is the timing. The run has to start at exactly the moment that makes it arrive on the beat, wherever the wind-up happened to end. So the AI solves its own steering equations for the travel time. Under our steering, speed approaches its target exponentially, and the bowl’s pull adds a constant acceleration on the way down. The distance covered by time t has a closed form, and a 24-step bisection inverts it:

// distance covered by time t: exponential approach to vmax, plus the bowl's pull
float d = vmax * t - (vmax - v0) * (1f - Mathf.Exp(-g * t)) / g
        + 0.5f * bowlPull * t * t;

When the time remaining until the beat drops to that answer, the top commits, and once committed it doesn’t re-decide. Without that, a top that slowed on contact would drop back into its wind-up mid-strike.

The steering gain needed its own value. The normal chase closes about 63% of a speed gap per second, which never reaches charge speed between beats. A gain of 8 got there but snapped on like a remote-controlled car. 4.5 gets there and still looks like momentum.

Then it read wrong, which surprised us. With only killing blows charging, the charge was the one move in the round unlike every other move, so it looked remote-controlled for a different reason: it announced itself. The fix was to make it vocabulary. About 35% of ordinary clashes with at least 0.4 s of room now get a run as well, at a lower speed (2.8 m/s against 4.0) and by either top. Measured on real book rounds, plain clashes peak at 1.2–1.5 m/s, ordinary runs at 2.0–2.2 and killing blows at 2.65–2.86. The killing blow is still the hardest hit in the round, but it is no longer a different kind of hit.

Over: a flight that can’t fail

A real knockout is a physics impulse, and a bowl wall eats impulses. In free play a failed ejection is fine. In playback it isn’t: if the book says Over, the player has to see the top leave.

So the Over flight is scripted rather than thrown. The victim goes kinematic and rides a half-second parabola aimed well past the rim on the arena’s long axis. The frame it reads as outside the bowl, physics takes back over with the arc’s own momentum and the ring-out lands:

float u = Mathf.Clamp01(elapsed / flightSeconds); // 0.5 s flight
Vector3 p = Vector3.Lerp(start, end, u)
          + Vector3.up * (arcHeight * 4f * u * (1f - u)); // parabola, 0.5 high

The victim is immune to damage for the whole flight, or a pursuing top would land a kill mid-air and turn an Over into a Spin. In the melee, the books also contain Over strikes that the victim survives. Only an Over followed by that top’s death within 1.2 s is a real knockout. The rest get a weak hop that peaks under the rim, staggers the top toward the wall and lets it roll back in, which is what a failed knockout looks like in real life.

Watch the clip (video)

A base-mode round from the book: glancing bounces, the striker's charge run into the killing blow, then the scripted Over flight out of the bowl in slow motion.

Burst, and the slow motion

A Burst splits the losing top into its three real parts: blade, ratchet and bit. Each part gets a seeded chance to fly out of the bowl (75%, 50% and 15% respectively) and velocities set directly rather than as forces, so they don’t depend on mass. The wreckage stays on the floor until the round ends.

Both round-ending finishers also play in slow motion: a 60 ms hit-stop at 5% speed, then 25% easing back to full over 0.75 s for an Over and 0.5 s for a Burst. The ring-out’s flight plays slowed and lands as speed returns. The physics timestep scales with it, so the debris doesn’t stutter.

Watch the clip (video)

The last four seconds of a Burst round, cropped to the bowl: the full-charge strike, the burst, and the slow motion that follows.

How it’s seeded, and what “the same” means

The question we get most: if it’s all random-looking, how is the same round guaranteed to give the same result?

The answer is that Spinblade X has three kinds of randomness, kept strictly apart.

1. The seed stream decides things. Unity’s global Random is initialised from the round’s seed, and the game draws from it in a fixed order: does the player win, which opponents, which spawn points, and in the melee which NPC is the protected champion. That order is a contract. Insert one draw anywhere and every later draw shifts, and old recordings stop reproducing. In playback the book is authoritative anyway (the payout, the finisher, the opponents and the mode all come from the JSON), but the draw order is kept so recordings and generated books line up.

2. Cosmetic randomness never touches the seed stream. The clash scatter, the burst debris and the arena’s colour scheme each get their own System.Random, never UnityEngine.Random. This rule has been broken twice in this project, and both times by something that looked harmless. The first burst effect made two cosmetic Random.insideUnitSphere calls. In a duel that’s invisible, because a Burst ends the round. In the melee the round continues after a Burst, those two draws shifted every later roll, and recorded melee rounds stopped reproducing. Some cosmetic generators are seeded from the round seed (the scatter uses roundSeed ^ 0x5CA77E, the debris roundSeed * 397 ^ actorIndex), so they repeat when a round is replayed. The charge-run planner is seeded from the clock on purpose.

3. Physics isn’t deterministic, and we don’t ask it to be. A rigidbody simulation varies with frame timing, and on WebGL that means it varies by device.

So the guarantee comes in two strengths:

Exact: who wins, every clash’s strike tiers and damage, every Shoot Power and multiplier value along the way, the finisher and the payout. These come from the book, never from the simulation. The on-screen counter and power bars play back the recorded curves rather than computing their own. Once the battle ends, the book’s payout overrides whatever the live tracker computed.
Similar: where the tops are and how they get there. Every beat lands within about a third of a second of its recorded time, between the right two tops. Two viewings of the same round are two takes of the same script.

We decided the second one should not be exact, and the next section is why.

Four designs we threw away

1. Re-simulate from the seed. Replay re-runs the physics with the same seed. The same seed paid 2.37×, then 2.43×, then 2.31× on consecutive runs. A physics engine can’t carry money.

2. Force the hits on the clock. Fire each recorded clash at its time and pull the tops together for it. By each beat the physics had drifted, so the controller dragged tops across the bowl to meet. We called it the magnet snap, and it fought the bounce, so the tops rubber-banded apart and together forever.

3. Let collisions consume the beats. Let the AI fight freely and have each real contact claim the next recorded clash. It worked for duels. Then four tops in one bowl broke it. The pair that owed the next beat chased other tops, bounces compounded until tops slingshot over the rim, and idle tops ground together without clashing. Four heuristic layers each helped and none sufficed. This one survived in a narrower form: it’s the binding window in today’s design.

4. Ghost playback: record positions too. Store a 10 Hz position track for every top and play it back kinematically. It’s the classic racing-game ghost, and it worked beautifully for rounds recorded in Unity, because the tops are exactly where they were when each beat happened.

Our books weren’t recorded in Unity, though. A 100× maximum win needs a Burst on a round that has already built up 25× before the finisher. Organic Unity battles produce that roughly 0.5 times in 10,000 rounds, and weighting a pool can only redistribute payouts it already contains. So the math engine builds its rounds tail-first: it draws a payout band, then constructs a round that lands in it.

So we gave those generated rounds positions after the fact. A baker played each line once as theatre, recorded where everything went, time-warped each top’s track so its beats lined up with the recorded times, and wrote the tracks back into the book. It ran for six days over all eight melee books, 80,000 rounds, and every rebuilt book paid out exactly as before.

Then we scanned what it produced. In 44–61% of melee rounds, a top held perfectly still for half a second or more, up to 20 seconds. Some of that was the time-warp: a beat that fired late followed by one that bound early put two anchors almost on top of each other, and the warped track froze between them. The worst was a bug: an Over strike the victim survived had been played as a full knockout up to 18 seconds early, so that top’s recorded track froze outside the arena for the rest of the round.

We fixed the bug and replayed the worst rounds live, with beat-bound theatre and no tracks. They showed no stillness, ran their full length and landed 53–74% of beats on a real touch. So we retired the bake. The tracks are still in the books, and nothing plays them.

The lesson cost us a six-day run: a recording is only as good as the take you recorded. We had been treating “exactly reproducible” as the goal, when the actual goal was “always looks right”. A bad take played back perfectly is still a bad take. Theatre that’s re-performed every time gets a fresh chance to look good, and the outcome is protected either way, because the book never depended on the motion.

What we’d tell another team

Separate what must be identical from what must look right. Ours is a JSON file and a physics simulation, and only one of them carries money. Once that line is drawn, the motion can be as loose as it needs to be.
Give cosmetic randomness its own generators, and treat any new call to the shared seeded one as a bug until proven otherwise.
Make the special move ordinary. A killing blow that is the only move of its kind reads as scripted, however good it is. Sprinkling the same move, toned down, through the rest of the round is what made it read as a hit.
Measure stillness, not just accuracy. Our baked tracks hit every beat to the frame and still looked broken. The metric that caught it was “how long does anything stand still”, which no beat-accuracy check would ever have asked.

Spinblade X is live on Stake. The best way to see all of this is to watch a few rounds of the four-top melee and try to spot which hits were scripted. All of them were.

How we built Farm Pop: a slot game where every symbol is a living 3D character

Raw Fun Gamer — Tue, 18 Aug 2026 00:00:00 +0000

Farm Pop is a game we built at Raw Fun Gaming: a 7×7 cluster-pays slot where the “symbols” are not spinning icons — they are fully animated 3D pets. A dog, a cat, a chick, a rabbit, each one idling, running as the reels move, jumping when they win, and burning away in a dissolve when a cluster pops. Match five or more touching symbols, they dissolve, everything above tumbles down, and the cascade continues. Trigger free spins and the whole farm sinks into night — lanterns on, fireflies out — until the bonus ends.

It runs entirely in the browser, built for Stake, where most players are on mobile Safari. That combination — a boardful of skinned, animated characters, on WebGL, on the worst-case browser — is where all the interesting engineering lives.

The client is a choreographer, not a game

Like every game we ship, the outcome is decided before the first frame renders. A math engine pre-generates the full result set — “books” of simulated rounds, one file for the base game and one for the bonus — and the web layer feeds Unity a script of typed events for the round it drew: reveal (here is the board, with per-column anticipation flags), win (these clusters, these amounts), tumble (remove these, drop in those), grid boosts, free spins.

Unity’s job is to perform each event beautifully and then say “done.” That handshake is the entire contract: every event ends with a completion message back to the web layer, which only then sends the next one. Nothing advances on a timer; nothing races. It also makes the system forward-compatible in a way we like: if the web sends an event type the engine does not handle yet, the interface auto-completes it back immediately instead of deadlocking the round. A new mechanic can ship in the math and the webfront before the Unity presentation exists, and the game degrades gracefully instead of hanging.

The deeper win is what this does to animation sequencing — the thing slot games live or die on. Because each event is a discrete, awaited performance, the tumble choreography (dissolve → despawn → compact → spawn → settle) can be genuinely asynchronous inside while still being strictly ordered outside. Column-by-column settles, staggered win animations, anticipation delays — all free to overlap internally, all guaranteed to finish before the next event starts. Even anticipation is authored by the math: the reveal event flags which columns should tease, and turbo mode’s settle-everything-at-once fast path is explicitly disabled when a flag is present. You never skip the tease.

A side effect we use constantly: a debug controller can load a book straight from disk in the editor and replay it against the same handshake, so the entire game is testable — every mechanic, every cascade — without a webfront running at all.

A state machine wearing a fur coat

The heart of the engine is a small state machine on every symbol: Idle, Spinning, Settling, Landed, Anticipating, Win, Dissolving, Clicked. The engine drives states; a game-specific subclass translates them into whatever the art can do. Farm Pop’s translation layer maps states onto the pet animators: idle loops (picked at random so a row of seven cats does not breathe in unison), a run cycle while scrolling and falling, a jump for wins, a landing animation that plays only on a symbol’s first settle — tumbles re-settle existing symbols and should not retrigger it.

Because symbols are characters, they can do character things. Tap one and it plays a reaction animation with its own sound. The scatter — a little farmer — spawns with randomized outfits, hair, and a 50/50 hoe-or-pitchfork prop, so no two look alike; during anticipation, when one more scatter would trigger the bonus, he digs. That is the kind of storytelling a flat symbol atlas cannot do, and it costs nothing extra: it is the same anticipation state every game built on this engine gets.

The price of living symbols is that everything must survive pooling. Forty-nine skinned characters churn through every tumble, so all of them come from object pools — and Unity’s Animator makes pooled characters expensive by default, because re-enabling one triggers a full avatar rebind. A one-line setting (keepAnimatorStateOnDisable) skips that. The pooling discipline runs deep: when the backend awards position multipliers, the winning symbol visually duplicates into a vertical stack of clones, and those clones are pooled too, with their animators rebound on dequeue and their materials restored on return. When a symbol dissolves, its clones share the same dissolve material instance, so the whole stack burns away in perfect sync without any coordination code.

That multiply stack is our favorite piece of pure juice in the game. It is not a loop — it is a recursive wave: the original squashes and pops, and at the peak of its overshoot the first clone starts rising out of it; when that clone arrives, it pops and launches the next one, like a stadium wave traveling up the stack. The glow flash is derived from the same motion — rim-light intensity is computed from how far the scale overshoots 1.0 — so one animation curve drives both the bounce and the flash, through a shared material property block, with zero extra material instances. And because a tall stack clips the top of the frame, the effect requests a ref-counted camera pullback that scales with the stack’s depth in the scene — computed against a fixed reference distance, because computing it against the current distance turns your camera into a positive feedback loop.

Safari, again, but worse

On Highway Rush we learned that Safari compiles and reflects shaders on first draw with no persistent cache — a multi-second main-thread stall the first time an effect appears. A slot game is the pathological case for this: almost every interesting visual is conditionally spawned. Win bursts, dissolve variants, cluster highlights, floating win amounts, grid-boost overlays — none of it renders during the loading screen naturally, so all of it stalls mid-celebration on a player’s first win. The worst possible moment. Our dissolve shader alone — four passes, times shadow, light, fog, and dissolve keyword combinations — put roughly 194 shader programs through first-use uniform reflection at once, at about 3ms per uniform on WebKit versus about 0.1ms on Chrome. First cluster win on iOS: a three-second freeze.

The fix grew into a proper engine service. A shader warmup system stages prefabs under a hidden transform, moves it in front of the real camera for three frames during boot, and holds the webfront’s splash screen until every scheduled pass completes. Two details turned out to matter far more than the basic idea:

The warmup must produce the same pipeline state the gameplay draw will. Unity’s render pipeline picks shader variants from global lighting state at render time — how many additional lights, which cascades, fog on or off. Warm up too early, or in the wrong part of the scene, and you compile pristine variants of shaders the game will never use, then stall on the real ones anyway. So the service waits about a second for scene lighting to stabilize, and stages geometry at a gameplay anchor — the grid root — so warmup symbols sit in the same light volume as real ones and the pipeline resolves the same lighting keywords.
Each spawning system registers its own warmup. The win handler warms its popups (actually showing one so the text-outline keyword toggles), the dissolve effect warms its burn variant half-dissolved so both branches of the fragment shader execute, the boost manager warms its overlays. New engine systems warm themselves on startup, so the next game gets the coverage for free instead of maintaining a fragile central list.

Even that was not quite enough — per-prefab warmup does not cover the combination of states a real win produces. So the boot sequence ends with a fake spin: three real grid symbols play a full win-then-dissolve cycle behind the splash screen, with a warmup flag that turns the sound and web-event calls into no-ops so the webfront never knows it happened. The single most hazardous frame of the session — the first cluster win — gets pre-played where nobody can see it.

Safari had more lessons. WebGL caps fragment shaders at 16 texture units, and feature-rich toon shaders blow past it — Unity logs a link error but keeps rendering, silently dropping the shadow-receiving variant. Objects look fine and simply never show shadows, which took a while to stop blaming on light settings. Everything that needs to receive shadows now uses a minimal custom toon shader that binds three textures.

Fonts were their own saga. TextMesh Pro’s dynamic atlas mode — the convenient one, where glyphs rasterize on demand — calls FreeType, which is a null function pointer in a WebGL wasm build. Works perfectly in the editor, breaks in the browser. So every font in the game is a static SDF atlas with its glyphs pre-baked: currency symbols for every market baked into the Latin font, and the CJK fonts for localized bonus text baked down from 3–5 MB of raw font files to atlases of exactly the seventeen Chinese and fourteen Japanese characters the translation table actually uses, with the source font reference cut so the build drops the file entirely.

Free spins turn off the sun

Farm Pop’s bonus does not cut to a different scene — the same farm transitions from day to night in front of you. One environment controller lerps everything at once: directional light color and intensity, the ambient spherical-harmonics gradient, fog, the toon shader’s shadow tint, even per-symbol emission and outline colors so the pets stay readable in the dark. Then the night lights come on: lanterns, window glow, fireflies.

Nineteen point lights is a lot for WebGL, and the way it is affordable is an unusual renderer split: the project ships three render pipeline configurations — Forward for mobile, Forward+ for desktop, and deferred for the WebGL build, where many small lights are close to free. But the lights still caused the best bug of the project: a visible flicker on the ground plane whenever the wild symbol appeared. The wild dog carries a real light for its glow, and on the big ground plane it competed with all the night lights for per-object light slots — as the sorted list reshuffled each frame, the ground popped. The fix was rendering layers: the ground got its own layer, the nineteen night lights were excluded from it entirely, and only the wild’s glow light opts in. The non-obvious part is that light layers are a shader feature, not a free engine feature — our hand-written environment shader had to add the light-layers variant and test each light’s layer mask inside its own light loop before any of it worked.

Shadows got the same kind of platform-specific care: shadow distance doubled to 100 (the portrait camera pullback had pushed the camera past the old range, silently killing shadows on phones), and the WebGL renderer runs three cascades split so the middle cascade covers exactly the band of world the grid sits in — better effective shadow resolution with no increase in shadowmap size.

The multiplier patch that grows

One mechanic is pure Farm Pop: grid boosts. Cells accumulate “+N” multiplier levels as wins land on them, and each boosted cell grows a little ecosystem — a patch of grass that gains blades with every level (10 blades at +1, capped at 55) and butterflies whose color escalates through tiers as the number climbs. Blade positions are hashed from the cell’s world position, so every cell’s patch is unique but identical every time it regrows. The overlays are pooled like everything else, with an explicit teardown on return — an early bug had a level-9 overlay going back to the pool with fifty grass blades still attached, ready to reappear fully grown on some other cell’s +1.

It is a small system, but it is the game’s personality in miniature: a math-engine integer arriving over the bridge and becoming something that feels grown rather than displayed.

One engine, thinner games each time

Farm Pop is the first of the “Pop” series, and it shares its engine with the “Rush” runners — same web bridge, same pooling, same warmup service, same build hardening. The whole slot layer (grid manager, tumble choreography, anticipation, win presentation, overlay UI, day/night system, boost manager) lives in the shared engine. What is actually Farm Pop? Ten scripts, about 1,300 lines: the animator adapter, the farmer’s costume randomizer, the butterflies and grass, the wild dog’s glow. The next game — different animals, different theme — reuses everything else.

Even the 2D art pipeline leans on this. An editor tool renders the actual 3D symbol prefabs to transparent PNGs for the paytable and marketing — posing them mid-jump by sampling animation clips in edit mode, on an isolated layer with its own throwaway camera, no Play button involved. The paytable cannot drift from the game because the paytable is the game, photographed.

That was the bet with this architecture, and Farm Pop is the proof: the second game in a genre should mostly be art.

If you want to see the result, it is live: Farm Pop on Stake.

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

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

Raw Fun Gamer — Sun, 09 Aug 2026 00:00:00 +0000

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.