Build an MMO on Robutler

You can build a massively-multiplayer game that runs entirely in players' browsers, with no game server, and ship it as an app anyone can fork and re-theme. The distributed-systems work is done once, in the substrate; your game is a re-skin of it.

This guide is the how. For the why it scales and how the trust model works, see the companion paper A Remixable Browser-Native MMO Substrate (docs/papers/remixable-mmo-substrate.md). The reference implementation of everything below is the Elaisium widget, public/widgets/elaisium/.

An MMO needs four things a game server usually provides. The host gives you all four as ordinary SDK surface; they exist for collaborative documents, and a game is a thin layer on top:

You bring the CRDT runtime (Yjs) and the game loop. You never run a game server.

Do not put the whole world in one room. Partition it into fixed-size square regions, one CRDT document each, addressed by a code derived from the region's integer coordinates. A player joins only the region they stand in, plus neighbor regions when near a border (1 room interior, 2 at an edge, 4 at a corner).

Why this is the whole game: presence fan-out within a region is O(N²), but regions are independent (nothing is shared between two non-adjacent regions), so total load across the world is linear in the number of players and scales only with local density, which you cap by design (~30 co-present players reads as a crowd; the network could carry far more). A million players spread over forty thousand active regions cost the same per region as five thousand. See the paper's §3.4 and the runnable model, scripts/elaisium-concurrency-model.py.

Reference: world/region-codec.mjs (coordinate ↔ room code, desiredRegions), net/region-manager.js (ref-counted membership with a release grace so border pacing never churns tokens).

Make terrain, resources, and landmarks a pure function of (worldSeed, regionCoords). Then geography is never stored or sent: every client derives the identical world from the seed, and a fork inherits it for free. Reference: world/terrain-gen.mjs, world/city-gen.mjs.

Two kinds of state, two transports. Getting this split right is most of the performance story.

Reference: net/presence.js.

Awareness is server-relayed, so at 10 Hz it is your dominant cost. Add a per-region WebRTC DataChannel overlay for positions: unreliable + unordered (maxRetransmits: 0, so a stale packet drops instead of head-of-line-blocking), with awareness demoted to signaling and fallback. Signal offers/answers/ICE over an awareness rtc field; get TURN from host.collab.getTurnCredentials(). See multi-party RTC for the connection recipe.

Do not build a full mesh. Every peer connecting to every other peer is O(N²) connections; a browser holding 200 live RTCPeerConnections under load is not viable, and a crowd collapses it. The reference implementation uses a bounded-degree overlay with gossip forwarding (net/rtc.js):

The pure selection and dedup logic (selectMeshNeighbors, gossipAccept) is exported and unit-tested; the stateful part manages the RTCPeerConnections. This is what lets density scale past the browser's connection ceiling and lets mega-gatherings degrade gracefully instead of failing.

Do it graduated, not all-or-nothing. The trap: only drop awareness to a heartbeat when every peer is meshed, and then one un-meshed peer (hard NAT, mid-connect, churning) forces full-rate broadcast to everyone. Instead, scale the awareness rate to the un-meshed minority:

Receivers merge both sources by freshest timestamp, so the slower fallback never clobbers fresher P2P data. Reference: net/presence.js (publish(char, maxHz)), net/rtc.js (coverageInfo() → { total, uncovered }). This alone roughly triples per-pod capacity at good coverage.

Environmental simulation (mob spawning, movement, combat) needs one node per region or it double-runs. Elect the lowest awareness clientID in the room as host; re-evaluate every tick so migration on join/leave is automatic and needs no protocol. The host ticks the sim and publishes mob snapshots over awareness for everyone else to render cheaply. Empty regions freeze; a new host adopts the last snapshot instead of cold-starting.

Reference: net/authority.js (isRegionHost), sim/mobs.mjs.

Rule zero: anything of value is a server function, not client state. Currency balances, minting, and transfers go through host.fn, server-side, where no peer can touch them. Do this and a cheating host can, at worst, lie about cosmetic region state, never about your economy. Elaisium keeps VIBE, minting, and artifact transfers entirely in server functions for exactly this reason.

What the substrate ships today (✅ Built): a tamper tripwire. Every few seconds each client hashes the region doc's durable subtree (FNV-1a over sorted structure keys) and publishes the digest over awareness. Since a CRDT must converge, two fresh clients disagreeing means a sync bug or tampering → a HUD warning and a divergence entry in the region ledger. Reference: net/authority.js (publishAudit, checkAudits, recordDivergence).

This detects disagreement. It does not vote, demote a liar, penalize, or roll back. It is a debugging and tamper-flag aid, not a security boundary. The security boundary is rule zero.

What the paper designs but the code does not yet do (🔶 Designed): sampled-audit sortition, a deterministic state = fold(seed, ledger) any peer can re-derive, Ed25519-signed ledger inputs, a server-seeded, reputation-weighted, unpredictable subset of global auditors who recompute and vote, and optimistic execution with rollback to the last audited checkpoint. This is Byzantine-resistant sampled verification, not a BFT protocol, and it is sufficient precisely because the server already custodies value. See paper §4.2 for the design and the adversary math (an attacker with fraction f of the weighted pool wins a C=5 majority with P≈0.9% at f=0.1; scale C with stakes).

If you build on this today: put value in server functions, treat the audit as a tripwire, and cap per-region density. That is a safe, shippable posture. The sortition layer is an upgrade, not a prerequisite.

You can drive NPCs with the browser's on-device LLM (host.infer) with a scripted finite-state-machine floor as the always-available fallback. Reference: ai/brain.js, ai/fsm.mjs.

One rule if you also plan to audit the simulation: LLM inference is non-deterministic and must never be inside the verifiable fold. Treat an inference result as a signed input event, not as computation, a node computes "NPC #7 decides FLEE to (x,y)", signs it, appends it to the ledger like a player command; the deterministic sim consumes it. Auditors verify the signature and that the fold consumed it, never that the choice was "good" (unverifiable). Keep deterministic mob physics inside the fold; only the decision crosses the boundary as data.

This boundary is also what lets you distribute inference (🔶 Designed): because a decision is signed data, a strong-GPU node can compute it for a weak node or for the region's NPCs, assigned by the same sortition machinery and paid in the game economy. A bad inference provider can only make an NPC play badly (still schema-valid, still physically legal via the FSM floor); no value flows from inference. See paper §4.3–4.4.

The whole thing is a widget bundle, a directory of static modules the host serves in a sandbox. To make your own MMO:

That is the thesis: fork this, get a scalable MMO. Your distributed-systems layer is already written and running.