中EN
概念页

角色移动组件与 Mover

Character Movement Component & Mover

角色移动组件 (CMC) 用「客户端预测 + 服务器校验 + 纠正后重放」实现联网移动:自主代理先在本地移动并把操作存起来,用 ServerMove RPC 发给服务器重演,位置不符时服务器用 ClientAdjustPosition 纠正,客户端再按保存的操作重放;模拟代理只应用复制下来的移动并做平滑。实验性插件 Mover 计划接替 CMC,改用共享时间线、回滚与重模拟的模型,并且更模块化。

CMC 每帧做什么

CMC 在 TickComponent 中调用 PerformMovement,按当前移动模式和玩家输入计算加速度,然后在世界中实际移动角色:施加冲量、力和重力等外部物理;计算动画根运动 (root motion) 和根运动源;再通过 StartNewPhysics 选择对应移动模式的 Phys* 函数计算速度与加速度。如果本帧移动模式改变(例如开始下落),Phys* 会再次调用 StartNewPhysics,以新模式继续移动。单机游戏中每帧直接调用 PerformMovement;联网时由服务器和客户端各自的专用函数调用。(Understanding Networked Movement in the Character Movement Component for Unreal Engine)

三种网络角色与一次完整往返

角色所在机器做什么
自主代理 (Autonomous Proxy)拥有该角色的客户端本地预测移动,记录并发送操作
权威 (Authority)服务器重演客户端的操作,决定是否纠正
模拟代理 (Simulated Proxy)其他客户端直接应用复制下来的移动并平滑

(Understanding Networked Movement in the Character Movement Component for Unreal Engine;角色的基本概念见 网络复制与 RPC)

sequenceDiagram
  participant C as 自主代理(拥有者客户端)
  participant S as 服务器(权威)
  participant O as 模拟代理(其他客户端)
  C->>C: PerformMovement 本地移动,生成 FSavedMove_Character 并存入 SavedMoves
  C->>S: 合并相似操作后,用 ServerMove RPC 发送精简数据
  S->>S: 用 PerformMovement 重演,比较结束位置
  alt 位置不符
    S->>C: ClientAdjustPosition 纠正
    C->>C: 采用服务器状态,用 SavedMoves 重放之后的操作
  end
  S->>O: 复制 ReplicatedMovement(位置、旋转、状态)
  O->>O: 直接应用 + 网络平滑

上图对应官方的 9 步流程:客户端先移动、存档、发送;服务器重演并比对,不符就纠正;客户端收到纠正后从服务器给的位置重放尚未确认的操作;同时服务器把结果复制给其他客户端的模拟代理。(Understanding Networked Movement in the Character Movement Component for Unreal Engine)这正是经典的「客户端预测 + 服务器和解」模型。

Mover:下一代移动(实验性)

Mover 插件支持模块化的 Actor 移动,并通过 Network Prediction 插件或 Chaos 网络物理实现回滚联网;目标是让玩法开发者不需要网络专业知识也能做移动。Epic 打算让它最终取代 CMC,但目前仍是实验性功能,API 和数据格式可能变化;即便 Mover 可用于生产,CMC 在可预见的未来仍会继续支持。(Mover in Unreal Engine)

MoverCMC
结构模块化、不限 Actor 类型、支持更多形状单体、必须是 ACharacter、只能用胶囊体
回滚统一回滚各自独立回滚
纠正客户端判断服务器判断
状态受保护,不能从外部直接改可直接访问
节奏服务器驱动统一的时间线客户端按自己的帧率发 RPC
成熟度尚未经过大量验证;支持网络物理已在大量项目中发售验证;物理交互有限

(Comparing Mover and Character Movement Component in Unreal Engine)

复制模型差异:CMC 由拥有者客户端按自己的帧率发送「输入 + 状态」,服务器立即执行同样的移动并回复确认或纠正。Mover + Network Prediction 中,服务器和客户端在共享时间线上模拟,客户端预测性地领先服务器一小段时间,只发送某个模拟时间段的输入;服务器把输入缓冲到对应时刻再执行,然后把状态广播给所有客户端,由客户端决定是否回滚并重新模拟。(Comparing Mover and Character Movement Component in Unreal Engine)

Mover 的概念:MoverComponent 管理移动并提供查询与影响移动的 API;移动模式 (Movement Mode) 同一时刻只有一个处于激活状态;叠加移动 (Layered Moves) 是临时的附加运动(排斥力、追踪力、根运动等),可以同时存在多个、跨模式保留,类似 CMC 的 Root Motion Source;转换 (Transitions) 判断是否切换模式;移动修饰器 (Movement Modifiers) 只调参数不产生运动,例如下蹲;瞬时效果 (Instant Effects) 用于传送、强制速度等。导航通过 NavMoverComponent 和 NavWalking 模式实现,但 RVO 避障尚不支持。(Mover Features and Concepts in Unreal Engine,导航见 AI 感知、EQS 与导航)

取舍

  • 现在要发售的项目:CMC 经过大量项目验证;自定义移动要同时处理好保存操作的数据和纠正逻辑,这部分复杂度在官方流程里已经可以看出来。
  • Mover 的坑:状态不能从外部直接修改(例如没有可以直接设置的速度属性),只能通过模式、瞬时效果等在下一个模拟 tick 生效;玩家输入必须先合并成一条该 tick 的输入命令。Mover 也不对输入做假设,把输入转成移动模拟输入的工作要由项目自己完成(输入系统见 增强输入)。(Comparing Mover and Character Movement Component in Unreal Engine)
  1. Understanding Networked Movement in the Character Movement Component for Unreal Engine UE 5.8 文档
  2. Movement Components in Unreal Engine UE 5.8 文档
  3. Mover in Unreal Engine UE 5.8 文档(实验性功能)
  4. Mover Features and Concepts in Unreal Engine UE 5.8 文档(实验性功能)
  5. Comparing Mover and Character Movement Component in Unreal Engine UE 5.8 文档(实验性功能)

相关页面

游戏开发快照插值Snapshot Interpolation发送端按固定频率拍下世界(或相关子集)的快照,接收端不跑权威模拟,而是把渲染时刻拨回一小段,在缓冲里的两份快照之间插值,用额外延迟换平滑,并扛住抖动与偶发丢包。Source 的实体插值与 clinterp 是同一思想的产品化。游戏开发延迟补偿Lag Compensation服务器在执行玩家开火等用户命令前,把其他玩家(及必要状态)回拨到「该命令在客户端生成时」所对应的世界时刻——扣除包延迟与客户端视图插值——再做命中判定,然后恢复。这样玩家可以对着自己屏幕上看到的目标直接开火,而不必凭感觉提前量;代价是可能出现「拐角后仍被击中」等时间悖论。游戏开发多人网络游戏模型Multiplayer Networking Models多人游戏并不是共享同一份物理现实,而是每位玩家各自看到的近似。历史上主要两条路:对等锁步 (Peer-to-Peer Lockstep)(RTS 仍常用)与权威客户端/服务器 (Authoritative Client/Server)(动作/FPS 主流);后者再叠加客户端预测、插值与延迟补偿,把延迟藏进体验里。游戏开发客户端预测与纠正重放Client-Side Prediction & Reconciliation本地客户端立刻用与服务器相同的运动(及可选武器)代码根据输入推进自己的角色,消除操作往返延迟;服务器仍是权威。权威纠正到达时已是「过去」,客户端丢弃过期缓冲、回绕到纠正状态再重放未确认输入,得到与服务器一致的「现在」。游戏开发 · UE5网络复制与 RPCNetwork Replication & RPCUE 采用服务器权威 (Server-Authoritative) 的客户端-服务器模型:游戏真正在服务器上进行,服务器把状态复制 (Replication) 给客户端,客户端通过远程过程调用 (Remote Procedure Call, RPC) 向服务器请求操作。开发者需要显式声明哪些 Actor、属性、函数要走网络,并借助所有权、网络角色、相关性、优先级控制“发给谁、发多少”。UE 5.8 提供通用复制系统、Replication Graph 和实验性的 Iris 三套复制系统。游戏开发 · UE5Gameplay 框架Gameplay FrameworkGameplay 框架 (Gameplay Framework) 是 UE 提供的一组相互配合的类,用来搭建游戏的基本结构:Actor 与组件 (Component) 构成场景中的一切;GameMode 在服务器上定规则并生成玩家;玩家由“控制器 (Controller) + 棋子 (Pawn)”组成;GameState 与 PlayerState 负责把全局与每个玩家的状态复制给所有客户端;GameInstance 跨关卡存活。游戏开发 · UE5动画蓝图与动画系统Animation Blueprint & Animation SystemUE5 角色动画以动画蓝图 (Animation Blueprint) 为核心:它每帧为骨骼网格体 (Skeletal Mesh) 计算最终姿势。动画蓝图内部用状态机 (State Machine) 组织“何时播什么”,用混合空间 (Blend Space) 按速度、方向等参数连续混合,用蒙太奇 (Animation Montage) 在插槽 (Slot) 中插播攻击、交互等一次性动作,用 Control Rig 做程序化骨骼控制(如贴地)。算出的骨骼姿势最终交给蒙皮 (Skinning) 驱动顶点。游戏开发 · UE5增强输入Enhanced Input增强输入 (Enhanced Input) 是 UE5 默认启用的输入插件,把输入拆成四层:输入动作 (Input Action) 表示“玩家想做什么”,输入映射上下文 (Input Mapping Context) 规定“哪些按键在什么情境下触发它”,输入修饰器 (Input Modifier) 预处理原始值,输入触发器 (Input Trigger) 判定是否触发。上下文可在运行时按优先级增删,从而用数据资产而非代码处理情境切换、按键冲突与改键。游戏开发 · UE5专用服务器Dedicated ServerUE 多人游戏采用客户端-服务器模型。监听服务器 (listen server) 由某个玩家的客户端兼任服务器;专用服务器 (dedicated server) 无头运行,不渲染画面,也没有本地玩家。专用服务器体积更小、房主没有不公平优势、能专注于玩法逻辑,适合大规模或竞技游戏。构建专用服务器需要源码版引擎和支持客户端-服务器的 C++ 项目,并要有 <ProjectServer.Target.cs。游戏开发 · UE5AI 感知、EQS 与导航AI Perception, EQS & NavigationAI 的感官层由三块组成:AI 感知 (AI Perception) 组件挂在 AIController 上监听视觉/听觉/伤害等刺激并更新黑板;环境查询系统 (EQS) 用生成器产生候选项、先过滤后打分,回答「哪里最好」;导航系统从碰撞几何生成分瓦片的导航网格 (NavMesh),按多边形代价寻路,并提供 RVO 与 Detour Crowd 避让。它们为行为树/StateTree 提供输入。游戏开发 · UE5运动匹配Motion Matching运动匹配 (Motion Matching) 是 Pose Search 插件提供的动画蓝图节点,可以作为状态机和混合空间的动态替代:每次用 Schema 定义的通道(骨骼位置/速度、轨迹采样点等)构造查询,在数据库里的大量动画中找出代价最低的姿势,而不需要手工编写过渡和混合逻辑。增加动画数据就能提高保真度;代价是内存和查询开销会随通道、采样数和采样率增加。游戏开发 · UE5Chaos 载具Chaos VehiclesChaos Vehicles 是 UE5 的轮式载具物理插件:用骨骼网格加物理资产表示车身,用 ChaosVehicleWheel 蓝图配置车轮、悬挂和刹车,用扭矩曲线描述引擎,再由动画蓝图里的 Wheel Controller 节点驱动车轮转动和转向动画。另有 Chaos Modular Vehicle 插件,用几何体集合 (Geometry Collection) 拼装可拆解的模块化载具。游戏开发动画约束与后处理Animation Constraints & Post-Processing片段混合之后、渲染之前,动画系统常常还要修改姿势,这叫动画后处理:程序化动画、逆向运动学 (IK)、布娃娃。另一大类需求是约束:把武器挂在手上(挂接点)、让多个角色对齐演出(参考定位器)、手抓物体(手部 IK)、脚不滑步(根运动提取与脚部 IK),以及注视、掩体、穿越辅助等(GEA4 卷 II 13.7、13.11)。游戏开发物理引擎与游戏的集成Integrating a Physics Engine into a Game碰撞/物理世界里的刚体只是抽象的数学描述,要通过游戏对象这个中枢,间接连到屏幕上的视觉表现。刚体按谁驱动分三类:物理驱动、游戏驱动(Havok 称 key framed)、固定;Havok 用可在运行时切换的"运动类型"统一表示。每帧更新有固定顺序:先更新游戏驱动刚体、幻影、力、冲量和约束,再步进模拟,然后回读物理驱动对象、查询幻影、执行投射查询。物理宜用恒定的 1/30 或 1/60 秒时间步。GEA 还逐一讨论了子弹、手雷、爆炸、可破坏物、角色移动、相机碰撞和布娃娃的实际做法(GEA4 卷 II 14.5–14.6)。游戏开发碰撞查询Collision Queries碰撞系统除了检测真实物体的接触,还要回答假设性问题:子弹从枪口朝某方向飞,先打中什么?车能否从 A 开到 B 不碰到东西?某半径内有哪些敌人?这类操作称为碰撞查询。最常见的是投射 (cast),也叫 trace 或 probe:沿射线或线段移动一个假想物体,看它会碰到什么;被投射的东西并不真正进入碰撞世界,不会影响其他物体(GEA4 卷 II 14.3.7)。游戏策划角色度量与基础移动Character Metrics & MovementRogers 把角色 (Character)、镜头 (Camera)、操控 (Control) 称为"三个 C",必须在前期定下,中途改动会像涟漪一样波及整个游戏。角色的玩法核心是度量 (metrics):以主角的身高、速度、可达高度为尺子,度量全世界的通道宽度、跳跃距离与攻击距离,玩家会像击剑手一样"凭眼"判断这些距离。在此之上,本页整理抽象游戏的度量、行走、奔跑、冲刺、潜行、待机、跳跃、攀爬与边缘摇晃、坠落、影子、游泳的设计要点,以及如何用角色本身传达状态(Level Up! 第 3 版 Level 5 The Three Cs, Part 1: Character,第 103、112–1游戏美术玩法动画Gameplay Animation第 9 章从 Three Cs(角色 Character、相机 Camera、控制 Control)出发,系统讲地面移动(idle、循环、原地 vs 向前、 strafing、起停过渡)、跳跃与攀爬度量、以及攻击/受击的预备—响应—可读性与连招切割。这是五大基本功在「每帧可玩」场景下的落地清单。

被这些页面引用1 篇

输入关键词开始搜索

滚轮或双指缩放 · 拖动平移 · 双击放大 / 还原