Essential session storage is required to sign in. Optional analytics remain off unless you allow them.
Build a more complete multiplayer backend around your game (design/implement as far as your stack allows; document any parts you design rather than fully build). Requirements: (1) MATCHMAKING — group waiting players into matches (a simple skill/latency or FIFO matcher), with a stated match-quality-vs-queue-time approach; (2) SESSION MANAGEMENT — spawn/allocate a game session per match with a clear lifecycle (allocate → play → end → clean up) and reconnection to the same session; (3) PERSISTENCE — store player data (accounts/progression) in a database, loaded on join and written back at match end, with an economy/currency change done as an atomic transaction; (4) DEFENSIVE anti-cheat via server-authoritative validation across the systems; (5) LOAD TESTING — drive the server with many simulated players/bots and report the concurrency ceiling and tick-time behavior; (6) OBSERVABILITY — expose metrics (tick time, player/match counts, queue time) and a short runbook. Document the architecture and the build-vs-designed split honestly.
A working (or clearly designed) matcher with a stated quality-vs-wait approach; per-match session lifecycle + reconnection to the same session.
Player data in a DB (load on join, write back on end) with an atomic economy transaction; server-authoritative validation across systems.
Bots/simulated players find the concurrency ceiling and tick behavior; metrics (tick time, player/match counts, queue time) + a short runbook.
Use this README structure to make the work reviewable.
DevPath fetches a read-only, size-capped snapshot. Submitted code is never executed.
# A multiplayer backend: matchmaking, sessions & ops ## Goal Build a more complete multiplayer backend around your game (design/implement as far as your stack allows; document any parts you design rather than fully build). Requirements: (1) MATCHMAKING — group waiting players into matches (a simple skill/latency or FIFO matcher), with a stated match-quality-vs-queue-time approach; (2) SESSION MANAGEMENT — spawn/allocate a game session per match with a clear lifecycle (allocate → play → end → clean up) and reconnection to the same session; (3) PERSISTENCE — store player data (accounts/progression) in a database, loaded on join and written back at match end, with an economy/currency change done as an atomic transaction; (4) DEFENSIVE anti-cheat via server-authoritative validation across the systems; (5) LOAD TESTING — drive the server with many simulated players/bots and report the concurrency ceiling and tick-time behavior; (6) OBSERVABILITY — expose metrics (tick time, player/match counts, queue time) and a short runbook. Document the architecture and the build-vs-designed split honestly. ## Acceptance criteria - [ ] Matchmaking & sessions: A working (or clearly designed) matcher with a stated quality-vs-wait approach; per-match session lifecycle + reconnection to the same session. - [ ] Persistence & anti-cheat: Player data in a DB (load on join, write back on end) with an atomic economy transaction; server-authoritative validation across systems. - [ ] Load testing & observability: Bots/simulated players find the concurrency ceiling and tick behavior; metrics (tick time, player/match counts, queue time) + a short runbook. ## Verification - [ ] Document installation and run commands. - [ ] Record automated checks and their exact commands. - [ ] Add representative output, screenshots, or a short demo where useful. - [ ] Confirm failure paths and known constraints. ## Decision log ### Decision title - Context: - Choice: - Alternatives considered: - Tradeoffs: ## Evidence - Link each rubric criterion to the file, test, or artifact that demonstrates it. ## Known limitations - List what is intentionally out of scope and what should be improved next.