This guide is for developers changing or extending the framework itself. The Designer Guide explains how to configure existing systems. This section explains where the code boundaries are, what owns authority, and where your own code should plug in.
Authoritative gameplay
Movement, interactions, combat, inventory, quests, banking, travel, death, and saves resolve on the server.
Thin network bridges
NGO components validate ownership and requests, then delegate to transport-agnostic rules and services instead of duplicating gameplay logic.
Data-driven content
Stable string IDs and ScriptableObject definitions are the normal identity boundary for items, actions, spells, quests, travel, audio, and other authored content.
Presentation-only clients
Camera, UI, input, interpolation, animation, VFX, audio, and transitions react to replicated state rather than deciding gameplay outcomes.
Recommended reading order
- Architecture & Runtime Flow
- Networking & Readiness
- Interaction Pipeline
- Persistence & Save Modules
- Developer API Reference
Golden rules
- Do not create a second single-player implementation. Host mode is the local gameplay path.
- Do not let UI or clients mutate authoritative models directly.
- Do not use display names or array indexes as persistent/network identity. Use stable IDs.
- Do not run gameplay from
Update()when it belongs on the RPG tick. - Do not save after despawn. Capture authoritative state while the player still exists.
- Do not load player travel scenes outside
NetworkLocationSession. - Prefer new definitions, handlers, modules, and interfaces over editing central services.