BE AWESOME
Settings
Dev Notes
📅 September 4, 2026 · ⏱️ 5 min read

One Shell for 27+ Games, Proven Small Before Going Everywhere

The shared architecture started quietly on one or two games back in August — today it becomes the foundation for the entire catalog.

This post is about One Shell for 27+ Games, Proven Small Before Going Everywhere
Browse the Games Catalog →

Every game on the site now shares one template architecture — the boot sequence, the box model, the leaderboard widget, the vote widget, the related-games sidebar, all coming from one shared shell instead of each game hand-rolling its own version of the same surrounding chrome. This didn't happen all at once. The shell itself started small back on August 11, quietly, on just one or two games, and only became "the" architecture for all 27-plus games with today's push to roll it out everywhere.

Why the shell had to prove itself small before going everywhere

Rolling out a shared architecture across every single game on day one, before it had actually been tested against a real, working game in production, would have meant discovering its design flaws simultaneously across the entire catalog instead of in one contained, low-risk spot. Letting it live quietly on a small number of games for a few weeks first meant any awkward assumption baked into the original design — a fullscreen edge case, an unexpected interaction with a specific game's own custom UI — surfaced somewhere small and fixable before I ever asked every other game to depend on the same foundation. That patience is most of why today's full rollout across dozens of games went as smoothly as it did.

Extracting shared chrome from games that were never built to share it

The genuinely hard part of today's work wasn't building the shell itself, it was migrating dozens of existing games that were each built independently, on different days, with their own slightly different approaches to fullscreen handling, their own bespoke leaderboard markup, their own one-off sidebar implementations. Retrofitting a shared shell onto code that was never written with sharing in mind meant carefully identifying what was genuinely common chrome versus what was actually game-specific logic that happened to live near the chrome, without accidentally deleting or breaking behavior a specific game quietly depended on that I'd forgotten was there.

Testing a migration like this means checking dozens of games, not one

A normal feature launch means testing one new thing carefully. This migration meant re-testing dozens of already-shipped, already-working games to confirm none of them regressed silently in the process of moving onto shared chrome. That's a fundamentally different, more tedious kind of verification — not "does the new thing work," but "did I just break something that was already fine yesterday." I went through every migrated game individually rather than spot-checking a representative handful, specifically because a shell this foundational failing quietly on even one game would undermine confidence in the whole migration, not just that one game.

A single fullscreen and cinema-mode implementation, not dozens

Fullscreen toggling and the "lights off" cinema focus mode used to be something I'd reimplement, with small inconsistencies, every time a new game needed them. Consolidating both into the shared shell means every game gets identical, correctly-behaving fullscreen and cinema mode for free, and fixing a bug in either one now means fixing it exactly once instead of hunting down which of dozens of slightly different implementations actually has the bug this time. That's the real payoff of this refactor — not a new feature visible to a player, but a collapse in how many places a given class of bug could be hiding.

The shell had to stay flexible enough for genuinely different games

A shared shell risks becoming a straitjacket the moment a game needs something the shell didn't anticipate — a different frame class, extra attributes on the game frame element, a custom style block a specific game's presentation genuinely requires. I built in explicit extension points rather than assuming every game would fit the exact same mold with zero variation, since the alternative was either rejecting legitimate per-game customization outright or letting individual games quietly bypass the shell entirely the moment it got in their way, which would have undone the entire point of unifying the architecture in the first place.

Vote and leaderboard widgets became genuinely shared components, not copies

Before today, a game's vote widget or leaderboard panel was effectively its own hand-copied version of a pattern I'd built for an earlier game, pasted and lightly adapted rather than genuinely shared. That's the kind of duplication that quietly drifts apart over time — a small improvement made to one game's leaderboard widget would never automatically reach the copy living in a different game's template unless I remembered to manually port it everywhere. Making these actual shared includes, referenced once from the shell rather than duplicated per game, means an improvement to how leaderboards render now reaches every single game simultaneously the moment it's made, instead of only the one game I happened to be working on when I thought of it.

What almost-30 games sharing one shell actually buys going forward

The real payoff of today isn't visible in any single game — it's that every future game now inherits a working boot sequence, leaderboard widget, and sidebar automatically, for free, on day one, instead of each new game needing its own chrome built from scratch the way every game up to this point has. That changes the actual cost of shipping a new game going forward, and three months from now, when a new game takes noticeably less time to reach a polished, complete-feeling state than an old one did, this is the refactor that quietly made that possible.

I'll admit this kind of work is the least satisfying to actually sit down and do. There's no new game to point at afterward, no new mechanic to show off — just dozens of existing games behaving exactly as they did yesterday, now built on cleaner foundations underneath. It's also exactly the kind of work that makes every future release faster and every future bug fix apply everywhere at once, which is a trade I'd make again without hesitation even though nobody playing the site today will notice anything changed at all, which is, in its own way, exactly the point of doing it well.

Hello!