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.
This commit is contained in:
Lefteris Notas
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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
|
||||
```
|
||||
@@ -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
|
||||
```
|
||||
@@ -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
|
||||
```
|
||||
@@ -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*
|
||||
@@ -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*
|
||||
@@ -337,4 +337,70 @@ flowchart TD
|
||||
|
||||
---
|
||||
|
||||
## 11. Multiplayer Networking (Expanded)
|
||||
|
||||
### Replicated Variables (Existing + New)
|
||||
|
||||
| Variable | Type | Condition | Description |
|
||||
|----------|------|-----------|-------------|
|
||||
| `CurrentHealth` | `Float` | `Replicated Using OnRep_CurrentHealth` | Clients sync via OnRep → dispatcher |
|
||||
| `DeathState` | `E_DeathState` | `Replicated Using OnRep_DeathState` | Death state synced; OnRep triggers death effects |
|
||||
| `bIsInvincible` | `Boolean` | `Replicated` | Invincibility visible to other players |
|
||||
| `MaxHealth` | `Float` | `Replicated` | Synced for UI percentage calculations |
|
||||
|
||||
### Server RPCs
|
||||
|
||||
| RPC | Direction | Description |
|
||||
|-----|-----------|-------------|
|
||||
| `Server_ApplyDamage` | Client→Server | Client reports taking damage. Server validates source, range, damage type. |
|
||||
| `Server_ApplyHealing` | Client→Server | Client requests healing. Server validates heal source, applies. |
|
||||
| `Server_KillInstant` | Client→Server | Only accepted from authoritative sources (GM, traps). Client calls are rejected. |
|
||||
|
||||
### Authority Gates
|
||||
|
||||
```
|
||||
Function ApplyDamage(DamageEvent)
|
||||
Switch HasAuthority
|
||||
Authority:
|
||||
→ Calculate resistance, apply damage, fire dispatchers
|
||||
Remote:
|
||||
→ Return (clients never modify health directly)
|
||||
→ Server_ApplyDamage is called by damage source (weapon/trap), not victim
|
||||
|
||||
Function ApplyHealing(HealAmount)
|
||||
Switch HasAuthority
|
||||
Authority:
|
||||
→ Apply healing, fire dispatchers
|
||||
Remote:
|
||||
→ Return
|
||||
→ Consumable use calls Server_UseConsumable → server calls ApplyHealing
|
||||
```
|
||||
|
||||
### Client Prediction
|
||||
|
||||
- **Health bar:** Client predicts damage flash on hit; server-corrected value arrives via `OnRep_CurrentHealth`.
|
||||
- **Death:** No prediction. `OnRep_DeathState` triggers all death effects (screen fade, ragdoll).
|
||||
- **Healing:** Client shows green flash immediately + predicted health; server corrects within one RTT.
|
||||
- **Invincibility:** Visual effect (shield shimmer) is local cosmetic; state is replicated.
|
||||
|
||||
### OnRep Handlers
|
||||
|
||||
```
|
||||
OnRep_CurrentHealth()
|
||||
→ Broadcast OnHealthChanged(OldHealth, CurrentHealth, Delta)
|
||||
→ UI updates identically to single-player path
|
||||
|
||||
OnRep_DeathState()
|
||||
→ Broadcast OnDeathStateChanged(OldState, NewState)
|
||||
→ If Dead: play death animation, screen effects, notify GM
|
||||
```
|
||||
|
||||
### Anti-Cheat
|
||||
|
||||
- Server validates all `Server_ApplyDamage` calls: check instigator range, weapon fire rate, damage type validity.
|
||||
- Server never trusts `DamageEvent.BaseAmount` from client — always recalculates from weapon data.
|
||||
- `Server_KillInstant` is only callable from server-authoritative systems (traps, death zones, GM).
|
||||
|
||||
---
|
||||
|
||||
*Blueprint Spec: Health System. Conforms to TEMPLATE.md v1.0 — part of the UE5 Modular Game Framework.*
|
||||
@@ -326,6 +326,41 @@ flowchart TD
|
||||
- The drain rate map supports runtime modification for buffs/debuffs (e.g. Adrenaline reduces sprint cost).
|
||||
- UI widgets should bind to OnStaminaChanged for smooth bar animation, not tick polling.
|
||||
- For multiplayer: Server authorises all DrainStamina calls; client predicts and corrects on repnotify.
|
||||
|
||||
---
|
||||
|
||||
## 11. Multiplayer Networking (Expanded)
|
||||
|
||||
### Server RPCs
|
||||
|
||||
| RPC | Direction | Description |
|
||||
|-----|-----------|-------------|
|
||||
| `Server_DrainStamina` | Client→Server | Client requests stamina drain for action. Server validates MinStamina, applies. |
|
||||
| `Server_StartContinuousDrain` | Client→Server | Client starts sprinting. Server begins drain timer. |
|
||||
| `Server_StopContinuousDrain` | Client→Server | Client stops sprinting. Server stops drain, begins regen. |
|
||||
| `Server_RestoreStamina` | Client→Server | Client uses stamina item. Server validates item, applies restore. |
|
||||
|
||||
### Authority Gates
|
||||
|
||||
```
|
||||
Function DrainStamina(ActionType)
|
||||
If HasAuthority:
|
||||
→ Check cooldown, MinStamina
|
||||
→ Apply drain, update exhaustion, fire dispatchers
|
||||
Else:
|
||||
→ Client predicts stamina bar decrease for responsiveness
|
||||
→ Server_ RPC called; server corrects via OnRep if wrong
|
||||
|
||||
Function SetMaxStamina(NewMax, bMaintainRatio)
|
||||
If NOT HasAuthority → Return
|
||||
→ Apply change, fire dispatchers, auto-replicates
|
||||
```
|
||||
|
||||
### Client Prediction
|
||||
|
||||
- **Stamina bar:** Client predicts decrease on sprint/jump. Server corrects via `OnRep_CurrentStamina`.
|
||||
- **Exhaustion:** ExhaustionState replicated. Client plays breathing audio locally.
|
||||
- **Cooldowns:** Server-authoritative. Client shows cooldown timer after server confirms action.
|
||||
- Exhaustion state can drive conditional audio: heavy breathing, heart-beat, fatigue voice lines.
|
||||
|
||||
---
|
||||
|
||||
@@ -337,6 +337,28 @@ flowchart TD
|
||||
- Stress tiers can gate narrative content — questgivers behave differently based on player stress.
|
||||
- Hallucination types can be configured via Data Asset (DA_HallucinationConfig).
|
||||
- For multiplayer: Stress is server-authoritative; clients receive tier changes for local effects.
|
||||
|
||||
---
|
||||
|
||||
## 11. Multiplayer Networking (Expanded)
|
||||
|
||||
### Server RPCs
|
||||
| RPC | Direction | Description |
|
||||
|-----|-----------|-------------|
|
||||
| `Server_AddStress` | Client→Server | Client reports stress event. Server validates source, applies. |
|
||||
| `Server_AddStressSource` | Client→Server | Client enters enemy proximity zone. Server adds/updates source. |
|
||||
| `Server_RemoveStressSource` | Client→Server | Client leaves enemy zone. Server removes source. |
|
||||
| `Server_SetSafeZone` | Client→Server | Client reports safe zone status. Server validates, applies decay. |
|
||||
|
||||
### Authority
|
||||
- **Server** calculates total stress from all sources, updates tier, replicates.
|
||||
- **Client** plays local hallucination/audio effects based on replicated tier.
|
||||
- `ForcePanic()` is server-only (narrative system calls it directly on server).
|
||||
|
||||
### Client Prediction
|
||||
- Stress bar: predicted on client, corrected by `OnRep_CurrentStress`.
|
||||
- Hallucinations: randomly triggered by client based on replicated tier (cosmetic only).
|
||||
- Safe zone: server-authoritative; clients see OnSafeZoneChanged dispatcher.
|
||||
- The HealthDeficitMultiplier creates a death spiral feel — use carefully for horror pacing.
|
||||
- Safe zones double as narrative checkpoints and stress recovery areas.
|
||||
|
||||
|
||||
@@ -320,4 +320,33 @@ flowchart TD
|
||||
|
||||
---
|
||||
|
||||
## 11. Multiplayer Networking (Expanded)
|
||||
|
||||
### Replication
|
||||
Movement state is natively handled by `CharacterMovementComponent` replication. `BPC_MovementStateSystem` replicates state enums for non-movement consumers (UI, camera, audio).
|
||||
|
||||
| Variable | Condition | Notes |
|
||||
|----------|-----------|-------|
|
||||
| `CurrentPosture` | `Replicated Using OnRep_Posture` | Synced posture for other players' animation |
|
||||
| `CurrentMovementMode` | `Replicated Using OnRep_MovementMode` | Synced mode for audio/camera systems |
|
||||
| CMC velocity | Native replication | Position/velocity handled by CharacterMovementComponent |
|
||||
|
||||
### Server RPCs
|
||||
| RPC | Direction | Description |
|
||||
|-----|-----------|-------------|
|
||||
| `Server_SetMovementMode` | Client→Server | Client requests mode change. Server validates against MovementSettings. |
|
||||
| `Server_SetPosture` | Client→Server | Client requests posture change. Server validates ceiling clearance. |
|
||||
| `Server_SetSprinting` | Client→Server | Client toggles sprint. Server checks stamina before authorizing. |
|
||||
|
||||
### Authority
|
||||
- `SetMovementMode` and `SetPosture` check `HasAuthority()` before modifying state.
|
||||
- Movement penalties (`ApplyMovementPenalty`) are server-authoritative.
|
||||
- `CanTransitionToPosture` is read-only; clients can call for local prediction.
|
||||
|
||||
### Client Prediction
|
||||
- Posture/mode transitions: client predicts movement locally; server validates.
|
||||
- Footstep sounds: local calculation based on replicated state.
|
||||
|
||||
---
|
||||
|
||||
*Blueprint Spec: Movement State System. Conforms to TEMPLATE.md v1.0 — part of the UE5 Modular Game Framework.*
|
||||
@@ -321,6 +321,30 @@ flowchart TD
|
||||
- The LOS trace channel should be custom (e.g., DetectionChannel) to ignore small props.
|
||||
- Breath-hold mechanic adds depth to stealth gameplay near enemies.
|
||||
- For multiplayer: only the hiding player knows their state; other players see a generic "occupado" on the spot.
|
||||
|
||||
---
|
||||
|
||||
## 11. Multiplayer Networking (Expanded)
|
||||
|
||||
### Server RPCs
|
||||
| RPC | Direction | Description |
|
||||
|-----|-----------|-------------|
|
||||
| `Server_EnterHideSpot` | Client→Server | Client requests entering hide spot. Server validates slot availability, proximity. |
|
||||
| `Server_ExitHideSpot` | Client→Server | Client requests exiting. Server validates, teleports player, replicates. |
|
||||
| `Server_StartPeek` | Client→Server | Client starts peeking. Server validates peek ability, starts duration timer. |
|
||||
| `Server_StopPeek` | Client→Server | Client stops peeking. Server returns to Hidden state. |
|
||||
| `Server_TryBreathHold` | Client→Server | Client holds breath. Server validates, applies noise reduction on server. |
|
||||
|
||||
### Authority
|
||||
- `EnterHideSpot`, `ExitHideSpot` are server-authoritative.
|
||||
- `IsPlayerDetectable` is server-only — AI runs on server.
|
||||
- `PerformLOSCheck` runs on server; results multicast to clients for UI feedback.
|
||||
- `ForceKickFromHide` is server-only (triggered by enemy discovery / damage).
|
||||
|
||||
### Client Prediction
|
||||
- Enter/exit animations: client predicts; server confirms via replicated `CurrentHideState`.
|
||||
- Peek: camera offset is local; state replicated.
|
||||
- Hide spot occupation: `I_HidingSpot.OccupantPawn` is replicated — other clients see "Occupied".
|
||||
- Hide spots with bBlocksStress = true can double as narrative safe rooms.
|
||||
|
||||
---
|
||||
|
||||
@@ -255,4 +255,21 @@ flowchart TD
|
||||
|
||||
---
|
||||
|
||||
## 11. Multiplayer Networking
|
||||
|
||||
**Replication: Minimal.** Embodiment is primarily local rendering. Only visibility mode and overlay state sync for shared visual consistency.
|
||||
|
||||
| Variable | Condition | Purpose |
|
||||
|----------|-----------|---------|
|
||||
| `CurrentVisibility` | `Replicated` | Other clients see correct body visibility (FullBody in mirrors/death) |
|
||||
| `CurrentOverlay` | `Replicated` | Blood/water visible to other players |
|
||||
| Arms IK, wall proximity, overlay blending | **Local only** | First-person rendering is per-client |
|
||||
|
||||
### Authority
|
||||
- `SetVisibilityMode` is server-authoritative for replicated variable; client applies local mesh changes.
|
||||
- `ApplyOverlay` and `ClearOverlay` are server-authoritative.
|
||||
- `CheckWallProximity` and `ApplyOverlayBlendTick` are **local only**.
|
||||
|
||||
---
|
||||
|
||||
*Blueprint Spec: Embodiment System. Conforms to TEMPLATE.md v1.0 — part of the UE5 Modular Game Framework.*
|
||||
@@ -326,4 +326,22 @@ flowchart TD
|
||||
|
||||
---
|
||||
|
||||
## 11. Multiplayer Networking
|
||||
|
||||
**Replication: State only — effects are local.** Camera FOV blending, shake, and post-processing are per-client experiences. Only the state enum syncs.
|
||||
|
||||
| Variable | Condition | Purpose |
|
||||
|----------|-----------|---------|
|
||||
| `CurrentCameraState` | `Replicated` | Synced for shared context (e.g., all players know someone is aiming) |
|
||||
|
||||
### Authority
|
||||
- `RequestCameraState` can be called by client; state replicates to all.
|
||||
- `PlayCameraShake`, `ApplyPostProcessOverride`, `BlendToTargetFOV` are **local only**.
|
||||
- FOV pulse, head bob, camera offset blending are **local only**.
|
||||
|
||||
### Client Prediction
|
||||
- Camera is inherently local — no prediction needed. State changes replicate for other players' awareness.
|
||||
|
||||
---
|
||||
|
||||
*Blueprint Spec: Camera State Layer. Conforms to TEMPLATE.md v1.0 — part of the UE5 Modular Game Framework.*
|
||||
@@ -332,4 +332,26 @@ flowchart TD
|
||||
|
||||
---
|
||||
|
||||
## 11. Multiplayer Networking
|
||||
|
||||
### Replication
|
||||
| Variable | Condition | Purpose |
|
||||
|----------|-----------|---------|
|
||||
| `CurrentSnapshot` | `Replicated` | Synced for scoreboard, playstyle classification |
|
||||
|
||||
### Authority
|
||||
- **Server** accumulates all metrics (listens to gameplay dispatchers server-side).
|
||||
- **Server** creates periodic snapshots and replicates.
|
||||
- **Clients** only read metrics (for local HUD/scoreboard display).
|
||||
|
||||
### Server RPCs
|
||||
| RPC | Direction | Description |
|
||||
|-----|-----------|-------------|
|
||||
| `Server_LogEvent` | Client→Server | Client reports a metric event. Server validates before recording. |
|
||||
|
||||
### Anti-Cheat
|
||||
- Server validates `Server_LogEvent` calls: damage dealt must match server calculations, distance traveled must be plausible, item pickups validated by inventory system.
|
||||
|
||||
---
|
||||
|
||||
*Blueprint Spec: Player Metrics Tracker. Conforms to TEMPLATE.md v1.0 — part of the UE5 Modular Game Framework.*
|
||||
@@ -379,4 +379,29 @@ flowchart TD
|
||||
|
||||
---
|
||||
|
||||
## 11. Multiplayer Networking (Expanded)
|
||||
|
||||
### Replication
|
||||
| Variable | Condition | Purpose |
|
||||
|----------|-----------|---------|
|
||||
| `CurrentTarget` | `Replicated` | Synced target for UI (other players see what you're looking at) |
|
||||
|
||||
### Server RPCs
|
||||
| RPC | Direction | Description |
|
||||
|-----|-----------|-------------|
|
||||
| `Server_PerformInteraction` | Client→Server | Client requests interaction. Server validates range, conditions, then calls I_Interactable. |
|
||||
|
||||
### Authority
|
||||
- **Detection** (trace, sorting, target selection): runs locally per client.
|
||||
- **Interaction execution**: server-authoritative. Client calls `Server_PerformInteraction`; server validates and executes.
|
||||
- `ForceSetTarget`: server-only for scripted interactions.
|
||||
- `HighlightTarget`: local cosmetic effect per client.
|
||||
|
||||
### Client Prediction
|
||||
- Interaction prompt: shown immediately based on local trace.
|
||||
- Hold progress: shown locally; server confirms completion.
|
||||
- Blocked feedback: shown locally if conditions fail client-side; server may also reject.
|
||||
|
||||
---
|
||||
|
||||
*Blueprint Spec: Interaction Detector. Conforms to TEMPLATE.md v1.0 — part of the UE5 Modular Game Framework.*
|
||||
@@ -283,4 +283,26 @@ sequenceDiagram
|
||||
|
||||
---
|
||||
|
||||
## 10. Multiplayer Networking
|
||||
|
||||
### Replicated Variables
|
||||
| Variable | Condition | Purpose |
|
||||
|----------|-----------|---------|
|
||||
| `bOccupied` | `Replicated` | Other clients see spot as occupied |
|
||||
| `LockedByPlayer` | `Replicated` | Synced lock state |
|
||||
| `OccupantPawn` | `Replicated` | Who is hiding here (for third-person visibility) |
|
||||
| `bIsVisible` | `Replicated` | Spot availability synced |
|
||||
|
||||
### Authority
|
||||
- `OnPlayerEntered`/`OnPlayerExited` are called by the server-authoritative `BPC_HidingSystem`.
|
||||
- `LockSpot`/`UnlockSpot` are server-only.
|
||||
- `GetOccupancyStatus` is read-only, safe for any side.
|
||||
|
||||
### Server RPCs
|
||||
| RPC | Direction | Description |
|
||||
|-----|-----------|-------------|
|
||||
| `Server_ClaimSpot` | Client→Server | Client requests occupying spot. Server validates availability. |
|
||||
|
||||
---
|
||||
|
||||
*Blueprint Spec: Hiding Spot Interface & Actor. Conforms to TEMPLATE.md v1.0 — part of the UE5 Modular Game Framework.*
|
||||
@@ -336,4 +336,38 @@ Player Presses Interact
|
||||
|
||||
- This renamed file (formerly `BPC_InteractableDoorComponent`) is now an Actor-based system (`BP_DoorActor`) as per Master Section 3.5.
|
||||
- The door actor encapsulates all door logic directly rather than as an ActorComponent.
|
||||
- Cross-references updated: `BPC_InventoryComponent` → `BPC_InventorySystem`, `BPC_LeverPuzzleComponent` → `BP_PuzzleDeviceActor`.
|
||||
- Cross-references updated: `BPC_InventoryComponent` → `BPC_InventorySystem`, `BPC_LeverPuzzleComponent` → `BP_PuzzleDeviceActor`.
|
||||
|
||||
---
|
||||
|
||||
## 13. Multiplayer Networking (Expanded)
|
||||
|
||||
### Server RPCs
|
||||
|
||||
| RPC | Direction | Description |
|
||||
|-----|-----------|-------------|
|
||||
| `Server_Interact` | Client→Server | Client requests door interaction. Server validates range, state, lock, then executes TryOpen/TryClose. |
|
||||
| `Server_DamageBarricade` | Client→Server | Client deals damage to barricade. Server validates damage source, applies to barricade health. |
|
||||
| `Server_TryUnlock` | Client→Server | Client attempts unlock with key item. Server validates inventory, consumes item if configured. |
|
||||
|
||||
### Authority Gates
|
||||
|
||||
```
|
||||
Interact_Implementation
|
||||
If NOT HasAuthority:
|
||||
→ Call Server_Interact(DoorActor)
|
||||
→ Return (client prediction: show prompt, wait for OnRep)
|
||||
// Server executes authoritative logic
|
||||
→ TryOpen / TryClose / TryUnlock
|
||||
→ OnRep broadcasts to all clients
|
||||
```
|
||||
|
||||
### Client Prediction
|
||||
- **Interaction:** Client calls `Server_Interact` RPC; server validates and changes state.
|
||||
- **Animation:** `OnRep_DoorState` triggers animation on all clients identically.
|
||||
- **Locked feedback:** Played locally by client when server rejects interaction.
|
||||
|
||||
### Anti-Cheat
|
||||
- Server validates player is within interaction range before opening door.
|
||||
- Server validates key item is in player inventory before unlocking.
|
||||
- Server validates barricade damage source.
|
||||
@@ -301,4 +301,10 @@ Below are the most cross-referenced systems — these are the ones the State Man
|
||||
|
||||
---
|
||||
|
||||
*Master Blueprint Index v3.0 — The single reference document for every file in the framework. Now 135 files with State Management + MetaSounds Audio systems.*
|
||||
*Master Blueprint Index v3.1 — The single reference document for every file in the framework. Now 135 files with State Management, MetaSounds Audio, and Multiplayer Networking support.*
|
||||
|
||||
---
|
||||
|
||||
## Multiplayer Networking
|
||||
|
||||
See [`docs/architecture/multiplayer-networking.md`](../architecture/multiplayer-networking.md) for the full networking architecture specification. All blueprint specs include replication stubs, Server RPCs, and authority patterns. Developer docs include Multiplayer Networking sections per category.
|
||||
|
||||
Reference in New Issue
Block a user