AC-0001: v0 Two-Client Multiplayer Slice

[danieldilly]

Governance Classification

Requires new domain concept (DM-*)

Problem Statement

The system currently lacks a functional end-to-end multiplayer implementation. Without this foundational slice, we cannot:

• Validate that the authoritative multiplayer architecture (ADR-0001, ADR-0004) works in practice
• Verify that the deterministic simulation (INV-0001, INV-0002, INV-0004) maintains integrity across networked gameplay
• Test replay verifiability (INV-0006) in a realistic multiplayer scenario
• Prove the Simulation Core boundary (DM-0014) remains uncompromised when integrated with networking

This creates a critical validation gap for the v0 milestone: we have architectural decisions and invariants defined, but no concrete implementation demonstrating they work together.

Player Value / Design Intent

This enables the foundational experience of real-time multiplayer gameplay where:

• Two players can connect to a shared game session and see each other's actions
• Players experience responsive, synchronized gameplay (WASD movement as the initial slice)
• The system can reliably reproduce matches for debugging, anti-cheat, and competitive integrity

While players won't directly see "AC-0001" on a feature list, this unlocks all future multiplayer features: matchmaking, team play, competitive modes, and esports infrastructure. Without this foundation, the game remains single-player only.

Constitution IDs

• INV-0001 (Deterministic Simulation)
• INV-0002 (Fixed Timestep)
• INV-0004 (Simulation Core Isolation)
• INV-0006 (Replay Verifiability)
• DM-0010 (Match)
• DM-0011 (Server Edge)
• DM-0014 (Simulation Core)
• AC-0001 (v0 Two-Client Multiplayer Slice)
• KC-0001 (Simulation Core Boundary Violation)
• KC-0002 (Replay Verification Blocker)
• ADR-0001 (Authoritative Multiplayer Architecture)
• ADR-0004 (Server-Authoritative Architecture)
• ADR-0005 (v0 Networking Architecture)

Acceptance Criteria

• Two native Game Clients can connect to a Game Server Instance, complete handshake, receive initial authoritative state (JoinBaseline), and remain synchronized
• Each Game Client can issue WASD movement inputs; the authoritative simulation processes them; both clients see their own and the opponent's movement via snapshots with acceptable consistency
• The authoritative simulation produces identical outcomes for identical input+seed+state across multiple runs (same build/platform), verified by Tier-0 replay test
• The Simulation Core performs NO I/O, networking, rendering, or wall-clock reads (INV-0001, INV-0002, INV-0004)
• Server enforces input validation: magnitude limit, tick window sanity check, and rate limit per docs/networking/v0-parameters.md; malformed inputs are rejected without crashing
• A completed match produces a replay artifact (initial state, seed, input stream, final state hash) that can reproduce the authoritative outcome on the same build/platform (INV-0006)

Proposed Solution

High-level approach (detailed spec to be created post-approval):

1. Simulation Core interface: Define tick-indexed Input/Output boundary (INV-0005)
2. Server Edge: Implement connection handling, input collection, snapshot broadcasting
3. Game Client: Implement connection, input submission, snapshot application
4. Replay recording: Capture input stream + initial state during match execution
5. Replay verification: Tier-0 test that replays a recorded match and validates final state hash

Implementation will follow ADR-0005 (v0 Networking Architecture) and create a spec (FS-XXXX) before coding begins.

Non-Goals

• Client-side prediction or lag compensation (deferred to post-v0)
• Interpolation or extrapolation for smoother rendering (deferred to post-v0)
• Matchmaking, lobby system, or player authentication (deferred)
• Cross-platform determinism verification (deferred per ADR-0005; v0 scoped to same-build/same-platform)
• Bandwidth optimization, compression, or protocol efficiency (v0 focuses on correctness, not performance)
• Reconnection/migration handling (deferred)
• More than 2 clients (v0 is explicitly a two-client slice)
• Gameplay beyond WASD movement (initial slice is intentionally minimal)

Risk Notes

Potential risks:

• First-time integration risk: This is the first time we're connecting Simulation Core to networking. Boundary violations (KC-0001) are the primary architectural risk.
• Determinism validation: Replay verification (INV-0006) must work from day one. If determinism breaks, it's a release blocker (KC-0002).
• Scope creep: Resist adding client prediction, interpolation, or other "nice-to-haves" to v0. Keep it minimal and testable.
• Unspecified domain concepts: If DM-* entries for networking primitives don't exist, they must be defined before/during implementation to maintain Constitution integrity.

Mitigation: Strict adherence to Tier-0 gate plan, early replay test implementation, and ruthless non-goal enforcement.

Verification

• I have selected the correct governance classification
• I have listed relevant Constitution IDs (or confirmed none apply)
• If this requires a new domain concept or ADR, I understand those must land before/with implementation

[danieldilly]

Completed in PR #11. All 58 tests passing, spec FS-0007 status updated to Implemented.