We had a working Keno that looked like someone else's product. Rebuilding it as a native part of our lineup taught me the difference between repainting a game and actually porting one.
The Keno I inherited was built as a clone of another operator's game. Navy and indigo palette, a left sidebar layout, a different type system. Nothing was broken. It just looked like a stranger sitting in our lobby, and players notice that faster than we like to admit: a game that doesn't match its siblings reads as third-party, and third-party reads as less accountable.
The obvious move is a restyle: open the CSS, swap the colors, ship it in a day. I've done that before and paid for it later. Every hex value stays hand-placed, so the game drifts out of sync with the lineup on the very next brand tweak, and you end up re-restyling forever. This time I wanted the port to be permanent.
The port ran on two rails, in order. First, anatomy. Our lineup shares a skeleton: the same header, the same bet controls, the same drawers for history and fairness, the same boot sequence. Keno adopted that shell before a single color changed. This is the part most restyles skip, and it's the part players actually feel. Someone who has played our Moles already knows where Keno's history lives, how the bet bar works, where to verify a round. Zero relearning.
Second, tokens. Instead of restyling elements one by one, every color in the clone was mapped to a token in our brand system. The game stopped having its own opinions about color. When the token set changes, Keno changes with it, automatically, along with every other game. Anatomy makes the game feel native to players; tokens make it stay native for the team.
A shell and tokens make the game correct. A few smaller decisions made it feel like it had always been ours. The game got its own generated wordmark and a branded boot screen with a progress bar, held to the same minimum duration as the rest of the lineup, because boot rhythm is part of a family identity too. Fast is good, but consistent is calmer.
Hits on the board are marked with a cut-gem shape and misses with red numbers, which sounds decorative until you state it as the rule it is: shape plus color, never color alone. And below 520 pixels the board switches to a compact mode, because ten picks on a 40-number grid have to stay comfortably tappable on a small phone, where most of our players actually are.
The sharpest finding of the port wasn't visual. For one type of free round, the game engine reports the total payout already net of the stake. The cloned client recomputed payouts on its own, so every one of those wins displayed a wrong number. The fix was a single rule that's now documented in the code and mirrored in our test mocks: display the engine's number verbatim, never re-derive money in the client. In a real-money game, two versions of the same number is the fastest way to lose a player for good.
The fairness layer got the same treatment as everything else: a deliberate one-to-one port of the lineup's per-round verification flow, down to a pure JavaScript hashing fallback so verification works even in contexts where the browser's crypto API doesn't. Parity was the point. A port that's 95% consistent is inconsistent.
The ported Keno went live with a real-money operator and has logged 23,000+ rounds from 340+ players so far, behaving indistinguishably from its native siblings, which was the entire brief. It's the smallest game in our lineup by volume and it might be the most important one to me, because it proved the system: a game built outside our world can be brought fully inside it, permanently, in one pass.
If you're facing the same job, my honest advice is to resist the repaint. Adopt the skeleton first, map to tokens second, hold the line on the invisible details, and treat any place where the game computes its own version of the truth as a bug. The skin is the easy part. Belonging is the deliverable.
Beka Jikurishvili