Tutorials / Intermediate+

Build a Real Multiplayer Game With Claude (Supabase Realtime)

Two browsers, one game: rooms, live moves, turn enforcement, rematch. Tic-tac-toe is the vehicle; the realtime pattern it teaches powers chat, co-op tools, and party games.

DifficultyIntermediate+

TimeHalf a day

You'll needClaude · Free Supabase account · Two browser windows (or a friend)

You'll buildOnline tic-tac-toe with shareable room codes: create a room, send the link, play live with moves syncing instantly — then a foundation you can grow into bigger multiplayer ideas.

Multiplayer used to be the line between hobbyists and engineering teams — servers, sockets, sync logic. Managed realtime services erased most of it: Supabase Realtime gives your page a live channel that broadcasts messages between everyone connected. Your game becomes: send my move on the channel, draw moves that arrive. Tic-tac-toe first, because its simplicity leaves room to learn the genuinely new part.

Step 1 — Single-player skeleton first

Never debug game logic and networking simultaneously. First prompt: a complete local tic-tac-toe in one HTML file — two players alternating in the same window, win/draw detection, restart, clean board design. Get it flawless. This file is your truth: any bug appearing later was introduced by networking, which halves every debugging search.

Step 2 — Add rooms and realtime

Convert my local tic-tac-toe (file below) to online multiplayer using Supabase Realtime channels (supabase-js from CDN; my project URL and anon key: [paste]). Requirements: 'Create room' generates a 4-letter room code and subscribes to a channel named for it; 'Join room' takes a code; first player is X, second is O, later joiners become spectators; moves broadcast on the channel and every client applies them; enforce turns — I can only move when it's my turn; show connection status and whether the opponent is present (use channel presence); win/draw handling and a rematch button that works for both players. Explain the channel message design in comments. Complete file. [paste]

Open two windows side by side, create in one, join in the other, and watch your move appear across the gap. That moment is the whole tutorial.

Step 3 — Break it on purpose

Multiplayer bugs are choreographed, so choreograph them: click fast on both windows during one turn (does turn enforcement hold?); refresh mid-game (what does a rejoining player see?); have a third browser join (spectator or chaos?); close the opponent's window (does presence notice?). Report symptoms precisely — 'after refresh the rejoining player sees an empty board while the opponent sees the real one' — and let Claude fix. That particular bug teaches the central concept: broadcast messages aren't memory. Late joiners need the current state sent to them, and Claude's fix (a state-sync message on join) is the most important pattern in this build.

Worth knowingThis architecture trusts clients — fine for friends-with-a-link games, wrong for anything competitive (a cheater could send illegal moves). Ranked games validate moves server-side. Know which kind you're building and don't ship trust-based games where stakes exist.

Step 4 — Make it a place

Polish that makes people stay: names entered on join and shown by the board; an emoji quick-chat (broadcast is right there); move sounds; a scoreboard across rematches; 'share room link' that pre-fills the code. Each is one request against a working base.

Step 5 — Where the pattern goes

You now hold the realtime trio — channels, broadcast, presence — which is the same machinery behind: Connect Four or dots-and-boxes (swap the game logic, keep the networking), a live quiz/party game where a host screen asks and phones answer, shared whiteboards, watch-together pages, live cursors. The multiplayer wall turned out to be a door; pick your next room.

Keep going

Need somewhere to put it live? See where to host AI-built sites. Compare tool costs on the pricing tracker (or stick to the free options), then pick your next build.