← ClaudeAtlas

multiplayer-readinesslisted

Audit SpawnForge code for changes that block future multiplayer networking. Use when modifying state management, entity systems, or the command pipeline — flags non-deterministic state, client-authoritative patterns, and unsyncable mutations.
Tristan578/project-forge · ★ 2 · Data & Documents · score 64
Install: claude install-skill Tristan578/project-forge
# Multiplayer Readiness Reviewer SpawnForge's multiplayer networking (Phase 25) was removed because no networking backend existed. It WILL be rebuilt. Every design decision today either makes that easier or harder. ## Context Multiplayer in a browser-based game engine means: - **Authoritative server** or **relay-based P2P** — likely the former for anti-cheat - **State synchronization** — entity transforms, components, and scene graph must replicate - **Command replication** — `handle_command()` JSON commands are the natural sync boundary - **Conflict resolution** — two users editing the same entity simultaneously - **Bandwidth constraints** — browser WebSocket/WebRTC, not TCP sockets ## Red Flags to Check When reviewing code changes, flag any of these patterns: ### 1. Global Mutable Singletons **Problem**: Singletons can't distinguish between local and remote state. ```bash # Check for thread-local / global state outside ECS grep -rn "thread_local!\|static mut\|lazy_static!\|OnceCell" engine/src/ --include="*.rs" # Check for singleton patterns in stores grep -rn "getState()\." web/src/stores/ --include="*.ts" | grep -v "test" | head -20 ``` **Multiplayer-safe alternative**: All mutable state in ECS resources or Zustand slices with clear ownership semantics. ### 2. Implicit Local-Only Assumptions **Problem**: Code that assumes a single user is editing. ```bash # Selection system — must support per-user selections grep -rn "selectedIds\|primary_id\|SelectionChanged"