Behind the Code
DEVLOG
Notes on the architecture bets behind KAINYNE — why the games run the way
they do. Seeded from our in-repo decision records.
Architecture · ADR-0001
Why peer-to-peer WebRTC, not a WebSocket server
KAINYNE games carry their moves over a WebRTC DataChannel between players
rather than relaying everything through a server socket. A tiny Cloudflare
Worker brokers the initial handshake (room codes, offer/answer), then steps
out of the way — so there's no game-state server to scale, pay for, or keep
warm, and a match starts the instant two browsers connect. The tradeoff:
connection setup is fussier (NAT traversal, TURN fallback), which is why a
lot of our engineering goes into making the handshake bulletproof.
Architecture · ADR-0002
One host is the referee (host-authoritative game loop)
Rather than have every peer agree on game state through distributed
consensus, one player's browser is the authority: it runs the rules engine
and broadcasts the resulting state. Clients send intents ("I play this
card"); the host validates and resolves them. It's dramatically simpler than
consensus, it makes cheating harder (clients can't fabricate state), and it
maps cleanly onto how a real card game has one person dealing.
Design · ADR-0012
Every game is a thin consumer of one framework
Our catalog grows fast because new titles aren't rewrites. A five-pillar
"Tabletop OS" framework (actions, resolution, pressure, resources, victory)
plus shared multiplayer-lobby and signaling factories mean a new game ships
as configuration over proven systems. The same per-seat redaction, session
resume, and error-reporting plumbing carries every title — so we spend our
time on what makes each game fun, not on rebuilding the backbone.
The full decision records live in docs/adr/ in the
repository.