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.

The Godot client is organized around runtime ownership boundaries, not around Godot scene inheritance. Each directory corresponds to a clear area of responsibility — transport, session state, screen flow, actor presentation, or world rendering — so that features can be added to one boundary without entangling others. The only tight coupling that is intentional is between GameScreen and its controllers, which are collocated under screens/game/controllers/ precisely because they are scoped to that scene.

​
Directory layout

PathResponsibility
screens/Scene-level UI flows: LoginScreen and GameScreen
screens/game/controllers/Controllers scoped to GameScreen.tscn: HUD, movement, inventory, equipment, NPCs, remote players, context menus, ground items, and tooltips
screens/game/state/game_session_presenter.gd (message routing) and game_state_store.gd (authoritative state ownership)
network/WebSocket transport — session_client.gd
session/Autoloaded client session state — session_state.gd
actors/Reusable actor scenes: PlayerComposite (layered player sprite) and StaticNpc
world/Map-view and movement-boundary scaffolds; intended to become reusable world-presentation code as the prototype matures
tools/Local asset-preparation helpers (Python scripts). Not runtime code.
assets/Extracted game assets (tiles, actor sprites, UI icons). Git-ignored.

​
Design rules

​
GameScreen stays thin

GameScreen is responsible for session wiring and server-response application only. It connects controller signals to WebSocket send calls and routes incoming server messages to the correct controller. It does not interpret clicks or build menus. All player input — world left-click, world right-click, inventory clicks, and pending interactions such as move-to-pickup — lives exclusively in player_interaction_controller.gd.

​
Transport flow

Raw WebSocket frames travel through four layers before reaching the render surface: 
SessionClient.message_received
  → GameSessionPresenter.handle_message   (classify by message name)
    → GameStateStore.*                    (own and patch authoritative state)
      → controller signals                (render)
Controllers subscribe to GameStateStore signals. They do not parse raw WebSocket payloads directly.

​
Context menu ownership

The client owns displaying context-menu actions and reporting the player’s selection. The server owns deciding what an action does. Inventory item menus are built from the context_actions array in the authoritative inventory snapshot — the client renders whatever the server describes and never hardcodes action names or effects.

​
Expanding the client

When adding new interactions — attack, talk, trade, examine, or drop-quantity — add the input orchestration and menu building to player_interaction_controller.gd. Emit intent signals from that controller back to GameScreen, which issues the corresponding WebSocket requests. Do not add new input branches directly to game_screen.gd. If world, actor, or movement behavior starts being reused outside GameScreen, move those pieces into world/ or actors/ rather than growing GameScreen further.
The assets/ directory is git-ignored. Extracted game assets must be placed there locally and are never committed to the repository. The client will fail to render tiles and actors if this directory is empty or missing.

Build docs developers (and LLMs) love

Get started for freeTalk to us