Punchline
A playable web-first multiplayer party game with server-authoritative rooms, rotating judges, timers, private per-player views, reconnects, smoke tests, and deployment routing notes.
What it is
Punchline is designed to be instantly playable: no install, a host shares a short code, and players join from phones.
The product loop is familiar but technically demanding because everyone needs a consistent view of the room while each player sees different private information.
The loop it has to make believable
- 01
Built the live room loop with create, join, start, submit, reveal, pick winner, next round, end game, and play again messages.
- 02
Kept game state server-authoritative so reconnects and refreshes recover from the room snapshot.
How it’s built
The Go backend owns the game state and broadcasts WebSocket snapshots. The frontend reconnects after refresh and renders viewer-specific state.
Postgres is used only as an optional room ownership registry for multi-machine routing, not as durable active-game storage. If the owning process restarts, full room-state recovery is still future work.
Architecture
- Gameplay
- Host room, guest join, judge rotates, answer cards submit blind, reveal, pick winner, score to limit
- Backend
- Go API plus WebSocket engine; server pushes room_state snapshots to connected players
- Fairness
- Viewer-specific redaction: only your own hand is visible, submissions stay hidden until reveal, authors hidden during judging
- Routing
- Optional Postgres room code leases let wrong-machine API/WS requests return 421 plus Fly-Replay before upgrade
What has to hold up
- Redacted room state per viewer to protect hands and preserve anonymous judging.
- Added production hardening around one-container runtime, probes, security headers, origin checks, socket limits, idle eviction, local room caps, smoke testing, and optional Postgres room ownership leases.
How I would present it
I would demo it with two browser windows, then explain redaction, judge rotation, timers, guest-token reconnects, bounded WebSocket fanout, and the Fly-Replay room ownership path.
The strongest signal is honest realtime engineering rather than a polished static game mockup.
Proof
VerifyRepository, checks, stack, status
- 01
Start with the project status and available evidence.
- 02
Read the architecture and edge-case sections.
- 03
Follow the documented proof path: README, Go tests, frontend build, Dockerfile, Fly config, realtime smoke script.
- Role
- Go game engine, WebSocket protocol, React client, deployment shape
- Scope
- Live multiplayer party game engine
- Proof
- README, Go tests, frontend build, Dockerfile, Fly config, realtime smoke script
- Stack
- Go, WebSocket, React, Vite, Docker, Fly.io, PostgreSQL
- Room code
- 4 letters
- Transport
- WebSocket
- Routing
- Fly-Replay
- State
- In memory