Virtual Tabletop blueprint

This is a design blueprint, not a shipped example. A tabletop recipe maps decks to Stack/Source, board areas to Space zones, characters and pieces to immutable Tokens, and players to Agent identities. Attachments and provenance can represent equipment, counters, and transformed pieces.

Rules to decide first

Define ownership, visibility, legal zones, turn/phase transitions, and whether an object can be edited by more than one player. A face-down placement is a UI state, not automatically private: peers may still receive the underlying CRDT data. Hidden hands require a deliberate projection or encryption design.

Use atomic, validated engine.dispatch() actions and game:setState for game-specific state. Keep derived board views rebuildable. For concurrent movement, preserve contested placements or declare an explicit deterministic winner; for turn games, add stale-turn guards and choose an authority for resolution.

When to use it

HyperToken fits replayable, token-centric tabletop rules and offline-friendly play. A server-authoritative room can own the Engine when strict ordering is more important than peer autonomy. It is not a replacement for a renderer, voice/presence service, physics engine, or a secure referee. Avoid it for games whose central difficulty is high-frequency simulation or confidential state with no workable projection boundary.