Realtime Game Platform

The problem

Most indie realtime card-game builds stop at the rules engine and a happy-path multiplayer loop. They skip the parts that turn a game into a B2B-integratable platform: reviewer audit trails, a risk-escalation queue, an admin shell with role-gated moderation, and a webhook bridge so external systems can subscribe to platform events. We wanted the full stack — client, server, admin, and review — architected so additional games or downstream integrations could plug in without rewriting the core.

How we built it

1. 01Built the server as a typed Dart engine with 445 unit + integration tests covering hand flow, pot splits, and disconnect recovery — the rules engine is one component, the platform around it is the rest.
2. 02Designed a ReviewQueue with SqlReviewCaseStorage, a full audit log, a reviewer role gate, and five REST endpoints for human moderation. Every multiplayer session is reviewable end-to-end.
3. 03Shipped a Flutter admin screen (HttpRiskReviewRepository) plus a WS session-open auto-enqueue hook so the review queue fills automatically as sessions open.
4. 04Added a RiskWebhookBridge emitting `risk.case.enqueued` and `risk.case.decided` events for downstream B2B fan-out — external compliance, analytics, or moderation systems consume the same stream.

Outcome

Phase 22 architecturally complete: 445 server tests, 149 network tests, 23 admin tests, all green. Postgres adapter is a ~20-line swap from the SQLite-backed development path. The platform stack (audit log, review queue, admin shell, webhook bridge) is game-agnostic and ready to host a different card game with no platform-layer changes.

Next up

Provision the Postgres executor adapter, then either add a second card game on top of the same platform, or expose the review-queue + webhook bridge as a standalone B2B service.