Skip to content

Multiplayer launch implementation

Active work, September 9, 2026. Companion to the audited multiplayer platform design.

The owner confirmed hundreds of thousands of total campaign visitors, with staged concurrency growth. Do not describe this as 100,000 simultaneously tested players. The accepted scope includes gameplay and Dave UX, plus all six architecture stages. Evaluations in the design remain evaluations until evidence supports adoption.

Delivery checklist

  • [x] Read current Sonnet usage and validate existing production Dave notebooks without modifying player data.
  • [x] Fix inconsistent model response history and tolerate harmless JSON wrappers/optional annotations without relaxing native rewards.
  • [x] Add private, correlated server/client Dave outcome diagnostics; separate generation, storage, ledger, rate and connection failures.
  • [x] Validate paid replies commit with their ledger and usage records; failed transactions preserve balance/history.
  • [x] Correct display-name analytics; use stable anonymous IDs, verified account IDs, login identification and logout rotation.
  • [x] Finish English/Chinese visual/browser recovery checks on desktop and phone; publish and verify production.
  • [ ] Shared platform guest bootstrap, legacy token adapter, verified attribution and server-observed lifecycle events.
  • [x] Room registry, host ownership/fencing, assigned endpoint support and scoped admission capabilities.
  • [ ] Burst admission, jittered reconnect, resume priority and drain lifecycle.
  • [x] Persistence failure semantics, ordered/revisioned player writes and acknowledged shutdown; guest-safe storage.
  • [x] Separately addressed US and Singapore hosts with private staged rollout; public enablement remains gated.
  • [ ] Public room discovery and casual matchmaking with cancellation/reservations.
  • [x] Cloudflare independent static delivery, verified downloads and public game startup.
  • [ ] Cloudflare bounded queued lifecycle ingestion, deduplication and backlog visibility.
  • [ ] Namespaced creator storage and execution capability boundary; isolated runtime/pilot evaluation.
  • [ ] Sustained staging load, bursts, reconnect storms, host failure/drain, stale credentials, database failures.
  • [ ] Measured real Asia–Asia/Asia–US gameplay; user/device assistance may be required for real network evidence.

Current evidence and limits

The three sampled production notebooks validate. Recent Sonnet requests include successful billed replies and pvz-dave-unheard attempts completing in 2–6 seconds. The older endpoint groups silent background decisions and failed delivery together, so it does not establish the exact historical error. Existing PostHog has game networking events but no Dave-specific outcomes. No notebook reset is justified.

Railway HTTP logs subsequently established that the recent failed requests returned 422, including the two failures immediately after the successful 01:11:12 UTC reply. This is the generated-reply validation path. The old code did not retain the specific validation reason; the new bounded diagnostics do. Server commit 7af34179d is deployed successfully. PvZ commit d69ac81, release 7fc68c348b, is uploaded to S3 and verified at /pvz/. Both the main service (DB and Redis included) and realtime health endpoints return 200.

Persistence implementation now has ordered/coalesced snapshots, SQL revision checks, bounded payloads/deadlines, account-only progress sessions, restore failure rejection and acknowledged shutdown. The 80 game-host tests pass, including real PostgreSQL-engine conflict/failure tests and real WebSocket guest-outage/shutdown tests. Full build and typecheck pass. The additive revision migration is applied to development and the realtime production database. Commit 817aba0eb is deployed to the realtime host; health/status and startup logs verify it. Status distinguishes humans from bots (the five sea bots do not represent five people). This does not yet provide global room ownership, room resurrection or infrastructure-preserved draining.

Cloudflare yumina-game-edge version 2026-09-10.2 is live; source, route IDs and rollback are in infra/game-edge/README.md. Eight unit tests, full live SHA-256 comparisons for WASM/pak, cache hits, byte ranges and a production phone browser pass. /pvz?join=...&lang=... preserves its parameters. /pvz-models* has an explicit no-Worker exception. The route falls back to the existing main-service handlers if the account hits a Worker request limit. Worker account settings report the Standard usage model, but billing-subscription access is denied; the user has been asked to verify Workers Paid before promotion. A storage-provider read-only credential scoped to the two game prefixes remains a hardening follow-up.

Local actual-WASM checks use an isolated account/provider fixture; they prove UI behavior, not live Sonnet availability. Provider formatting and monetary settlement have separate service/SQL tests. Build and typecheck passed before the latest UI-only refinement. Railway CLI authentication was restored during this work; MCP had an OAuth scope problem.

No multi-region capacity or full campaign readiness is claimed until the corresponding gates are recorded here. A host replacement cannot preserve process-local PvZ rooms; drain and ownership must be deployed before replication.

Shared identity foundation: a signed platform cookie and standalone browser SDK now migrate existing PvZ guests, preserve live guest seat tokens through login, and link observed guest activity only through authenticated account requests. Atomic link ownership prevents combining two registered accounts; stale-tab/account checks prevent login races. The additive game_guest_links migration is applied to development and production. Identity/server, SDK and PvZ analytics tests pass; full build/typecheck pass. The generic room adapter and authoritative lifecycle reporting remain separate unfinished work.

Regional foundation 4f1bd867c is deployed to the main control API and two independently addressed relay-only hosts (US West and Singapore). The hosts have public admission keys and their own heartbeat secrets, with no account database or signing private key. Both passed actual desktop-host/Chinese-phone-guest invite and forced-reconnect tests against production APIs. The public rollout flag remains off. Six control tests, SQL concurrency races, and the game tests establish reservation/idempotency, owner fencing, replay prevention and same-boot resume. This is not host-crash recovery.

Generic GameRoomConnection now supports shared guests, cancellation and a single 15-second admission deadline; five regression tests pass. Its automatic reconnect and regional runtime migration are still separate work. The regional PvZ adapter has jitter and local resume; authenticated resume priority is implemented and tested under a full handshake budget. Lifecycle Worker/Queues resources now exist, with a tested deduplicating SQL sink and bounded server emitters; deployed event verification is the next gate. See infra/game-events/README.md and infra/game-regions/README.md for resource IDs, limits and recovery behavior.

Further save audit found that the original PvZ cloud PUT trusted whichever account cookie was current, while the native profile stayed pinned to the tab's original account. The new endpoint requires that original account ID and observed revision. A different account or competing tab cannot overwrite it; preconditionless old clients must refresh before cloud writes resume. Device-local saving continues. The game also limits retries during outages and keeps a recovery copy on conflict. Owner/CAS SQL tests, browser-shell save tests and full build/typecheck pass. The latest actual-WASM Chinese desktop/phone test again passes the shared model pill, credit errors, provider switching, failed-reply recovery and native restart.