中EN
概念页

增强输入

Enhanced Input

增强输入 (Enhanced Input) 是 UE5 默认启用的输入插件,把输入拆成四层:输入动作 (Input Action) 表示“玩家想做什么”,输入映射上下文 (Input Mapping Context) 规定“哪些按键在什么情境下触发它”,输入修饰器 (Input Modifier) 预处理原始值,输入触发器 (Input Trigger) 判定是否触发。上下文可在运行时按优先级增删,从而用数据资产而非代码处理情境切换、按键冲突与改键。

四个核心概念的数据流

下图是一次按键从硬件到游戏代码的路径:原始值先经过映射上下文中该按键的修饰器链,再由触发器判定状态,最后以触发事件回调绑定在 Input Action 上的函数。

flowchart LR
  K["原始输入:按键/摇杆"] --> IMC{"映射上下文<br/>按优先级选中"}
  IMC --> M1[Modifier 1] --> M2[Modifier N]
  M2 --> T["Trigger 判定<br/>None/Ongoing/Triggered"]
  T --> IA["Input Action 值<br/>bool/1D/2D/3D"]
  IA --> CB["绑定回调<br/>Started/Ongoing/Triggered/Completed/Canceled"]

(Enhanced Input)

输入动作 (Input Action)

Input Action 是增强输入与项目代码之间的“通信链接”,概念上等同旧系统的 Action/Axis 映射名,但它是数据资产。每个 Action 应代表玩家能做的一件事(“蹲下”“开火”)。值类型决定行为:

值类型C++ 类型典型用途
Digital (bool)bool开/关类动作(等价旧 Action 映射),如“拾取”
Axis1Dfloat单轴,如油门
Axis2DFVector2D摇杆、行走方向
Axis3DFVector运动控制器等复杂数据

触发事件有 Started、Ongoing、Triggered、Completed、Canceled 五种。例如“按住”触发器在未达时长时持续 Ongoing,提前松手则 Canceled;最常用的是 Triggered。C++ 中在 SetupPlayerInputComponent 里把 UInputComponent 转成 UEnhancedInputComponent,调用 BindAction(Action, ETriggerEvent::Triggered, this, &AFoo::Func),回调中用 Instance.GetValue().Get<FVector2D>() 等取值。输入组件挂在 Pawn/PlayerController 上的分工见 Gameplay 框架。(Enhanced Input)

输入映射上下文 (Input Mapping Context)

上下文是某个情境下可用的一组 Action 及其触发规则,层级为“Action → 可触发它的按键 → 每个按键的触发器与修饰器”。通过本地玩家的 Enhanced Input Local Player Subsystem 添加/移除,并带优先级:多个上下文映射到同一 Action 时只考虑优先级最高的那个。(Enhanced Input)

官方给出的典型用法(Enhanced Input):

  • 情境切换:步行时 Ctrl 是蹲下,冲刺时 Ctrl 是滑铲,趴下时 Ctrl 是起身——各用一个上下文,切换状态时换上下文。
  • 载具:通用动作放一个常驻上下文,载具动作单独一个,上车添加、下车移除。这样不合适的 Action 根本不会执行,互斥的上下文能避免输入冲突。
  • 官方示例以 TSoftObjectPtr<UInputMappingContext> 暴露上下文,再 AddMappingContext(InputMapping.LoadSynchronous(), Priority);软引用与同步加载的取舍见 资产管理与异步加载。

玩家可映射输入配置 (Player Mappable Input Config) 是一组上下文的预设(如“默认”与“左撇子 Southpaw”),可一次性添加,并带有便于制作改键 UI 的元数据。(Enhanced Input)

输入修饰器 (Input Modifier)

修饰器是触发器之前的预处理器:调整轴顺序、死区 (Dead Zone)、转换到世界空间、灵敏度、多帧平滑等。自定义时继承 UInputModifier 并重写 ModifyRaw_Implementation(蓝图同理),返回值传给下一个修饰器或第一个触发器;因为能拿到 UPlayerInput,可以读取所属 PlayerController 和任意游戏状态。Lyra 用一个修饰器根据设置反转瞄准轴。(Enhanced Input)

经典例子是把四个一维按键(WASD)合成一个 2D 移动 Action:每个键只报告 X 轴上的 0 或 1,用 Negate 取负、用 Swizzle 把 X 换到 Y:

按键期望解释需要的修饰器
W / ↑+YSwizzle (YXZ 或 ZXY)
A / ←−XNegate
S / ↓−YNegate + Swizzle
D / →+X无

(Enhanced Input)

输入触发器 (Input Trigger)

触发器判定经修饰后的输入是否激活 Action:最小驱动量、短按、长按、按下/松开等;“组合键 (Chorded Action)”触发器例外,它依赖另一个 Action。默认(无触发器)时任何输入每帧都会触发。触发器分三类,组合规则如下(Enhanced Input):

情况结果
无隐式、无显式只要值非 0 就触发
仅显式 (Explicit)至少一个显式成功
仅隐式 (Implicit)全部隐式成功
隐式 + 显式全部隐式且至少一个显式成功
阻断 (Blocker) 成功强制失败,覆盖一切

单个触发器返回 None / Ongoing / Triggered。自定义可继承 UInputTrigger 或 UInputTriggerTimedBase(后者自身从不返回 Triggered,要在子类中决定);引擎的 UInputTriggerHold 以 HoldTimeThreshold(默认 1 秒)和 bIsOneShot 控制长按触发一次还是每帧触发。(Enhanced Input)

调试、注入与平台差异

  • showdebug enhancedinput 显示当前映射,showdebug devices 显示设备。(Enhanced Input)
  • 输入注入:控制台 Input.+key Gamepad_Left2D X=0.7 Y=0.5 / Input.-key ...,或 C++ InjectInputForAction,可用于自动化测试和调试。(Enhanced Input)
  • 平台设置:继承 UEnhancedInputPlatformData 做按平台的上下文重定向(如 Switch 面键位置、移动端动作),写入平台 DefaultInput.ini,可热修复。(Enhanced Input)

取舍与常见坑

要点说明
Action 表达意图而非按键代码只认 Action,改键与多平台都只动数据
用上下文而不是 if 判断状态不合适的动作不会触发,减少 bug
优先级冲突同一 Action 在多个上下文中时只取最高优先级,叠加上下文时要规划好优先级
无触发器 = 每帧触发想要“按下一次”的语义需加 Pressed 等触发器
输入与网络绑定到输入的可靠 RPC 可能被狂按撑爆队列,见 网络复制与 RPC

在使用 GAS 的项目里,输入通常只负责发出“激活能力”的请求,具体条件和互斥交给能力标签处理,见 Gameplay 能力系统;在蓝图还是 C++ 中绑定的分工见 蓝图与 C++ 协作。

  1. Enhanced Input UE 5.8 文档

相关页面

游戏开发 · UE5Gameplay 框架Gameplay FrameworkGameplay 框架 (Gameplay Framework) 是 UE 提供的一组相互配合的类,用来搭建游戏的基本结构:Actor 与组件 (Component) 构成场景中的一切;GameMode 在服务器上定规则并生成玩家;玩家由“控制器 (Controller) + 棋子 (Pawn)”组成;GameState 与 PlayerState 负责把全局与每个玩家的状态复制给所有客户端;GameInstance 跨关卡存活。游戏开发 · UE5蓝图与 C++ 协作Blueprint & C++ InteropEpic 官方建议:多数项目混用蓝图 (Blueprint) 与 C++,以 C++ 作为基础、在其上构建蓝图类。C++ 适合“编程”——定义系统;蓝图适合“脚本”——在已有系统上定义具体行为。两者通过反射说明符互相调用:C++ 用 BlueprintCallable/BlueprintReadWrite 等暴露给蓝图,用 BlueprintImplementableEvent/BlueprintNativeEvent 让蓝图实现或覆盖 C++ 声明的函数。游戏开发 · UE5Gameplay 能力系统Gameplay Ability SystemGameplay 能力系统 (Gameplay Ability System, GAS) 是 UE 用来构建「Actor 可拥有并反复触发的能力」的框架:能力系统组件 (Ability System Component, ASC) 是持有者,Gameplay 能力 (Gameplay Ability) 编排执行过程,属性集 (Attribute Set) 存数值,Gameplay 效果 (Gameplay Effect, GE) 改数值和标签,Gameplay 标签 (Gameplay Tags) 做状态与互斥,Gameplay Cue 负责表现。它内建复制与客户端预测,代价是概念多、上手重,游戏开发 · UE5资产管理与异步加载Asset Management & Async LoadingUE 资产默认按引用自动加载:硬引用 (Hard Reference) 会让被引用资产随引用者一起加载,不加控制就可能在启动时加载全部内容。软引用 (Soft Reference,TSoftObjectPtr/FSoftObjectPath) 只存路径,配合流式管理器 (Streamable Manager) 异步按需加载;资产管理器 (Asset Manager) 进一步把内容划分为主资产 (Primary Asset) 和次资产 (Secondary Asset),用资产包 (Asset Bundle) 管理加载、卸载、烘焙分块与内存审计。游戏开发 · UE5UMG、Slate 与 Common UIUMG, Slate & Common UISlate 是 UE 平台无关的 C++ 声明式 UI 框架(编辑器即用它构建),UMG 是在其之上的可视化控件蓝图层(UE 5.8 API:UWidget 是所有暴露给 UObject 的被包装 Slate 控件的基类),Common UI 插件再在 UMG 之上补充多层界面、输入路由、手柄导航、平台按键图标和样式资产。官方 UMG 最佳实践强调事件驱动更新而非绑定/Tick、固定分辨率与 DPI 制作、用 Scale Box 而非 Render Transform 做永久缩放。游戏开发 · UE5角色移动组件与 MoverCharacter Movement Component & Mover角色移动组件 (CMC) 用「客户端预测 + 服务器校验 + 纠正后重放」实现联网移动:自主代理先在本地移动并把操作存起来,用 ServerMove RPC 发给服务器重演,位置不符时服务器用 ClientAdjustPosition 纠正,客户端再按保存的操作重放;模拟代理只应用复制下来的移动并做平滑。实验性插件 Mover 计划接替 CMC,改用共享时间线、回滚与重模拟的模型,并且更模块化。游戏开发命令模式Command Pattern命令模式 (Command Pattern) 把一次方法调用“物化”成对象,从而可以存储、传递、延迟执行、排队或撤销。游戏里最典型的三种用法是:可配置的按键映射、让玩家输入和 AI 共用同一套“驱动角色”的接口、以及撤销/重做。游戏开发人机接口设备Human Interface Devices人机接口设备 (HID) 是玩家向游戏提供输入、游戏向玩家提供反馈的硬件:手柄、键鼠、摇杆、Wii 遥控器、方向盘、跳舞毯、吉他等。GEA 从三个层面介绍它们:游戏如何与设备通信(轮询、中断、无线协议),设备提供哪几类输入,以及设备能输出哪些反馈。引擎如何加工这些原始输入见 引擎输入系统。(卷 I 9.1–9.4 节)游戏开发引擎输入系统Game Engine HID System多数引擎不直接使用「原始」HID 输入,而是先加工(死区、滤波)使游戏内行为平滑直观,并在 HID 与游戏之间加至少一层间接(如按键映射表把原始按钮翻译成逻辑游戏动作)。GEA 列出引擎输入系统的典型需求并逐一讲解实现:死区、模拟信号滤波、按下/松开事件、组合键与序列手势、多设备多玩家、跨平台抽象、输入重映射、上下文相关控制与输入禁用。(卷 I 9.5–9.6 节)游戏策划游戏界面Game Interface界面是分隔玩家(阳)与游戏(阴)那层无限薄的膜;界面失灵,体验之火即熄。界面的目标不是好看或流畅,而是让玩家感到掌控自己的体验。Schell 把界面拆成物理输入、物理输出、虚拟界面三部分和其间的六种映射 (mapping),并讨论透明、反馈、多汁 (juiciness)、原始性 (primality)、信息通道与维度、界面模式,以及十条实用建议(第 3 版第 15 章 Players Play Games through an Interface;第 1 版为第 13 章,无原始性一节,建议为八条)。游戏策划游戏操控Game Controls"三个 C"的最后一个,也是唯一对所有游戏都适用的一个(抽象解谜、载具模拟没有角色,老式固定画面没有镜头)。Rogers 的核心原则:玩游戏的是人——手指短、运动协调一般,所以操控要讲人体工学;按下按键,动作就要发生;任何按键都不能"什么也不做";镜头相对还是角色相对,选一种坚持到底;触屏、震动与体感要语言一致、贴近现实动作(Level Up! 第 3 版 Level 7 The Three Cs, Part 3: Controls,p.171–187)。游戏开发 · UE5网络复制与 RPCNetwork Replication & RPCUE 采用服务器权威 (Server-Authoritative) 的客户端-服务器模型:游戏真正在服务器上进行,服务器把状态复制 (Replication) 给客户端,客户端通过远程过程调用 (Remote Procedure Call, RPC) 向服务器请求操作。开发者需要显式声明哪些 Actor、属性、函数要走网络,并借助所有权、网络角色、相关性、优先级控制“发给谁、发多少”。UE 5.8 提供通用复制系统、Replication Graph 和实验性的 Iris 三套复制系统。游戏开发 · UE5子系统Subsystems子系统 (Subsystem) 是自动实例化、生命周期绑定在宿主对象上的类:Engine、Editor、GameInstance、World、LocalPlayer 五种。宿主创建时自动创建并 Initialize(),宿主关闭时 Deinitialize(),之后无引用即被 GC。它替代了「继承 GameInstance 塞管理器」的老做法,自带按类型的蓝图节点和 Python 访问,特别适合插件。官方编程页只列四种,World 子系统依据 5.8 Python API 补充。综合游戏编程模式选型:解耦与性能Choosing Game Programming Patterns本页把《Game Programming Patterns》里的 19 个模式放到同一张取舍图上:大多数模式要么为了解耦(降低改代码时需要装进脑子里的知识量),要么为了性能(利用对数据和硬件的具体假设),而这两个目标经常互相拉扯。下面先讲全书的定位和 Nystrom 的架构观,再给出按问题选模式的路线和与 UE 的对照。

被这些页面引用1 篇

输入关键词开始搜索

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