feat: Add multiplayer networking architecture and documentation updates

- Updated Master Blueprint Index to include Multiplayer Networking support.
- Added detailed Multiplayer Networking sections across all developer documentation (01-11).
- Introduced authority maps, key patterns, and RPC guidelines for each system.
- Established a comprehensive multiplayer networking architecture document outlining core principles, replication strategies, and anti-cheat considerations.
- Enhanced UI documentation to clarify local-only behavior and binding to replicated dispatchers.
- Implemented client prediction strategies and RPC naming conventions for consistency across the framework.

docs/blueprints/01-core/01_GI_GameTagRegistry.md

@@ -186,4 +186,12 @@ This asset does not talk to other systems directly. All communication is passive
 5. Add variables `TagNamespace` (FText) and `bIsFrameworkTag` (bool).
 6. Implement the functions listed in Section 6 as Blueprint Callable / Pure nodes.
 7. Document all tag namespaces from Section 10 in the asset's description.
-8. Save and run the validation test.
+8. Save and run the validation test.
+
+---
+
+## 15. Multiplayer Networking
+
+**Replication: None needed.** This Data Asset is read-only configuration. All clients load identical copies from disk. GameplayTag data lives in `DefaultGameplayTags.ini` which is identical on all instances.
+
+**Authority: N/A.** No runtime state changes.

docs/blueprints/01-core/02_FL_GameUtilities.md

@@ -137,4 +137,14 @@ All functions can be called from Construction Scripts since they are pure (no wo
 2. `GetSubsystemSafe` returns `None` instead of crashing when a subsystem doesn't exist.
 3. `FormatTime(3661.0)` returns `01:01:01`.
 4. `LogDebug` prints to both the output log and the viewport in editor builds.
-5. `LogDebug` produces no output in a shipping build.
+5. `LogDebug` produces no output in a shipping build.
+
+---
+
+## Multiplayer Networking
+
+**Replication: None needed.** This is a static BlueprintFunctionLibrary with no state. All functions are callable from any Blueprint on any side (client or server).
+
+**Authority: N/A.** Functions are context-free. World-context operations work identically on server and client.
+
+**Note:** `GetSubsystemSafe()` returns local subsystems. On clients, only client-side subsystems are available. Never rely on a server-only subsystem being available on a client.

docs/blueprints/01-core/03_I_InterfaceLibrary.md

@@ -393,4 +393,22 @@ Objects with continuous adjustment values rather than binary states. Pressure va
 2. An actor with [`I_Persistable`] saves and restores its state correctly through the save system.
 3. An actor can implement multiple interfaces simultaneously without conflicts.
 4. Calling an interface function on an actor that doesn't implement it safely returns the default value (no crash).
-5. All interface functions are accessible via the Blueprint node context menu under their category name.
+5. All interface functions are accessible via the Blueprint node context menu under their category name.
+
+---
+
+## Multiplayer Networking
+
+**Replication: None needed.** Interfaces are communication contracts — they define function signatures, not data. Interface calls work identically on client and server.
+
+**Key Rule:** When calling an interface function that modifies state (e.g. `I_Interactable.Execute_OnInteract`), the caller must either:
+- Be on the server (HasAuthority check), OR
+- Call through a `Server_` RPC wrapper that validates and executes the interface function server-side
+
+**Example:**
+```
+Client calls: Server_Interact(TargetActor)
+  → Server validates range, conditions
+  → Server calls: I_Interactable.Execute_OnInteract(TargetActor)
+  → State changes replicate back via RepNotify
+```

docs/blueprints/01-core/04_GI_GameFramework.md

@@ -214,4 +214,45 @@ flowchart TD
 - Add new subsystems to the init list; they are auto-initialized by UE's GameInstanceSubsystem system.
 - The `SessionFlags` map lets you add per-project transient state without modifying this class.
 - For multi-world / split-screen, treat this as a single-instance singleton per application session.
-- `PlatformType` can be overridden via command-line switch `-Platform=Steam` in packaging scripts.
+- `PlatformType` can be overridden via command-line switch `-Platform=Steam` in packaging scripts.
+
+---
+
+## 11. Multiplayer Networking
+
+### Replicated Variables
+
+| Variable | Type | Condition | Description |
+|----------|------|-----------|-------------|
+| `CurrentGamePhase` | `E_GamePhase` | `Replicated Using OnRep_GamePhase` | Replicated phase; OnRep fires dispatcher for all clients |
+| `ActiveSaveSlotIndex` | `Integer` | `Replicated` | Synced save slot |
+| `PlatformType` | `E_PlatformType` | `Replicated` | Platform info for cross-play filtering |
+
+### Authority Notes
+
+| Function | Authority | Notes |
+|----------|-----------|-------|
+| `SetGamePhase` | `Server` | Clients cannot change game phase. OnRep broadcasts to all. |
+| `SetSessionFlag` | `Server` | Session flags are server-authoritative. |
+| `GetSubsystem` | `Any` | Read-only — safe for clients. Returns subsystems that exist per-side. |
+| `InitPlatformServices` | `Any` | Runs on each instance; platform type synced. |
+
+### Server RPCs
+
+| RPC | Direction | Description |
+|-----|-----------|-------------|
+| `Server_SetGamePhase` | Client→Server | Client requests phase change (e.g. player pauses). Server validates and sets. |
+
+### Client Prediction
+
+- GamePhase transitions are server-authoritative with no client prediction.
+- Clients bind to `OnGamePhaseChanged` dispatcher (fired by `OnRep_GamePhase`) — same as single-player.
+- `SessionFlags` are not predicted; clients read after server sets them.
+
+### OnRep Handlers
+
+```
+OnRep_GamePhase(NewPhase)
+  → Broadcast OnGamePhaseChanged(NewPhase)
+  → All systems react exactly as in single-player
+```

docs/blueprints/01-core/05_GM_CoreGameMode.md

@@ -178,4 +178,43 @@ flowchart TD
 - **`TriggerEnding`** is the only project-specific hook — override to handle unique ending sequences
 - **`bPauseAllowed`** can be extended to a tag-based system for finer control
 - For multiplayer, extend to derive from a replicated GameMode base
-- The entire class is project-agnostic — drop into any UE5 project and configure class references
+- The entire class is project-agnostic — drop into any UE5 project and configure class references
+
+---
+
+## Multiplayer Networking
+
+### Parent Class
+Derive from `GameMode` (not `GameModeBase`) in multiplayer. `GameMode` is replicated — `GameModeBase` is not. All default class references and spawn logic remain identical.
+
+### Replicated Variables
+| Variable | Type | Condition | Description |
+|----------|------|-----------|-------------|
+| `CurrentChapterTag` | `GameplayTag` | `Replicated Using OnRep_ChapterTag` | Synced chapter for all clients |
+| `bPauseAllowed` | `Boolean` | `Replicated` | Whether pause is permitted |
+
+### Authority Notes
+| Function | Authority | Notes |
+|----------|-----------|-------|
+| `TransitionToChapter` | `Server` | Chapter transitions are server-only. OnRep syncs chapter tag to clients. |
+| `HandlePlayerDead` | `Server` | Death is server-authoritative. Routes respawn or game-over. |
+| `SetPauseAllowed` | `Server` | Pause permission is server-controlled. |
+| `TriggerGameOver` | `Server` | Game-over sequence runs on server. |
+| `TriggerEnding` | `Server` | Ending determination is server-authoritative. |
+
+### Server RPCs
+| RPC | Direction | Description |
+|-----|-----------|-------------|
+| `Server_PauseRequest` | Client→Server | Client requests pause. Server checks `bPauseAllowed`, pauses if permitted. |
+
+### Client Prediction
+- Chapter transitions: no client prediction — loading screen runs on all clients.
+- Death routing: clients see death animation via multicast; respawn is server-driven.
+- Pause: server-authoritative with client request.
+
+### OnRep Handlers
+```
+OnRep_ChapterTag(NewTag)
+  → Update GS_CoreGameState.ActiveChapterTag
+  → Broadcast OnChapterTransition
+```

docs/blueprints/01-core/06_GS_CoreGameState.md

@@ -267,4 +267,46 @@ flowchart TD
 
 ---
 
+## 11. Multiplayer Networking
+
+### Full Replication Map
+
+All 5 state variables are replicated with `OnRep` handlers. GS_CoreGameState is the **primary replicated state bus** — every system that needs shared state writes through this object.
+
+| Variable | Replication | OnRep Handler | Writer (Authority) | Consumer |
+|----------|-------------|---------------|---------------------|----------|
+| `ElapsedPlayTime` | `Replicated Using` | `OnRep_ElapsedPlayTime` → dispatcher | Tick (server-only) | RunHistoryTracker, HUD |
+| `ActiveChapterTag` | `Replicated Using` | `OnRep_ActiveChapterTag` → dispatcher | GM_CoreGameMode | NarrativeSystem, HUD |
+| `ActiveNarrativePhase` | `Replicated Using` | `OnRep_ActiveNarrativePhase` → dispatcher | BPC_NarrativeStateSystem | UI, narrative triggers |
+| `bEncounterActive` | `Replicated Using` | `OnRep_EncounterActive` → dispatcher | BPC_EncounterDirector | HUD, atmosphere controller |
+| `ActiveObjectiveTags` | `Replicated Using` | `OnRep_ActiveObjectiveTags` → dispatcher | BPC_ObjectiveSystem | WBP_ObjectiveDisplay, journal |
+
+### Authority Notes
+
+- **All setter functions are Server-only.** Call with `HasAuthority()` check.
+- **All getter functions are Any.** Clients can read replicated state freely.
+- **OnRep fires dispatcher** — consumers bind to dispatcher, not variable. Identical SP/MP code path.
+- **Tick accumulation** is server-only (ElapsedPlayTime). Clients receive time via OnRep.
+
+### Server RPCs (None)
+
+GS_CoreGameState is a passive state bus. Clients never call RPCs on it directly — they call RPCs on the systems that write to it (e.g. `BPC_ObjectiveSystem.Server_CompleteObjective`).
+
+### Multicast Events (None)
+
+All state changes replicate via standard variable replication + OnRep dispatcher. No separate multicast needed.
+
+### Cross-System Flow (Multiplayer)
+```
+Client: Player completes objective
+  → Server_CompleteObjective RPC on BPC_ObjectiveSystem
+  → Server validates completion conditions
+  → Server calls GS_CoreGameState.RemoveActiveObjectiveTag
+  → Variable replicates to all clients
+  → OnRep_ActiveObjectiveTags fires OnObjectiveTagsChanged
+  → WBP_ObjectiveDisplay (local per-client) refreshes
+```
+
+---
+
 *Blueprint Spec v1.0 — GS_CoreGameState for UE5.5-5.7*

docs/blueprints/01-core/07_DA_ItemData.md

@@ -182,4 +182,12 @@ flowchart LR
 
 ---
 
+## Multiplayer Networking
+
+**Replication: None needed.** `DA_ItemData` is a PrimaryDataAsset — read-only configuration loaded identically on all clients. No runtime state.
+
+**Authority: N/A.** All clients load the same asset data from disk. Inventory operations that reference item data are server-authoritative (see `BPC_InventorySystem`).
+
+---
+
 *Blueprint Spec v1.0 — DA_ItemData for UE5.5-5.7*