Auto-sync: 2026-04-26 12:02
This commit is contained in:
46
wiki/concepts/Actor-Replication.md
Normal file
46
wiki/concepts/Actor-Replication.md
Normal file
@@ -0,0 +1,46 @@
|
||||
---
|
||||
title: "Actor Replication"
|
||||
type: concept
|
||||
tags: []
|
||||
sources: [unreal-multiplayer-architect]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Definition
|
||||
Actor 复制是 UE5 多人游戏网络同步的基础机制，允许 Actor 的属性和状态在服务器与所有客户端之间自动同步。通过 `UPROPERTY(Replicated)` 和 `GetLifetimeReplicatedProps()` 实现。
|
||||
|
||||
## Core Mechanisms
|
||||
- `UPROPERTY(Replicated)` — 将属性标记为需要复制到所有客户端
|
||||
- `UPROPERTY(ReplicatedUsing=OnRep_X)` — 带通知函数的复制，客户端可在属性变化时执行逻辑
|
||||
- `DOREPLIFETIME_CONDITION` — 条件复制，如 `COND_OwnerOnly`、`COND_SimulatedOnly`
|
||||
- `GetNetPriority()` — 控制 Actor 的复制优先级
|
||||
- `SetNetUpdateFrequency()` — 控制 Actor 的复制频率
|
||||
|
||||
## Key Implementation
|
||||
```cpp
|
||||
void AMyNetworkedActor::GetLifetimeReplicatedProps(TArray<FLifetimeProperty>& OutLifetimeProps) const
|
||||
{
|
||||
Super::GetLifetimeReplicatedProps(OutLifetimeProps);
|
||||
DOREPLIFETIME(AMyNetworkedActor, Health);
|
||||
DOREPLIFETIME_CONDITION(AMyNetworkedActor, PrivateInventoryCount, COND_OwnerOnly);
|
||||
}
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
- 仅复制所有客户端都需要的状态
|
||||
- 使用 `COND_OwnerOnly` 减少私有状态的带宽消耗
|
||||
- 按 Actor 类型设置合适的 `NetUpdateFrequency`（大多数 20–30Hz）
|
||||
- 使用 `ReplicatedUsing` 让客户端能响应属性变化
|
||||
|
||||
## Connection to Other Concepts
|
||||
- [[Server-Authoritative Model]] — Actor Replication 是实现服务器权威的技术基础
|
||||
- [[Network Prediction]] — 客户端利用复制的状态进行预测和调和
|
||||
- [[Replication Graph]] — 空间分区优化复制性能
|
||||
|
||||
## Relationship to Agent
|
||||
[[UnrealMultiplayerArchitect]] 强调 Actor 复制的正确实现是 UE5 多人游戏开发的第一步，必须从一开始就用 `DOREPLIFETIME_CONDITION` 进行带宽优化。
|
||||
|
||||
## Aliases
|
||||
- UE5 Replication
|
||||
- Property Replication
|
||||
- State Synchronization
|
||||
52
wiki/concepts/AntiCheatArchitecture.md
Normal file
52
wiki/concepts/AntiCheatArchitecture.md
Normal file
@@ -0,0 +1,52 @@
|
||||
---
|
||||
title: "Anti-Cheat Architecture"
|
||||
type: concept
|
||||
tags: [networking, security, multiplayer]
|
||||
sources: [unity-multiplayer-engineer]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Server-Side Validation
|
||||
- Anti-Cheat
|
||||
- 服务器端验证
|
||||
|
||||
## Definition
|
||||
反作弊架构是一套在服务器权威模型下**验证所有客户端输入**的设计原则和实现方案。由于客户端不可信，所有游戏关键操作必须在服务器端进行验证，拒绝非法请求并记录可疑行为。
|
||||
|
||||
## Core Principles
|
||||
1. **永远不要信任客户端数据**：客户端发送的任何值都需要验证
|
||||
2. **服务器拥有最终裁判权**：位置、生命值、分数等由服务器计算
|
||||
3. **输入验证**：检查输入是否在物理上可行
|
||||
4. **速率限制**：检测并断开超出人类可能速度的 RPC 调用
|
||||
|
||||
## Unity (NGO) Implementation
|
||||
```csharp
|
||||
[ServerRpc]
|
||||
private void SendInputServerRpc(Vector2 input, int tick)
|
||||
{
|
||||
// 服务器端验证：物理上是否可能？
|
||||
float maxDistancePossible = _moveSpeed * Time.fixedDeltaTime * 2f;
|
||||
if (Vector3.Distance(_serverPosition.Value, newPosition) > maxDistancePossible)
|
||||
{
|
||||
// 拒绝：瞬移检测或严重同步错误
|
||||
_serverPosition.Value = _serverPosition.Value; // 强制调和
|
||||
return;
|
||||
}
|
||||
_serverPosition.Value = newPosition;
|
||||
}
|
||||
```
|
||||
|
||||
## Key Techniques
|
||||
- **移动验证**：速度上限检测、瞬移检测
|
||||
- **命中检测**：服务器端验证目标位置和碰撞
|
||||
- **审计日志**：记录所有游戏影响 RPC 的时间戳、玩家ID、动作类型
|
||||
- **速率限制**：每玩家每 RPC 类型的调用频率限制
|
||||
|
||||
## Related Concepts
|
||||
- [[ServerAuthority]]: 反作弊的基础
|
||||
- [[UnityLobby]]: Lobby 数据不应包含游戏状态
|
||||
- [[BandwidthManagement]]: 带宽控制也是反作弊的一部分
|
||||
|
||||
## Related Entities
|
||||
- [[UnityMultiplayerEngineer]]: 实现反作弊架构的专家
|
||||
64
wiki/concepts/BandwidthManagement.md
Normal file
64
wiki/concepts/BandwidthManagement.md
Normal file
@@ -0,0 +1,64 @@
|
||||
---
|
||||
title: "Bandwidth Management"
|
||||
type: concept
|
||||
tags: [networking, performance, multiplayer]
|
||||
sources: [unity-multiplayer-engineer]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Network Bandwidth Optimization
|
||||
- 带宽管理
|
||||
|
||||
## Definition
|
||||
带宽管理是在多人游戏中**控制网络流量**的技术和策略，目标是在有限的带宽下提供流畅的游戏体验。典型目标：每玩家稳态带宽 < 10KB/s。
|
||||
|
||||
## Core Techniques
|
||||
|
||||
### 1. Dirty Check（脏值检查）
|
||||
`NetworkVariable` 仅在值真正变化时触发同步，避免重复设置：
|
||||
```csharp
|
||||
// BAD: 每帧设置相同值 → 无意义网络流量
|
||||
void Update() {
|
||||
Position.Value = transform.position; // 即使位置没变也同步！
|
||||
}
|
||||
|
||||
// GOOD: 值真正变化才同步
|
||||
void FixedUpdate() {
|
||||
if (Vector3.Distance(transform.position, lastPosition) > 0.01f)
|
||||
{
|
||||
Position.Value = transform.position;
|
||||
lastPosition = transform.position;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 2. Throttling（限流）
|
||||
非关键状态更新频率限制：
|
||||
- 生命值条：最高 1Hz
|
||||
- 分数：最高 1Hz
|
||||
- 位置同步：使用 NetworkTransform 而非每帧 NetworkVariable
|
||||
|
||||
### 3. Delta Compression（差分压缩）
|
||||
对复杂结构使用 `INetworkSerializable` 只同步增量：
|
||||
```csharp
|
||||
public struct ComplexState : INetworkSerializable
|
||||
{
|
||||
public Vector3 position;
|
||||
public Quaternion rotation;
|
||||
// 只同步变化的部分
|
||||
}
|
||||
```
|
||||
|
||||
### 4. Object Pooling（对象池）
|
||||
NGO NetworkObject 的 spawn/despawn 成本高，对频繁创建的对象使用对象池复用。
|
||||
|
||||
## Performance Target
|
||||
- 每玩家稳态带宽：< 10KB/s
|
||||
- 峰值带宽（事件触发时）：< 50KB/s
|
||||
- 同步延迟容忍：200ms 延迟下无明显卡顿
|
||||
|
||||
## Related Concepts
|
||||
- [[NetworkVariable]]: 带宽管理的核心对象
|
||||
- [[ClientPrediction]]: 预测减少对服务器状态的依赖
|
||||
- [[UnityMultiplayerEngineer]]: 负责带宽优化的专家
|
||||
40
wiki/concepts/ClientPrediction.md
Normal file
40
wiki/concepts/ClientPrediction.md
Normal file
@@ -0,0 +1,40 @@
|
||||
---
|
||||
title: "Client Prediction"
|
||||
type: concept
|
||||
tags: [networking, multiplayer, latency]
|
||||
sources: [unity-multiplayer-engineer]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Client-Side Prediction
|
||||
- 客户端预测
|
||||
|
||||
## Definition
|
||||
客户端预测是一种在服务器权威模型下的优化技术，允许客户端**立即执行输入预测移动**，无需等待服务器确认，从而提供流畅的用户体验。当服务器状态与客户端预测不一致时，触发**调和（Reconciliation）**机制进行校正。
|
||||
|
||||
## How It Works (Unity NGO Pattern)
|
||||
1. 客户端读取本地输入，立即更新本地渲染位置
|
||||
2. 客户端通过 `ServerRpc` 发送输入到服务器
|
||||
3. 服务器模拟输入，更新权威状态，广播给所有客户端
|
||||
4. 客户端在 `LateUpdate` 中比较预测位置与服务器位置
|
||||
5. 当偏差超过阈值时，强制将客户端位置回正到服务器位置
|
||||
|
||||
## Key Parameters
|
||||
- `ReconciliationThreshold`: 触发回正的偏差阈值（建议 0.5 单位）
|
||||
- 输入队列：客户端缓存最近 N 帧的输入，用于服务器重模拟
|
||||
|
||||
## Related Concepts
|
||||
- [[ServerAuthority]]: 客户端预测的先决条件
|
||||
- [[LagCompensation]]: 与延迟补偿协同工作
|
||||
- [[NetworkVariable]]: 用于同步服务器权威状态
|
||||
|
||||
## Unity Implementation Pattern
|
||||
```csharp
|
||||
// Reconciliation logic in LateUpdate
|
||||
if (Vector3.Distance(transform.position, _serverPosition.Value) > _reconciliationThreshold)
|
||||
{
|
||||
_clientPredictedPosition = _serverPosition.Value;
|
||||
transform.position = _clientPredictedPosition;
|
||||
}
|
||||
```
|
||||
52
wiki/concepts/Core-Gameplay-Loop.md
Normal file
52
wiki/concepts/Core-Gameplay-Loop.md
Normal file
@@ -0,0 +1,52 @@
|
||||
---
|
||||
title: "Core Gameplay Loop"
|
||||
type: concept
|
||||
tags: [game-design, player-experience, engagement]
|
||||
sources: [game-designer]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Core Gameplay Loop（核心游戏循环）是一套驱动玩家持续参与的三层循环结构——从瞬间决策（0-30秒）到会话目标（5-30分钟）再到长期进阶（数小时至数周）。它决定了游戏能否在多个时间尺度上维持玩家兴趣。
|
||||
|
||||
## Three-Layer Structure
|
||||
|
||||
### 1. Moment-to-Moment Loop（瞬间体验，0–30秒）
|
||||
玩家在极短时间内的重复决策与反馈。
|
||||
- **Action**：玩家执行具体操作（跳跃/射击/收集）
|
||||
- **Feedback**：即时视觉/音效/触觉反馈
|
||||
- **Reward**：资源/进度/内在满足感
|
||||
|
||||
> 核心问题：这个操作本身好玩吗？在没有升级、没有故事的情况下，它能独立成立吗？
|
||||
|
||||
### 2. Session Loop（会话循环，5–30分钟）
|
||||
玩家单次游戏会话中的目标与张力。
|
||||
- **Goal**：完成目标以解锁奖励
|
||||
- **Tension**：风险或资源压力（如时间限制、随机事件）
|
||||
- **Resolution**：胜负状态与后果
|
||||
|
||||
### 3. Long-Term Loop（长期循环，小时–周）
|
||||
驱动玩家持续回流的元进度与留存机制。
|
||||
- **Progression**：解锁树 / 元进度系统
|
||||
- **Retention Hook**：每日奖励 / 赛季内容 / 社交循环
|
||||
|
||||
## Design Principles
|
||||
|
||||
1. **每一层都必须独立成立**——长期循环坍塌时，瞬间体验仍能支撑短期参与
|
||||
2. **各层相互增强**——瞬间体验的积累推动会话目标，会话目标的完成推动长期进度
|
||||
3. **最小可行复杂度**——仅添加产生新颖决策的循环，移除不产生意义的复杂性
|
||||
4. **"有趣假设"优先**——在纸面原型阶段验证核心循环的可玩性，而非在完整系统构建后
|
||||
|
||||
## Relationship to Game Design Document
|
||||
|
||||
Core Gameplay Loop 是 GDD 的核心章节，与以下交付物对应：
|
||||
- **Mechanic Specification**：定义瞬间循环中的每个具体操作
|
||||
- **Economy Balance Spreadsheet**：定义会话循环中的资源流
|
||||
- **Player Archetypes**（鲸鱼/海豚/小鱼）：定义长期循环中的不同玩家路径
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Economy Balance]]：经济系统为会话循环和长期循环提供资源基础
|
||||
- [[Player Onboarding]]：引导流程必须快速呈现瞬间循环的可玩性
|
||||
- [[Systemic Design]]：次级系统应与核心循环交互以产生涌现性策略
|
||||
75
wiki/concepts/Economy-Balance.md
Normal file
75
wiki/concepts/Economy-Balance.md
Normal file
@@ -0,0 +1,75 @@
|
||||
---
|
||||
title: "Economy Balance"
|
||||
type: concept
|
||||
tags: [game-design, economy, monetization, balance]
|
||||
sources: [game-designer]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Economy Balance（经济平衡）是游戏内资源流通系统的设计与调优过程——通过控制来源（source）、汇点（sink）和均衡曲线，确保游戏经济在不同玩家路径上都保持健康（无无限循环、无死胡同、无通胀/通缩）。
|
||||
|
||||
## Core Framework
|
||||
|
||||
### Supply & Demand Model
|
||||
|
||||
游戏经济本质上是资源的供给-需求系统：
|
||||
- **Source**（资源来源）：玩家获取货币/道具的途径（任务奖励/掉落/购买）
|
||||
- **Sink**（资源汇点）：资源被消耗的途径（升级/强化/交易税/销毁）
|
||||
- **Equilibrium**：供需平衡曲线，决定经济稳定性
|
||||
|
||||
> 失衡信号：Source > Sink → 通货膨胀（资源贬值）；Source < Sink → 通货紧缩（玩家挫败感）
|
||||
|
||||
### Player Archetypes
|
||||
|
||||
不同付费意愿的玩家需要不同的经济设计：
|
||||
- **Whales（鲸鱼）**：高付费，需要 Prestige Sink（声望消耗机制）防止经济饱和
|
||||
- **Dolphins（海豚）**：中等付费，需要 Value Sink（性价比消耗机制）
|
||||
- **Minnows（小鱼）**：免费玩家，需要 Earnable Aspirational Goals（可获取的激励目标）
|
||||
|
||||
## Inflation Detection
|
||||
|
||||
定义关键指标并设置阈值：
|
||||
- **Metric**：每活跃玩家每日货币增量（Currency per Active Player per Day）
|
||||
- **Threshold**：当指标超过预设值时触发平衡调整流程
|
||||
- **Adjustment**：调整 Source（降低产出）或 Sink（增加消耗）以恢复平衡
|
||||
|
||||
## Advanced Methods
|
||||
|
||||
### Monte Carlo Simulation
|
||||
|
||||
在代码实现前对进度曲线进行蒙特卡洛模拟：
|
||||
- 模拟 1000+ 随机玩家路径
|
||||
- 识别极端情况（极速通关 vs 长期卡关）
|
||||
- 提前发现经济漏洞
|
||||
|
||||
### Paper Simulation
|
||||
|
||||
在电子表格中进行玩家经济路径模拟：
|
||||
- 穷举主要玩家路径
|
||||
- 验证无无限资源获取循环
|
||||
- 测试边界条件（最小/最大资源持有量）
|
||||
|
||||
## Design Standards
|
||||
|
||||
| Variable | Base Value | Min | Max | Tuning Notes |
|
||||
|----------|-----------|-----|-----|--------------|
|
||||
| Player HP | 100 | 50 | 200 | Scales with level |
|
||||
| Enemy Damage | 15 | 5 | 40 | [PLACEHOLDER] - test at level 5 |
|
||||
| Resource Drop % | 0.25 | 0.1 | 0.6 | Adjust per difficulty |
|
||||
| Ability Cooldown | 8s | 3s | 15s | Feel test required |
|
||||
|
||||
> 所有数值从假设开始，用 `[PLACEHOLDER]` 标记，直至通过测试验证
|
||||
|
||||
## Relationship to Core Gameplay Loop
|
||||
|
||||
Economy Balance 支撑会话循环和长期循环：
|
||||
- **会话循环**：资源稀缺性制造张力（Source - Sink = 可用资源）
|
||||
- **长期循环**：货币通胀/通缩直接影响玩家成就感曲线
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Core Gameplay Loop]]：经济系统为循环提供资源流通基础
|
||||
- [[Behavioral Economics in Games]]：经济设计中的行为心理学应用（损失厌恶、变率奖励）
|
||||
- [[Player Archetypes]]：不同付费玩家的经济需求差异
|
||||
65
wiki/concepts/GAS-Gameplay-Ability-System.md
Normal file
65
wiki/concepts/GAS-Gameplay-Ability-System.md
Normal file
@@ -0,0 +1,65 @@
|
||||
---
|
||||
title: "GAS (Gameplay Ability System)"
|
||||
type: concept
|
||||
tags: [unreal-engine, networking, multiplayer, ue5, abilities]
|
||||
sources: ["unreal-multiplayer-architect", "unreal-systems-engineer"]
|
||||
last_updated: 2026-04-26
|
||||
|
||||
## Additional Sources
|
||||
Gameplay Ability System（GAS）是 UE5 的可扩展技能与属性框架，通过 UGameplayAbility、UAttributeSet、UAbilitySystemComponent 实现网络就绪的技能系统。[[UnrealSystemsEngineer]] 补充：所有 Tick 逻辑必须 C++；FGameplayTag 优于字符串标识符；通过 UPROPERTY(ReplicatedUsing=OnRep_Health) + GAMEPLAYATTRIBUTE_REPNOTIFY 宏实现属性复制。
|
||||
|
||||
## Core Components
|
||||
- **UAbilitySystemComponent**：GAS 核心组件，管理技能和属性，必须正确配置网络复制
|
||||
- **UGameplayAbility**：可激活的技能类，支持网络预测和复制
|
||||
- **FGameplayEffectContext**：技能效果上下文，携带命中结果、来源和自定义数据
|
||||
- **FPredictionKey**：预测键，标记可预测的能力和属性变更，支持服务器确认或回滚
|
||||
- **UAttributeSet**：属性集，包含可复制的游戏属性（生命值、能量等）
|
||||
|
||||
## Network Integration (Dual Init Path)
|
||||
GAS 在多人游戏中必须实现双路径初始化：
|
||||
|
||||
```cpp
|
||||
// 服务器路径 — PossessedBy 在 Actor 被 Controller 拥有时调用
|
||||
void AMyCharacter::PossessedBy(AController* NewController)
|
||||
{
|
||||
Super::PossessedBy(NewController);
|
||||
AbilitySystemComponent->InitAbilityActorInfo(GetPlayerState(), this);
|
||||
}
|
||||
|
||||
// 客户端路径 — OnRep_PlayerState 在 PlayerState 复制到达时调用
|
||||
void AMyCharacter::OnRep_PlayerState()
|
||||
{
|
||||
Super::OnRep_PlayerState();
|
||||
AbilitySystemComponent->InitAbilityActorInfo(GetPlayerState(), this);
|
||||
}
|
||||
```
|
||||
|
||||
## Network Prediction in GAS
|
||||
- `FPredictionKey`：标记所有预测变更，服务器确认后生效
|
||||
- 客户端预测技能激活和属性变更
|
||||
- 服务器验证并广播 `GameplayEffect` 到所有客户端
|
||||
- 验证失败时服务器回滚客户端预测
|
||||
|
||||
## Best Practices
|
||||
- **双路径初始化**：必须在 `PossessedBy` 和 `OnRep_PlayerState` 两个入口点初始化 GAS
|
||||
- **AttributeSet 复制**：使用 `UPROPERTY(Replicated)` 让属性在服务器和客户端同步
|
||||
- **预测管理**：高频技能必须正确设置 `NetDeltaFrequency` 避免带宽爆炸
|
||||
- **预测键作用域**：`FPredictionKey` 必须在能力激活时生成并传递给所有子操作
|
||||
|
||||
## Connection to Other Concepts
|
||||
- [[Actor Replication]] — GAS 依赖 Actor 复制机制同步属性和状态
|
||||
- [[Network Prediction]] — GAS 内置网络预测支持（FPredictionKey）
|
||||
- [[Server-Authoritative Model]] — 服务器权威验证技能激活请求
|
||||
|
||||
## Relationship to Agent
|
||||
[[UnrealMultiplayerArchitect]] 强调：GAS 网络集成必须从双路径初始化开始，测试必须在 150ms 模拟延迟下验证技能激活，"Profile GAS replication overhead" 是网络优化的关键步骤。
|
||||
|
||||
[[UnrealSystemsEngineer]] 补充：系统架构师负责 UGameplayAbility/UAttributeSet C++ 实现和 BlueprintCallable 暴露；Tick 依赖逻辑必须 C++（即使是技能冷却检查）；AttributeSet 使用 FGameplayAttributeData + GAMEPLAYATTRIBUTE_REPNOTIFY 宏保证复制安全。
|
||||
|
||||
## Aliases
|
||||
- Gameplay Ability System
|
||||
- UE5 GAS
|
||||
- AbilitySystemComponent
|
||||
- FPredictionKey
|
||||
- GameplayEffect
|
||||
- AttributeSet
|
||||
37
wiki/concepts/LOD.md
Normal file
37
wiki/concepts/LOD.md
Normal file
@@ -0,0 +1,37 @@
|
||||
---
|
||||
title: "LOD"
|
||||
type: concept
|
||||
tags: ["game-engine", "performance-optimization", "3d-graphics"]
|
||||
sources: ["unreal-technical-artist", "unreal-world-builder"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Definition
|
||||
Level of Detail（LOD），根据渲染对象与摄像机距离动态切换网格体精度（或着色复杂度）的机制。是 3D 游戏引擎性能优化的基础技术。
|
||||
|
||||
## LOD Strategy
|
||||
- **Nanite 资产**：自动 LOD，无需手动配置
|
||||
- **非 Nanite 资产**（骨骼网格体、样条线、程序化网格体）：必须手动配置 LOD 链，并验证距离过渡
|
||||
|
||||
## Manual LOD Chain Requirements
|
||||
- 每个资产必须定义 LOD0–LOD3 最低要求
|
||||
- 过渡距离必须在目标硬件上验证
|
||||
- 开放世界道具（无 Nanite）超过 500 三角形须有文档化例外
|
||||
|
||||
## Cull Distance
|
||||
LOD 之外还需要 Cull Distance Volumes 配置远距离剔除：
|
||||
- 按资产类别设置，非全局统一
|
||||
- 所有开放世界关卡必须配置
|
||||
|
||||
## HLOD（Hierarchical LOD）
|
||||
- World Partition 开放世界的必备配置
|
||||
- 将多个小对象合并为大型远距离代理
|
||||
- 必须为所有室外区域生成 HLOD
|
||||
|
||||
## Relationship to Nanite
|
||||
Nanite 本质上是自动 LOD 系统，适用于静态几何体。LOD 链是手动 LOD 系统，用于 Nanite 无法处理的资产类型。
|
||||
|
||||
## Related
|
||||
- [[Nanite]] — 自动 LOD 系统
|
||||
- [[PerformanceBudget]] — LOD 是帧预算控制的核心工具
|
||||
- [[WorldPartition]] — HLOD 的配合框架
|
||||
36
wiki/concepts/LagCompensation.md
Normal file
36
wiki/concepts/LagCompensation.md
Normal file
@@ -0,0 +1,36 @@
|
||||
---
|
||||
title: "Lag Compensation"
|
||||
type: concept
|
||||
tags: [networking, multiplayer, latency]
|
||||
sources: [unity-multiplayer-engineer]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Server-Side Lag Compensation
|
||||
- 延迟补偿
|
||||
|
||||
## Definition
|
||||
延迟补偿是一种在服务器权威模型下**考虑网络延迟影响**的技术。当服务器处理客户端的射击/命中请求时，需要将客户端的请求时间「回溯」到网络延迟对应的时间点，以提供公平的命中判定。
|
||||
|
||||
## Problem It Solves
|
||||
在没有延迟补偿的情况下：
|
||||
- 客户端 A 看到命中了客户端 B
|
||||
- 但由于网络延迟，B 已经移动到了新位置
|
||||
- 结果：A 的命中被服务器拒绝，但 A 看到的是命中效果 → 体验不一致
|
||||
|
||||
## Standard Approach
|
||||
1. 客户端发送带有**时间戳**的输入/射击请求
|
||||
2. 服务器根据网络延迟计算**回溯时间**
|
||||
3. 服务器将目标玩家「回放」到回溯时间点的位置
|
||||
4. 在该位置进行命中判定
|
||||
5. 结果同步给所有客户端
|
||||
|
||||
## Related Concepts
|
||||
- [[ServerAuthority]]: 延迟补偿依赖服务器权威
|
||||
- [[ClientPrediction]]: 两者结合提供流畅且公平的游戏体验
|
||||
- [[AntiCheatArchitecture]]: 延迟补偿同时是反作弊的重要手段
|
||||
|
||||
## Related Entities
|
||||
- [[UnityMultiplayerEngineer]]: 实现延迟补偿的专家
|
||||
- [[UnrealMultiplayerArchitect]]: 虚幻引擎中的对应实现
|
||||
40
wiki/concepts/LargeWorldCoordinates.md
Normal file
40
wiki/concepts/LargeWorldCoordinates.md
Normal file
@@ -0,0 +1,40 @@
|
||||
---
|
||||
title: "Large World Coordinates"
|
||||
type: concept
|
||||
tags: ["unreal-engine", "coordinate-system", "precision", "ue5", "open-world"]
|
||||
sources: ["unreal-world-builder"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Definition
|
||||
Large World Coordinates（LWC），UE5 双精度坐标系统，通过在引擎层面使用 double（64 位浮点）替代 float（32 位浮点）存储世界位置坐标，解决超大世界（>2km）远距离处的浮点精度误差问题。
|
||||
|
||||
## The Precision Problem
|
||||
- 单精度浮点（float）在距离原点约 20km 处开始出现可见精度误差
|
||||
- 误差表现：抖动（Jitter）、接缝（Seam）、几何体重影（Ghosting）
|
||||
- 开放世界项目（4km² ~ 64km²）极易触碰到此阈值
|
||||
|
||||
## When LWC is Required
|
||||
- **任何轴超过 2km 的世界必须启用 LWC**
|
||||
- 测试方法：在距离原点 100km 处生成玩家，验证无视觉或物理瑕疵
|
||||
|
||||
## LWC Compatibility Requirements
|
||||
### Shader/Material
|
||||
- 替换所有直接 world position 采样为 `LWCToFloat()` 函数
|
||||
- 否则可能导致远处的材质出现视觉错误
|
||||
|
||||
### Gameplay Code
|
||||
- 世界位置使用 `FVector3d`（双精度）而非 `FVector`（单精度）
|
||||
- 特别是在处理坐标计算、Actor 放置、寻路等逻辑时
|
||||
|
||||
### Asset Pipeline
|
||||
- 检查第三方 DDC（Derived Data Cache）资产是否正确配置 LWC
|
||||
- 某些旧资产导入流程可能未处理双精度坐标
|
||||
|
||||
## Relationship to World Partition
|
||||
LWC 与 World Partition 协同：World Partition 管理大世界的分区流送，LWC 解决大世界的坐标精度问题，两者共同支撑 UE5 开放世界技术栈。
|
||||
|
||||
## Related
|
||||
- [[UnrealWorldBuilder]] — LWC 配置与审计专家
|
||||
- [[WorldPartition]] — LWC 的配套分区管理框架
|
||||
- [[Nanite]] — Nanite 虚拟几何体在大世界中的使用不受 LWC 影响（Nanite 内部使用相对坐标）
|
||||
28
wiki/concepts/MaterialFunction.md
Normal file
28
wiki/concepts/MaterialFunction.md
Normal file
@@ -0,0 +1,28 @@
|
||||
---
|
||||
title: "MaterialFunction"
|
||||
type: concept
|
||||
tags: ["unreal-engine", "materials", "shader"]
|
||||
sources: ["unreal-technical-artist"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Definition
|
||||
UE5 Material Editor 中可封装、可复用的节点逻辑单元。封装一组节点图作为黑盒函数，供多个 Master Material 引用。
|
||||
|
||||
## Purpose
|
||||
消除跨 Master Material 的重复节点簇，确保同一逻辑只需维护一处。
|
||||
|
||||
## Usage in This Wiki
|
||||
- [[unreal-technical-artist]] 强制规定：所有可复用逻辑必须封装为 Material Function，禁止在多个 Master Material 间重复节点簇
|
||||
- 示例：MF_TriplanarMapping（三平面映射）封装 WorldPosition 投影逻辑，可在任意岩石、悬崖、地形混合材质中使用
|
||||
|
||||
## Key Principles
|
||||
- 单一职责：一个 Function 只做一件事（三平面映射 / 噪声叠加 / 顶点偏移等）
|
||||
- 输入输出清晰：所有可调参数通过 Input 节点暴露
|
||||
- 禁止副作用：Function 内部不应修改外部状态
|
||||
- 避免 Static Switch 嵌套：每个 Static Switch 使引用该 Function 的材质排列数翻倍
|
||||
|
||||
## Related
|
||||
- [[MaterialEditor]] — Material Function 的创作环境
|
||||
- [[QualitySwitch]] — 同一材质内的质量分层机制
|
||||
- [[NiagaraVFX]] — VFX 系统，类似 Function 的模块化复用理念
|
||||
37
wiki/concepts/Nanite.md
Normal file
37
wiki/concepts/Nanite.md
Normal file
@@ -0,0 +1,37 @@
|
||||
---
|
||||
title: "Nanite"
|
||||
type: concept
|
||||
tags: ["unreal-engine", "geometry", "performance-optimization"]
|
||||
sources: ["unreal-technical-artist", "unreal-systems-engineer", "unreal-world-builder"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Definition
|
||||
UE5 虚拟几何体系统（Virtualized Geometry System），支持自动 LOD 和海量实例化渲染。Nanite 将几何体视为由微小三角形组成的流式资源，根据屏幕空间距离动态选择精度。
|
||||
|
||||
## Key Properties
|
||||
- **自动 LOD**：无需手动配置 LOD 链，系统自动处理
|
||||
- **海量实例**：支持数千个网格体同时渲染，由 PCG 驱动时尤为重要
|
||||
- **确定性精度**：相同场景始终产生相同的三角形流
|
||||
- **Nanite 禁用例外**：骨骼网格体、样条线网格体、程序化网格体无法使用 Nanite，必须手动配置 LOD 链
|
||||
|
||||
## In the PCG Pipeline
|
||||
所有 PCG 放置的静态网格体必须在 Nanite 适用时启用。PCG 的高密度特性（数千实例）与 Nanite 的海量渲染能力天然契合。
|
||||
|
||||
## LOD vs Nanite
|
||||
| 特性 | 手动 LOD | Nanite |
|
||||
|------|---------|--------|
|
||||
| 精度切换 | 固定距离阈值 | 屏幕空间连续 |
|
||||
| 配置成本 | 高（需逐资产手动配置） | 低（启用即可） |
|
||||
| 适用资产 | 所有类型 | 静态网格体 |
|
||||
| 骨骼/程序化 | 支持 | 不支持 |
|
||||
|
||||
## Performance Implication
|
||||
- 无 Nanite 资产的开放世界道具：禁止超过 500 三角形且无文档化例外
|
||||
- Cull Distance：Nanite 资产的远距离剔除仍通过 Cull Distance Volumes 配置
|
||||
- **[[UnrealSystemsEngineer]] 补充**：单场景硬上限 **1600 万实例**，开放世界项目需提前规划实例预算；Nanite 隐式在像素着色器推导切线空间（减少几何数据体积），因此 Nanite 网格不得存储显式切线；Nanite 不兼容骨骼网格（用标准 LOD）、复杂 clip 操作的遮罩材质（需性能基准测试）、样条网格和程序化网格组件；使用 `r.Nanite.Visualize` 模式提前发现兼容性问题
|
||||
|
||||
## Related
|
||||
- [[LOD]] — 非 Nanite 资产的 LOD 链配置
|
||||
- [[PCG]] — Nanite 的主要应用场景
|
||||
- [[PerformanceBudget]] — Nanite 是开放世界性能预算的关键工具
|
||||
45
wiki/concepts/Network-Prediction.md
Normal file
45
wiki/concepts/Network-Prediction.md
Normal file
@@ -0,0 +1,45 @@
|
||||
---
|
||||
title: "Network Prediction"
|
||||
type: concept
|
||||
tags: []
|
||||
sources: [unreal-multiplayer-architect]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Definition
|
||||
网络预测是 UE5 多人游戏中减少客户端感知延迟的核心技术。客户端在发送输入到服务器的同时，本地执行游戏逻辑（预测结果），当服务器确认结果返回时，客户端对比并调和（Reconcile）任何差异。
|
||||
|
||||
## Why It Matters
|
||||
即使服务器在 100ms 后才返回结果，客户端通过预测可以让玩家感受到即时响应：
|
||||
|
||||
```
|
||||
客户端发送输入 → 本地预测执行 → 显示预测结果（立即）→ 服务器执行 → 客户端调和（100ms后）
|
||||
```
|
||||
|
||||
## Prediction in UE5
|
||||
- **Movement Prediction**：角色移动在客户端本地预测
|
||||
- **Ability Prediction (GAS)**：`FPredictionKey` 标记所有预测变更，服务器确认或回滚
|
||||
- **Reconciliation**：服务器权威结果与客户端预测结果对比时，自动校正客户端状态
|
||||
|
||||
## Key Methods
|
||||
- `NetMulticast Unreliable` — 服务器向所有客户端广播，用于触发预测性的视觉效果
|
||||
- `FPredictionKey` — GAS 中的预测键，标记可预测的能力和属性变更
|
||||
- `p.NetShowCorrections 1` — 调试命令，可视化调和事件
|
||||
|
||||
## Prediction Pitfalls
|
||||
- 过度预测会导致大量回滚（Rollback），影响游戏体验
|
||||
- 仅预测确定性输入（移动、射击）——不预测随机事件
|
||||
- 在高延迟（>200ms）环境下需要特别调优预测容差
|
||||
|
||||
## Connection to Other Concepts
|
||||
- [[Server-Authoritative Model]] — 预测依赖服务器最终权威结果
|
||||
- [[Actor Replication]] — 复制的状态是预测和调和的数据基础
|
||||
- [[RPC (Remote Procedure Call)]] — 客户端通过 Server RPC 发送输入触发预测
|
||||
|
||||
## Relationship to Agent
|
||||
[[UnrealMultiplayerArchitect]] 强调："Desync events (reconciliations) < 1 per player per 30 seconds at 200ms ping" 是成功指标，网络预测的质量直接影响该指标。
|
||||
|
||||
## Aliases
|
||||
- Client-Side Prediction
|
||||
- Rollback Prediction
|
||||
- Reconciliation
|
||||
44
wiki/concepts/NetworkVariable.md
Normal file
44
wiki/concepts/NetworkVariable.md
Normal file
@@ -0,0 +1,44 @@
|
||||
---
|
||||
title: "NetworkVariable"
|
||||
type: concept
|
||||
tags: [networking, unity, ngo]
|
||||
sources: [unity-multiplayer-engineer]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- NetworkVariable<T>
|
||||
- NV (abbreviation)
|
||||
|
||||
## Definition
|
||||
`NetworkVariable<T>` 是 Unity Netcode for GameObjects（NGO）中的核心类型，用于**持久化复制状态**——当值发生变化时，自动通过网络同步到所有客户端。仅在值真正变化时触发同步（dirty check）。
|
||||
|
||||
## Usage Rules
|
||||
| 场景 | 应使用 |
|
||||
|------|--------|
|
||||
| 持久化、需要同步的状态 | `NetworkVariable` |
|
||||
| 一次性事件、触发通知 | `ClientRpc` / `ServerRpc` |
|
||||
|
||||
**核心原则：持久化用 NetworkVariable，一次性事件用 RPC，不可混用。**
|
||||
|
||||
## Bandwidth Considerations
|
||||
- **避免在 Update() 中重复设置相同值**——触发无意义的网络同步
|
||||
- 对高频数值使用差分压缩（`INetworkSerializable`）
|
||||
- 非关键状态（血条、分数）限流至最高 10Hz
|
||||
|
||||
## Example
|
||||
```csharp
|
||||
// 健康值：持久化 → NetworkVariable
|
||||
public NetworkVariable<int> PlayerHealth = new(100,
|
||||
NetworkVariableReadPermission.Everyone,
|
||||
NetworkVariableWritePermission.Server);
|
||||
|
||||
// 命中特效：一次性事件 → ClientRpc
|
||||
[ClientRpc]
|
||||
public void OnHitClientRpc(Vector3 hitPoint) { ... }
|
||||
```
|
||||
|
||||
## Related Concepts
|
||||
- [[ServerAuthority]]: NetworkVariable 体现服务器权威
|
||||
- [[BandwidthManagement]]: 优化 NetworkVariable 使用
|
||||
- [[ClientPrediction]]: 结合 NetworkVariable 实现客户端预测
|
||||
42
wiki/concepts/NiagaraVFX.md
Normal file
42
wiki/concepts/NiagaraVFX.md
Normal file
@@ -0,0 +1,42 @@
|
||||
---
|
||||
title: "NiagaraVFX"
|
||||
type: concept
|
||||
tags: ["unreal-engine", "vfx", "particle-systems"]
|
||||
sources: ["unreal-technical-artist"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Definition
|
||||
UE5 新一代粒子和 VFX（视觉效果）系统，替代旧版 Cascade。核心设计理念：GPU/CPU 模拟分离、模块化可复用、Scalability 分级预设。
|
||||
|
||||
## Key Design Decisions
|
||||
- **GPU vs CPU 选择**：粒子数 < 1000 用 CPU 模拟；粒子数 > 1000 用 GPU 模拟
|
||||
- **Max Particle Count 强制**：所有系统必须设置硬上限，禁止无限粒子
|
||||
- **Scalability 三档预设**：High（PC/主机高端）、Medium（主机基准/中端 PC）、Low（移动/性能模式），必须全部测试后交付
|
||||
|
||||
## Scalability Preset Example
|
||||
| 档位 | 最大活跃系统数 | 每系统最大粒子数 | 剔除距离 |
|
||||
|------|--------------|----------------|---------|
|
||||
| High | 10 | 50 | — |
|
||||
| Medium | 6 | 25 | 30m |
|
||||
| Low | 3 | 10 | 15m |
|
||||
|
||||
## Key Modules
|
||||
- Initialize Particle：生命周期、缩放、颜色参数化
|
||||
- Initial Velocity：锥形扩散、重力方向
|
||||
- Drag：水平摩擦力控制扩散范围
|
||||
- Scale Color/Opacity：线性淡出曲线
|
||||
|
||||
## Rendering
|
||||
- Sprite Renderer + T_Particle 纹理集（4×4 帧动画）
|
||||
- Blend Mode: Translucent，峰值时最多 3 层 overdraw
|
||||
|
||||
## Advanced Capabilities
|
||||
- GPU Simulation Stages：流体类粒子动力学（邻居查询、压力、速度场）
|
||||
- Data Interface：查询物理场景数据、网格表面、音频频谱
|
||||
- Parameter Collections：接收游戏状态参数，实现 VFX 实时响应玩法
|
||||
|
||||
## Related
|
||||
- [[VFX]] — 游戏 VFX 通用概念
|
||||
- [[PerformanceBudget]] — Niagara 帧预算管理
|
||||
- [[QualitySwitch]] — 材质质量分层，与 Niagara Scalability 理念一致
|
||||
38
wiki/concepts/PCG.md
Normal file
38
wiki/concepts/PCG.md
Normal file
@@ -0,0 +1,38 @@
|
||||
---
|
||||
title: "PCG"
|
||||
type: concept
|
||||
tags: ["unreal-engine", "procedural-generation", "open-world"]
|
||||
sources: ["unreal-technical-artist", "unreal-world-builder"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Definition
|
||||
Procedural Content Generation（程序化内容生成），UE5 框架，通过图节点控制开放世界资产分布、地形采样、密度过滤和实例化放置。输出确定性：相同输入图和参数始终产生相同结果。
|
||||
|
||||
## Core Pipeline
|
||||
1. **Input**：Landscape Surface Sampler → 密度和坡度过滤
|
||||
2. **Transform Points**：Jitter 位置（±1.5m XY）、随机旋转（仅 Yaw）、缩放变化（0.8–1.3）
|
||||
3. **Density Filter**：Poisson Disk 最小间距（防止重叠）、Biome 密度纹理采样
|
||||
4. **Exclusion Zones**：道路缓冲（5m）、玩家路径缓冲（3m）、手动放置 Actor 排除半径（10m）
|
||||
5. **Static Mesh Spawner**：权重分配（橡树 40%、松树 35%、桦树 20%、枯树 5%），全启用 Nanite
|
||||
|
||||
## Parameter Interface（必须文档化）
|
||||
- GlobalDensityMultiplier（0.0–2.0）
|
||||
- MinSeparationDistance（1.0–5.0m）
|
||||
- EnableRoadExclusion（bool）
|
||||
|
||||
## Performance Constraints
|
||||
- 最差情况下生成时间 < 3 秒
|
||||
- 流式加载不得造成帧卡顿（World Partition 配合）
|
||||
- PCG 密度控制：PCG → Nanite，密度可扩展至数千实例
|
||||
|
||||
## Advanced Patterns
|
||||
- Gameplay Tags 查询驱动环境分布规则
|
||||
- 递归 PCG：图 A 的输出作为图 B 的输入
|
||||
- Runtime PCG：几何体破坏后重新运行图
|
||||
- PCG 调试工具：编辑器视口内可视化点密度、属性值、排除区边界
|
||||
|
||||
## Related
|
||||
- [[Nanite]] — PCG 放置资产的首选渲染模式
|
||||
- [[WorldPartition]] — 与 PCG 流式加载协同
|
||||
- [[Procedural-Level-Design]] — 更广义的程序化关卡设计概念
|
||||
33
wiki/concepts/QualitySwitch.md
Normal file
33
wiki/concepts/QualitySwitch.md
Normal file
@@ -0,0 +1,33 @@
|
||||
---
|
||||
title: "QualitySwitch"
|
||||
type: concept
|
||||
tags: ["unreal-engine", "materials", "performance-optimization", "platform-targeting"]
|
||||
sources: ["unreal-technical-artist"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Definition
|
||||
UE5 Material Editor 中的 Quality Switch 节点，允许在单一材质图内定义多档质量层级（Mobile / Console / PC），引擎根据目标平台自动选择对应分支。
|
||||
|
||||
## Quality Tiers
|
||||
- **High**：PC/主机高端 — 完整着色器逻辑，所有纹理层
|
||||
- **Medium**：主机基准/中端 PC — 简化逻辑，较低纹理分辨率
|
||||
- **Low**：移动设备/主机性能模式 — 最简化逻辑，单一纹理层
|
||||
|
||||
## Key Principles
|
||||
- 在单个材质图中而非多个材质文件中管理质量差异
|
||||
- Quality Switch 是架构设计工具，不是性能问题修复工具
|
||||
- 必须在所有三档上验证视觉一致性
|
||||
|
||||
## Relationship to Niagara Scalability
|
||||
Quality Switch 用于**材质**质量分层，Niagara Scalability 用于**VFX** 质量分层。两者共同构成 UE5 项目的完整质量分级体系。
|
||||
|
||||
## Shader Complexity Implication
|
||||
- 每个 Static Switch **使着色器排列数翻倍**（而非加法增加）
|
||||
- 添加 Static Switch 前必须审计
|
||||
- Quality Switch 节点本身不翻倍，但其控制的分支逻辑可能包含 Static Switch
|
||||
|
||||
## Related
|
||||
- [[NiagaraVFX]] — VFX 系统的 Scalability 分级
|
||||
- [[PerformanceBudget]] — Quality Switch 是平台预算管理工具
|
||||
- [[MaterialFunction]] — Quality Switch 可封装在 Function 中
|
||||
59
wiki/concepts/RPC-Remote-Procedure-Call.md
Normal file
59
wiki/concepts/RPC-Remote-Procedure-Call.md
Normal file
@@ -0,0 +1,59 @@
|
||||
---
|
||||
title: "RPC (Remote Procedure Call)"
|
||||
type: concept
|
||||
tags: []
|
||||
sources: [unreal-multiplayer-architect]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Definition
|
||||
远程过程调用（RPC）是 UE5 多人游戏中客户端与服务器之间进行通信的核心机制。客户端通过 RPC 向服务器发送请求（Server RPC），服务器通过 RPC 向客户端或所有客户端广播事件（Client RPC / NetMulticast）。
|
||||
|
||||
## RPC Types
|
||||
| 类型 | 方向 | 可靠性 | 用途 |
|
||||
|------|------|--------|------|
|
||||
| `Server` | 客户端 → 服务器 | Reliable/Unreliable | 客户端请求服务器执行操作 |
|
||||
| `Client` | 服务器 → 特定客户端 | Reliable/Unreliable | 服务器通知特定客户端 |
|
||||
| `NetMulticast` | 服务器 → 所有客户端 | Reliable/Unreliable | 服务器广播事件 |
|
||||
|
||||
## Critical Rule: WithValidation
|
||||
**每个游戏影响型的 Server RPC 必须实现 `_Validate()` 函数。** 缺失 `_Validate()` 构成安全漏洞，恶意客户端可发送非法请求。
|
||||
|
||||
```cpp
|
||||
// Server RPC 必须有 WithValidation
|
||||
UFUNCTION(Server, Reliable, WithValidation)
|
||||
void ServerRequestInteract(AActor* Target);
|
||||
|
||||
bool AMyActor::ServerRequestInteract_Validate(AActor* Target)
|
||||
{
|
||||
// 拒绝不可能的请求
|
||||
if (!IsValid(Target)) return false;
|
||||
float Distance = FVector::Dist(GetActorLocation(), Target->GetActorLocation());
|
||||
return Distance < 200.f; // 最大交互距离
|
||||
}
|
||||
|
||||
void AMyActor::ServerRequestInteract_Implementation(AActor* Target)
|
||||
{
|
||||
// 验证通过后安全执行
|
||||
PerformInteraction(Target);
|
||||
}
|
||||
```
|
||||
|
||||
## Reliability Guidelines
|
||||
- **Reliable**：保证按序到达，用于游戏关键事件（伤害、得分、道具拾取）
|
||||
- **Unreliable**：即发即忘，不保证到达，用于视觉效果、高频位置同步
|
||||
- 绝不能将高频调用与可靠 RPC 混合——必须为高频数据创建独立的不可靠更新路径
|
||||
|
||||
## Connection to Other Concepts
|
||||
- [[Server-Authoritative Model]] — RPC 是服务器权威执行的游戏请求入口
|
||||
- [[Actor Replication]] — 属性复制与 RPC 互补，复制状态、RPC 触发动作
|
||||
- [[Network Prediction]] — 客户端在等待服务器 RPC 响应时进行本地预测
|
||||
|
||||
## Relationship to Agent
|
||||
[[UnrealMultiplayerArchitect]] 将 RPC 验证视为非妥协原则："Every Server RPC needs a `_Validate`. No exceptions."
|
||||
|
||||
## Aliases
|
||||
- Remote Procedure Call
|
||||
- Server RPC
|
||||
- Client RPC
|
||||
- NetMulticast
|
||||
54
wiki/concepts/Replication-Graph.md
Normal file
54
wiki/concepts/Replication-Graph.md
Normal file
@@ -0,0 +1,54 @@
|
||||
---
|
||||
title: "Replication Graph"
|
||||
type: concept
|
||||
tags: [unreal-engine, networking, multiplayer, ue5]
|
||||
sources: [unreal-multiplayer-architect]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Definition
|
||||
Replication Graph 是 UE5 的空间分区复制优化系统，用空间网格分区替代默认的扁平相关性模型。通过只向相关客户端复制区域内的 Actor，显著降低带宽消耗。核心机制：`UReplicationGraphNode_GridSpatialization2D`（开放世界空间网格）和自定义 `UReplicationGraphNode`（休眠 Actor 优化）。
|
||||
|
||||
## Core Mechanisms
|
||||
- **空间网格分区**：基于 2D 空间网格，将世界划分为网格单元，每个单元仅复制给附近玩家
|
||||
- **休眠 Actor 优化**：NPC 等休眠 Actor 不在任何玩家附近时，以极低频率复制
|
||||
- **动态 relevancy**：根据客户端视角动态决定 Actor 的相关性
|
||||
- `UReplicationGraphNode_GridSpatialization2D`：开放世界空间分区节点
|
||||
- `UReplicationGraphNode`：可自定义的复制图节点基类
|
||||
|
||||
## Implementation
|
||||
```cpp
|
||||
// 启用 Replication Graph 插件
|
||||
// DefaultEngine.ini
|
||||
[/Script/OnlineSubsystemUtils.IpNetDriver]
|
||||
ReplicationGraphClassName=ReplicationGraph.UReplicationGraph
|
||||
|
||||
// 自定义休眠节点
|
||||
UCLASS()
|
||||
class UMyDormancyNode : public UReplicationGraphNode
|
||||
{
|
||||
// 重写 DetermineWrites 会话逻辑
|
||||
};
|
||||
```
|
||||
|
||||
## Key Benefits
|
||||
- 开放世界多人游戏中带宽降低 40%+
|
||||
- 仅复制视野内 Actor，减少不必要的网络流量
|
||||
- 可自定义节点类型适配特殊需求
|
||||
|
||||
## Network Profiling Commands
|
||||
- `net.RepGraph.PrintAllNodes` — 打印所有复制图节点信息
|
||||
- Unreal Insights — 性能分析工具，测量复制图对带宽的影响
|
||||
|
||||
## Connection to Other Concepts
|
||||
- [[Actor Replication]] — Replication Graph 是 Actor 复制的空间优化层
|
||||
- [[Server-Authoritative Model]] — 服务器权威通过复制图高效同步状态到客户端
|
||||
- [[Network Prediction]] — 预测系统依赖高效的复制同步
|
||||
|
||||
## Relationship to Agent
|
||||
[[UnrealMultiplayerArchitect]] 使用 Replication Graph 作为生产级多人游戏的带宽优化方案，性能基准：\"Bandwidth per player < 15KB/s at maximum player count\"。
|
||||
|
||||
## Aliases
|
||||
- UE5 Replication Graph
|
||||
- Spatial Replication
|
||||
- Grid Spatialization
|
||||
40
wiki/concepts/RuntimeVirtualTexturing.md
Normal file
40
wiki/concepts/RuntimeVirtualTexturing.md
Normal file
@@ -0,0 +1,40 @@
|
||||
---
|
||||
title: "Runtime Virtual Texturing"
|
||||
type: concept
|
||||
tags: ["unreal-engine", "landscape", "texturing", "ue5", "performance"]
|
||||
sources: ["unreal-world-builder", "unreal-technical-artist"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Definition
|
||||
Runtime Virtual Texturing（RVT），UE5 运行时虚拟纹理技术，通过将多层地形纹理混合计算结果缓存到虚拟纹理图集（Virtual Texture Atlas），消除逐像素层混合的 shader 开销。当地形材质层数超过 2 层时，RVT 成为必选项而非可选项。
|
||||
|
||||
## Core Mechanism
|
||||
- **Virtual Texture Atlas**：多层混合结果以瓦片（Tile）为单位缓存，按需流送到 GPU
|
||||
- **RVT Resolution**：通常 2048×2048 每 4096m² 网格单元
|
||||
- **RVT Format**：推荐 YCoCg 压缩格式，相比 RGBA 节省内存
|
||||
- **Producer**：Landscape Actor 启用 Virtual Texture Producer；需要对应的 RVT Output Volume 放置在世界每个网格单元
|
||||
|
||||
## When RVT is Required
|
||||
| 条件 | RVT 建议 |
|
||||
|------|----------|
|
||||
| ≤2 层 Landscape 材质 | 可选，性能提升有限 |
|
||||
| >2 层 Landscape 材质 | **必须启用**，否则产生材质排列组合爆炸 |
|
||||
| 开放世界（World Partition） | **必须启用**，与流送系统协同 |
|
||||
|
||||
## RVT in Landscape Material Design
|
||||
典型四层 Landscape 材质结构（配合 RVT）：
|
||||
1. **Grass**：基础层，始终存在，填充空区域
|
||||
2. **Dirt/Path**：沿路径替换草地
|
||||
3. **Rock**：坡度驱动（WorldAlignedBlend，斜率阈值 0.6 自动切换）
|
||||
4. **Snow**：高度驱动（超过 SnowLine 高度参数时淡入）
|
||||
|
||||
Auto-Slope Rock Blend：`dot(WorldUp, SurfaceNormal) < 0.6` → Rock 层渐变到 Grass/Dirt
|
||||
|
||||
## RVT for Dynamic Gameplay State
|
||||
高级应用：RVT 权重混合可采样 Gameplay Tags 或 Decal Actor，驱动动态地形状态变化（如降雨累积 → 湿滑表面层）。
|
||||
|
||||
## Related
|
||||
- [[UnrealWorldBuilder]] — RVT 配置与调优专家
|
||||
- [[UnrealTechnicalArtist]] — Landscape Master Material 构建与 RVT Output Volume 放置
|
||||
- [[Landscape]] — RVT 是 Landscape 材质系统的性能关键
|
||||
41
wiki/concepts/Server-Authoritative-Model.md
Normal file
41
wiki/concepts/Server-Authoritative-Model.md
Normal file
@@ -0,0 +1,41 @@
|
||||
---
|
||||
title: "Server-Authoritative Model"
|
||||
type: concept
|
||||
tags: []
|
||||
sources: [unreal-multiplayer-architect]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Definition
|
||||
服务器权威模型是 UE5 多人游戏网络架构的核心原则：服务器拥有真相（Server Owns Truth），所有游戏状态变更必须在服务器执行，客户端仅发送请求（RPC），由服务器验证后复制结果。
|
||||
|
||||
## Core Principles
|
||||
- 所有游戏逻辑和状态变更必须运行在服务器端
|
||||
- 客户端仅负责输入发送、本地预测和视觉表现
|
||||
- `HasAuthority()` 检查必须在每次状态变更前执行
|
||||
- 服务器有权拒绝任何非法客户端请求
|
||||
|
||||
## Implementation in UE5
|
||||
```cpp
|
||||
void AMyCharacter::TakeDamage(float DamageAmount)
|
||||
{
|
||||
// 必须先检查权威
|
||||
if (!HasAuthority()) return; // 客户端绝对不能直接修改生命值
|
||||
|
||||
Health -= DamageAmount;
|
||||
// 服务器修改后自动复制到所有客户端
|
||||
}
|
||||
```
|
||||
|
||||
## Connection to Other Concepts
|
||||
- [[Actor Replication]] — 实现服务器权威的具体机制
|
||||
- [[Network Prediction]] — 客户端利用权威模型进行本地预测以减少延迟
|
||||
- [[RPC (Remote Procedure Call)]] — 客户端向服务器发送请求的通信方式
|
||||
|
||||
## Relationship to Agent
|
||||
[[UnrealMultiplayerArchitect]] 是该模型的严格执行者，其核心规则强制所有游戏状态变更必须通过服务器权威验证。
|
||||
|
||||
## Aliases
|
||||
- Server Authority
|
||||
- Server-Owns-Truth
|
||||
- Server-Authoritative Networking
|
||||
37
wiki/concepts/ServerAuthority.md
Normal file
37
wiki/concepts/ServerAuthority.md
Normal file
@@ -0,0 +1,37 @@
|
||||
---
|
||||
title: "Server Authority"
|
||||
type: concept
|
||||
tags: [networking, multiplayer, security]
|
||||
sources: [unity-multiplayer-engineer]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Server Authority Model
|
||||
- Server-Authoritative Architecture
|
||||
|
||||
## Definition
|
||||
服务器权威模型是一种多人游戏网络架构范式，其中**服务器拥有所有游戏状态的最终真相**，包括玩家位置、生命值、分数、物品所有权等。客户端仅发送输入请求，服务器模拟并广播权威状态给所有客户端。
|
||||
|
||||
## Key Principles
|
||||
- 客户端**永远不直接发送位置数据**——只发送原始输入（方向键、鼠标点击等）
|
||||
- 服务器执行所有游戏逻辑模拟，客户端显示服务器返回的结果
|
||||
- **"永远不要信任来自客户端未经服务器验证的值"**
|
||||
- 客户端预测移动后必须与服务器状态调和校正
|
||||
|
||||
## Implementation in Unity (NGO)
|
||||
```csharp
|
||||
// 服务器权威位置（只有服务器可写）
|
||||
private NetworkVariable<Vector3> _serverPosition = new NetworkVariable<Vector3>(
|
||||
readPerm: NetworkVariableReadPermission.Everyone,
|
||||
writePerm: NetworkVariableWritePermission.Server);
|
||||
```
|
||||
|
||||
## Related Concepts
|
||||
- [[ClientPrediction]]: 客户端预测在服务器权威框架下的实现
|
||||
- [[LagCompensation]]: 延迟补偿依赖服务器权威
|
||||
- [[AntiCheatArchitecture]]: 服务器权威是反作弊的基础
|
||||
|
||||
## Related Entities
|
||||
- [[UnityMultiplayerEngineer]]: 实现服务器权威的专家角色
|
||||
- [[UnrealMultiplayerArchitect]]: 虚幻引擎中的对应角色
|
||||
39
wiki/concepts/Substrate.md
Normal file
39
wiki/concepts/Substrate.md
Normal file
@@ -0,0 +1,39 @@
|
||||
---
|
||||
title: "Substrate"
|
||||
type: concept
|
||||
tags: ["unreal-engine", "materials", "shader", "ue5.3"]
|
||||
sources: ["unreal-technical-artist"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Definition
|
||||
UE5.3+ 引入的多层物理材质系统（Multi-Layer Physical Material System）。通过显式层叠堆栈（Slab）定义材质：湿涂层（wet coat）→ 泥土（dirt）→ 岩石（rock）。物理正确，性能可控，替代了传统的 Subsurface Scattering（SSS）workaround。
|
||||
|
||||
## Architecture
|
||||
Substrate 将材质建模为多层 slab 的堆叠：
|
||||
- 每层有独立的 BSDF（双向散射分布函数）
|
||||
- 层间有物理模拟的界面交互（界面反射、透射）
|
||||
- 与真实世界的多层材质（油漆→底漆→金属基底）对应
|
||||
|
||||
## Migration Path
|
||||
从旧版 Shading Model 系统迁移到 Substrate：
|
||||
1. 分析现有材质的视觉层（表层污垢、中层基础颜色、底层金属/次表面）
|
||||
2. 映射为 Substrate slab 堆叠顺序
|
||||
3. 使用 Substrate Complexity viewport mode 验证复杂度
|
||||
4. 在目标平台（尤其主机）上 Profile 性能
|
||||
|
||||
## Advantages over Legacy SSS
|
||||
- 物理正确性：多层交互有真实光学模型支撑
|
||||
- 单一材质：无需多个材质叠加
|
||||
- 性能可控：Substrate Complexity 工具可精确测量
|
||||
- 适用场景：湿表面、雪地、积雪岩石、多层植被
|
||||
|
||||
## Compatibility
|
||||
- UE 5.3+ 可用
|
||||
- 主机平台需要额外验证
|
||||
- 与 Nanite 兼容
|
||||
|
||||
## Related
|
||||
- [[MaterialFunction]] — Substrate slab 逻辑可封装为 Function
|
||||
- [[VFX]] — Substrate 用于静态场景材质，与 VFX 系统的物理真实感追求一致
|
||||
- [[QualitySwitch]] — Substrate 也需要质量分级
|
||||
39
wiki/concepts/UnityLobby.md
Normal file
39
wiki/concepts/UnityLobby.md
Normal file
@@ -0,0 +1,39 @@
|
||||
---
|
||||
title: "Unity Lobby"
|
||||
type: concept
|
||||
tags: [networking, unity, ugs, matchmaking]
|
||||
sources: [unity-multiplayer-engineer]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Unity Gaming Services Lobby
|
||||
- UGS Lobby
|
||||
- Unity Matchmaking Lobby
|
||||
|
||||
## Definition
|
||||
Unity Lobby 是 Unity Gaming Services（UGS）提供的**匹配大厅服务**，允许玩家创建和加入游戏房间。Lobby 仅存储元数据（如房间名、地图选择、玩家就绪状态），不存储游戏状态。
|
||||
|
||||
## Data Storage Rules
|
||||
| 数据类型 | 示例 | 存储位置 |
|
||||
|----------|------|----------|
|
||||
| 元数据 | 房间名、地图、游戏模式 | Lobby Data |
|
||||
| 玩家状态 | 名称、就绪、皮肤选择 | Lobby Data / Player Data |
|
||||
| **游戏状态** | 生命值、位置、分数 | **禁止存储在 Lobby** |
|
||||
|
||||
## Visibility Options
|
||||
- `Visibility.Public`: 对所有玩家可见
|
||||
- `Visibility.Member`: 仅房间内成员可见
|
||||
- `Visibility.Private`: 仅指定玩家可见
|
||||
|
||||
## Heartbeat Requirement
|
||||
Lobby 默认 30 秒无心跳自动销毁，需客户端定期调用 `SendHeartbeatPingAsync`（建议每 15 秒）。
|
||||
|
||||
## Related Concepts
|
||||
- [[UnityRelay]]: 与 Relay 配合，Relay 处理网络连接，Lobby 处理匹配
|
||||
- [[AntiCheatArchitecture]]: Lobby 不应存储游戏状态，防止数据泄露
|
||||
- [[UnityGamingServices]]: Lobby 是 UGS 的核心组件
|
||||
|
||||
## Related Entities
|
||||
- [[UnityGamingServices]]: Lobby 所属的服务平台
|
||||
- [[UnityMultiplayerEngineer]]: 配置和使用 Lobby 的专家角色
|
||||
38
wiki/concepts/UnityRelay.md
Normal file
38
wiki/concepts/UnityRelay.md
Normal file
@@ -0,0 +1,38 @@
|
||||
---
|
||||
title: "Unity Relay"
|
||||
type: concept
|
||||
tags: [networking, unity, ugs, nat-traversal]
|
||||
sources: [unity-multiplayer-engineer]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Unity Gaming Services Relay
|
||||
- UGS Relay
|
||||
|
||||
## Definition
|
||||
Unity Relay 是 Unity Gaming Services（UGS）提供的**流量中继服务**，用于解决 NAT 穿透问题，使不同网络环境下的玩家能够建立连接。玩家托管游戏必须使用 Relay，直接 P2P 连接会暴露主机 IP 地址。
|
||||
|
||||
## Key Features
|
||||
- **无需专用服务器**：玩家之一作为 Host，其他玩家通过 Relay 连接
|
||||
- **IP 保护**：Relay 隐藏了 Host 的真实 IP 地址
|
||||
- **多平台兼容**：支持 UDP/TCP DTLS 加密传输
|
||||
|
||||
## Workflow
|
||||
1. Host 初始化 Unity Services + 匿名认证
|
||||
2. Host 创建 Relay Allocation，获取 Join Code
|
||||
3. Host 将 Join Code 分享给其他玩家
|
||||
4. Clients 通过 Join Code 加入 Relay
|
||||
5. UnityTransport 自动将流量路由至 Relay 服务器
|
||||
|
||||
## Security Note
|
||||
> "Always use Relay for player-hosted games — direct P2P exposes host IP addresses"
|
||||
|
||||
## Related Concepts
|
||||
- [[UnityLobby]]: 与 Lobby 配合实现完整匹配流程
|
||||
- [[ServerAuthority]]: Relay 使服务器权威模型在玩家托管游戏中可行
|
||||
- [[UnityGamingServices]]: Relay 是 UGS 的核心组件之一
|
||||
|
||||
## Related Entities
|
||||
- [[UnityGamingServices]]: Relay 所属的服务平台
|
||||
- [[UnityMultiplayerEngineer]]: 使用 Relay 构建多人游戏的专家
|
||||
41
wiki/concepts/WorldPartition.md
Normal file
41
wiki/concepts/WorldPartition.md
Normal file
@@ -0,0 +1,41 @@
|
||||
---
|
||||
title: "World Partition"
|
||||
type: concept
|
||||
tags: ["unreal-engine", "open-world", "streaming", "ue5"]
|
||||
sources: ["unreal-world-builder", "unreal-technical-artist"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Definition
|
||||
UE5 的开放世界分区管理框架，将世界划分为网格状单元格（Cell），支持按需流送（on-demand streaming），使超大世界无需一次性全部加载到内存。
|
||||
|
||||
## Core Concepts
|
||||
|
||||
### Grid Cell Sizes
|
||||
| 内容类型 | 格子大小 | 加载范围 |
|
||||
|----------|----------|----------|
|
||||
| 密集城区 | 64m | 256m |
|
||||
| 空旷地形 | 128m | 512m |
|
||||
| 稀疏区域（沙漠/海洋） | 256m+ | 1024m+ |
|
||||
|
||||
### Critical Rules
|
||||
- **格子大小由流送预算决定**：小格子 = 更细粒度流送但更多开销
|
||||
- **关键游戏内容禁止放在格子边界**：格子跨越时流送短暂延迟可能导致关键 NPC/任务触发器不可见
|
||||
- **Always Loaded 层**：Sky、Audio Manager、GameMode 等全局内容必须放入 Always Loaded 数据层，不能分散在流送格子中
|
||||
- **Runtime Hash Grid 配置必须在填充世界前完成**：后期修改需完整重保存关卡
|
||||
|
||||
### Streaming Sources
|
||||
- **Player Pawn**：主要流送源，激活范围 = 加载范围
|
||||
- **Cinematic Camera**：辅助流送源，用于过场动画区域预加载
|
||||
- **非玩家流送源**：通过 `AWorldPartitionStreamingSourceComponent` 实现，供 AI Director、过场系统使用
|
||||
|
||||
## OFPA (One File Per Actor)
|
||||
- 为多用户协作启用 OFPA：避免多人同时编辑同一关卡文件产生的冲突
|
||||
- 大型关卡包含数千 Actor，会生成数千个文件，需建立文件数量预算
|
||||
|
||||
## Related
|
||||
- [[UnrealWorldBuilder]] — World Partition 配置与调优专家
|
||||
- [[PCG]] — PCG 图与 World Partition Surface 协同工作
|
||||
- [[HLOD]] — World Partition 与 HLOD 系统深度集成
|
||||
- [[LOD]] — HLOD 是 World Partition 远距离渲染优化的核心机制
|
||||
- [[Nanite]] — World Partition 流送加载区域的 Nanite 几何体优化
|
||||
Reference in New Issue
Block a user