ZzxxH
频道主
Mover 插件 READEME 的中文翻译
# Mover 插件
#d 使用 NetworkPrediction 进行网络预测、回滚
- @ 其目标是让游戏开发者能够专注于制作，而无需成为网络专家。
用于支持使用 Network Prediction 插件进行回滚网络的 Actor 移动。
这个插件是 Character Movement Component 的==未来继任者==。
> [!WARNING]
> **Mover 插件处于实验阶段。许多功能尚不完整或缺失。API 和数据格式可能随时发生变化。**
# 入门
将 Mover 和 MoverExamples 插件添加到任何现有项目中,或从新的空白模板项目开始。
打开 L_CharacterMovementBasics 地图,并激活编辑器内播放(PIE)。
推荐的项目设置开始:
- Network Prediction / Preferred Ticking Policy: Fixed
- Network Prediction / Simulated Proxy Network LOD: Interpolated
- Engine General Settings / Use Fixed Framerate: Enabled
如果你为 Network Prediction 设置了固定的 tick 率,但在"Engine - General Settings"下设置了不同的 tick 率,你可能会感觉移动模拟相比摄像机移动或动画不那么流畅。
# 示例
MoverExamples 插件提供了一系列地图和 Actor 示例,使用了蓝图和 C++ 的混合。
值得关注的地图:
- **L_CharacterMovementBasics** 有各种地形特征和移动示例。
- **L_LayeredMoves** 专注于演示多种分层移动类型,具有不同选项。
- **L_PhysicallyBasedCharacter** 有一个基于物理的 Pawn 示例。详见下面的章节。
值得关注的 Pawn/Actor 蓝图:
- **AnimatedMannyPawn** 是最简单的角色,基于 UE5 引擎模板项目中使用的人形角色。
- **AnimatedMannyPawnExtended** 添加了各种移动能力,如冲刺、翻越和滑索。
- **ScriptedAIMannyPawn** 展示了一种非玩家角色可以通过蓝图脚本控制的方式。
- **BP_SplineFollowerPlatform** 展示了一个简单的移动平台,可预测地沿定义的路径移动。
# 概念
### 移动模式
**移动模式**是一个控制你的 Actor 如何在空间中移动的对象。它既可以生成建议的移动,也可以执行它。例如,行走、下落、攀爬等。这些模式查看输入,决定角色应该如何移动,然后尝试在世界中实际移动它。
任何时候只有一种模式处于活动状态。
### 分层移动
**分层移动**代表临时的额外移动。例如,向上发射的恒定力,将你移向敌人的追踪力,甚至是动画驱动的根运动。
它们只生成建议的移动,并依赖活动的移动模式来执行它。
多个分层移动可以同时处于活动状态,它们的移动可以与其他影响混合。它们的生命周期可以有持续时间或瞬时,并且可以在模式转换之间存活。
### 转换
**转换**是评估 Mover Actor 是否应该改变其模式的对象,基于当前状态。它也可以在激活时触发副作用。
它们可以与特定模式相关联,只在该模式处于活动状态时评估。或者它们可以是全局的,无论 Mover Actor 处于什么模式都会评估。
使用转换是可选的,还有其他切换模式的方法可用。
### 其他概念
- **可组合的输入和同步状态:** 输入由控制所有者创作,并影响移动模拟步骤。同步状态是描述 Mover Actor 在某个时间点移动的快照。输入和同步状态都可以动态附加自定义结构数据。
- **共享设置:** 多个移动对象共享的属性集合,以避免在解耦对象之间重复设置。列表由 MoverComponent 根据其模式调用的设置类管理。
- **移动实用程序库:** (可选) 这些是对制作移动有用的函数集合,通常可从蓝图调用。在实现默认移动集时,我们尝试将方法尽可能地分解到这些库中,以便开发者可以在自己的移动中使用它们。
- **模拟黑板:** (可选) 这是一种方式,让解耦系统在模拟 tick 之间共享信息或缓存计算,而无需添加到官方模拟状态。请注意,该系统目前还不支持回滚。
- **移动记录:** (可选) 这是一种跟踪移动组合并标记哪些应影响移动 Actor 最终状态的机制。例如,导致角色踏上短台阶的移动包括水平和垂直移动,但我们不希望在计算 Actor 移动后的速度时包括垂直移动。垂直移动的记录将被标记为非贡献。
## 与 Character Movement Component (CMC) 比较
- **移动模式**在两个系统中非常相似,但在 Mover 中是模块化的
- **分层移动**类似于根运动源(RMS)
- **转换**是一个新概念
- 来自模式和分层移动的移动可以混合在一起
- 更容易添加自定义移动模式,甚至可以从插件和运行时添加
- Mover 中的 DefaultMovementSet 类似于内置在 CharacterMovementComponent 中的模式(行走、下落、飞行等)
Mover 插件提供了一个 DefaultMovementSet,类似于 CharacterMovementComponent 提供的模式。这个移动集假设类似的 Actor 组成,以 Capsule 原始组件为根,附加了骨骼网格。
MoverComponent 不要求你的 Actor 类派生自 ACharacter。
MoverComponent 需要一个根 SceneComponent,但它不必是单一的垂直方向胶囊或甚至是 PrimitiveComponent。开发者可以自由创建没有碰撞原始体的 Mover Actor,如果他们愿意的话。
MoverComponent 不要求或假设骨骼网格作为视觉表示。
在 CMC 中,添加自定义数据以在客户端和服务器之间传递需要子类化组件并覆盖关键函数。Mover 插件允许在运行时动态添加自定义输入和状态数据,而无需自定义 MoverComponent。
网络模型:
- 在 CMC 中,拥有的客户端以客户端的帧率发送输入和状态的组合作为"移动"。服务器接收它们并立即执行相同的移动,然后比较状态以决定是否需要修正,并回复移动确认或修正状态数据块。
- 在 Mover / Network Prediction 中,所有客户端和服务器都试图在共享时间线上模拟,客户端预测性地比服务器提前运行一小段时间。客户端为特定的模拟时间/帧创作输入,这就是他们发送给服务器的全部内容。服务器缓冲这些输入,直到它们的模拟时间到来。执行所有移动更新后,服务器向所有客户端广播状态,客户端决定是否需要修正(回滚 + 重新模拟)。
与 CMC 不同,Mover Actor 的状态不能在任何时候直接从外部修改。例如,没有可以直接操作的 Velocity 属性。相反,开发者必须使用模式和分层移动在下一个可用的模拟 tick 中影响变化。此外,玩家提供的输入(如移动输入和按钮按压)必须组合成单个输入命令用于移动模拟 tick,而不是立即影响 Mover Actor 的状态。根据你的项目设置,你可能有来自几个帧的玩家输入贡献给单个移动模拟 tick。
## 调试
### 游戏调试工具
可通过游戏调试工具(GDT)获得可视化和状态读出信息。要激活游戏调试工具,通常通过 **'** 键,并使用数字键盘切换 Mover 类别。默认选择本地控制的玩家角色,但你可以通过 GDT 输入和 **gdt.\*** 控制台命令更改这一点。
### 日志
来自 Mover 插件的输出日志信息将具有 **LogMover** 类别。
### 控制台命令
有各种有用的控制台命令,前缀为: **Mover.\***
## 基于物理的角色示例
MoverExamples 中包含了 Manny Pawn 的基于物理的版本。它是这个实验性插件中的一个实验,应该被视为这样。要尝试它,请打开 MoverExamples 插件中的 L_PhysicallyBasedCharacter 地图。确保根据地图内的文本调整你的项目设置。
其他 MoverExamples Pawn 和 CharacterMovementComponent 使用"运动学"移动风格,其中 Pawn 的形状通过以特定方式测试周围环境来移动。对物理力的响应和与物理模拟对象的交互很难实现。通过物理驱动移动,Pawn 可以真实地对其他对象施加力,并让力反作用于自身。
这个基于物理的角色并不使用 Network Prediction 插件。相反,它由 Chaos Networked Physics 系统驱动,该系统在操作方式上有许多相似之处。在底层,物理系统的 Character Ground Constraint 处理执行 Mover 系统生成的建议运动。物理模拟以固定的 tick 率运行,领先于游戏线程。随着模拟的进行,游戏线程的角色表示向最近的物理状态插值。
注意:
- 由于物理模拟的异步性质,玩家输入和影响屏幕上看到的 Pawn 移动之间会有一些额外的延迟时间。
- 角色交互的其他物理对象应该设置为复制。否则,这将导致客户端和服务器之间的差异。
- 与移动的非物理对象的交互可能会显示不佳的结果,这是由于物理模拟和游戏世界其余部分之间的 tick 差异。
- 各种游戏事件可能没有连接或不可靠。
- 如果不同时使用修改的物理约束和求解器,制作自定义移动可能不那么灵活。
- 基于物理的 Mover Actor 与使用 Network Prediction 的 Actor 不同步
## 常见问题
- **我的项目应该从 CharacterMovementComponent 切换到 Mover 吗?** 这在很大程度上取决于你的项目范围,需要进行一些尽职调查。Mover 插件是新的实验性插件,还没有经过已发布项目的严格测试。功能上还有许多空白,很少花时间在扩展/性能上。单人游戏或角色数量较少的游戏将更加可行。
- **Mover 是否解决了移动和游戏能力系统之间的同步问题?** 简短的回答是否定的。GAS 仍然有自己独立的复制方法。使用 Network Prediction 为 GAS(或其他系统)打开了与 Network Prediction 集成并实现与移动良好同步的大门。
- **单人游戏呢?** Mover 对单人游戏也很有用,你只是不会使用网络和回滚功能。由于不需要与服务器同步模拟时间,考虑将项目设置"Network Prediction / Preferred Ticking Policy"更改为"Independent"模式。这将使移动模拟以与游戏世界相同的速率 tick。
## 限制和已知问题
**另请参阅: Network Prediction 插件的文档** Mover 插件的一些当前限制来自其对 Network Prediction 插件的依赖。请查看其文档以获取更多信息。
**有限的蓝图支持:** 蓝图功能还不是 100% 支持。某些事情仍然需要原生 C++ 代码,或在蓝图中实现起来很笨拙。
**任意重力、碰撞形状等:** 虽然核心 MoverComponent 尽量不对 Actor 的组成做太多要求,但默认移动集有更严格的假设。例如,默认移动集目前假设是胶囊形状。此外,一些功能(如任意重力)在所有情况下还不完全支持。
**模拟代理示例角色的动画:** 在某些动作期间,另一个客户端的 Pawn(模拟代理)的动画可能没有完全复制。这将在未来的版本中改进。
**前向预测的模拟代理角色:** 由其他玩家控制的角色通常不适合前向预测,前向预测依赖过去的输入来预测未来的移动。加速和方向变化,以及跳跃等动作输入是不可预测的,将成为频繁错误预测的源头,可能导致模拟代理角色出现弹跳或不流畅的移动。考虑使用插值模式作为"Simulated Proxy Network LOD"项目设置,这将以一些视觉延迟为代价提供平滑的结果。
**烘焙数据优化可能导致数据丢失:** 烘焙构建可能会丢失一些 MoverComponent 数据,导致 Actor 无法正常工作。禁用 Actor 的"Generate Optimized Blueprint Component Data"选项(C++ 中的 bOptimizeBPComponentData)。
**MoverComponent 默认目前专注于角色:** 当前组件有比非角色类 Mover Actor 所需更多的 API 和数据。我们的目标是制作一个具有更精简 API 和属性集的极简基础组件,并将角色类 Actor 的专门化作为默认移动集的一部分单独实现。
**模拟黑板尚不支持回滚:** 当发生回滚时,黑板的内容简单地被无效化。虽然黑板对于避免重复先前帧的计算很有用,但移动逻辑不能总是依赖它有有效的条目,应该有一个后备方案。
- 下载图片
- 复制图片
2024-09-25
浏览210
资源分享
登录后评论
2
1
2