Why we built every VoltCade game from scratch

Almost every browser-arcade site you can find today is a portal. They're skinned wrappers around games licensed from third parties — sometimes hundreds of them, sometimes thousands. They earn money by squeezing ad calls between page loads, and they treat games as interchangeable inventory. Players know it, too: the games rarely get patched, leaderboards rarely matter, and the experience feels like a cheap download manager from the early 2000s.

VoltCade is the opposite of that. Every game on the site is original. Every line of every game was written for VoltCade. There are no licensed assets, no engine bundles, no ports of older work. We started this way for a few reasons that turned out to matter much more than we expected.

Reason one: the games can talk to each other

Because every game speaks the same VoltCade SDK — a tiny postMessage layer running between the game iframe and the host page — we can do things that aren't possible on a portal. Cross-game daily challenges. A capstone like Pulse Beat's "The 100" mode that themes its 10 acts after 10 other VoltCade games. Achievements that span multiple games. Streaks that count any game. None of that is feasible when your games are black boxes from third parties.

We didn't plan that capability up front. It emerged because every game shared a common surface and a common build pipeline, and once that was true, every new connection between games cost almost nothing.

Reason two: it's small enough to actually be fast

Browser game portals are notorious for taking forever to load. The games themselves are typically Unity or Construct exports running into multi-megabyte bundles, sandboxed inside cross-origin iframes that can't share assets. Each game is a fresh download.

Our games are vanilla JavaScript and Canvas2D. Most are under 200 KB. Art is drawn at runtime from primitives — rectangles, lines, gradients, the occasional SVG thumbnail — so there are no PNG sprites to download. The whole arcade is smaller than a single mid-sized mobile game, which means it works on slow networks and on devices that would choke on Unity WebGL exports.

Reason three: leaderboards stay honest

Anti-cheat is hard. It's harder when the game code is opaque and shipped from a vendor who doesn't care about your leaderboard. Because we control every game, we can wire each one to a signed session token, validate scores against a per-game maximum and minimum session length, and add behavioral signals to flag suspicious runs.

None of those defenses are bulletproof — a determined attacker can always go a layer deeper — but they make casual cheating far more effort than just playing the game well. That's the bar we wanted: leaderboards that feel like effort, not like an honor system.

Reason four: nothing breaks the rest of the site

Each game runs in a sandboxed iframe. A bug in Pulse Beat can't crash Drift Circuit. A memory leak in Hex Defense doesn't leak into the host page. We can hot-swap a single game — push a fix to one game.js file — without redeploying the platform. That's an underrated luxury when you ship ~100 update cycles.

What it cost

The honest tradeoff: building 17 games from scratch is a much slower path than licensing 1,700 of them. We'll never have the breadth of a portal. We can't cover every genre at every difficulty. New games take real engineering time, and they have to be good enough on their own that anyone would actually play them.

That tradeoff turns out to be fine. The site we're building isn't trying to be every arcade game ever made. It's trying to feel like one specific arcade — a place where the cabinets are hand-built, the high-score table is real, and someone is still in the back fixing the broken neon. If that's the kind of place you wish existed for browser games, you're probably the player we built it for.