I built the same retro gaming platform two ways: WebRTC and WebAssembly

The Nicholas 035 — Thu, 23 Jul 2026 18:34:18 +0000

What I learned from building two editions of PIXELATED—one that streams games through WebRTC and one that runs them directly in the browser with WebAssembly.

I started PIXELATED with a fairly ambitious idea: what if a browser could be the front door to a retro gaming platform, while the actual game ran somewhere else?

That became PIXELATED Studio, a project built around a desktop engine, Docker, and WebRTC streaming. The browser handles the interface and sends controls; the engine runs the emulator and streams the result back.

It worked, but it also raised an obvious question:

For small 8-bit games, do I actually need the streaming layer at all?

That question eventually became a second project: PIXELATED User Edition, where compatible games run directly inside the browser through WebAssembly.

The two editions now share a catalog and much of the same product experience, but they take completely different paths from clicking Play to seeing the first frame. Building both has been a useful lesson in architecture, product boundaries, and the fact that “faster” does not always mean the same thing.

One idea, two editions

The easiest way to explain the split is this:

PIXELATED Studio treats the browser as a client for a separate game engine.
PIXELATED User Edition turns the browser into the game engine.

In Studio, the desktop application manages a local Docker runtime. That runtime launches the emulator, captures its video and audio, creates a WebRTC session, and accepts controls sent back by the browser.

In User Edition, a Libretro emulator core is compiled to WebAssembly and loaded on demand. The ROM is verified and passed to the core, then the browser renders the game locally to a canvas. There is no desktop application, Docker container, video encoder, or WebRTC media path involved.

Studio version diagram

PIXELATED Studio: the system-oriented version

Studio is the version I use when I want to explore the infrastructure around remote and local game streaming.

The packaged desktop app manages the engine lifecycle, including Docker checks, runtime startup, health polling, and secure browser pairing. Once paired, the web app can ask the engine to boot an approved catalog game or a ROM from the user's Local Vault.

Some of the more interesting Studio features are:

WebRTC video, audio, and input transport
Local and LAN engine pairing
A persistent Local Vault backed by the engine's Docker volume
Multiplayer lobbies with player slots and spectators
Stream-quality profiles, fullscreen play, audio controls, and keyboard remapping
Creator submissions, browser-compatibility checks, and admin review tools
Favorites, comments, reactions, reports, and moderation
Opt-in stream telemetry and exportable research bundles

Studio is more complicated to install and operate, but that complexity buys it flexibility. The browser does not need to emulate the target system itself, and the engine can eventually support runtimes that would be unrealistic inside a normal web page.

The tradeoff is that every extra stage can affect startup time, reliability, and perceived responsiveness. The engine must start, the emulator must boot, signaling must complete, the media pipeline must become ready, and the browser must receive and display a usable frame.

Inside the desktop engine

Gameplay with telemetry

PIXELATED User Edition: the low-friction version

User Edition exists because NES, Game Boy, and Game Boy Color games are small enough that modern browsers can run them very well without streaming.

The first supported cores are FCEUmm for NES and Gambatte for Game Boy and Game Boy Color. They are loaded only when a compatible game starts, which keeps the regular catalog experience separate from the heavier emulator bundle.

The launch flow still does more than simply download a file and hope for the best. The app checks the selected build, enforces a size limit, verifies its expected SHA-256 checksum, resolves a compatible emulator core, and reports each stage to the player. Unsupported games remain visible in the shared catalog but are clearly marked as requiring Studio or a future browser core.

The User Edition currently includes:

Instant browser gameplay for eligible NES, GB, and GBC titles
Three local save-state slots with import and export
A Personal ROM flow that keeps ROM bytes in memory instead of uploading them
Local game history without silently persisting the ROM itself
Browser storage management and a PWA shell
Optional local performance measurements that stay in the tab until exported

The privacy boundary around personal ROMs was deliberate. Opening a local file does not upload it to the API, and the current version does not persist the ROM bytes after the session. Save states and harmless recent-file metadata can live locally, but persistent ROM storage will only be added later as an explicit opt-in feature with clear quota and deletion controls.

Why not replace Studio with the WASM version?

Because WebAssembly is not automatically a replacement for streaming.

For the systems User Edition supports today, running locally is usually the simplest experience. It avoids video compression, removes a network round trip from controls, produces a sharp native canvas, and requires no companion software.

Studio is solving a different problem. It separates the browser from the runtime, supports local-engine and LAN workflows, and gives me a real WebRTC media pipeline to instrument. Its architecture can grow beyond the limits of the browser, while User Edition is intentionally constrained by the emulator cores, memory, storage, and APIs available on the user's device.

Maintaining both also creates something more useful than either project alone: a controlled comparison.

The same catalog, visual design, game, and general interaction model can now be exercised through two very different execution paths. That makes architectural tradeoffs visible instead of theoretical.

My latency research

PIXELATED Studio is also connected to my thesis work. I am experimenting with a technique I currently describe as latency fingerprinting.

The basic idea is not to reduce an entire session to one latency number. A streamed game has several observable stages and behaviors: backend-session creation, engine startup, signaling, the first remote track, the first non-black frame, frame rate, bitrate, jitter, packet loss, stalls, disconnects, and recovery.

Together, those measurements form a kind of session fingerprint. Repeating runs under controlled localhost, LAN, and browser-only scenarios may help show where delay and instability are introduced, and whether different architectures produce consistently different patterns.

Studio can export versioned research bundles containing event timelines, telemetry samples, summary statistics, and graphs. User Edition provides a browser-only baseline with ROM download, verification, core-load, first-frame, frame-pacing, long-task, and supported memory measurements. Recording is opt-in, and the data remains local until the tester exports it.

What building both versions taught me

The biggest lesson was to stop treating architecture as a contest with one winner.

WebAssembly gives User Edition an excellent experience because the workload fits the browser. WebRTC gives Studio a useful boundary between the player and the runtime because Studio is meant to explore streaming, multiplayer, LAN access, and a broader engine.

I also learned that shared infrastructure needs explicit ownership. Studio is the migration authority for the shared database, while both editions consume a compatible API contract. Edition and runtime metadata are recorded deliberately, and Studio-only administration and publishing features are not copied into the User frontend just because the database is shared.

That separation has made both projects easier to reason about:

User Edition can optimize for opening a page and playing quickly.
Studio can optimize for engine capabilities, networking, and measurement.
Shared social and catalog features do not need to be rebuilt twice.
Experimental code stays out of the simpler product unless it has a reason to be there.

There is still plenty left to do. I want to test more browsers and devices, add browser cores one system at a time, improve the research procedure, and collect enough controlled runs to say something meaningful about the two architectures.

For now, though, both editions are real, playable projects, and they answer the same question in two very different ways.

Try them or explore the code

PIXELATED User Edition: Live app · GitHub
PIXELATED Studio: Live web app · GitHub · Desktop releases

If you have worked on browser emulation, WebRTC streaming, or performance measurement, I would be interested to hear how you would compare these two paths, and which measurements you would trust most.

The catalog is intended for approved, public-domain, or appropriately licensed homebrew content. Original creators retain ownership of their games and are credited in the project. Personal ROM features are intended for files users are legally allowed to use.

DEV Community: The Nicholas 035