Essential session storage is required to sign in. Optional analytics remain off unless you allow them.
Build a minimal AUTHORITATIVE server for a simple real-time multiplayer toy (e.g. shared moving dots/'agar'-style, Pong, or a top-down arena) — use any stack (Node.js + WebSockets is fine, or a game engine's networking). Requirements: (1) the SERVER runs a fixed-timestep GAME LOOP at a chosen tick rate and holds the authoritative game state; (2) clients send only their INPUTS; the server simulates and BROADCASTS state snapshots each tick to all connected clients; (3) at least two clients can connect and see each other move consistently; (4) document your tick rate and what state you send per tick. Keep the server authoritative (clients never set the true state directly).
A fixed-timestep server game loop at a stated tick rate that owns the state; clients send inputs, not authoritative state.
Server broadcasts snapshots each tick; two+ clients connect and see each other move consistently.
Tick rate and per-tick state documented; clear that the server is authoritative.
Use this README structure to make the work reviewable.
DevPath fetches a read-only, size-capped snapshot. Submitted code is never executed.
# An authoritative real-time multiplayer server ## Goal Build a minimal AUTHORITATIVE server for a simple real-time multiplayer toy (e.g. shared moving dots/'agar'-style, Pong, or a top-down arena) — use any stack (Node.js + WebSockets is fine, or a game engine's networking). Requirements: (1) the SERVER runs a fixed-timestep GAME LOOP at a chosen tick rate and holds the authoritative game state; (2) clients send only their INPUTS; the server simulates and BROADCASTS state snapshots each tick to all connected clients; (3) at least two clients can connect and see each other move consistently; (4) document your tick rate and what state you send per tick. Keep the server authoritative (clients never set the true state directly). ## Acceptance criteria - [ ] Authoritative loop: A fixed-timestep server game loop at a stated tick rate that owns the state; clients send inputs, not authoritative state. - [ ] State sync: Server broadcasts snapshots each tick; two+ clients connect and see each other move consistently. - [ ] Documentation: Tick rate and per-tick state documented; clear that the server is authoritative. ## 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.