Skip to content
WalkRPG Wiki

Multiplayer scope — M1 package (async lightweight co-op + full guild + scheduled regional events)

D-025: Multiplayer scope — M1 package (async lightweight co-op + full guild + scheduled regional events)

Pick 9 from the 2026-05-21 vision verification session specified “sync co-op + guildy + regional events” as “matches D-007 §4 full networked at maximum scale.” game-director’s triage flagged this as the only HARD-gated D-candidate in the queue — D-008 (stack canon) assumed WebSocket presence but NOT sync-walk session orchestration; D-015 reshaped backend cost surface after D-007 §4 was authored.

tech-architect’s pre-ratification cost memo (ops/research/d-025-multiplayer-cost-estimate.md, 2026-05-21) named pick 9’s literal reading as veto-grade against D-015: real-time sync walking requires production GCP stack unfreeze (~€1-5k/mo infra, 6-12 months engineering, GKE Autopilot WebSocket pool, plus an entire D-007 §3 anti-cheat re-derivation that does not currently exist). D-015’s “Phase 13/14 = local Docker → Hetzner CX22 VPS €5/mo, mock auth retained” cannot absorb that cost.

D-025 ratifies the M1 (recommended) package: the largest multiplayer scope that fits D-015’s incremental phasing without reversing it. Three multiplayer surfaces (sync co-op + guildy + regional events) all ship — at the cheapest version of each. Real-time sync walking deferred explicitly to post-Phase-16 production unfreeze (earliest ship: 18-24 months from 2026-05-21).

1. M1 package — three surfaces

SurfaceWhat ships (Phase 13/14)What defers
Async lightweight co-opPaired Walkers (max 2) opt into a “co-walking session” sharing a tropy queue (D-020) + PRNG seed (D-010) for a bounded session window (~30 min default). Combat resolves asynchronously when both Walkers next sync HealthKit / Health Connect — server reconciles results. “Fight the same tropy, see the same outcome when you both sync.”Real-time WebSocket-synced walking sessions (post-Phase-16); 3+ Walker co-op sessions; cross-device clock-synchronized turn order.
Full guild infrastructureGuild entity (id, name, roster, hierarchy, emblem, treasury), GuildMember + GuildRole models, polling chat (Phase 13: ~10-30s polling, Postgres-backed, hard message cap per guild), real-time chat (Phase 14 VPS: long-polling at 1-3s), guild events (one per month authored by mechanics-designer, gated to avoid live-ops burden), guild-level rep tracking, FCM push for mentions / events.Real-time WebSocket chat (post-production only); guild-vs-guild content (post-Phase-16); guild member presence at sub-second granularity (post-production).
Scheduled regional eventsServer-scheduled events per region (e.g. “Mglica leak attack — 1 hour window”). FCM push at start. Eligibility resolved at participation time (in-region check via D-022 Map state + D-007 §3 attestation). Postgres-archived scoring + leaderboard with hourly refresh in Phase 13, sub-second leaderboard in Phase 14 (Redis sorted set).10k-concurrent live events (post-production); cross-region events (Phase 16+); live admin tool for event configuration (Phase 13 ships YAML-as-config, admin tool post-production).

2. Hard constraints (ratified, NOT amendable B-level)

Seven constraints from tech-architect’s cost memo. Each closes a future re-litigation:

  1. Real-time sync walking sessions are post-Phase-16 only. Earliest plausible ship: 18-24 months from 2026-05-21. The deferral is explicit — D-025 §What-does-NOT-decide forbids B-level “incremental sync walking work” in Phase 13/14/15. If sync walking ships earlier, it requires a new D-decision reversing this constraint AND addressing the production-stack unfreeze cost (D-015 reversal).
  2. Guild member cap = ≤50 in Phase 13/14, ≤200 in production. Memorystore standard-tier + Postgres on Hetzner CX22 cannot sustain >50-member guild presence + chat fanout. D-008 §3 amended editorially (see §5).
  3. Regional events cap = ≤500 concurrent participants in Phase 13/14, ≤5000 in production. Closed-beta cohort never sees a “10k Walkers respond to Mglica leak” event; the feature exists at smaller scale and grows post-production.
  4. Guild chat is asynchronous through Phase 14. Phase 13: polling at 10-30s intervals. Phase 14 (VPS): long-polling at 1-3s. WebSocket-real-time only post-production. Tester UX is degraded vs Discord/Slack standards through Phase 14; ratified trade-off.
  5. Lightweight co-op session ≠ sync walking session. The M1 lightweight co-op model relies on HealthKit / Health Connect-paced reconciliation, NOT real-time clock sync. UX promise: “fight the same tropy, see the same outcome when you both sync” — NOT “see combat resolve in real-time.” Canon, not a Phase 13 limitation.
  6. Sync co-op anti-cheat requires its own future D-decision. D-007 §3’s anti-cheat rules assume one Walker per session. M1’s lightweight co-op reconciliation MUST validate against HealthKit / HC for both Walkers independently (catch step-injection vectors). The full sync co-op anti-cheat space (cross-device GPS sanity, timezone consistency, step-rate validation, mid-session attestation gaps) is NEW design space that does not exist. Required: a separate D-decision authored before any real-time sync walking work begins (post-Phase-16). The lightweight co-op M1 reconciliation is W-level under tech-architect within D-007 §3 framing; D-025 forward-references the full sync co-op anti-cheat D-decision without authoring it.
  7. GDPR right-to-delete on shared chat history must be resolved before guild chat ships. D-009 §3 implies full purge within 30 days. Full purge from shared message data does not exist in current schema. D-025 requires either (a) a B-level under tech-architect documenting the chosen posture (full purge / redact to [deleted user] / anonymize-but-retain) with legal review, OR (b) a new D-decision if the posture is genuinely controversial. Default expectation: redact to [deleted user] preserves chat context while honoring deletion; full message body purge happens in the deleted Walker’s own archive.

3. Phasing alignment with D-015

D-025 fits D-015’s Android-first incremental → VPS → iOS → Watch sequence:

  • Phase 13 (Android-first, local Docker → Cloudflare Tunnel): Guild persistence + polling chat (one tester per CEO machine; chat as polling endpoint). Scheduled regional events as YAML-configured cron in NestJS, FCM push, hourly leaderboard. Lightweight co-op session reconciliation worker ships as additional NestJS module (~3-4 weeks W-level — the most complex Phase 13 increment).
  • Phase 14 (VPS Hetzner CX22): Real-time chat upgrade (long-polling 1-3s on single VPS process; ~30 testers concurrent OK). Sub-second event leaderboard (Redis sorted set). Cross-timezone co-walking sessions become feasible (VPS public IP + always-on).
  • Phase 15 (iOS native): M1 carries to iOS without protocol changes. HealthKit’s 30-second opaque sync window means iOS reconciliation UX shows longer “session pending” than Android (acceptable).
  • Phase 16 (Watch-native): Watch surfaces guild notifications + event notifications. Multiplayer state lives on phone; watch shows summary. NO watch-to-watch nearby co-walking via BLE in scope.
  • Post-Phase-16 (deferred): Real-time sync walking, full guild-vs-guild content, 10k-concurrent live events. Requires production GCP stack unfreeze + ~€1-5k/mo infra + 6-12 months engineering. Re-litigated at that time, NOT now.

4. Cross-D coexistence

  • D-007 §4: D-025 specialises — pick 9’s “maximum scale” reading replaced by “sustainable cost envelope under D-015.”
  • D-008 §3: Editorial amendment under §5 — Guild Master sub cap shape.
  • D-009 §3: Constraint 7 surfaces shared-chat right-to-delete as canonical follow-up. D-009 §3 stands; D-025 names the subordinate question.
  • D-010: Lightweight co-op uses shared PRNG seed + Walker-first per D-010 §2 (each Walker’s local resolution is Walker-first locally; server reconciliation merges). NO amendment to D-010 under M1. (M2’s real-time sync WOULD require D-010 amendment — explicitly deferred.)
  • D-015: Fully respected. No reversal, no earlier-than-D-015 GCP unfreeze.
  • D-018: Each Walker spends own Energy in co-op session. NOT shared.
  • D-020: Co-walking session shares tropy queue; combat outcomes are independent per-client. No D-020 amendment.
  • D-022: Co-walking session surfaces both Walkers as map presence indicators on shared session’s Map view. Regional events render as global map pins during window. ui-designer W-level for visual treatment.
  • D-023: Co-op rejestry deferred per D-023 §What-not-decide — D-025 inherits.
  • D-024: Co-op quest chain interaction deferred per D-024 §What-not-decide — D-025 inherits. Two Walkers cannot share a main-quest chain. Co-op hidden-quest credit allocation = B-level (mechanics + narrative joint).

5. D-008 §3 editorial amendment (Guild Master sub cap)

D-008 §3 currently reads: “optional $2.99/mo guild master subscription unlocking custom emblems, larger guild member cap, regional event hosting.”

Amended editorially under D-025: “…larger guild member cap (specifically: 50 free / 100 with sub in Phase 13/14; 100 free / 200 with sub in production), …” Editorial — D-008 §3’s intent (sub unlocks larger cap) preserved; only the cap shape is named. Note: the amendment is two-tier (free + sub) because D-025 constraint 2 requires a hard free-tier cap for resource-budget reasons; D-008 §3 originally named only the sub-tier without specifying a free-tier cap, so D-025 §5 implicitly canonizes both. CEO ratifies the implicit free-tier cap inline alongside the sub-tier shape. Same editorial-amendment pattern as D-016’s D-006 §Pillar 3 (70%→75%) and D-019’s CLAUDE.md Pillar 2 amendments — D-008 §3 stands; D-025 §5 sharpens the cap-shape detail.

What D-025 does NOT decide (delegated)

  • Specific guild persistence schema — W-level (tech-architect).
  • Lightweight co-op session reconciliation worker design (riskiest M1 piece; must validate against HealthKit / HC for both Walkers, not step-injection vector) — W-level (tech-architect; 3-4 weeks effort).
  • Guild Master sub feature set beyond cap (emblems, event hosting authority) — B-level (mechanics + game-director joint).
  • First regional event authoring (Mglica leak attack worked example) — W-level (game-director + mechanics-designer joint).
  • Co-walking opt-in surface (invite, accept, etc.) — ui-designer.
  • Co-walking session abort / rejoin protocol — W-level (tech-architect).
  • Cross-timezone co-walking step-validation (M1 supports — Walkers in different cities CAN co-walk; D-007 §3 GPS sanity applies per-Walker, not cross-Walker) — W-level (tech-architect).
  • GDPR right-to-delete posture for shared chat — B-level (tech-architect drafts, CEO inline ratifies at posture draft); see constraint 7.
  • Hidden-quest credit allocation across paired Walkers (D-024 cross-ref) — B-level (mechanics + narrative joint).
  • Co-walking session shared Energy (D-018) — explicitly NO (each Walker spends own Energy); recorded for future agent clarity.
  • Real-time sync walking work of any kind in Phase 13/14/15 — FORBIDDEN at B-level. Requires new D-decision reversing constraint 1.
  • Sync co-op anti-cheat D-decision authoring — deferred per constraint 6; required before any post-Phase-16 sync walking work begins.

Rejected alternatives

  • M2 (pick 9 literal — real-time sync walking + 10k concurrent events + WebSocket guild chat). Rejected — veto-grade against D-015. ~€1-5k/mo infra cost, 6-12 months engineering, ~24-36 months roadmap reshape. Reversing D-015 to absorb M2 means: no VPS phase, direct GCP from Phase 13, full real-time multiplayer in scope from day one, no incremental release. Material design call CEO declined; pick 9’s “maximum scale” wording was authored before D-015 cost ceiling was visible.
  • M0 (guild + scheduled events, NO co-op surface at all). Rejected — sells pick 9 “sync co-op” element short. Spirit of pick 9 requires some co-op surface; lightweight async variant delivers spirit without compromising D-015.
  • M1 minus lightweight co-op session module (guild + events + nothing co-op-specific). Rejected — collapses M1 back into M0; loses the “shared session” framing that distinguishes a walking-RPG from a generic mobile-MMO guild chat.
  • Phase 13 ships WebSocket-real-time chat. Rejected — Cloudflare Tunnel + one-tester-per-machine cannot sustain WebSocket connections; long-polling deferred to Phase 14 VPS is the correct sequence.
  • Defer entire D-025 to post-Phase-16. Rejected — pick 9 spirit asks for multiplayer in scope; deferring whole D-025 contradicts D-007 §4 + leaves narrative-designer and game-director without a guild/event surface to author against through Phase 13/14.

Reasoning

D-015 ratified an incremental backend strategy that was authored before D-025’s multiplayer scope was visible. pick 9 (and behind it, D-007 §4) implicitly assumed production GCP — D-015 paused that. D-025 cannot ratify as-aspired without first deciding whether to reverse D-015. tech-architect’s cost memo made the trade-off concrete: pick 9 literal = €1-5k/mo + 6-12 months + production unfreeze. M1 is the largest scope respecting both pick 9’s three-surface spirit AND D-015’s incremental ceiling.

The seven hard constraints (§2) are the load-bearing canonization. Each closes a future re-litigation: real-time sync walking deferral, guild cap shape, regional event scale, chat protocol per phase, lightweight-co-op-is-not-sync distinction, sync co-op anti-cheat as separate D-decision, GDPR shared-chat posture as required follow-up.

The lightweight co-op session is the M1-defining choice. It honors pick 9’s co-op surface using HealthKit / HC-paced reconciliation rather than WebSocket sync. UX promise is bounded — narrative-designer + ui-designer can frame this affirmatively (cooperative editorial-commit per D-013 grammar: two Walkers commit the same chapter from different angles) rather than apologetically.

Forward-compat with post-Phase-16 production migration is structurally clean: M1’s lightweight co-op reconciliation worker becomes the seed for M2’s real-time sync walking server (the reconciliation logic generalises; only the transport changes from HC-paced to WebSocket-paced). No M1 design choice forecloses M2 if/when D-015 reversal is ratified.

Source: pick 9 from ops/memory/vision-qa-2026-05-21.md. Triage by game-director (2026-05-21) flagged HARD risk requiring tech-architect cost re-estimate. Cost memo at ops/research/d-025-multiplayer-cost-estimate.md recommended M1; CEO accepted M1 + all 7 constraints inline at /decide ratification (2026-05-21 session).

(append new D-records below, never above)