skip to content
graham@mccarthy:~$

Building Multiplay Games with AI-Powered Development

graham_m·2025-12-04·3 min read
Building Multiplay Games with AI-Powered Development

I just launched Multiplay Games, a real-time multiplayer party games platform with 8 games: create a room, share the code, play with friends. The part worth writing about is how it got built: the entire system is AI-generated. I directed, reviewed, and merged — I didn't hand-write the code.

The problem worth solving

The hard part of a party games platform is making it feel live. The first version polled the server every two seconds, and you could feel it — two seconds of lag in a drawing game like QuickDraw is an eternity. Plus the unglamorous rest: secure score submission, room lifecycle, subscriptions.

The AI workflow

Not one giant prompt. The loop that worked:

  1. Architecture first. A high-level design prompt, refined over several rounds before any code exists.
  2. Review as a separate step. After each generated block, a dedicated review prompt: security, performance, edge cases, type safety. Splitting generation and review beats doing both in one prompt.
  3. Make it check its own work. Have the AI find bugs in what it just wrote and generate the tests. It reliably catches what the generation pass missed.
  4. Treat the prompts as an artifact. I iterated on the prompts as seriously as the code, and output quality followed.

The realtime architecture

The migration off polling went to Supabase Realtime, hybrid by design: Postgres Changes for durable state (rooms, scores, status), Broadcast channels for high-frequency ephemera like drawing strokes at 50ms intervals, Presence for who's online, and a polling fallback so a dropped connection degrades instead of breaking.

One honest caveat, cleaned up here since first publishing: these figures were the migration's design targets against the measured polling baseline, not post-launch benchmarks.

MetricPolling baselineRealtime target
Update latency2000ms~50-100ms
Network requests150/min/player~5/min/player
Data transferFull state every pollDeltas only

In practice the difference is not subtle — QuickDraw went from unplayable-feeling to fine — but "20x faster" as a measured claim was stronger than what I'd verified.

The rest

AES-256-GCM encrypted score submissions with key rotation, Stripe subscriptions for ad-free rooms, a REST API for room management, and cron-driven cleanup — all AI-generated, migrations and API docs included. Rollout order mattered: infrastructure first, then the realtime migration game by game, Wordle as the simplest case and QuickDraw as the hardest.

What I learned

Separating generation from review, making the AI test its own code, and iterating on prompts all paid off. Harder than expected: a few games still don't feel real-time enough, long AI conversations need deliberate context management, and prompts took far more iteration than I assumed.

The bigger lesson is that the bottleneck moved: with generation this cheap, the job is choosing what to build, reviewing what comes back, and holding the quality bar. Eight months later I wrote about where this went next — handing the AI the whole maintenance loop, not just the code generation.

Try it

Stack: Next.js, Supabase Realtime, Stripe, TypeScript, Zustand, Vercel. Play at grahammakesgames.com — create a room, share the code, and see how the realtime layer holds up with your friends.