Coordination and multiplayer
Add deterministic match, race, roster, round, and input-arbitration policy without creating a privileged multiplayer activity fork.
Coordination is policy beside an activity. The activity still owns scoring and state transitions. The trusted host owns invitations, authenticated rosters, connections, sequenced signals, retries, presence, and recovery.
Public interface
Prop
Type
Wrap it with defineCoordinationEngine and expose it with createCoordinationWorkerHandler.
What policy may decide
- roster eligibility and readiness;
- active actor or simultaneous input topology;
- round/leg/set transitions;
- invalid or out-of-turn input handling;
- rematch eligibility;
- semantic match outcomes and Story Events.
What the host still owns
- finding and inviting members;
- authorization and private visibility;
- ordering signals exactly once;
- network transport and reconnect;
- assigning input routes and Station bindings;
- starting, pausing, recovering, or expiring the ephemeral Live Run.
A Live Run coordinates one solo activity or multiplayer match. It is not an enclosing practice session and does not become practice-history truth.
Topologies
Shared physical source
Two Darts players alternate on one board. The coordination policy chooses the active participant. Station routes the same source to the Live Run, and the host attributes accepted input according to authenticated turn policy.
Independent sources
Two runners or puzzle players produce evidence from separate devices. The policy accepts simultaneous or phase-specific progress and declares outcomes without one package connecting directly to the other.
Required scenarios
Prove invite/accept, readiness, ineligible roster, turn or phase arbitration, disconnect/reconnect, completion, correction after provisional result, rematch, duplicate signal, and deterministic recovery from the same sequenced log.