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.
2026-05-19 17:15:57 +03:00
parent b2b6e1e7c7
commit 8bc731e5ae
35 changed files with 1259 additions and 11 deletions
--- a/docs/developer/01-core-foundation.md
+++ b/docs/developer/01-core-foundation.md
@@ -377,4 +377,28 @@ MainMenu → Loading → InGame ⇄ Paused

 ---

+## Multiplayer Networking
+
+### Category Authority Map
+| System | Role | Authority |
+|--------|------|-----------|
+| `GI_GameFramework` | GamePhase, session flags | Server sets; clients read via replicated dispatcher |
+| `GM_CoreGameMode` | Player spawning, chapter transitions, death routing | Server-only (extends replicated GameMode) |
+| `GS_CoreGameState` | Shared session state bus | **Fully replicated** — 5 vars with OnRep handlers |
+| `GI_GameTagRegistry` | Tag documentation | Read-only config — identical on all clients |
+| `FL_GameUtilities` | Static utilities | No state — callable from any side |
+| `I_InterfaceLibrary` | Communication contracts | Interface calls work on any side; mutators must check authority |
+| `DA_ItemData` | Item definitions | Read-only Data Asset — identical on all clients |
+
+### Key Patterns
+- **GS_CoreGameState as Replication Hub:** All shared session state (chapter, phase, objectives, encounter status) writes through GS_CoreGameState which auto-replicates to all clients via OnRep → dispatcher.
+- **GamePhase transitions are server-authoritative:** `SetGamePhase()` checks `HasAuthority()`. Clients receive phase changes via `OnRep_GamePhase` → `OnGamePhaseChanged` dispatcher.
+- **Interface calls route through server:** `I_Interactable.Execute_OnInteract` must be called server-side. Clients call `Server_Interact` RPC → server validates → calls interface.
+- **Data Assets are client-ready:** All `DA_*` assets load identically on all instances from disk. No replication needed.
+
+### Full Spec
+See [`docs/architecture/multiplayer-networking.md`](../architecture/multiplayer-networking.md) Section 3.1.
+
+---
+
 *Developer Reference v1.0 — 01 Core Foundation Systems. Companion to docs/blueprints/01-core/ specs.*
--- a/docs/developer/02-player-systems.md
+++ b/docs/developer/02-player-systems.md
@@ -453,4 +453,33 @@ Exposed → Entering → Hidden ⇄ Peeking → Exiting → Exposed

 ---

+## Multiplayer Networking
+
+### Category Authority Map
+| System | Authority Pattern | Client Prediction |
+|--------|------------------|-------------------|
+| `BPC_HealthSystem` | Server-authoritative damage/healing/death | Client predicts damage flash; server corrects health via OnRep |
+| `BPC_StaminaSystem` | Server-authoritative drain/restore | Client predicts bar decrease; server corrects via OnRep |
+| `BPC_StressSystem` | Server-authoritative stress accumulation | Client plays local hallucinations; server is canonical |
+| `BPC_MovementStateSystem` | Server-authoritative mode/posture | Native CMC replication handles position/velocity |
+| `BPC_HidingSystem` | Server-authoritative enter/exit/peek | Client predicts animation; server validates slot availability |
+| `BPC_EmbodimentSystem` | Minimal — visibility/overlay state only synced | Rendering is local per-client |
+| `BPC_CameraStateLayer` | State enum only synced | FOV, shake, post-process are local per-client |
+| `BPC_PlayerMetricsTracker` | Server accumulates; snapshot replicates | No client prediction needed |
+
+### Key Server RPCs
+- `Server_ApplyDamage` / `Server_ApplyHealing` — validated by server before health modification
+- `Server_DrainStamina` / `Server_StartContinuousDrain` — validated against MinStamina thresholds
+- `Server_AddStress` / `Server_AddStressSource` — stress sources validated server-side
+- `Server_SetMovementMode` / `Server_SetPosture` — validated against MovementSettings
+- `Server_EnterHideSpot` / `Server_ExitHideSpot` — validated against slot availability
+
+### Multiplayer Cascade
+The cascade (Health→Stress→Camera→Movement) works identically in multiplayer because each system fires the same dispatchers regardless of whether the state change came from local mutation or `OnRep`. No special-case multiplayer code needed in the cascade chain.
+
+### Full Spec
+See [`docs/architecture/multiplayer-networking.md`](../architecture/multiplayer-networking.md) Section 3.2.
+
+---
+
 *Developer Reference v1.0 — 02 Player Systems. Companion to docs/blueprints/02-player/ specs.*
--- a/docs/developer/03-interaction-systems.md
+++ b/docs/developer/03-interaction-systems.md
@@ -241,4 +241,31 @@ Barricaded → (break) → Closed

 ---

+## Multiplayer Networking
+
+### Category Authority Map
+| System | Authority | Client Request Pattern |
+|--------|-----------|----------------------|
+| `BPC_InteractionDetector` | Detection runs locally; interaction validated by server | `Server_PerformInteraction` RPC |
+| `BP_DoorActor` | Server-authoritative state machine | `Server_Interact` → server validates → OnRep animates |
+| `BP_PuzzleDeviceActor` | Server-authoritative | `Server_TrySolution` RPC |
+| `BPC_ContextualTraversalSystem` | Client-predicted movement | Server validates traversal target |
+| `BPC_PhysicsDragSystem` | Client-predicted physics | Server periodically corrects position |
+| `BPC_UsableWorldObjectSystem` | Server-authoritative toggle/adjust | `Server_Use` RPC |
+
+### Interaction Flow (Multiplayer)
+```
+Client looks at door → local trace detects it → shows "Press E"
+Client presses E → calls Server_Interact(DoorActor)
+Server: validates range, door state, lock
+  → If valid: door state changes → RepNotify broadcasts
+  → All clients: OnRep plays door animation
+  → If locked: server rejects, Client_ShowError RPC to requesting client
+```
+
+### Full Spec
+See [`docs/architecture/multiplayer-networking.md`](../architecture/multiplayer-networking.md) Section 3.3.
+
+---
+
 *Developer Reference v1.0 — 03 Interaction Systems. Companion to docs/blueprints/03-interaction/ specs.*
--- a/docs/developer/04-inventory-systems.md
+++ b/docs/developer/04-inventory-systems.md
@@ -240,4 +240,29 @@

 ---

+## Multiplayer Networking
+
+### Category Authority Map
+| System | Authority | Anti-Cheat |
+|--------|-----------|------------|
+| `BPC_InventorySystem` | Server-authoritative add/remove/use/drop | Server validates slot space, weight, stack limits |
+| `BPC_ContainerInventory` | Server-authoritative open/loot/transfer | Server validates distance, lock, slot availability |
+| `BP_ItemPickup` | Server-authoritative pickup | Server validates inventory space before removing pickup |
+| `BPC_EquipmentSlotSystem` | Server-authoritative equip/unequip | Server validates slot type compatibility |
+| `BPC_ConsumableSystem` | Server-authoritative use | Server validates item exists, cooldown, applies effect |
+| `BPC_ItemCombineSystem` | Server-authoritative combine | Server validates recipe from DA_ItemData |
+
+### Server RPCs
+- `Server_AddItem`, `Server_RemoveItem`, `Server_UseItem`, `Server_DropItem`, `Server_TransferItem`
+- `Server_EquipItem`, `Server_UnequipItem`
+- `Server_LootContainer`, `Server_PickupItem`
+
+### Inventory Replication Strategy
+- **Slots array** replicated with `OnRep_Slots` → recalculates weight, fires `OnInventoryChanged`
+- **Client predicts UI** (item moves visually on drag-drop); server validates and corrects via OnRep
+- **Server validates all transactions** against slot space, weight capacity, stack limits, and category restrictions
+- **Cooldowns** managed locally (not replicated) but validated on server for authoritative actions
+
+---
+
 *Developer Reference v1.0 — 04 Inventory Systems. Companion to docs/blueprints/04-inventory/ specs.*
--- a/docs/developer/05-saveload-systems.md
+++ b/docs/developer/05-saveload-systems.md
@@ -184,3 +184,24 @@
 ---

 *Developer Reference v1.0 — 05 Save/Load Systems. Companion to docs/blueprints/05-saveload/ specs.*
+
+---
+
+## Multiplayer Networking
+
+### Category Authority Map
+| System | Authority | Notes |
+|--------|-----------|-------|
+| `SS_SaveManager` | Server triggers save/load | Clients receive restored state via GS_CoreGameState replication |
+| `BP_Checkpoint` | Server validates activation | Active checkpoint replicates to all |
+| `BPC_DeathHandlingSystem` | Server determines death outcome | Death animation multicast; respawn is server-driven |
+| `BPC_PlayerRespawnSystem` | Server executes respawn | Client receives respawn state via replication |
+| `BPC_PersistentCorpseSystem` | Server spawns corpse actor | Corpse replicated to all clients |
+| `BPC_PersistentWorldStateRecorder` | Server records changes | State changes replicated via individual actor RepNotify |
+| `BPC_RunHistoryTracker` | Server tracks; snapshot replicates | For scoreboard display |
+
+### Key Multiplayer Considerations
+- **Save/Load is server-coordinated.** Only server triggers save/load. Clients receive restored state via GS_CoreGameState and actor replication.
+- **Death is server-authoritative.** Runs on server, determines outcome, multicasts death events.
+- **Alt Death Space** (separate level): server calls `ClientTravel` for all clients.
+- **Corpses** are replicated actors — all clients see them.
--- a/docs/developer/06-ui-systems.md
+++ b/docs/developer/06-ui-systems.md
@@ -154,4 +154,23 @@ Binds to `BPC_InteractionDetector.OnTargetFound/Lost` and `OnHoldProgressUpdated

 ---

+## Multiplayer Networking
+
+**All UI is local per-client. Zero networking code in widgets.**
+
+### UI Networking Pattern
+```
+Server state changes → replicated variable → OnRep fires dispatcher
+  → Widget (local) already bound to that dispatcher
+  → Widget updates with zero multiplayer awareness
+```
+
+### Category Rules
+- **WBP_* Widgets:** Local only. Bind to replicated dispatchers from gameplay systems. Use the same binding code as single-player.
+- **SS_UIManager:** Local per-client. Menu stack is per-player — different players can be in different menus.
+- **Input mode changes:** Handled per-client by `SS_EnhancedInputManager` listening to game phase dispatchers.
+- **HUD visibility:** Each client independently determines what to show based on their replicated state (e.g., hiding player sees different HUD than exposed player).
+
+---
+
 *Developer Reference v1.0 — 06 UI Systems. Companion to docs/blueprints/06-ui/ specs.*
--- a/docs/developer/07-narrative-systems.md
+++ b/docs/developer/07-narrative-systems.md
@@ -130,4 +130,26 @@

 ---

+## Multiplayer Networking
+
+### Category Authority Map
+| System | Authority | Replication |
+|--------|-----------|-------------|
+| `BPC_NarrativeStateSystem` | Server sets flags | Flags replicate via GS_CoreGameState or replicated array |
+| `BPC_ObjectiveSystem` | Server activates/completes | Active objectives in GS_CoreGameState.ActiveObjectiveTags |
+| `BPC_DialoguePlaybackSystem` | Server sequences dialogue | Line index replicated; clients play audio locally |
+| `BPC_DialogueChoiceSystem` | Client selects → Server processes | Server validates choice availability against flags |
+| `BPC_BranchingConsequenceSystem` | Server executes consequences | Results sync to all clients |
+| `BPC_CutsceneBridge` | Server triggers → Multicast to all | All clients enter cutscene simultaneously |
+| `BP_NarrativeTriggerVolume` | Server validates overlap | Overlap events replicate; triggers execute on server |
+| `BPC_EndingAccumulator` | Server accumulates; evaluates at end | Ending result syncs to all |
+
+### Key Patterns
+- **Narrative flags** are GameplayTags stored in replicated arrays — all clients see flag changes.
+- **Dialogue choices** flow: Client selects → `Server_SelectChoice` RPC → server validates → executes consequences → state replicates to all.
+- **Cutscenes** are synchronized: server triggers, all clients enter cutscene via multicast.
+- **Objectives** route through `GS_CoreGameState` which already has full replication.
+
+---
+
 *Developer Reference v1.0 — 07 Narrative Systems. Companion to docs/blueprints/07-narrative/ specs.*
--- a/docs/developer/08-weapons-systems.md
+++ b/docs/developer/08-weapons-systems.md
@@ -136,4 +136,41 @@ Holstered → Equipping → Ready ⇄ Firing → Reloading → Ready

 ---

+## Multiplayer Networking
+
+### Category Authority Map
+| System | Authority | Client Prediction |
+|--------|-----------|-------------------|
+| `BP_WeaponBase` | Server-authoritative state machine | Client predicts fire animation/muzzle flash |
+| `BPC_AmmoComponent` | Server-authoritative ammo | Client predicts count; server corrects via OnRep |
+| `BPC_FirearmSystem` | Server performs trace/damage calc | Client predicts tracers; server hit result is canonical |
+| `BPC_MeleeSystem` | Server validates hit detection | Client predicts swing animation |
+| `BPC_ReloadSystem` | Server validates reload | Client predicts animation; server validates ammo state |
+| `BPC_RecoilSystem` | **Local only** | Recoil is cosmetic; no replication needed |
+| `BPC_DamageReceptionSystem` | Server calculates damage | HealthSystem is authoritative |
+| `BPC_HitReactionSystem` | Server triggers → multicast animation | All clients see flinch/stagger |
+| `BPC_CombatFeedbackComponent` | **Local only** | Hit markers, kill confirm are per-client |
+| `BPC_ShieldDefenseSystem` | Server validates block/parry | Shield state replicated |
+
+### Weapon Fire Flow (Multiplayer)
+```
+Client presses Fire:
+  1. Client predicts: play fire anim, muzzle flash, recoil immediately
+  2. Client calls Server_StartFire() RPC
+  3. Server validates: weapon state Ready, has ammo, not on cooldown
+  4. Server: trace/damage calc, consume ammo → RepNotify ammo to all
+  5. Server: Multicast fire FX to other clients
+  6. Client receives OnRep_Ammo → corrects if prediction was wrong
+```
+
+### Server RPCs
+- `Server_StartFire`, `Server_StopFire`, `Server_StartReload`, `Server_EquipWeapon`, `Server_HolsterWeapon`
+
+### Anti-Cheat
+- Server validates fire rate (timer between Server_StartFire calls must exceed weapon fire rate)
+- Server never trusts client damage calculations — always recalculates from weapon data
+- Server validates ammo count before allowing fire (prevents infinite ammo cheat)
+
+---
+
 *Developer Reference v1.0 — 08 Weapons Systems. Companion to docs/blueprints/08-weapons/ specs.*
--- a/docs/developer/09-ai-systems.md
+++ b/docs/developer/09-ai-systems.md
@@ -115,4 +115,33 @@

 ---

+## Multiplayer Networking
+
+### AI is Server-Only
+
+**All AI logic runs on the server.** Behavior trees, perception, memory, and state machines execute on the server only. Clients receive:
+- **Position/Rotation/Animation:** via standard Actor replication
+- **Alert level:** replicated for client awareness UI (detection meter, investigation icon)
+- **Health:** replicated for client health bars
+- **Perception events:** replicated for client awareness indicators only (cosmetic)
+
+### Category Authority Map
+| System | Runs On | Replicated To Clients |
+|--------|---------|----------------------|
+| `AI_BaseAgentController` | Server | Position, rotation, animation |
+| `BP_EnemyBase` | Server | Health, state, mesh |
+| `BPC_AlertSystem` | Server | Alert level enum for UI |
+| `BPC_AIStateMachine` | Server | Current state for animation |
+| `BPC_AIPerceptionSystem` | Server | Detection events → client awareness indicators |
+| `BPC_AIMemorySystem` | Server | LastKnownLocation → client investigation UI |
+| `BPC_BehaviourVariantSelector` | Server (at spawn) | Variant choice for client animation matching |
+| `BP_PatrolPath` | Read-only | Spline data is static; identical on all clients |
+
+### Client Awareness
+- Clients receive perception events (enemy detected player, heard sound) as **cosmetic indicators** — red detection bar, investigation icon, audio cue.
+- The actual AI behavior (investigate, engage, flee) runs on server only.
+- Clients never run behavior trees — they only display the results.
+
+---
+
 *Developer Reference v1.0 — 09 AI Systems. Companion to docs/blueprints/09-ai/ specs.*
--- a/docs/developer/10-adaptive-systems.md
+++ b/docs/developer/10-adaptive-systems.md
@@ -146,4 +146,32 @@

 ---

+## Multiplayer Networking
+
+### Category Authority Map
+| System | Authority | Replication |
+|--------|-----------|-------------|
+| `BPC_AdaptiveEnvironmentDirector` | Server coordinates | Atmosphere state replicates |
+| `BPC_AtmosphereStateController` | Server sets tier | Clients play local audio/lighting per tier |
+| `BPC_DifficultyManager` | Server adjusts | Difficulty params replicate |
+| `BPC_FearSystem` | Server-authoritative | AI fear behavior runs on server |
+| `BPC_ScareEventSystem` | Server triggers → Multicast | All clients play scare FX simultaneously |
+| `BPC_RareEventSystem` | Server selects → Multicast | All clients see rare event |
+| `BPC_LightEventController` | Server triggers | Replicated for synchronized lighting |
+| `BPC_MemoryDriftSystem` | **Local only** | Hallucinations are per-player experience |
+| `BPC_PacingDirector` | Server controls | Intensity band replicates |
+| `BPC_PlaystyleClassifier` | Server classifies | Classification replicates |
+| `BPC_PerformanceScaler` | **Local only** | Per-client hardware adaptation |
+| `SS_AudioManager` | **Local playback** | Gameplay parameters (heart rate, tension) sync from server |
+| `BP_RoomAudioZone` | **Local only** | Each client applies room acoustics based on their position |
+| `BPC_ProceduralEncounter` | Server generates | Spawned actors replicate normally |
+
+### Key Patterns
+- **Atmosphere is server-controlled, locally rendered.** Server sets atmosphere tier → clients play local audio/lighting/FX.
+- **Scare events are synchronized via multicast** — all players experience the scare at the same moment.
+- **Per-player systems** (MemoryDrift, PerformanceScaler) are strictly local.
+- **Audio is local playback** — only gameplay parameters sync from server; sound assets loaded locally.
+
+---
+
 *Developer Reference v1.0 — 10 Adaptive Systems. Companion to docs/blueprints/10-adaptive/ specs.*
--- a/docs/developer/11-16-systems.md
+++ b/docs/developer/11-16-systems.md
@@ -109,3 +109,40 @@
 ---

 *Developer Reference v1.0 — Categories 11-16 Systems. Companion to docs/blueprints/ specs.*
+
+---
+
+## Multiplayer Networking
+
+### Category 11-12: Meta & Settings
+| System | Authority |
+|--------|-----------|
+| `BPC_ProgressStatTracker` | Server accumulates; snapshot replicates for scoreboard |
+| `SS_AchievementSystem` | Server validates unlocks; client receives unlock notifications |
+| `BPC_AccessibilitySettings` | **Local per-client** — each player's accessibility preferences |
+| `SS_SettingsSystem` | Settings save per-client; key bindings are local |
+
+### Category 13: Polish
+| System | Authority |
+|--------|-----------|
+| `BPC_AnalyticsTracker` | **Local only** — per-client telemetry |
+| `BPC_DevCheatManager` | **Local only** — but cheats that affect world must be server-validated |
+| `BPC_ErrorHandler` | **Local only** — per-client error handling |
+| `BPC_FPSCounter` | **Local only** — per-client performance |
+| `BPC_LoadingScreen` | **Local only** — but sync'd via GamePhase |
+| `BPC_TutorialSystem` | **Local per-client** — tutorial progression is per-player |
+| `WBP_CreditsScreen`, `WBP_DebugMenu`, `WBP_SplashScreen` | **Local only** |
+
+### Category 14: Data Assets
+All `DA_*` Data Assets are **read-only configuration** — loaded identically on all clients. No replication needed.
+
+### Category 15: Input
+| System | Authority |
+|--------|-----------|
+| `SS_EnhancedInputManager` | **Local per-client.** Input mapping contexts, key rebinding, and input mode are per-player. Context priority stack is per-client. |
+
+### Category 16: State Management
+| System | Authority |
+|--------|-----------|
+| `BPC_StateManager` | **Server-authoritative.** All state change requests go through server. `IsActionPermitted()` is read-only — safe for client prediction. `RequestStateChange()` must be server-validated. |
+| `DA_StateGatingTable` | Read-only Data Asset — identical on all clients. Server uses it for validation; clients use it for prediction of gating results. |
--- a/docs/developer/INDEX.md
+++ b/docs/developer/INDEX.md
@@ -1,6 +1,6 @@
 # Developer Reference — UE5 Modular Game Framework

-**Version:** 1.0 | **Generated:** 2026-05-19 | **Files:** 14 (1 index + 2 overview + 10 category docs + 1 combined)
+**Version:** 1.1 | **Generated:** 2026-05-19 | **Files:** 14 (1 index + 2 overview + 10 category docs + 1 combined) | **Networking:** All docs include multiplayer sections

 This directory contains developer-facing reference documentation for every system in the framework. Unlike the blueprint spec files (which define *what* to build), these documents explain *how each system works internally* — the data flow, state machines, integration points, and design rationale. Use these when you need to understand a system's behavior to implement, debug, or extend it.

@@ -178,6 +178,7 @@ docs/developer/
 2. **Implementing a system?** Find it in the quick reference above, then read its category document.
 3. **Debugging?** Each category doc includes a data flow section showing how data moves between systems.
 4. **Need implementation patterns?** See [`implementation-patterns.md`](implementation-patterns.md) for common UE5 Blueprint patterns.
+5. **Multiplayer networking?** See [`../architecture/multiplayer-networking.md`](../architecture/multiplayer-networking.md) for the full networking architecture. Every category doc has a Multiplayer Networking section.

 ## Relationship to Spec Files

--- a/docs/developer/architecture-overview.md
+++ b/docs/developer/architecture-overview.md
@@ -153,4 +153,45 @@ The 16 build phases follow dependency order:

 ---

+## Multiplayer Networking Architecture
+
+The framework is built server-authoritative from the ground up. See [`docs/architecture/multiplayer-networking.md`](../architecture/multiplayer-networking.md) for the full specification.
+
+### How Networking Fits the Layers
+
+```
+┌────────────────────────────────────────────────────────────────┐
+│  LOCAL-ONLY LAYER (never replicated)                            │
+│  WBP_* Widgets, Camera, Embodiment, Debug, Analytics, Tutorials │
+├────────────────────────────────────────────────────────────────┤
+│  REPLICATED STATE LAYER (server-authoritative)                  │
+│  GS_CoreGameState (chapter, objectives, encounter, time)        │
+│  Player Components (health, stamina, stress, movement, hide)    │
+│  World Actors (doors, containers, pickups, puzzles)             │
+│  Inventory (slots, weight, equipment)                           │
+│  Narrative (flags, dialogue state, objectives)                  │
+│  AI (position, alert state, health — behavior trees on server)  │
+│  Adaptive (atmosphere tier, tension, difficulty params)         │
+├────────────────────────────────────────────────────────────────┤
+│  CLIENT PREDICTION LAYER (cosmetic, corrected by server)        │
+│  Weapon fire FX, muzzle flash, recoil, hit markers              │
+│  Stamina bar, health bar (predicted; RepNotify corrects)        │
+│  Door animations (predicted; OnRep confirms)                    │
+├────────────────────────────────────────────────────────────────┤
+│  SERVER-ONLY LAYER                                              │
+│  AI Behavior Trees, Damage Calculation, Loot Generation         │
+│  Save/Load coordination, State Gating validation                │
+└────────────────────────────────────────────────────────────────┘
+```
+
+### Key Multiplayer Principles
+1. **HasAuthority() gate** on every mutator function
+2. **Server_ RPC** for client→server requests
+3. **RepNotify** fires same dispatchers as SP code — UI needs zero changes
+4. **Client prediction** for responsiveness; server correction for correctness
+5. **AI runs on server** only — replicated to clients via Actor replication
+6. **UI is local per-client** — binds to replicated dispatchers
+
+---
+
 *Architecture Overview v1.0 — Start here before reading category-specific developer docs.*
--- a/docs/developer/implementation-patterns.md
+++ b/docs/developer/implementation-patterns.md
@@ -292,4 +292,96 @@

 ---

+## Multiplayer Networking Patterns
+
+### Pattern 11: Server Authority Gate
+
+**When to Use:** Every function that modifies replicated state.
+
+**Blueprint Implementation:**
+```
+[Function: ApplyDamage(DamageEvent)]
+  Switch HasAuthority
+    Authority:
+      → Execute authoritative logic (damage calc, health modification)
+      → Fire dispatchers
+    Remote:
+      → Return (client cannot modify replicated state directly)
+      → Client calls Server_ RPC to request the change
+```
+
+**Key Rule:** Never modify a replicated variable without `HasAuthority()` check.
+
+### Pattern 12: Server RPC Wrapper
+
+**When to Use:** Client needs to request a state change from the server.
+
+**Blueprint Implementation:**
+```
+[Client Event Graph — Input: Interact pressed]
+  → Call Server_Interact(TargetActor)  // RPC: Run on Server, Reliable
+
+[Server RPC: Server_Interact(TargetActor)]
+  Switch HasAuthority
+    Authority:
+      → Validate distance, conditions
+      → Call I_Interactable.Execute_OnInteract(TargetActor, Instigator)
+      → State changes replicate automatically
+```
+
+**Naming:** All Server RPCs prefixed with `Server_`.
+
+### Pattern 13: OnRep Dispatcher Relay
+
+**When to Use:** Any replicated variable that should trigger the same effects as single-player.
+
+**Blueprint Implementation:**
+```
+[Variable: CurrentHealth]
+  Replication: Replicated Using OnRep_CurrentHealth
+
+[Function: OnRep_CurrentHealth]
+  → Broadcast OnHealthChanged(OldHealth, CurrentHealth, Delta)
+  → UI, audio, effects react exactly as in single-player path
+  → No multiplayer-specific code in consumer systems
+```
+
+**Key Rule:** `OnRep_` fires the SAME dispatcher the SP mutation code fires. Zero consumer changes needed.
+
+### Pattern 14: Client Prediction with Correction
+
+**When to Use:** Actions that need instant feedback (firing, using items, interacting).
+
+**Blueprint Implementation:**
+```
+[Client: Input → Fire pressed]
+  → Client prediction: play fire animation, muzzle flash, reduce ammo display
+  → Call Server_StartFire()
+
+[Server: Server_StartFire()]
+  → Validate weapon state, ammo, cooldown
+  → If valid: execute authoritative fire logic, consume ammo
+  → If invalid: log warning, return (client will be corrected via OnRep)
+
+[Client: OnRep_Ammo]
+  → If server count matches client prediction: no visible change
+  → If different: correct ammo display, stop fire animation
+```
+
+### Pattern 15: Multicast for Cosmetic Events
+
+**When to Use:** Server needs to trigger a cosmetic-only event on all clients.
+
+**Blueprint Implementation:**
+```
+[Server: Explosion triggered]
+  → Multicast_PlayExplosionFX(Location, Radius)
+  → All clients play VFX, SFX, camera shake locally
+  → No replication of individual particles
+```
+
+**Key Rule:** Multicast is for **cosmetic only** — never use for state changes. State changes replicate via variable RepNotify.
+
+---
+
 *Implementation Patterns v1.0 — Reference when building blueprint specs into UE5 Blueprint assets.*