可以构建什么
Generic Movement System 帮助你把角色 locomotion 做成可复用架构，但这个产品应按“框架代码 + 配套内容”一起理解。组件化的移动控制层和数据驱动的动画/locomotion 层围绕同一套 Gameplay Tag 语义工作；配套项目则展示这些机制如何与真实角色、动画、Movement Set 和演示关卡组装成一套可玩的运动系统。
可实现的玩法模式
- 多角色共享一套移动架构，但拥有不同速度、姿态、Overlay 和动画库
- 步行、慢跑、冲刺、瞄准、持武器、携带物、受伤等状态切换
- 不同骨架或动画包复用同一套 locomotion 结构，只替换对应数据
- 用人形、四足、动物、马和龙示例作为自己内容的接入参考
- 第三人称动作、射击、RPG、冒险或近战项目的基础 locomotion
- 多人项目中同步远端动画所需的移动语义
- 基于 Character Movement 的自定义穿越，例如滑索或项目专属 movement mode
接入、移动档案与状态语义
- 接入到已有角色架构。 GMS 围绕 movement system component 和动画层工作流设计，可以放进项目自己的角色体系中，而不是强制改成一套新的父类。
- 为每种角色风格建立完整档案。 Movement Definition 通过 Gameplay Tags 选择 Movement Set，让不同角色、姿态或 loadout 拥有自己的控制、后端、Overlay 和项目数据。
- 运行时切换配置。 玩法逻辑可以通过共享的 GMS 协议切换 Movement Definition、Movement Set、movement state、rotation mode、locomotion mode 和 overlay mode。
- 把移动意图和实际结果分开。 期望移动状态与当前移动状态独立存在，动画可以读取角色已经达到的结果，而不是猜测速度变化中的中间状态。
- 按玩法选择朝向。 旋转模式支持移动方向和视角方向，适合探索、瞄准、锁定或项目自定义状态。
- 用临时速度调整处理状态变化。 Buff、减速、地表影响或 AI catch-up 可以通过运行时速度调整叠加到基础档案上。
- 由 Gameplay Tags 驱动表现。 Gameplay 状态可以通过 tags 驱动动画和姿势变化，减少散落在角色逻辑与动画逻辑里的大量 If/Else。
动画层与表现组合
- 把 locomotion 责任拆进清晰层级。 主动画实例协调 grounded locomotion、overlay、view、additive 和 skeletal control，避免所有逻辑都挤进一个动画图。
- 把姿态叠加到基础移动上。 Pose overlay、sequence overlay 和 parallel overlay stack 可以表现武器、携带物、受伤或项目特有姿态。
- 把骨架相关配置保存在数据中。 Animation Graph Settings 保存动画层设置和节点需要的骨骼引用，让不同骨架和动画库可以配置到同一套框架上，而不是重写框架。
- 让图节点读玩法含义。 Gameplay Tag blend、curve blend、layered-bone blend、orientation warping、stride warping 和 Chooser / Pose Search 上下文帮助动画从语义和数据中选择表现。
配套项目内容
- 学习一套可运行的 GMS 内容结构。 配套项目包含核心 Animation Blueprint Template、Animation Layer Interface、Overlay Layer、AnimModifier、AnimNotify、debug/editor 辅助，以及 MovementSystem 设置内容。
- 从具体角色示例开始。 Demo 内容包含人形示例、动物 Movement Set、马和龙示例、GMS 演示关卡、Camera、UI Widget 和 custom overlay 示例。
- 查看 gameplay 驱动的状态变化。 GMS demo 内容包含面向 GAS 的角色基础操作、状态管理、触发器和 Gameplay Effect，用于 carrying、hand-tied、injured、overlay switching 等状态示例。
- 把可选集成当成扩展示例，而不是默认依赖。 Essential Animation Movement Set 和部分动画包集成与默认配套内容分开管理。
多人与 Gameplay Tag 语义
- 复制动画需要的 locomotion 上下文。 Movement Definition、Movement Set、locomotion mode、overlay mode、Gameplay Tags 和 view rotation 会同步给远端表现。
- 同步 Character Movement 决策。 Character Movement 路径会复制请求的步态、旋转模式和 movement intent。
- 适合 Gameplay Tag 驱动的项目。 GMS 更偏好使用 Gameplay Tags，而不是把项目状态封死在枚举里；已经使用 GAS 或其它 tag-producing 玩法系统的项目更容易接入。
双后端架构与复用性
- 让自定义 movement mode 拥有语义。 项目可以把自定义 mode id 映射到 Locomotion Mode tag，让动画理解攀爬、滑索或其它穿越含义。
- 从可读示例开始扩展。 插件包含 Character Movement zipline 相关实现，可作为自定义穿越接入参考。
- 用统一协议连接不同后端。 GMS 针对 CMC 和 Mover 建立抽象，动画层消费 GMS 协议，不需要关心 Pawn 使用哪种 movement backend。
- 当前稳定路径使用 CMC。 Character Movement Component 路径是当前稳定路径；Mover 支持仍处于试验性阶段，可在配套项目的
_Mover内容中体验。 - 复用 Animation Blueprint Template。 配套项目中的核心动画蓝图多为 Animation Blueprint Template，不绑定单一骨架；骨骼控制和 Montage 槽位相关图表则在需要骨架信息时关联标准 UE5 骨架。
需要围绕设计的边界
- 不要把 GMS 当成纯 code-only 就能独立生成完整运动系统的插件；实际接入依赖先学习并改造配套项目内容。
- Fab 插件上传包包含代码模块；角色、动画、骨架设置、输入资产、Blueprint 示例和演示关卡会在购买验证后通过配套项目提供。
- 当前推荐生产路径是 Character Movement Component；Mover 相关类型仍按源码状态视为实验路径。
- GMS 不面向完全零基础用户；购买和接入前应能阅读文档，并具备 Blueprint、动画资产配置与 Gameplay Tags 基础。
- GMS 组织 locomotion 架构，但不替项目决定动画质量、角色控制手感、输入方案或最终 Gameplay Tags 词汇。