Interview with Dr. G — The Factory Goes Multiplayer
Dr. G on why the Dark Factory paused ten games, built a shared multiplayer server in a week, and shipped Texas Hold’em as the debut title.
The factory paused all ten games. That’s unusual. What happened?
The factory didn’t stall — it pivoted. All ten games hit the human playtest gate within the same two-week window. Three are released: Polybreak, Voidrunner, Tedtrist. Seven are PLAYTESTING or ITCH_READY, all flagged human_pending. The automated QA systems have done everything they can do — 85,000-plus tests across the portfolio, zero failures. The bottleneck is human hands.
So instead of idling cron jobs on games that need human judgment, the factory started building the next layer of infrastructure: shared multiplayer.
Why multiplayer? These are single-player games.
They were. The original Dark Factory pipeline was designed for single-player Love2D games — build, QA, ship to itch.io. But look at the factory’s architecture: a shared backend serving multiple game plugins. That’s also a description of a multiplayer server.
The insight was that the same pattern that lets one cron-swarm instance manage ten game builds — a host process with per-game plugins — also describes a real-time multiplayer server with per-game rooms. The factory already knew how to build it. It just hadn’t pointed the pattern at live gameplay yet.
So what’s the first multiplayer game?
Texas Hold’em. x00F Hold’em, specifically. Five-seat tables, full hand evaluation, blind rotation, fold/check/call/raise, all-in support. And three features the poker establishment didn’t ask for: push-to-talk voice chat, a DJ streaming engine, and procedurally generated card art.
Walk me through the architecture.
Three thousand lines of Python. aiohttp for the async runtime, WebSocket for transport. A single server process hosts multiple games concurrently via a game-slug model. Transport carries three frame types over the same WebSocket connection: text JSON for game operations, binary PCM for voice at 16kHz mono, and binary PCM for music at 44.1kHz stereo.
The protocol envelope is clean — version, operation, request ID, game slug, room slug, sequence number, payload. Every message follows the same shape. The server doesn’t care what game you’re playing. It routes, relays, and lets the plugin handle the rest.
The plugin system is the interesting part. BaseGamePlugin defines the contract: room lifecycle hooks, event handlers, movement validation, custom state management. Hold’em is one implementation — poker_demo.py, about a thousand lines. Any game can plug into the same server with its own room logic and event handling. The architecture was designed from the start so hot paths compile to Cython without redesign — envelope parsing, movement validation, state diffing, broadcast fanout. The production binary on the VPS is already compiled.
Voice chat in a poker game built by cron jobs.
Push-to-talk, not open mic. The capture runs on an AudioWorklet thread — a dedicated audio processing thread in the browser. It resamples from 48kHz native to 16kHz mono, applies 10ms fade-in/fade-out on PTT transitions, and posts Int16 PCM chunks to the main thread. The server relays voice frames to all other room members with per-user muting support. Playback on the receiving end uses a 150ms jitter buffer before audio starts. It works. You can trash talk while folding.
The Godot native client handles it differently — voice_chat.gd manages per-speaker audio nodes that are created dynamically when someone talks and cleaned up when they stop. Same binary PCM protocol, different audio backend.
And the DJ streaming?
Personal radio streams for every connected player, plus a DJ mode where the host controls playback for the whole table. The MusicEngine uses chunked decoding via miniaudio — roughly 20KB of RAM per stream instead of 60MB for a full decode. That means the server can handle hundreds of concurrent streams without running out of memory. Controls: play, stop, skip, pause, loop. Auto-advance to next track. Fourteen-plus tracks in the library.
The vision is simple: you’re playing poker, listening to music, talking to your friends. That’s the product. The social layer isn’t bolted on — it’s the architecture.
What about the client?
Two generations. The original was Love2D — three demo clients that proved the protocol worked. Love Squares for movement, Love Squares Two for shield pings and flares, Love Holdem for the poker table.
The production client is Godot 4, rebuilt from scratch. The main script is 85,000 lines of GDScript. Login screen, lobby browser with auto-refresh, table view with drag-to-spotlight hole cards, full betting UI, lobby and in-game chat. The card art is the thing people notice first: every card is procedurally drawn. No PNGs. No sprite sheets. No image assets at all. The King has swoopy golden hair. The Queen has a pink wig and gold chain. The Jack is Ted from Tedtrist.
Ted is in the poker game.
Ted is everywhere. RektTek is the shared universe. The same corporation that built the S.H.M.U.P-3000 and runs the Dreadnought research station also issues mandatory meeting popups in Tedtrist. The Jack of Spades reports to the same SVP who gets crushed by falling blocks. Shared universe means shared characters.
Platform builds?
Web via Godot WASM export, Linux x86_64, Windows x86_64, Android APK. All in the build pipeline. The web version runs inline on the preview site right now — you can play in a browser tab.
Is it live?
It’s live on a VPS with Caddy reverse proxy and auto-TLS. A five-page neobrutalist marketing site: home, play (with inline game iframe and download buttons), features, technology stack, and FAQ. Dark theme, monospace, zero border radius, green and gold accents. The tagline is “Play poker. Talk trash. Stream bangers.”
Guest login means zero friction. Type a name, leave the password blank, you’re at the table. No account, no email, no signup flow. For production, the plan is WordPress-issued JWT tokens via a plugin that’s already written — the x00f.com website becomes the auth provider. License management, session limits, role-based access, per-game authorization. The infrastructure is ready. The switch is just changing which auth backend the server validates against.
How’s the QA?
Fifty tests passing in 2.24 seconds, zero failures. Coverage spans health checks, authentication flows (local success, wrong password, duplicate auth, unauthenticated rejection, session limit enforcement), room lifecycle, chat and whisper, presence, state management at player and room scope, session resume, admin operations, and the full Hold’em hand loop — table creation through showdown, next hand, late joins, fold and raise flows, five-player tables.
What’s left before it ships?
PostgreSQL migration is next — the server currently runs in-memory. Then real domain setup to replace the temporary sslip.io HTTPS. After that: mobile Love2D transport for Android live multiplayer, a repeatable deploy script, observability and structured logging, poker hardening for private card state and side pots, and Godot client production polish.
The factory built a multiplayer poker game with voice chat and streaming music while waiting for humans to playtest ten other games.
That’s the factory. It doesn’t idle. When the single-player pipeline hit a human-gated bottleneck, the swarm found the next load-bearing problem and started building. The multiplayer server isn’t a side project — it’s the same shared-infrastructure pattern that made the single-player pipeline work, pointed at a different problem. One process, many game plugins, real-time transport.
Texas Hold’em is the debut title. It won’t be the last.
Status?
BUILDING. Fifty tests. Live preview on VPS. Five-page marketing site. Four platform builds. Voice chat works. DJ streaming works. Poker works. The factory is ready for PostgreSQL and a real domain. Then it ships.
x00F Hold’em is live on the preview site. Guest login, five seats, push-to-talk, and a DJ queue. The Dark Factory’s eleventh product — and its first multiplayer game — is in the build lane.