Building Up The Company's Portfolio
A catalogue of 30+ HTML5 table, card, roulette and racing titles where the core rules cannot change. Variation had to come from modular features, bonus systems and mathematically controlled outcomes, without ever leaving the return-to-player target.
Designing games with fixed rules that need to feel different from each other
Design and deliver a scalable system for developing multiple casino-style games, where the core rules remain fixed but gameplay variation is introduced through modular features, bonus systems and mathematically controlled outcomes.
The goal was to create distinct player experiences across many titles, while holding fairness, balance and production efficiency constant.
Differentiating games with fixed rules
The rules are fixed by the genre, so how does one title become different from the next?
By weighing where to adjust in the math formula. Adjusted lower base bet payouts and introducing bonus payouts that would exceed expected value and can land in any session. It raises volatility, but it gives each betting round something to anticipate, which is what the base game cannot supply on its own.
Virtual racing products largely look alike. How do you make one stand apart?
Find inspiration in unconventional races, try out treadmill racing and marble racing. Races are simulated in Unity and designed to produce close calls, thousands of such simulated videos are generated containing a different arrangement and winning combination each time.
Marble Knockout
Marble Knockout brings a video trend into the casino genre. Structured like a casino racing product, it runs four coloured teams and sixteen marbles in a survival race. A full round lasts 120 seconds, including a 20-second betting window before the race. Every betting option sits inside a theoretically targeted RTP model.
Goals
- Break a new theme into the casino racing market.
- Keep betting options familiar against existing racing games, so players are not relearning a bet menu.
- Allow interchangeable future iterations, from the marbles themselves through to track assets.
The track could not be built first and priced later. Track design and economy design had to be built against each other.
Main challenges
- What kind of track should be built, and how does each race stay exciting across it?
- Technical constraints meant the game could not generate races in real time during live operations. So how does every race outcome shown still read as random and exciting?
Gathered research on marble race videos and similar products, to understand the feel of a typical marble race. Those insights shaped the direction the product took.
- Each race needs to feel like a survival race and finish in under 100 seconds.
- There must be a clear, visible reason why some marbles survive and others do not.
- How heavily or lightly eliminated each race should be is a tuning decision, not an accident.
- Track design and economy design could not be sequential. They had to be built against each other.
Modular track design
Built and tested modular track types for pacing, visuals and visibility, and settled on a modular straight track. A straight downward track gives constant acceleration, propelling the marbles from start to finish.
To influence pacing and eliminations, I defined a set of block categories: Normal, Slow, Very Slow and Killers (Fast). Each holds several named obstacle types, assembled into a full race from a sequence definition. New track variety then comes from recombining and re-sequencing existing blocks, rather than hand-building a specific track every time.
Each category carries positional sub-variants, the same obstacle type placed or shaped differently, so the block library produces visual variety without new assets.
Block obstacle types
All obstacle types are modular. Once the sequence is chosen, the set draws from a library of obstacles designed to contribute different kinds of variance: slowing and separating obstacles, static dividers that funnel marbles through fixed paths, rotating and spinning blockers that redistribute position, and elimination-driving obstacles such as swingers, pushers and drop pockets, concentrated towards the back half of the race.
Racetrack sequence and pacing
Track sequences come in sets, each determining a variant of pacing rhythm. The sequence orchestrates what happens at each part of the race, and keeps every race finishing inside the timeframe.
- Sequence 1 runs a slower pace but carries more eliminating obstacle types, pushing marbles off the race to build tension moments throughout.
- Sequence 2 runs a more chaotic fast-slow pattern, for a high-speed, high-octane race.
The checkpoint mechanic
Two checkpoints sit along the track. Once the first marble arrives, a short countdown starts, and any marble not at the checkpoint when it expires is removed from the race.
The mechanic does two jobs at once. It clears marbles that are too slow or too far apart, and it shuffles a one-sided race back to common ground.
The survivor rate at the finish was an explicit target the pacing curve was built to hit, not a side effect of obstacle placement. The track sets a targeted survivor rate with its variance and volatility controlled to a degree. The rest is tuned from the economy model, cherry-picked against tracking metrics such as survival count and near-miss winners, so it meets the right survivor rate and a visually pleasant pace.
The economy model
The bet menu needed to support twenty distinct bet types. Rather than pricing each one by hand, all twenty derive from a single model.
- Built a fair, full combinatorial model of race outcomes across all sixteen marbles, deriving exact survival probabilities for every colour at every survival threshold.
- Used that model to determine an achievable size for the pool of outcome videos, which produced the final adjusted probability for each.
- Extended that probability base out to the available bet options.
- Solved payouts from the probabilities against the expected RTP target.
- Calculated a bonus payout against the remaining RTP and checked it lands inside the target, rather than assuming it scales linearly with the base paytable. It resolved to a 2x bonus payout.
The visible race outcome is drawn from a pre-rendered pool of outcome videos rather than simulated live each round, so the probability model had to drive content selection directly. Each outcome in the model maps to a matching video, weighted so the pool's outcome distribution matches the target curve.
Volatility and the overall model were then validated through a 10 million round simulation with the backend before the paytable was locked, catching rounding and edge-case discrepancies.
The probability derivations and target RTP figures are the client's IP and are not reproduced here. What is shown is the modelling approach itself: how a twenty-option bet menu gets built from one unified probability model instead of twenty ad hoc guesses, how a bonus mode gets validated rather than assumed, and how that model gets pressure-tested before it goes live.
What this project taught
Constraints are the differentiator
When the rules are fixed by the genre and the maths is fixed by the RTP target, the only room left is structure: what the bonus does, how volatile the session feels, and what the player gets to anticipate.
Model once, price everything
Twenty bet types priced independently is twenty chances to be wrong. One combinatorial model that every option derives from is a single thing to verify, and it makes the bonus payout a solved number instead of an assumption.
Pacing is a target, not an outcome
Survivor rate was designed for, then tuned against tracking metrics. Treating the visual drama and the economy as one problem is what let a pre-rendered video pool still feel like a live race.
