Shadda

Shadda is a game table, not a game. Five games run on it today — Tarneeb, Baloot, Trix, Spades, and Chess — with server-authoritative rules, seat-safe views, bots, reconnectable seats, rematches, and persistent named tables.

The architectural rule

One rule holds the whole system together, and almost every design question resolves by applying it:

A game engine owns rules and game state. A room owns people and presence. The client receives only the view its seat is allowed to see.

That separation is what makes adding a sixth game a contained job rather than a rewrite. Engines are deterministic and know nothing about sockets, presence, or identity; rooms know nothing about trumps or checkmate.

Seat-safe views are the security half of the same rule. The server never sends a client a state it could cheat with — your opponent's hand isn't hidden in the UI, it never arrives.

apps/client       Expo and React Native application
apps/server       HTTP, Socket.IO, rooms, matches, bots, persistence
packages/games    Deterministic game engines and game metadata
packages/protocol Shared client/server wire contract

Operating model

Production is deliberately a single always-on server. Live matches, presence, timers, and Socket.IO membership are process-local — the fast path stays in memory — while SQLite holds room snapshots, deal seeds, and an accepted-command log used to recover state across a restart.

It is a small-scale choice made on purpose. Distributing the live match state would buy scale I don't need yet and cost a class of bugs I would rather not own.

Reconnection

Card games are played on phones, and phones drop connections mid-trick. A seat is a durable thing that a device attaches to, rather than being the device itself, so walking through a tunnel loses your connection but never your hand.