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.

LoginScreen is the entry point of the Godot client. It collects account credentials from the player, opens the WebSocket connection via SessionClient, sends a login_request, and drives the full handshake — login, character load, and world entry — before handing off to GameScreen. It does not make authentication decisions; those remain entirely with the server.

​
Scene location

prototype/client/screens/login/LoginScreen.tscn
prototype/client/screens/login/login_screen.gd
The script extends Control and accesses SessionClient through the SessionState autoload (SessionState.session_client).

​
Login sequence

1

Player submits credentials

The player enters account_name and password in the login form. Submitting the form (OK button or Enter key) calls _attempt_login(), which validates that both fields are non-empty before proceeding.
2

WebSocket connection opens

login_screen.gd calls _session_client.connect_to_session(session_url). The default session URL is ws://localhost:5000/session, configurable via the session_url export property. The status label shows "Connecting..." while the handshake is in progress.
3

login_request is sent

When connection_opened fires, login_screen.gd calls send_login_request(account_name, password). The outbound JSON message includes account_name, password, protocol_version: "v1", and runtime_delta_protocol: 1.
{
  "name": "login_request",
  "payload": {
    "account_name": "alice",
    "password": "secret",
    "protocol_version": "v1",
    "runtime_delta_protocol": 1
  }
}
4

Server responds with login_response

The server sends login_response with login_status, session_id, and account_id. On "ok", login_screen.gd calls SessionState.apply_login_response(payload) to persist session_id and account_id, and the status label advances to "Authenticated. Loading character...". On any other status the connection is closed and an error is shown.
5

character_load_response arrives

The server automatically sends character_load_response with character_id. login_screen.gd calls SessionState.apply_character_load_response(payload). If character_id is empty the flow aborts and an error is displayed.
6

enter_world_response arrives and scene transitions

The server sends enter_world_response with map_id, tile_x, tile_y, facing, and presence_source. login_screen.gd calls SessionState.apply_enter_world_response(payload), which writes all five values into the SessionState autoload. The login screen then disconnects its signal handlers and calls get_tree().change_scene_to_file("res://screens/game/GameScreen.tscn").
7

GameScreen reads cached session state

GameScreen._ready() reads SessionState.map_id, SessionState.tile_x, SessionState.tile_y, SessionState.facing, and SessionState.world_snapshot to initialize the viewport and HUD. Any world_snapshot message received before the scene transition was cached by SessionState.apply_world_snapshot; GameScreen picks it up from there. If a world_snapshot arrives after the transition, GameScreen handles it directly via its own message_received subscription.

​
runtime_delta_protocol flag

Sending runtime_delta_protocol: 1 in the login_request opts the client into revisioned delta delivery. In this mode the server sends character_state_updated messages for inventory, equipment, status, and private-ground-item changes instead of a full world_snapshot after every mutation. Clients that omit runtime_delta_protocol or send 0 receive the legacy snapshot-refresh mode, where a complete world_snapshot is sent after every authoritative state change. The prototype client always sends runtime_delta_protocol: 1 via the RUNTIME_DELTA_PROTOCOL_VERSION constant in session_client.gd.

​
Login response statuses

login_status valueClient behaviour
"ok"Store session_id and account_id in SessionState; proceed to character load
"invalid_credentials"Display "Login rejected: invalid_credentials"; re-enable the login form; close the WebSocket
"account_inactive"Display "Login rejected: account_inactive"; re-enable the login form; close the WebSocket
Any other valueDisplay "Login rejected: <status>"; re-enable the login form; close the WebSocket
session_id and character_id are stored in session_state.gd (autoload) as SessionState.session_id and SessionState.character_id. Every subsequent WebSocket request — movement, inventory use, equipment unequip — includes both fields from SessionState rather than storing them locally in the screen or controller that sends the request.

Build docs developers (and LLMs) love

Get started for freeTalk to us