Colyseus room protocol
Defines which commands a room accepts and how they change the shared game. It validates payloads against the authenticated player and current match phase before applying server-owned outcomes.
colyseus-room-protocol
See how it helpsWhen is it useful?
Use it before implementing room messages or when malformed client commands can affect other players.
What does it help you do?
- Maps room creation, admission, play and disposal states.
- Validates each command against authenticated player identity.
- Bounds payloads and separates durable outcomes from room memory.
Try asking this
Define move, ready and attack commands for our multiplayer arena. Send an oversized payload, attack before the match starts and try moving another player’s unit. Reject invalid commands without changing the room, while valid actions produce a clear authoritative state update.
Detailed documentation
Read the skill’s original instructions, examples and checks in their authored language.
Show less
Colyseus — room protocol
Use when designing Colyseus rooms, message contracts, command validation or state ownership.
Version and project gate
Inspect Server, client SDK and @colyseus/schema versions, TypeScript/decorator configuration, room registrations, auth hooks, patch/simulation rates, transport, deployment topology and persistence adapters. The 0.17 reconnection lifecycle must not be assumed for older versions. Never turn a task into an engine upgrade without the user’s intent. Read the version-matching official reference when an API decision depends on it.
Work
Define room creation, admission, active play and disposal transitions. Map each client command to authenticated identity, validation, authoritative mutation and response. Separate durable game outcomes from ephemeral room state. Bound payload size and command frequency from gameplay requirements.
Deliver
A versioned command/state contract and a minimal authoritative room implementation. Keep the change in the existing project structure; separate actual observations from the proposed acceptance scenario below.
Failure to prevent
Room membership alone does not authorize acting for another player; do not trust client-reported rewards or positions.
Acceptance scenario
Send malformed, out-of-order and duplicated commands from two identities and confirm authoritative invariants remain intact. Follow the project’s execution and verification permissions. If execution or a target device is unavailable, provide the reproduction steps and name the remaining uncertainty; do not mark it passed.
Scope and sources
This skill belongs to Relay. Agent selection is restricted by Orqestria’s assigned-agent policy, including forced skill selection; instruction text alone is not an access control. These are original task workflows researched from official documentation, not a copied or endorsed vendor skill.
Included files 1
SKILL.md