Realm How to Make an MMO (Browser Server Loop 2026)

Searchers who type "how to make an mmo" in 2026 usually fall into two camps - one imagines a WoW clone with a five-year roadmap and a studio, the other has already accepted that a solo weekend is a real budget and just wants to know the smallest honest server loop that still counts. This guide is for the second camp. A small-scale browser MMO in 2026 is a persistent 2D tile world, one authoritative game server (verified 2026-09-02 on the Wikipedia game server entry), a WebSocket per client (verified 2026-09-02 on MDN), and a PostgreSQL row per player character (verified 2026-09-02 on Wikipedia). The client is Phaser v4.2.1 "Giedi" (released 9 July 2026, verified 2026-09-02 on the Phaser stable download page) running in a browser tab. The whole thing is scaffolded by WizardGenie and the Sorceress Code agent in a single Saturday, and the assets that dress the realm - the terrain tileset, the hero and slime sheets, an ambient music bed, and four combat SFX - come out of Tileset Forge, AI Image Gen, Music Gen, and SFX Gen for under 0.61 USD. Total build: one weekend, under two dollars in generation.

What how to make an mmo actually means for an indie in 2026

The phrase "how to make an mmo" carries decades of unhelpful baggage. The massively multiplayer online game Wikipedia entry (verified 2026-09-02) defines the category by two properties - persistent world and concurrent players - and says nothing about scale. The word massively is the marketing part; the persistent-world and concurrent-players part is the actually-required part, and it is genuinely tractable in a browser tab. A small-scale MMO with sixteen simultaneous players wandering a shared 2D realm, fighting slimes, looting chests, and coming back tomorrow to find their character where they logged off - that is a real MMO under the Wikipedia definition, and it is a first-weekend browser build in 2026.

The honest 2026 reframe for how to make an mmo as a solo or two-person team is one shard, not one thousand. Pick a single 2D tile realm with sixteen to fifty concurrent player slots, one authoritative Node server, one Postgres database, one browser client. Scale later or not at all; players do not care about your architecture, they care whether the tab loads their character in the same spot the friend they were adventuring with is standing. Anyone selling "ship a WoW clone in a month" is showing a fake demo. Anyone selling "here is the smallest loop that still counts as an MMO" is showing the honest 2026 workflow, and that is exactly what this guide walks step by step.

The second reframe is small everything on pass one. One realm map, not a continent. One player class, not five. One enemy type (say, slimes), not a bestiary. One loot type (gold coins), not a full item table. One combat verb (attack), not a spell tree. The how to make a multiplayer game guide covers the lobby-and-match end of the same tech; this how-to picks up where that leaves off and stays persistent instead of round-based. The how to make an RPG walkthrough covers the single-player tile-realm version, and every content system there (the terrain, the hero sheet, the enemy AI, the music bed) applies unchanged - the only new thing this guide adds is the server loop.

The MMO server loop in one minute (auth, world tick, sync, persist)

Four moving parts, and that is the whole thing. Verified 2026-09-02 against the Wikipedia game server entry and the MDN Writing WebSocket servers reference. Understand these four stages once and every future how-to-make-an-mmo question ("how do I add mail?", "how do I add parties?", "how do I add a shop?") is just adding a subsystem that hangs off one of the four:

1. Auth - a client opens a WebSocket to wss://your-shard.example/realm, sends a token (JWT signed by your Supabase or Auth0 project), the server verifies the token and returns a playerId plus the current character row from Postgres. If the token is bad, the server closes the socket. If the player already has an open socket from another tab, the server closes the older one first (one active socket per character is the honest 2026 default).
2. World tick - the server runs a monotonic authoritative loop at 20 Hz (a 50 ms setInterval is fine for a first pass, upgrade to a drift-corrected setTimeout loop when you outgrow it). Each tick advances physics, moves NPCs, resolves damage, spawns loot, and stamps a tick number on every entity that changed. Twenty ticks per second is the number that lets every action feel snappy without eating a whole CPU core - the client-server model Wikipedia entry (verified 2026-09-02) covers the general pattern.
3. Sync - after each tick the server sends every client a compact snapshot of the entities inside that client's view radius (say, 30 tiles). The message is a small JSON payload (or a MessagePack blob when the JSON gets bloated) containing entity id, x, y, hp, and a couple of state flags per entity. Every client keeps the last two snapshots and interpolates.
4. Persist - every 20 seconds (400 ticks) the server writes every dirty player row to Postgres with an UPDATE players SET x=$1, y=$2, hp=$3, xp=$4, updated_at=now() WHERE id=$5. A crash never loses more than one 20-second window. NPCs do not persist (they respawn from the spawner config); only player-owned data touches the disk.

That is the whole MMO server loop, and the rest of this how-to walks each stage as concrete WizardGenie prompts and Sorceress tool clicks. If any part of that four-step summary reads as intimidating, it is because the phrase "how to make an mmo" carries a fifteen-year memory of Java + C++ Linux boxes. The 2026 stack is a single Node process, and modern managed hosts (Fly, Railway, Render) all run it on the free tier.

Pick your stack for how to make an mmo - Node WebSocket, or WizardGenie scaffolds it

Two honest choices for how to make an mmo in 2026 as an indie, and picking one is entirely a "do you want to type it, or type about it" question.

Option one - roll it yourself. Node LTS on the server (the built-in node:http plus the ws package for the WebSocket upgrade, or the standard WebSocket support in newer Node). Postgres for persistence (a free-tier Supabase or Neon project is a one-click setup). Phaser v4.2.1 "Giedi" as the client renderer. This path gives you full control, zero framework magic, and every line of authoritative logic is in code you own. Best when the reader already knows Node and wants to understand every packet.

Option two - let WizardGenie scaffold it. Open WizardGenie in a browser tab (or the desktop app with the auto-updater), paste a one-page spec, and the agent produces the whole authoritative-loop scaffold in one pass. The spec prompt that reliably works in September 2026 is:

Build a small-scale browser MMO named RealmDemo.
- Client: Phaser v4.2.1 "Giedi", 2D top-down, 60 FPS render, 640x480 canvas that scales.
- Server: Node LTS, one process, WebSocket per client (use the 'ws' package).
- Persistence: Postgres via 'pg', one 'players' table (id uuid, x int, y int, hp int, xp int, updated_at timestamptz).
- World tick: 20 Hz (50 ms setInterval), monotonic tick counter.
- Sync: after each tick, broadcast a snapshot per client of entities in a 30-tile view radius.
- Client interpolation: 100 ms buffer over the last two snapshots.
- Auth: JWT verify at socket open, one player per character, close the older socket on reconnect.
- NPCs: one slime type, spawner every 60 ticks in a 4-tile radius around spawn points.
- Combat: melee attack, 500 ms cooldown, 1 damage per hit, slime dies at 0 hp and drops 1 gold.
- Persist: UPSERT dirty player rows every 20 seconds.
Use the Planner+Executor split - Claude Opus 4.7 as planner, DeepSeek V4 Pro as executor.

WizardGenie drives every leading coding model in a single panel (Claude Opus 4.7, Claude Sonnet 4.6, GPT-5.5, Gemini 3.1 Pro, DeepSeek V4 Pro, Kimi K2.5, Grok 4.2, MiniMax M2.7 - verified 2026-09-02 against CODING_MODELS in src/app/_home-v2/_data/tools.ts lines 766-775). The Planner + Executor pattern is what makes how-to-make-an-mmo genuinely cheap in 2026 - an expensive reasoner (Opus 4.7 or GPT-5.5) plans the systems and writes each follow-up prompt while a cheap fast typer (DeepSeek V4 Pro or Kimi K2.5) grinds out the actual Phaser and Node code. Never put Sonnet, Opus, GPT-5.5, or Gemini 3.1 Pro on the typing side; that erases most of the cost advantage. The best AI coding model breakdown covers each model against game-dev tasks, and the Claude vibe coding walkthrough covers the same Planner + Executor pattern in more detail.

Step 1 - model the world, the players, and the persistence layer

Every MMO starts as a data model, not a render loop. On a small-scale realm the model is short. Two Postgres tables plus a couple of in-memory maps and the whole authoritative state fits on one page.

-- Postgres schema for how to make an mmo, first pass
CREATE TABLE players (
  id         uuid PRIMARY KEY,
  name       text NOT NULL,
  x          int  NOT NULL DEFAULT 100,
  y          int  NOT NULL DEFAULT 100,
  hp         int  NOT NULL DEFAULT 10,
  hp_max     int  NOT NULL DEFAULT 10,
  xp         int  NOT NULL DEFAULT 0,
  gold       int  NOT NULL DEFAULT 0,
  updated_at timestamptz NOT NULL DEFAULT now()
);

CREATE TABLE realm_events (
  id         bigserial PRIMARY KEY,
  player_id  uuid REFERENCES players(id),
  kind       text NOT NULL,
  payload    jsonb NOT NULL,
  created_at timestamptz NOT NULL DEFAULT now()
);

The in-memory state on the Node server keeps the same fields but adds derived-only data - the current WebSocket handle per player, the last input tick, the current animation state, the last snapshot sent - none of which touches Postgres. NPCs (slimes) live only in memory; when a slime dies the loot drop lands on the ground as an in-memory pickup entity, and the pickup is authoritative on the server just like the slime. When a player picks up gold, the increment goes to players.gold in memory and gets flushed to Postgres in the next 20-second persist tick.

The persistence tick itself is a boring async loop:

setInterval(async () => {
  const dirty = [...playersState.values()].filter(p => p.dirty);
  if (dirty.length === 0) return;
  await pg.query(
    `UPDATE players AS p SET x=v.x, y=v.y, hp=v.hp, xp=v.xp, gold=v.gold, updated_at=now()
     FROM (VALUES ${dirty.map((_,i)=>`($${i*6+1}::uuid,$${i*6+2}::int,$${i*6+3}::int,$${i*6+4}::int,$${i*6+5}::int,$${i*6+6}::int)`).join(',')}
       ) AS v(id,x,y,hp,xp,gold) WHERE p.id = v.id`,
    dirty.flatMap(p => [p.id, p.x, p.y, p.hp, p.xp, p.gold])
  );
  for (const p of dirty) p.dirty = false;
}, 20_000);

That single query pattern (a bulk UPDATE ... FROM VALUES) writes every dirty row in one round trip. On sixteen players that is a sub-millisecond query on a free-tier Postgres. On fifty players it is still under 5 ms.

Step 2 - wire the authoritative server tick and client interpolation for the mmo

The server tick is a 50 ms interval that reads the input queue, moves entities, resolves combat, and stamps a monotonic tick counter. The client sends inputs (WASD movement intents, attack) at whatever rate it likes; the server only reads the latest input at tick boundaries. That single rule (server reads inputs at its own clock, not at the client's clock) is what makes an MMO authoritative instead of lag-broken.

let tick = 0;
setInterval(() => {
  tick++;
  // 1. Read latest input per player
  for (const p of playersState.values()) {
    const dx = p.input.right - p.input.left;
    const dy = p.input.down  - p.input.up;
    if (dx || dy) { p.x += dx * 2; p.y += dy * 2; p.dirty = true; }
    if (p.input.attack && tick - p.lastAttackTick > 10) {
      resolveAttack(p);
      p.lastAttackTick = tick;
    }
  }
  // 2. Advance NPC AI
  for (const s of slimes.values()) stepSlimeAI(s, tick);
  // 3. Broadcast per-client snapshot
  for (const p of playersState.values()) sendSnapshot(p, tick);
}, 50);

On the client, every arriving snapshot goes into a two-slot buffer. Rendering runs at the browser's requestAnimationFrame cadence (roughly 60 FPS) and each frame draws every remote entity at a time 100 ms behind "now" - interpolating linearly between the two snapshots that bracket that render time. That 100 ms artificial delay gives the client one full snapshot of headroom to always have two valid samples to interpolate between, and it is the difference between "buttery" and "everyone is teleporting". The local player's own character is drawn without the delay, using client-side prediction from their own inputs, and reconciles softly if the server snapshot disagrees. That is the canonical pattern documented in the client-server model entry (verified 2026-09-02) and it works for every browser MMO shipped in the last decade.

Step 3 - dress the realm with Tileset Forge, AI Image Gen, Music Gen, SFX Gen

A working authoritative-loop scaffold with placeholder rectangles is a solved technical problem in 2026; a working authoritative-loop scaffold with a genuinely playable-looking realm is where most solo how-to-make-an-mmo attempts stall. The Sorceress asset stack closes that gap in an hour.

• Terrain - open Tileset Forge, prompt "top-down 16x16 grass and stone autotile terrain, hand-painted 2D pixel-art, dappled sunlight, mossy edges, matching corner variants". Ships a Godot-ready or Tiled-ready tileset PNG plus a JSON with the autotile edge rules, and drops straight into the Phaser TilemapLayer. Roughly 30 credits per pass (0.30 USD at CREDITS_PER_DOLLAR equals 100 in src/lib/models.ts line 69, verified 2026-09-02).
• Hero + slime sheets - open AI Image Gen, use Nano Banana Pro for consistent character sheets. Prompt for a four-direction hero (idle, walk, attack in each of N/S/E/W) and a four-direction slime. Two generations, roughly 8 credits each (16 credits, 0.16 USD). Auto-Sprite v2 is the alternative when you want animation clips instead of a static four-direction sheet; the AI sprite sheet generator walkthrough covers the whole prompt-to-atlas pipeline.
• Ambient music bed - open Music Gen, prompt "gentle 80 BPM medieval fantasy overworld loop in D minor, dulcimer and flute, no vocals, 20 seconds, loopable". One 10-credit generation via Suno V5.5 (MUSIC_CREDIT_COST equals 10 in src/app/music-gen/page.tsx line 28, verified 2026-09-02) returns two variations. Pick the one that loops cleanest and drop it into the Phaser scene as a looping WebAudio asset.
• Combat SFX - open SFX Gen, prompt four cues: "soft plosive whoosh of a pixel hero attack, 200 ms", "wet impact of a slime being hit, 150 ms", "coin pickup chime, 300 ms", "descending slime death squelch, 400 ms". Bills at SEED_AUDIO_CREDITS_PER_SECOND equals 1 credit per second (src/app/sfx-gen/page.tsx line 23, verified 2026-09-02) - the four cues total roughly 5 credits (0.05 USD).
• Optional NPC voice - open Speech Gen for a one-line greeter NPC at the spawn tavern. Ship the barks as short WAV clips that play on proximity.

Two content rules keep the first realm honest. First, one biome on pass one - the whole realm is one grass tileset; add stone and water only after a friend has actually logged in and walked around. Second, one music bed for the whole realm, not one per zone; a 20-second Music Gen loop plays for the whole session and nobody notices repetition inside a first-weekend build. The dungeon map generator walkthrough covers procedural room graphs when the realm eventually grows past one map, and the multiplayer game lobby walkthrough covers the account and friend-list layer that turns "some players in a realm" into "your friends and you in a realm".

What a first how to make an mmo build costs on Sorceress in 2026

Honest weekend budget for a first how-to-make-an-mmo build against the 2026 Sorceress rate card (verified 2026-09-02 against local source):

• Tileset Forge autotile terrain: roughly 30 credits or 0.30 USD.
• AI Image Gen hero sheet plus slime sheet: 16 credits or 0.16 USD.
• Music Gen 20-second ambient loop: MUSIC_CREDIT_COST equals 10 credits, 0.10 USD.
• SFX Gen four cues (attack, hit, coin, death): roughly 5 credits, 0.05 USD.
• Coding-model API time with a Planner + Executor split for a small-scale scaffold: under 1.50 USD.
• Server hosting on a free-tier Fly or Railway machine: 0 USD.
• Postgres on a free-tier Supabase or Neon project: 0 USD.

Total roughly 61 credits or 0.61 USD in Sorceress asset generation, plus a coding-model bill under 1.50 USD, for a grand total under 2 USD on a first weekend. Credits convert at 100 per dollar via CREDITS_PER_DOLLAR in src/lib/models.ts line 69 (verified 2026-09-02). The free 100-credit signup grant covers the entire asset side outright and leaves headroom for a terrain retry. Lifetime Early Access sits at 49 USD (LIFETIME_PRICE in src/app/plans/page.tsx line 51, verified 2026-09-02) if the second weekend is already planned - it unlocks the desktop WizardGenie with auto-update and a bigger monthly credit allowance.

The realm loads at sorceress.games/play/<your-slug> once you push the client build through Sorceress Publishing, and other creators browsing the Play Arcade can walk into your shard the same day. The Sorceress tools guide lists every asset tool in one place; the AI for game development indie stack overview is the honest zoom-out on how the coding pillar plus the asset pillars plus the publish pillar assemble into a full 2026 workflow. How to make an mmo in 2026 is not a five-year plan and it is not a fake demo - it is a Node process, a Postgres table, a Phaser tab, and a Saturday afternoon with a Planner Executor split doing the typing.