Quick context

I'm a solo dev building SQL Protocol, a browser game where you play a covert operative and every mission is a real SQL query against a real Postgres database. Three modes: 15-chapter story, timed interview drills, and 1v1 Arena PvP.

It shipped, people played it, and the consistent feedback was: "the world feels empty." Even with PvP, between missions it played like a single-player tutorial.

This article is the four-week story of turning that into a real shared world without rewriting the engine.

The plan

Two requirements:

1. Every map is shared. Walk into the hub, you see other operatives. Walk into a mission map, you see whoever else is running it.
2. Chat. A global channel for everyone online and a per-map channel for whoever is in your current area.

Constraint: no full rewrite. The single-player code had to keep working.

Why Nakama

I was already using Nakama for auth, storage, and RPCs. The realtime primitives I needed - matches, presence, channels - were already in the box. Picking a second realtime stack would have meant two operational surfaces and two auth flows. So Nakama for everything realtime, full stop.

Architecture: two transports, two concerns

| Transport | For |
| HTTP/RPC | One-shot reads and writes. Cases, progress, leaderboards, storage. |
| WebSocket | Persistent push. Player positions, chat, presence. |

This split keeps caching honest. RPC reads go through TanStack Query. WebSocket events go through Zustand stores. Components subscribe to slices.

The big lesson: socket events write directly to Zustand

The first version of the multiplayer hub assigned socket handlers inside React useEffects. The handlers closed over component state. Stale closures everywhere. Other-player positions would freeze, drift, or disappear.

The fix was to stop putting realtime state in React entirely. Socket handlers call useGameStore.getState() and setState() directly, components subscribe to slices.

socket.onmatchdata = (data) => {
  const current = useGameStore.getState().players;
  useGameStore.setState({
    players: { ...current, [data.userId]: data.pos },
  });
};

const players = useGameStore((s) => s.players);

Three things this gives you for free:

1. No stale closures. getState() always reads current state.
2. No per-tick React re-render. 60fps remote-player movement never triggers a render unless the slice you subscribe to changes.
3. The handler is correct on Day 1 of writing it, no useRef gymnastics.

Server-authoritative positions

The client never decides where another player is. The local client sends position inputs, the server stamps them, broadcasts the authoritative state to all clients in the match. This is the same pattern any modern multiplayer engine uses, and it gives you anti-cheat for free.

For a SQL game, anti-cheat matters less for movement and more for the rest of the game state (XP, progress, query validation). But applying the same discipline to positions kept the architecture consistent.

Chat: two channels, not one

I shipped chat with a single global channel first. Felt wrong immediately. A global channel is a highway, you can't have a conversation. So I added a per-map channel.

Server side: a Nakama channel per map id, plus the global channel. Clients join the map channel on map enter, leave on map exit, stay subscribed to global throughout.

Client side: a single ChatStore holds messages tagged by channel. The chat panel filters by tab. Speech bubbles read the same store. So a chat message and a speech bubble are the same event, not two systems.

What surprised me

• The "world feels alive" threshold is much lower than I expected. Three concurrent users is enough. Walking past one other agent while typing a query changes the whole feel.
• Position interpolation matters more than I thought. Raw socket positions look choppy. A simple lerp toward the latest server position fixed it without buffering.
• The chat panel needed instant show/hide. No max-height transitions. Fancy animation made high-frequency UI feel laggy.

What I'd do differently

• Build the speech bubble + chat panel as one feature, not two. I split them, regretted it, merged them.
• Write the position lerp from day one. I shipped raw positions first and immediately had to redo it.
• Stub out chat in the very first multiplayer prototype. Watching characters walk silently next to each other for a week made the world feel deader than before the update.

Try it

SQL Protocol is free, in browser, desktop only.
https://sqlprotocol.com

Happy to answer questions in the comments. Especially interested in feedback from people doing browser-based realtime multiplayer with sandboxed user-typed code, that's a niche.