DEV Community: Raw Fun Gaming

One Number, One Race: How Marble Derby Re-Runs Its Physics in Every Browser

Raw Fun Gamer — Sun, 08 Nov 2026 00:00:00 +0000

In Marble Derby, six glass marbles race down a tower of ramps, pegs and bowls, and the player backs one. Where it finishes, and what it collects on the way, decides the payout.

Marble Derby is a real-money game, so the result can’t come from a physics engine running on the player’s device. It comes from a pre-computed book of rounds, picked server-side. Here is a whole round, exactly as the book stores it:

{"seed": 1, "multiplier": 0, "perMarble": [{"rank": 3}, {"rank": 2}, {"rank": 4},
 {"rank": 5}, {"rank": 1}, {"rank": 0}], "duration": 56.192,
 "modules": ["stadium-loops", "pin-field", "bowl-cascade", "maze-or-fall", "pin-field",
 "cube-scatter", "stadium-loops", "switchback-maze", "rubber-gauntlet"],
 "rank": 3, "accrued": 2.070435, "pickupsCollected": 30}

There is no position in it. Not one. A book line averages 436 bytes. The 56-second race it describes, every bounce, every near miss and the photo finish, is rebuilt in the player’s browser from the first field: the seed.

That only works if the browser builds exactly the race the book generator built, on every device, forever. This post is about how we made that hold: why we chose to re-simulate rather than record, the rules that keep a physics engine bit-identical across JavaScript engines, what it took to make 2D marbles feel real, how we made sure every seed finishes, and how the game checks itself on every round.

Here is seed 1’s whole race, the one in that book line, at double speed, exactly as every browser rebuilds it:

Why we didn’t record the race

Every other burst game in our studio solves this problem the same way: record and replay. The physics runs once, free, in the Unity editor. A sweep records each round’s events and every actor’s position track into the book, and the client plays that recording back as kinematic “ghosts”. It works, the tooling already existed, and it was the obvious starting point.

We ran the numbers for six marbles and dropped it:

Book size. Six marbles sampled 10 times a second over a 45-second race is about 2,700 position samples per round. That is roughly ten times the per-round size of Spinblade Rush’s book, our most mature burst game, before multiplying by every mode.
Sweep time. A book needs 10,000 rounds per mode. Recorded in real time in Unity, that is about five days per mode, before any verification re-run. Every change to a track module or to the payout math would have cost a week.

The alternative was to write our own physics: a small, purpose-built 2D solver that is fully deterministic, so the same seed always produces the same race. The book then shrinks to “seed and result”, sweeps run headless in minutes, and the client re-runs the race instead of replaying it.

A tilted 2D board is the one track shape where this is tractable. Everything is circles against line segments and arcs, plus circle against circle. Six marbles, nine modules, fixed timestep.

The first plan had two copies of that solver: one in C# inside Unity to draw the race, one in TypeScript for the sweeps, with a cross-language test harness to keep them in step. Nine days in, we measured the alternative of drawing the race on a plain web canvas. The kernel plus the entire canvas renderer came to 14.6 kB gzipped against a multi-megabyte Unity WebGL build, so Unity went. There is now one kernel, in TypeScript, imported by the Node script that writes the books and by the game in the browser.

That made the problem smaller and sharper at the same time. There was no second language to keep in parity any more. But the books are generated in Node, on V8, and the race is replayed in whatever browser the player happens to use: V8 in Chrome, JavaScriptCore in Safari, SpiderMonkey in Firefox. A kernel that isn’t bit-identical across those engines would draw a race that contradicts the book that paid the player, on some devices and not on others.

The rules that keep every browser in step

Most floating-point code is “deterministic enough”: same inputs, nearly the same outputs. A race is chaotic. A marble grazing a peg one billionth of a unit further left can take the other side of it, and a minute later a different marble wins. So “nearly” is not enough. Every step has to produce the same bits on every engine.

These are the rules the kernel lives by, and why each one is there.

Doubles only, and only + - * / and sqrt. IEEE-754 requires these five operations to be correctly rounded: given the same inputs, every conforming engine must return the same bits. JavaScript numbers are doubles everywhere, so this one is nearly free.

No sin, cos, tan, exp, log or pow. This is the rule people find surprising. The ECMAScript spec allows those functions to be implementation-approximated, and engines really do differ in the last bit. Two browsers can legitimately return different answers for the same Math.sin call. One last-bit difference, compounded through a minute of collisions, is a different race.

So the kernel has no trig at all. Module rotations are baked into segment endpoints when the modules are authored, and arcs are handled with vector algebra. Where an angle is genuinely needed, it is drawn as a sine and the cosine is derived with sqrt. This is the start burst the backed marble gets in the Comet bet mode, a random direction within 30 degrees of straight down:

// Draw 4 (edge families only): burst within +-30 degrees of straight down.
const sin = (rng() * 2 - 1) * 0.5;
marbles[playerIndex].vx += cfg.edgeBurst * sin;
marbles[playerIndex].vy -= cfg.edgeBurst * Math.sqrt(1 - sin * sin);

A rule like this rots the first time someone reaches for Math.atan2 on a Friday afternoon, so a test enforces it. It reads every kernel source file, strips the comments, and fails on any banned member:

const BANNED_MATH_MEMBERS = [
    'sin', 'cos', 'tan', 'atan', 'asin', 'acos',
    'pow', 'exp', 'log', 'hypot', 'random', 'cbrt',
];
// Other banned globals: plain substring bans are enough here.
const BANNED_SUBSTRINGS = ['Object.keys', 'new Map', 'new Set'];

The first version of that test had holes, and its own review found them: Math['sin'], destructuring const { sin } = Math, and aliasing const M = Math all slipped through. It now catches each of those forms, and has a test of its own for every evasion.

A fixed collision order. Each step integrates every marble, then resolves marble-against-wall contacts, then marble-against-marble. The order inside each phase is part of the contract: walls by ascending segment index, marble pairs by ascending (i, j). Resolve two contacts in a different order and the marble ends the step somewhere slightly different. That is the classic “same seed, different race” bug.

That rule got tested for real when we sped the kernel up. Checking every marble against every segment of a nine-module board is wasteful, so we added a broadphase: the board is cut into horizontal bands, and a marble only looks at the segments in the bands it overlaps. A broadphase normally hands back candidates in whatever order its buckets hold them. Ours collects them and sorts them before resolving:

// 2. Statics, ascending segment index — now via the broadphase. Gather
// the marble's overlapping bands, sort, and skip duplicates, so the
// resolution order is identical to a full ascending scan.
candidates.sort((p, q) => p - q);

It shipped with two proofs: every race bit-identical to the brute-force version, and a test fixture of a marble wedged between two walls where the order genuinely changes the outcome, so the sort can’t quietly be deleted.

No hash-ordered containers. Iterating a Map or Object.keys is defined by insertion order in JavaScript, but it is an easy place for order to depend on something incidental. The kernel uses arrays and indices only, and the purity test bans the rest.

Our own random numbers, drawn in a fixed order. Math.random() can’t be seeded, so the kernel uses mulberry32, a tiny generator built from integer operations (Math.imul is exact, which is why it is the one other Math member allowed). One generator is seeded per race, and the draws happen in an order written into the source as a contract:

// DRAW ORDER IS A CONTRACT (spec §5):
// 1. module selection (assemble())
// 2. one op draw per pickup spot, board order (assemble())
// 3. per-marble launch impulse (here)
// 4. edge families only: one draw for the backed marble's start-burst angle
// (here, after the launch loop). Base and bonus consume no draw 4.

Insert a draw in the middle and every seed’s board and launch change, which invalidates every book. When the “edge” bet mode needed one more random number, it went at the end, after the launch impulses, and only that mode consumes it. The other modes’ races stayed bit-identical to what they were before the edge existed.

A fixed timestep. The simulation advances in steps of 1/120 of a second, always. Nothing in the kernel reads a clock or a frame time. The browser simulates the whole race the moment the seed arrives, which takes about 8 ms for a 48-second race in Node on a laptop, and then plays it back from the recorded track at whatever frame rate the device manages.

Making 2D marbles feel real

Determinism is the easy half to state. The hard half is that the race has to look like marbles, not like a simulation.

The first kernel resolved every contact as a bounce: reflect the normal velocity with restitution, scale the tangential velocity down by the surface’s friction. A marble on a ramp touches the ramp 30 to 60 times a second, so it lost a slice of its speed 30 to 60 times a second and could never build momentum. It crept.

We measured it on one module’s 0.5-slope ramp. A real ball rolling without slipping crosses it in about 2 seconds; acceleration down a slope is (5/7) g sinθ, because two sevenths of the pull goes into spinning the ball. The kernel took 15.5 seconds. Someone watching the viewer called the surfaces “sticky”.

Worse, the problem had been absorbed by three unrelated fixes, none of which named it: gravity had crept up from 9 to 10.9, one module had a bespoke low-friction material, and the pacing had been fitted around both.

The fix was a rolling-contact model, without adding spin to the kernel’s state. Each contact is classified by how fast the marble is moving into the surface:

Fast is a bounce, as before: reflect with restitution, apply the surface’s friction.
Slow is rolling: drop the normal velocity, apply a much smaller rolling friction, and take back 2/7 of the step’s gravity impulse along the surface. That reproduces a = (5/7) g sinθ from linear quantities alone, with nothing but + - * /.

Gravity went back to 9, the bespoke material went, and marbles got fast. Too fast: at the original six modules the median race fell to 31 seconds, with 39% of races under the 30-second floor. We could buy the time back with lower gravity or with a longer board. Over 400 seeds:

Gravity 4.6, 6 modules: median 44.1 s, 0.3% under 30 s, and marbles falling like they were on the Moon.
Gravity 9, 6 modules: median 31.1 s, 39.3% under 30 s.
Gravity 9, 9 modules: median 46.7 s, 0% under 30 s.

We kept honest gravity and made the board longer. Every board is nine modules.

One more detail matters for the “never twice the same” feel. Real marbles diverge because of microscopic surface variation, so the kernel adds a small seeded roughness at each bounce. Its first version could multiply the bounce’s speed by slightly more than 1, which manufactures energy. It is now 1 - rng() * noise, so roughness can only ever take speed away.

Every seed has to finish

A book is 10,000 races per mode, every one of them paid. A race where a marble gets stuck forever can’t be paid, can’t be replayed, and can’t be shipped. So every board the assembler can build has to deliver all six marbles, and we can’t check that by watching.

Each track module obeys a four-rule contract: a fixed inner width so the side rails run unbroken, flat full-width entry and exit edges so any module stacks under any other, a declared height, and guaranteed passable. The sweep checks the last one over every seed, and every way a marble found to stop became a rule. A few of them:

A closed cup traps marbles, and it isn’t the solver’s fault. We proved it by holding the geometry fixed and changing only the bounciness. Escape rates followed restitution and nothing else: 13% for wood, 67% for pegs, 92% for rubber, and 240 out of 240 with energy loss turned off. So bowls are open hooks with a 150° gap facing down, never closed cups.
A dead-flat facet on a curve. Arcs are drawn as short straight chords. A span symmetric about vertical put a horizontal chord at the bottom for odd chord counts, and 2,000 out of 2,000 releases stopped on it.
A nearly flat facet stops a marble too. Gravity sinks a marble a hair into a shallow facet each step, which creates a second contact on the steeper chord next to it, and the two responses cancel. We found the cliff by releasing 25,001 marbles per angle: below 3.72° marbles stop, above it they roll. The library’s floor is now 10% above the cliff, derived from the kernel’s own dt, gravity and radius, so a config change that moves the cliff fails a test.
Two walls can freeze a marble bit-for-bit. At a concave corner, pushing a marble out of one wall pushed it into the other, and back. One marble sat frozen, identical to the last bit, for over 900 steps. The fix was to detect every contact against the same state, combine them, and apply them once.
Spaces that look dead aren’t. A pocket closed above but open below is reachable from underneath: marbles bounce back up into it from the module below. Those spaces get explicit floors.

Finding these needs a stall detector, and the first one was wrong in both directions. It asked whether any racing marble had set a new depth record recently. It declared a race dead while a rubber-launched marble was in free flight at nearly 7 m/s (it finished 0.76 s later), and it missed a genuinely pinned marble for 42 seconds because other marbles were still making progress. The current one tracks each marble on its own: a marble is held while it stays within one radius of where it was, and the race is stalled when the least-held racing marble has been held too long. A trapped marble wanders 0.008 units; a false alarm covers five.

The finish has to be physical too

The race doesn’t end at a line. A funnel hangs under the last module, a wide catch narrowing into a single-file channel, and every marble drops in and stays there. A marble is ranked the instant it passes the throat, and the channel is too narrow for one marble to pass another below that point. So the order the marbles come to rest in is the order that was paid, and the sweep checks exactly that for every race.

When the player’s marble crosses the throat within a whisker of a marble whose place pays differently, the playback drops to slow motion. It only stretches the reveal: the order was settled the moment each marble passed the throat.

Real physics means uneven lanes

A real-physics race has a consequence a scripted one doesn’t. Marble 1 always starts in lane 1, and the modules aren’t perfectly symmetric, so some lanes do better than others. Across a sweep, the rightmost marble wins about 22–23% of races and lane 2 about 13%.

We could have hidden that with a random start shuffle, or tried to tune the asymmetry out of twenty modules. We did neither: the six marbles really do race differently, and that is part of their character. What can’t differ is the return, so each lane gets its own book. In the plain modes the same 10,000 races are simply read from each marble’s point of view (in the edge mode the edge changes the race, so each lane has its own), and each book’s weights are fitted so every lane returns the same 96.5%. The physics stays honest, and so does the payout.

Trust, but check every round

All of this is designed to hold. The game still checks that it does, on every round.

When a round’s book line arrives, the browser simulates the seed and compares the race it built with the line that paid:

the rank , the multiplier and the number of pickups must match exactly;
the duration must match within a millisecond;
the accrued multiplier must match within one millionth.

Any mismatch is logged loudly as KERNEL PARITY BROKEN, and the round still pays the book’s number and completes: the book is authoritative for money, the kernel only decides what is seen. A rank, multiplier or pickup mismatch also skips the animation entirely. The funnel’s resting order is the visible ranking, so playing a diverged race would show the player an order the book didn’t pay.

The first version broke on every round, and the bug is worth passing on. The book also stores payoutMultiplier, which is the multiplier times 100, rounded, for the payment system. We compared against it, and it never matched. The check now reads the raw multiplier, and our notes carry the warning.

One more: production builds normally strip console calls. We drop only debugger. Those console.error lines are the detector; stripping them would make a broken contract invisible.

The runtime check catches a divergence when it happens. To stop one being introduced, the kernel has a regression pin: kernel-vectors.json, checked in every test run. It holds:

56 micro vectors: single collisions. Five surface angles from flat to near-vertical, crossed with a bounce, rolling, receding contacts and a clean miss. They catch a changed formula.
4 fold vectors: the pickup arithmetic on its own, where order matters, because (1 + 2) × 3 isn’t 1 × 3 + 2.
210 macro races: complete races across all three bet modes, each pinned by finish order, multiplier, pickups, duration and a hash of every marble’s position once a second. They catch drift that builds up over a minute.

Any change that moves a race fails the vectors before it can reach a book.

What it bought us

A tiny book. 436 bytes a round on average, with no position data at all.
Fast iteration. Re-sweeping a mode after a module change takes minutes, not days, so the physics and the math could be tuned together.
One source of truth. The race the player watches is the race the book was generated from, rebuilt from one number, on whatever browser they use.

The price was discipline. No trig, a sort that looks redundant, a draw order nobody may reorder, and a test that greps the kernel for Math.sin. For a race decided by a billionth of a unit, that turned out to be cheap.

Faking 3D With 2D Lines: How Marble Derby Draws Its Board From the Physics

Raw Fun Gamer — Sun, 08 Nov 2026 00:00:00 +0000

Marble Derby is six glass marbles racing down a tall tower of ramps, bowls, pegs and zigzag channels. On screen the tower looks built: pastel slabs with a lit top and a shaded side, walls you can see the thickness of, plates standing out from the board. None of that exists in the physics. The simulation that decides every race knows two things: discs, and line segments with no thickness at all.

This post is about how we get from one to the other. It covers the single rule the whole art layer hangs on, the projection that turns a line into a slab, the offline bake that decides how thick each slab may be, the joint problems that took most of the work, how we measured that the art never lies about where a marble is, and the marbles themselves. Along the way are the fixes that looked right and weren’t.

The rule: draw the physics, not a picture of it

Marble Derby’s race is simulated by a small deterministic kernel in TypeScript. The same code builds the books on the server side and replays the race in the player’s browser from a seed, so the race you watch is, step for step, the race that was paid. That kernel models a marble as a disc of radius 0.28 and every surface as a segment: two endpoints, nothing else. A ramp is a segment. A peg is a short segment. A bowl is a ring of short segments.

We could have drawn the board as separate art: sprites or meshes laid over the physics and lined up by hand. Every game that does that eventually ships a marble that rolls along a ledge half a pixel above the drawn ledge, or through the corner of a wall. With twenty board modules assembled in a different order every race, that was not a risk we wanted to manage forever.

So the renderer draws the kernel’s own segments. There are no prefabs, no meshes and no hand-placed geometry. If a segment moves in the physics, the art moves with it, because the art is built from it at load time.

That rule creates the whole problem. A segment has no thickness. To look solid, it has to be given some, and that thickness has to go somewhere. If it goes on the wrong side, or is too deep, a marble rolling on the segment gets drawn inside the wall. So for every segment the renderer needs two answers:

Which side is solid? The side marbles never touch.
How thick may it be there? Up to wherever a marble came close.

The segment list can’t answer either, and the kernel is off limits: it is a pure function of seed and mode, and the art may never touch it. The answers come from somewhere else, which we’ll get to after the projection.

The projection: one vector

The 3D look is a fixed oblique projection. Everything recedes along one vector, up and to the right:

/** Oblique depth, view units: up and to the right. Also sets the light. */
export const DEPTH: readonly [number, number] = [0.3, -0.24];

There’s no camera matrix, perspective or z-buffer. The camera is effectively above and to the right of the board, so it sees every surface that faces up or to the right, and none that face down or left. That one sentence turned out to be the most useful rule in the whole layer; more on it later.

Each segment that has a solid side is drawn as a slab:

A front band : its cross-section in the board plane, from the line itself to its depth on the solid side, in two tones as a cheap gradient.
Receding faces : each edge that faces along DEPTH is swept back along it into a parallelogram. That’s the lit top of a ramp, the right-hand face of a wall.

A segment that marbles touch on both sides (a pin, a divider) has no solid side, so it can’t be a slab. It’s drawn as a thin plate : a strip 0.04 either side of the line, swept back as a box.

Painting is two layers: every receding face, then every front face. The faces are built once per board, not per frame. Each frame draws only the horizontal bands of the tower that are on screen, from an index built at load.

The bake: asking 3,000 races where the marbles went

If the kernel can’t say which side of a segment is solid, the races can. A marble that rolls on a ramp’s top side, thousands of times, tells you the top is open air and the underside can be solid. A marble that comes within 0.1 of the underside tells you exactly how thick that slab may be at that point.

So an offline script, npm run bake:art, simulates 1,000 races in each bet family (3,000 races when the board art was last baked) and records every marble sample near every segment of every module. It writes the result to a JSON file the renderer loads. Two passes:

Sides. Count contacts on each side of each segment. One side only: that’s the open side, the other is solid. Both sides, with the minority side above 0.5% of contacts: two-sided, drawn as a plate. Neither: untouched.
Depth. At stations every 0.5 units along the segment, find how close any marble disc came to the solid side. Subtract the radius and a 0.02 margin. That is the room at that station, and the slab’s depth there is the room clamped to between 0.04 and 0.38.

Seeds 1 to 1,000 are the bake’s. Seeds 1,001 to 1,100 are never baked, so the result can be measured honestly on races it has never seen (below). The bake script refuses to run past seed 1,000 for exactly that reason.

That’s the idea, and the first version was little more than that. The rest of the work was everything a list of segments doesn’t know about.

Sides need context

Contact counts lie at tips. A marble rounding the free end of a ramp touches its far side for a moment. Counted naively, half the ramps in the game came out two-sided and turned into thin plates. That’s why the threshold exists: under 0.5% of contacts on the minority side, it’s a marble wrapping a tip, and the majority side wins.

Identical props must match. A peg field is forty copies of the same plate. If marbles happen to brush one copy’s back and not the others, one plate in forty comes out different, and it shows. So copies share a code: if any copy is two-sided, all are. The subtle part is what counts as a copy. Our first attempt matched segments one at a time, and a wall’s top stub inherited “two-sided” from the bottom stub of a different wall that happened to be the same length. A copy now has to be the same segment of a copy of the whole prop , matched within 1e-4 with the same winding.

We also first found copies by turning coordinates into string keys after rounding. One copy’s coordinate rounded to 10200 and its exact twin’s to 10199. Matching within a tolerance is right; rounding never is.

Untouched isn’t unknown. A bowl that marbles bypass has no contacts on half its segments. Left alone, the untouched half had no solid side and the bowl broke in two. Untouched segments now take the side of the segment they carry on from, around the shape’s winding, so the bowl keeps its solid side all the way round.

Depth needs smoothing, then simplifying

Raw clearance is noisy. One marble that clipped a ledge on one race in 3,000 would pinch that ledge to a sliver, and every copy of it with it. The rules that came out of that, in the order the bake applies them:

Ignore the single closest race. A station’s room is the second-closest race, not the closest. Ignoring three races was tried; it thinned fewer props, but frames with a big overlap went from 10 to 27 in the measurement below.
Taper slowly. Depth may rise at most 0.5 per unit of length away from a thin station, so a slab tapers instead of stepping:
Profile whole shapes. Consecutive segments of one wall are profiled as one line, so depth flows round a curve with no step at a joint. Mirrored or translated copies share the thinnest profile of all of them.
No lumps. A lone ledge may thin toward one end but never thin, thick, thin again (monotone). A multi-segment shape may taper to its tips but never pinch mid-way and swell again (unimodal), which read as a break.
Straight edges. Every segment’s slab gets one straight outer edge: the deepest constant or linear wedge that fits under its profile.

Step 5 was a design call, not a geometry one. After steps 1 to 4, the slabs followed the marbles’ paths beautifully, with gentle curves and waists. They also looked bent and broken. The verdict was plain straight boards, and that turned out to be right: a segment that has to be thin somewhere is usually best thin all along.

Joints: where 2D-to-3D breaks

Almost every visible defect we fixed was at a joint. A single slab is easy. Two slabs meeting at an angle each extend their bands past the corner and poke through each other’s faces, and the projection makes every such overlap obvious.

Inside bends clip. Where two slabs meet with their solid sides facing into the corner, each one is clipped by its neighbour’s wall line. That’s one Sutherland-Hodgman pass, and it’s shared by the renderer and the bake, so the bake measures exactly the slab that will be drawn:

export function clipToSolid(pts: number[], px: number, py: number, nx: number, ny: number): number[] {
    const out: number[] = [];
    const n = pts.length / 2;
    const side = (i: number) => (pts[i * 2] - px) * nx + (pts[i * 2 + 1] - py) * ny;
    for (let i = 0; i < n; i++) {
        const j = (i + 1) % n;
        const si = side(i);
        const sj = side(j);
        if (si <= 0) out.push(pts[i * 2], pts[i * 2 + 1]);
        if ((si < 0 && sj > 0) || (si > 0 && sj < 0)) {
            const t = si / (si - sj);
            out.push(pts[i * 2] + (pts[j * 2] - pts[i * 2]) * t, pts[i * 2 + 1] + (pts[j * 2 + 1] - pts[i * 2 + 1]) * t);
        }
    }
    return out;
}

Clipping alone left square ends lying across each other. The bands are now mitred like a picture frame : both end on one cut line from the joint through the points where their edges cross at each fraction of depth.

Before clipping existed, we used a bisector mitre. It fixed long zigzags and failed on short “teeth”, where the mitre point ran out past the end of the segment. Every acute zigzag corner pinched to the 0.04 minimum.

Free ends are chamfered. A hook’s tip, touching nothing, used to end square, and its back corner jutted past the tip. It’s now cut at 45 degrees back from the tip. On a leg too short for that cut, it runs straight to the other end’s corner instead of leaving a jog.

Plates and slabs are different materials. A slab whose end lies on a free-standing divider stops at the divider’s near face, so the divider covers its end. A plate hung off a slab’s side, like a hook’s leg, is part of the same sheet and is mitred to it instead. We tried the picture-frame cut for the divider case too. It opened sky-coloured triangles, because the plate is 0.08 deep and the slab 0.38, and a mitre between two very different depths leaves a gap.

Two-sided walls were round-capped strokes at first: easy, and they never overlapped anything. They also read as a 2D pen line drawn over a 3D board. Thin plates with square ends replaced them.

The rails bound everything. Every slab is clipped at the side rails’ inner faces, so a diagonal meeting a rail ends under it along a vertical line, rather than its square end lying across the rail.

Which faces the camera sees

For a while, slabs only drew the receding face on their marble side. A channel’s right-hand wall, seen from a camera above and to the right, should obviously show its right face, and didn’t. A fix that drew the solid side’s receding face too made channel walls sprout pale panels across their corridors, so we limited it to thin slabs.

The panels turned out to be a joint bug, not the rule. Receding faces at a joint were being matched to the neighbour’s faces by which way they faced. They should be matched by which hand each face is on when you travel through the joint. A corner search was also capped short of the band’s mitre. Once that was fixed, the limit came out, and the rule became the plain sentence from the projection section: the camera sees every top and right face.

Painting order is depth, not kind

With only two layers, faces within a layer still overlap, and the order decides which one wins. The first rule sorted by kind: sideways faces before upward ones, so a ramp’s top covers the rail it hangs from. It failed for boards ending on the far side of a divider, whose tops were painted over the divider’s face.

Receding faces now keep their source line and which way they face. Where two overlap on screen, the one whose source line lies behind the other’s plane is drawn first:

// Is all of b's source line behind a's plane?
const behind = (a: number[], b: number[]) => {
    const d = [0, 2].map((i) => (b[i] - a[0]) * a[4] + (b[i + 1] - a[1]) * a[5]);
    return Math.max(...d) <= 1e-6 && Math.min(...d) < -1e-6;
};

That gives a partial order; a topological sort over it does the rest. The old kind-based sort is still there as the starting order and as the fallback if the overlaps ever form a cycle.

Measuring that the art doesn’t lie

Rules like these are easy to get subtly wrong, and wrong here means a marble drawn inside a wall. So there’s a measurement, run on demand: it replays the out-of-sample races (seeds 1,001 to 1,100, in all three bet families), takes every second 120 Hz frame, and measures how far each marble’s disc overlaps any front face. It also reports the worst segments by name, which is how most of the joint fixes were aimed.

The current numbers:

Overlap over 0.05: 86 of 5.02 million marble-frames (0.0017%), in 19 of 1,800 marble-races.
Overlap over 0.14: 25 frames, all in one race.

For scale, the marble’s radius is 0.28. The very first version, every slab a uniform 0.38 deep, overlapped by more than 0.05 on 1.66% of all frames and in 91% of races: nearly every marble, at some point, drawn inside something.

A unit test guards the other direction, in sample: it fails if any front face covers a marble’s centre on the bake’s own seeds. That catches a broken bake before anyone looks at a screenshot.

Trade-offs, priced

Some art choices cost overlap, and some looked better anyway. Those were priced on the bake’s own races (51 million marble-frames) and decided by a person, not by the number. One example was the hooked end of the spiral bowl:

A , a thin last plate: no cost, but it read as a separate piece glued on.
B , an even taper across the tip and its slab: 36 more frames over 0.05, and 5 more over 0.14.
C , a full wedge: 89 more frames over 0.05, and 20 more over 0.14.

B was chosen, and became a rule: a short tip whose clearance can’t take a full wedge tapers across its slab too.

How the defects were found

None of these rules came from a design document. They came from about ten days of someone looking at the board and pointing at what was wrong, usually with a screenshot and a red scribble, and from the code changes that answered each one. Much of that code was written by Claude, working from coordinates. An AI editing a renderer can’t see what it draws, so most of the tooling exists to close that loop:

A contact sheet. npm run art:sheet renders every module alone, between its rails, with headless Chrome: an overview, plus one image per module, named by number and id (19-bowl-bypass.png). The file names became the shared vocabulary for every review.
Geometry at 4x. A sheet URL renders one module four times larger, so a joint is judged as shapes, not antialiased pixels.
Pixel to polygon. To find what drew a wrong pixel, map it back to board coordinates and list every face whose polygon contains it, each tagged with the segment it came from.
Every fix, across the whole library. A bake rule or a joint rule is library-wide, and so is its damage. Each change was diffed before and after across all twenty modules. Several fixes caught their own regressions in modules nobody had mentioned. The diff threshold mattered: pale top faces sit within about 10 levels of the sky, so a threshold of 12 silently hid changes there; it’s 3.
A stated camera model. One sentence from the reviewer, that the camera sits top right and should see the top and right faces of every plate, turned several local patches into one rule that held across every module.
The checklist as a skill. Every defect class the reviewer caught became a line in a review checklist that loads whenever the art changes, so the same mistake doesn’t need catching twice.

Night, for free

Because every face is built from geometry and coloured from a palette, a second look costs almost nothing. Face colour follows depth down the tower from dawn to dusk, by palette lookup, and long segments are drawn in pieces so a rail shades along its length instead of taking one mid-board colour. The Starlight mode uses a second palette, dusk into deep night with stars, through the same code:

The marbles

The marbles are fakes too, and cheaper ones. Each is a filled circle with a radial gradient whose bright point sits up and to the left, matching the board’s light:

const g = ctx.createRadialGradient(x - r * 0.35, y - r * 0.4, r * 0.05, x, y, r * 1.15);
g.addColorStop(0, mixHex(colour, '#ffffff', 0.6));
g.addColorStop(0.4, colour);
g.addColorStop(1, mixHex(colour, '#20103a', 0.45));

Building a gradient per marble per frame is wasteful, so the sphere is pre-rendered once per colour and per 2-pixel radius bucket (the zoom eases continuously, so exact radii would never repeat) and drawn as a sprite.

A plain sphere doesn’t look like it rolls. It looks like it slides. The fix is a contrast: a faint swirl inside the marble rotates by the marble’s real roll angle (horizontal travel divided by radius, accumulated along its track), while the white highlight on top stays put. The eye reads a pattern turning under a fixed reflection as a ball rolling.

The same split carries the rank skins players unlock on the stats page. Each skin is a pattern (cat’s-eye vanes, a swirl, onionskin streaks, agate bands) drawn in the marble’s own lane colour and clipped to the disc, rotated by the roll, then covered by one shared layer of shading and the fixed highlight. Colour is what tells the six marbles apart, so a skin may change the pattern but never the hue. Steelie is the one exception to rotating: it’s chrome, which reflects the room rather than turning with the ball, so its horizon band stays level.

What we’d keep

Derive the art from the simulation, and measure the difference. Once the drawn surface is the physics surface, the only remaining question is thickness, and thickness can be measured from real races.
Bake on one set of seeds, measure on another. Without the held-out seeds, every tweak would have looked like an improvement.
Most of 3D is joints. A single extruded line took an afternoon. The joints took ten days.
Plain beats clever. Straight boards over measured curves, square plates over round caps, a stated camera model over a pile of special cases.
Price the trade-offs, then let a person choose. Overlap numbers say what a choice costs, not whether it’s worth it.

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.