Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/TaylorZaneKirk/MMO-Project/llms.txt

Use this file to discover all available pages before exploring further.

All communication between the MMO Project client and server uses a versioned JSON WebSocket protocol over a single persistent connection. Every message carries a type field that identifies the message and a payload object containing message-specific fields. The server is the authoritative source for all game state — no client message directly mutates state.

Design rule

All client messages represent player intent, not player-authored state mutations. The server resolves all outcomes authoritatively and sends the confirmed result back to the client before the client applies any change.

Message format

Every message on the wire follows this envelope structure:
{
  "type": "message_name",
  "payload": { }
}
The type value matches the name field in protocol-v1.json. The payload object contains the fields documented for that message. Empty or missing payloads are not used — every message has at least one payload field.

Version

The protocol version for this slice is v1. The client sends protocol_version: "v1" as part of login_request. The server rejects any message that carries an unknown or unsupported protocol version and closes the connection.

Complete message catalog

Message NameDirectionPurpose
login_requestC→SAuthenticate with account credentials and declare protocol version
login_responseS→CReturn login outcome, session ID, and account ID
character_load_responseS→CBind the authenticated session to the account’s character
enter_world_responseS→CDeliver starting map position and presence source
world_snapshotS→CDeliver full authoritative world state including player, NPCs, ground items, and remote players
player_state_updateS→CBroadcast a remote player’s updated position and state to map peers
npc_state_updateS→CBroadcast an NPC’s updated position and state to the map
movement_intentC→SRequest movement to a target tile coordinate
movement_appliedS→CConfirm the authoritative movement result and updated position
character_state_updatedS→CPush a revisioned delta of changed character streams (delta clients only)
ground_item_spawnedS→CNotify the map that a ground item has become visible
ground_item_removedS→CNotify the map that a ground item has been removed
player_entered_mapS→CReserved — notify the map that a player has joined (not yet active)
player_left_mapS→CReserved — notify the map that a player has departed (not yet active)
world_resync_requestC→SRequest a fresh world snapshot after detecting a revision gap
inventory_item_use_requestC→SRequest a primary use action on an inventory item
inventory_item_use_responseS→CReturn the authoritative outcome of the use action
inventory_item_drop_requestC→SRequest that an inventory item be dropped onto the current tile
inventory_item_drop_responseS→CReturn the authoritative outcome of the drop action
ground_item_pickup_requestC→SRequest pickup of a visible ground item on the current tile
ground_item_pickup_responseS→CReturn the authoritative outcome of the pickup action
equipment_item_unequip_requestC→SRequest that an equipped item be moved back to inventory
equipment_item_unequip_responseS→CReturn the authoritative outcome of the unequip action
logout_requestC→SEnd the session explicitly and clear map presence
reconnect_requestC→SAttempt to restore a disconnected session within the grace window
reconnect_responseS→CReturn the reconnect outcome and restored position

Excluded from v1

The following feature areas are outside the scope of this protocol slice and have no messages in protocol-v1.json:
  • Chat
  • Combat
  • NPC interaction
  • Storage
  • Admin commands
player_entered_map and player_left_map are reserved for the next presence-delta slice. Current connect, disconnect, and reconnect flows still use full snapshots for map-membership reconciliation.

Build docs developers (and LLMs) love