Modeling games

Start with entities and invariants. A card, piece, item, or task can be a Token with a stable ID and metadata. Tokens are immutable; transformations create new records and provenance (_mergedFrom/_splitFrom). Put ordered ownership in a Stack or Source, spatial membership in Space, and lifecycle fields under a game-specific top-level key.

An invariant must survive merge: unique identity, legal ownership, valid phase, resource bounds, and a defined treatment of duplicate or competing actions. Validate before mutation and use deterministic seeds for replayable randomness. Do not assume that a CRDT merge validates game rules or creates a serial order.

Choose authority per rule. Peer-authored state is useful for mergeable play; an authoritative Engine is appropriate for admission, ordering, moderation, or settlement. A relay is only transport. If a game needs strict global transactions, secret state, or high-frequency simulation, HyperToken may be the wrong foundation.