Open-Source DOOM: Real-Time Multiplayer With No Servers Required

In May 2021, Cloudflare did something wonderful. They took DOOM - the 1993 game that defined an entire genre - compiled it to WebAssembly, wired up WebSocket multiplayer through their Durable Objects edge platform, and wrote a fantastic blog post about it. As Celso Martinho put it:

We loved it. And then we thought: what if we could take it further?

What if multiplayer DOOM didn't need Cloudflare's servers - or anyone's servers? What if it didn't need the internet at all? What if you could send a 4MB file to a friend in a chat message and be fragging each other within seconds, purely peer-to-peer, with the game feeling like a modern real-time shooter instead of a 1994 LAN party?

That's what we built. We call it Open-Source DOOM.

It's powered by a stack of open technologies: Chocolate Doom compiled to WebAssembly via Emscripten, distributed as a WebXDC mini-app, with peer signalling encrypted over Nostr via Marmot (MLS), and game packets transported and encrypted peer-to-peer through Iroh (QUIC-based gossip). Every layer is open-source. Every packet is encrypted. No servers required.

What Cloudflare Built (And Why It's Great)

Credit where it's due. Cloudflare's doom-wasm project did the hard work of porting Chocolate Doom - the faithful open-source recreation of the original DOOM engine - to WebAssembly using Emscripten. That alone is a serious engineering effort. They then wrote net_websockets.c, a transport adapter that replaced DOOM's original IPX/UDP networking with WebSocket connections routed through Durable Objects on Cloudflare's edge network.

Their architecture looked like this:

A Durable Object acted as the game room - maintaining a routing table of connected players and forwarding packets between them. Clean, elegant, and a great demo of edge computing.

But there was a catch.

What they kept the same

Cloudflare didn't modify DOOM's actual netcode. The game still used its original lockstep networking model from 1993 - the same protocol designed for four PCs on a local area network connected by coaxial cable. Every player sends their inputs (which keys they pressed) to every other player, every single frame, and the game freezes until everyone's inputs arrive.

This worked in 1993 when your LAN had sub-millisecond latency. Over the internet, through WebSockets, through a routing layer? It meant choppy gameplay, freezes whenever anyone's connection hiccupped, and a gameplay experience that felt more like a slideshow than a shooter.

The Durable Object was also a single point of failure and a centralised dependency. No Cloudflare, no DOOM.

What We Changed (Everything Except the Game Itself)

We forked Cloudflare's doom-wasm project and rebuilt the entire networking stack from scratch. Not just the transport layer - the fundamental model of how the game synchronises state between players.

Let's break down each piece.

1. No Servers, No Problem

The Simple Version

Cloudflare's DOOM needed their servers to work. Ours doesn't need any servers. When you open the game, your device automatically figures out who should be the "host" - no configuration, no IP addresses, no port forwarding, no sign-ups. It just works.

The game runs inside a .xdc file - essentially a tiny 4.2MB zip archive containing the entire game. You literally send it as a file in a chat message. Your friend opens it. You're playing DOOM together. The data travels directly between your devices through the chat app's peer-to-peer channels.

[to: uint32 LE (4 bytes)][from: uint32 LE (4 bytes)][doom_payload]

2. Who's the Server? Magic.

The Simple Version

In a normal online game, someone runs a server, and everyone connects to it. In Open-Source DOOM, there is no predetermined server. When you open the game, all players silently negotiate who becomes the host. The person who opened the game first wins. This happens automatically in about three seconds, and you never even notice it.

3. From Lockstep to Real-Time

The Simple Version

Original DOOM multiplayer works like a group of people writing a letter round-robin. Nobody can write their next line until everyone has received and read the previous line. If one person is slow, everyone waits.

We changed it to work more like a live conversation. Everyone talks at their own pace. If you miss a word, you can still follow along because the speaker periodically summarises where things stand. The result feels like a modern shooter - smooth movement, responsive controls, no freezing.

// Close 60% of the gap each tic = smooth exponential convergence
#define INTERP_FRAC  39322  // 0.6 * 65536 (fixed-point)
mo->x += FixedMul(target_x - mo->x, INTERP_FRAC);
mo->y += FixedMul(target_y - mo->y, INTERP_FRAC);

4. "I Shot You!" "No You Didn't!"

The Simple Version

In the original DOOM, every computer runs its own copy of the game physics. When you shoot someone, your computer calculates the damage, and their computer calculates the damage, and because the game is in lockstep, they always agree.

With our real-time model, that guarantee vanishes - your screen and theirs might show slightly different positions. So we made one player (the host) the referee. When you shoot someone, you tell the host "I hit Player 2 for 50 damage". The host checks the physics, applies the damage if it's valid, and announces the result to everyone. One truth, no arguments.

Client A fires weapon → bullet hits Player B locally
  → Send DAMAGE_EVENT to host: {target: B, damage: 50}
  → Apply visual feedback only (screen flash, attacker tracking)
  → Do NOT reduce Player B's health

Host receives DAMAGE_EVENT:
  → Set damage_from_event = true (bypass remote-source skip)
  → Call P_DamageMobj() with full physics
  → Broadcast result via HEALTH_AUTH packet

All clients receive HEALTH_AUTH:
  → Apply as ground truth

5. Making Monsters Agree

The Simple Version

DOOM has dozens of monsters per level, each running their own AI - chasing you, shooting fireballs, infighting with each other. In the original game, every computer simulates every monster identically (because lockstep ensures they all see the same inputs). In our version, only the host simulates the monsters. Everyone else just sees the results - like watching a puppet show where only the puppeteer knows the script, but the audience sees the performance in real-time.

6. "Room for One More?"

The Simple Version

Original DOOM didn't let you join a game already in progress. Everyone had to be there at the start, or tough luck. Our version lets players drop in mid-game. You open the .xdc, the game finds the server, and you spawn in - even if everyone else is already knee-deep in the dead.

7. Fits in a Chat Message

The Simple Version

The entire game - engine, levels, monsters, weapons, networking, touch controls, gamepad support, all of it - fits in a 4.2 megabyte file. That's smaller than most photos your phone takes. You send it in a chat message like you'd send a meme. Your friend taps it, and they're in the game. No app store, no downloads, no accounts, no updates.

From Keypress to Frag

Here's what happens when you press the fire button on your phone:

1. Your finger hits the Fire button (HTML touch event)
2. JavaScript calls inject_key_event(0, 32) - keydown, spacebar
3. DOOM's event queue receives ev_keydown
4. G_Responder() builds a ticcmd with BT_ATTACK
5. Your weapon fires, P_LineAttack() traces a hitscan ray
6. Bullet hits Player 2 → send DAMAGE_EVENT to host
7. Your position snapshot broadcasts via realtimeChannel → Iroh gossip → peer devices
8. Host receives damage event → validates → applies → broadcasts HEALTH_AUTH
9. Player 2's screen: health drops, pain flash plays
10. Your screen: the host's HEALTH_AUTH confirms the kill

Total time from keypress to kill confirmation: roughly 100–200ms depending on network conditions. No servers touched. No corporation involved. Just two chat apps talking directly to each other.

Standing on the Shoulders of Giants

None of this would exist without:

• id Software for open-sourcing the DOOM engine in 1997 - a decision that created an entire modding ecosystem and directly enabled everything described here
• Chocolate Doom for faithfully recreating the original engine in portable, hackable C
• Cloudflare for proving DOOM-in-WebAssembly was viable and open-sourcing their doom-wasm port - the foundation we forked
• Emscripten for making C-to-WASM compilation actually work
• Iroh (by n0.computer) for the QUIC-based P2P gossip protocol that makes serverless real-time gaming possible
• The WebXDC community for defining an open standard for sandboxed web apps in chat messages

And a special note: the networking architecture of Open-Source DOOM was designed and implemented as a collaboration between a human developer and an AI (Claude, by Anthropic). Not generated and pasted - collaborated on. Hundreds of iterations, debugging sessions with hex dumps of gossip packets, heated debates about whether to interpolate angles (don't), and moments of genuine surprise when things just... worked.