企业官网建设流程全解析

1. 角色移动的核心逻辑拆解

1.1 为什么 FPS 角色移动不能直接用引擎默认的飞行模式

很多刚接触 UE4 C++ 的开发者，起步阶段都会用模板项目里的默认角色先跑起来，看角色能走能跳就欢呼雀跃。但一旦切换到 FPS 游戏场景，你会发现默认角色完全不是那么回事——前后左右移动倒是能跑，但视角总不对、手感飘、转身的时候身体和镜头不同步，甚至稍一加速就感觉整个人在冰面上滑。

问题出在一个被严重低估的点上：FPS 游戏的角色移动，本质上不是在“移动角色”，而是在“移动摄像机的同时带动身体”。

我用一个生活类比来解释。你手里拿一个自拍杆，杆顶夹着手机，你转身拍风景的时候，是手机先动还是你身体先动？FPS 里的角色就是那根自拍杆，摄像机是手机。真实 FPS 游戏中，玩家通过鼠标旋转的是“观察方向”，角色身体和摄像机之间要建立一种「视觉带动物理」的联动关系。如果默认让角色自动朝向移动方向，就会出现经典的“第三人称逻辑生硬套进第一人称”的违和感。

所以在正式写代码之前，你需要先想清楚一件事：这一节要实现的，不是“让角色能走”，而是“让角色像 FPS 一样被精确操控”。落到引擎层面，其实只需要理解三个组件的关系。

在 FPS 游戏里，SpringArm 的长度几乎都是 0，或者根本不用弹簧臂直接把摄像机挂在角色头部骨骼上，因为第一人称不需要“第三人称的跟随感”。这个细节会在下面实操里展开。

1.2 这一节实现的目标清单

按照“入坑指南”这个系列一贯的节奏，我不喜欢一次性扔出几百行代码让读者去啃。我们需要先把这一节的功能范围画出来，明确哪些必须做、哪些可以留到下一节再做。

这一节的核心目标：

• 创建一个可以被 GameMode 召唤的 C++ 角色类
• 配置好 CharacterMovementComponent 的移动参数
• 接入鼠标 X/Y 轴输入，控制视角旋转
• 接入键盘 WASD 输入，控制角色相对视角方向移动
• 实现奔跑、跳跃两个基础动作
• 处理一个 FPS 必备的细节：视角俯仰角限制，防止镜头翻转

暂不实现的内容（会在后续章节涉及）：

• 武器系统、开火、弹道、命中检测
• 动画蓝图与骨骼动画（第一人称中手臂动画另行处理）
• UI、准星、生命值系统
• 蹲伏、冲刺、滑铲等进阶移动方式

把这个清单写在前面的意义在于，你心里要有数：角色移动是所有后续功能的“地基”，地基歪了，武器跟随、准星同步、命中检测全都会歪。很多人后期排查 bug 排查到发疯，最后发现是角色移动逻辑里埋了个三目运算符的错误。

2. 创建 FPS 角色类的完整实操

2.1 从 C++ 默认类开始，还是从蓝图开始

这个问题几乎每期都会被问到。我的建议非常明确：用 C++ 创建 Character 子类作为“逻辑核心”，用蓝图做“数据配置”和“后续迭代”。

为什么不直接全蓝图？因为 FPS 游戏涉及大量玩家状态、输入处理、物理参数的运行时修改，蓝图节点图一旦复杂起来，可读性会迅速崩溃。分清楚逻辑归属很重要，连移动和跳跃这种“简单功能”都塞进蓝图节点，后期每改一个参数都要进蓝图拖节点，效率极低。

为什么不干脆全 C++？因为武器类型、角色皮肤、不同枪械的后坐力曲线、不同移动模式的参数组合，这些东西每次修改都要重新编译工程，浪费时间不说，调试起来也笨重。C++ 写框架和核心机制，蓝图留出变量接口做配置调整，是 FPS 项目里最平衡的做法。

创建步骤很简单，在编辑器里选择 Tools -> New C++ Class，父类选择 Character。命名上我习惯加个前缀 FPS，避免和项目里的其他角色类冲突。可以命名为：

FPSCharacter

创建完成后，你得到的是一个继承自 ACharacter 的类。注意一个细节：ACharacter 已经自带了一个 USkeletalMeshComponent 和一个 UCharacterMovementComponent，你不用手动再添加，只需要配置它们即可。很多新手在这里会犯错——自己又 New 出来一个 CharacterMovementComponent 挂上去，导致角色同时存在两个移动组件，自己把自己埋了。

2.2 头文件的成员声明与组件配置

打开刚刚生成的 FPSCharacter.h，我们需要添加摄像机组件声明和几个供蓝图调整的公开参数。这里我给出一份实际项目里经得起拷打的配置。

#pragma once #include "CoreMinimal.h" #include "GameFramework/Character.h" #include "FPSCharacter.generated.h" class UCameraComponent; UCLASS() class FPS_PROJECT_API AFPSCharacter : public ACharacter { GENERATED_BODY() public: AFPSCharacter(); protected: virtual void BeginPlay() override; public: virtual void Tick(float DeltaTime) override; virtual void SetupPlayerInputComponent(class UInputComponent* PlayerInputComponent) override; // 曝光给蓝图调整的移动参数 UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "Movement") float SprintSpeedMultiplier = 1.6f; UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "Movement") float JumpHoldTime = 0.2f; // 视觉灵敏度，默认给一个比较跟手的值 UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "Camera") float MouseSensitivity = 1.0f; protected: // 第一人称视角摄像机 UPROPERTY(VisibleAnywhere, BlueprintReadOnly, Category = "Camera") UCameraComponent* FirstPersonCamera; // 移动输入处理函数 void MoveForward(float Value); void MoveRight(float Value); void Turn(float Value); void LookUp(float Value); void StartSprint(); void StopSprint(); };

有几个点我说一下背后逻辑。第一是 SprintSpeedMultiplier 设置为 1.6，而不是直接在蓝图里把 MaxWalkSpeed 改成 1300，因为基础走路速度是一个“稳定值”，冲刺是在这个值基础上临时放大，而不是替换掉它。这样以后调整基础速度，冲刺速度会自动跟着变，不需要两处同时维护。

第二是 JumpHoldTime，这个参数用于控制“跳跃输入的有效时间”。真正实现的时候，如果玩家在落地前 0.2 秒按了跳跃键，角色落地后应该能立刻跳起来，而不是吞掉这次输入。这就是很多游戏里“跳跃延迟补偿”的实现思路。

第三是 MouseSensitivity 单独作为一个变量暴露出来，而不是直接用 Controller 的 InputYawScale。原因在于，不同玩家的习惯差异极大，你不可能要求每个玩家都去引擎设置里改全局灵敏度。在角色类里暴露这个变量，以后做设置菜单时，只需要把它和 UI 滑块绑定即可。

2.3 构造函数里如何配置摄像机与移动组件

现在进入 FPSCharacter.cpp 的核心实操。构造函数里做的事情不多，但每一件都直接影响手感，标准配置如下。

#include "FPSCharacter.h" #include "Camera/CameraComponent.h" #include "GameFramework/CharacterMovementComponent.h" AFPSCharacter::AFPSCharacter() { PrimaryActorTick.bCanEverTick = true; // 创建第一人称摄像机，挂在角色头部组件上 FirstPersonCamera = CreateDefaultSubobject<UCameraComponent>(TEXT("FirstPersonCamera")); FirstPersonCamera->SetupAttachment(RootComponent); // FPS 摄像机的位置，通常放在角色眼睛高度： FirstPersonCamera->SetRelativeLocation(FVector(0.f, 0.f, 160.f)); FirstPersonCamera->bUsePawnControlRotation = true; // 移动组件基础配置 UCharacterMovementComponent* MovementComp = GetCharacterMovement(); // 关闭角色自动旋转朝向移动方向 —— 这是 FPS 和 TPS 的分水岭 MovementComp->bOrientRotationToMovement = false; MovementComp->bUseControllerDesiredRotation = false; // 重力正常，最大步速与加速度设置 MovementComp->GravityScale = 1.75f; MovementComp->MaxWalkSpeed = 600.f; MovementComp->MaxAcceleration = 2048.f; // 空中控制力：FPS 空中转向能力要比亚度大，否则跳跃时手感巨僵 MovementComp->AirControl = 0.6f; // 跳跃相关 MovementComp->JumpZVelocity = 620.f; MovementComp->AirControl = 0.6f; // 地面刹车减速 MovementComp->BrakingDecelerationWalking = 2048.f; // 胶囊体尺寸，FPS 角色通常瘦长 GetCapsuleComponent()->InitCapsuleSize(34.f, 92.f); }

这里最值得展开说的是bUsePawnControlRotation = true。它代表摄像机始终和被 PlayerController 控制的旋转保持一致。通俗讲就是鼠标动一下，摄像机立刻跟着转，没有延迟、没有插值。如果你把这一项设成 false，画面就会出现“鼠标甩过去，镜头慢半拍才转到位”的延迟感，这在 FPS 里是灾难。

而 bOrientRotationToMovement = false 则是让角色身体不自动转向移动方向。很多人不理解为什么要关掉。你可以做个测试：开着这个选项跑一下，角色在前进过程中按 A 键横移，整个身体会扭过来朝左，但摄像机视角还没变，导致画面里出现“脖子向右扭、身体朝左跑”的诡异效果。FPS 里身体和镜头应该保持同样的朝向，或者说身体并不需要跟随移动方向转向，只有镜头转向就够了。

这里还设置了一个可能有点反常的数值：GravityScale = 1.75。这个数值高于 UE4 默认的 1.0，意味着我刻意让角色受到更大的重力影响。为什么？因为在很多动作模板里，默认重力配合默认跳跃高度会给人一种“月球漫步”感——跳起来半天落不下来。FPS 游戏需要更清脆、更利落的跳跃-落地节奏，调高重力系数是立竿见影的手段。JumpZVelocity = 620 与 GravityScale = 1.75 配合，跳跃高度大约是：

[ H = \frac{v^2}{2g} = \frac{620^2}{2 \times 980 \times 1.75} \approx 112 ]

差不多 112 个 Unreal Unit 的跳跃高度，这个手感在实际测试中是比较扎实的，不会出现轻轻一跳就上房顶的尴尬。

2.4 计算过程与实际调试参数对照

继续跳到一个很多教程根本不提的维度：为什么要 620 的 JumpZ，为什么不直接填一个正好能跳过 100 高度台阶的数字？

因为角色移动是物理模拟，胶囊体和地面的碰撞不是一帧一帧精确到像素的，跳跃过程中角色的胶囊体会和地面边缘擦碰，实际跨过的台阶高度通常比你计算的理论高度低 10% 左右。所以你如果只想要角色能轻松跨过一个 100 高的箱子，理论上 JumpZ 达到 610 就够了，但实际我会调到 620 到 650 之间，留出约 5% 的余量。

同理，MaxWalkSpeed 为什么是 600？因为 FPS 暴风行动类游戏的标准步行速度通常在 500~650 之间。600 是一个“让人走得动、又不至于飘”的中庸数值。如果低于 500，地图稍微大一点玩家就感觉自己在原地踏步；高于 700，碰撞精度不变的情况下，角色更容易穿模或卡进墙缝。

移动朝向偏差公式：当玩家按 W 键向前走，但摄像头朝 30 度偏左方向时，角色实际移动方向是摄像机朝向的水平投影方向，而不是世界坐标的正前方。这一步由 AddMovementInput 自动完成，所以不需要手动算三角函数。但在后面实现“滑铲”“弹射”等功能时，你会经常手动算朝向向量，建议先在纸上把水平投影公式写清楚：

[ Forward = FVector(FMath::Cos(Yaw), FMath::Sin(Yaw), 0) ]

方向确定之后，乘以移动速度、乘以 DeltaTime，再加上重力系数的影响，就是每一帧实际的位移。引擎里你不需要亲手实现这套物理，但理解它有助于排查“为什么我按 W 角色却往斜上方飞”这种非常经典的 bug。

3. 输入映射与视角控制实现

3.1 项目设置里的输入轴绑定方式

UE4 的输入系统有两套思路：旧版直接绑定轴映射（InputAxis），新版推荐使用增强输入系统（Enhanced Input）。这个系列为了降低入门门槛，先使用旧版轴映射，因为它的配置链路短、代码直观，等玩家真正理解了轴输入的本质之后，再考虑切换到增强输入系统处理组合按键与多玩家输入映射。

打开 Project Settings -> Engine -> Input，我们需要添加四个轴映射：

注意这里的顺序，W 给 Scale 设为 1.0，S 设为 -1.0，以确保“按 W 向前、按 S 向后”。鼠标 X 的 Scale 用 1.0，鼠标 Y 的 Scale 用 -1.0，因为屏幕向上滑动时引擎的 Pitch 是负方向，需要反向。

我见过很多新手在 Scale 上栽跟头，尤其是鼠标 Y。如果你发现“往上甩鼠标，镜头朝下看”，百分之百是 Scale 没反转。

3.2 C++ 侧的绑定代码与轴输入细节

绑定输入到 C++ 函数，准确说是在 SetupPlayerInputComponent 里完成。

void AFPSCharacter::SetupPlayerInputComponent(UInputComponent* PlayerInputComponent) { Super::SetupPlayerInputComponent(PlayerInputComponent); PlayerInputComponent->BindAxis("MoveForward", this, &AFPSCharacter::MoveForward); PlayerInputComponent->BindAxis("MoveRight", this, &AFPSCharacter::MoveRight); PlayerInputComponent->BindAxis("Turn", this, &AFPSCharacter::Turn); PlayerInputComponent->BindAxis("LookUp", this, &AFPSCharacter::LookUp); PlayerInputComponent->BindAction("Jump", IE_Pressed, this, &ACharacter::Jump); PlayerInputComponent->BindAction("Jump", IE_Released, this, &ACharacter::StopJumping); PlayerInputComponent->BindAction("Sprint", IE_Pressed, this, &AFPSCharacter::StartSprint); PlayerInputComponent->BindAction("Sprint", IE_Released, this, &AFPSCharacter::StopSprint); }

这里有几个老手习惯性的细节处理。

第一，Jump 动作直接绑定到父类 ACharacter 的 Jump 和 StopJumping，而不是自己写函数。因为 CharacterMovementComponent 内置的跳跃流程考虑了“是否在地面”“是否在游泳”“是否在飞行”等状态，自己重新实现这些状态判断纯属重复造轮子，而且很容易漏掉边缘情况。

第二，Sprint 的 Release 事件必须要绑定。很多新手只绑 Pressed 事件，然后发现角色跑起来就再也停不下来了。

第三，BindAction 的 IE_Pressed 和 IE_Released 语义很明确，但请注意：跳跃按键不要用轴输入实现，轴输入响应的是连续值（摇杆），而不是瞬时按键。

3.3 MoveForward / Turn 的实现与人称视角换算

下面这段代码是整个角色移动的精华，值得逐行分析。

void AFPSCharacter::MoveForward(float Value) { if (Controller == nullptr || Value == 0.0f) return; // 获取控制器的旋转，提取出绕 Z 轴的朝向 const FRotator YawRotation(0, Controller->GetControlRotation().Yaw, 0); // 计算摄像机朝向所对应的前后方向（世界坐标） const FVector Direction = FRotationMatrix(YawRotation).GetUnitAxis(EAxis::X); AddMovementInput(Direction, Value); } void AFPSCharacter::MoveRight(float Value) { if (Controller == nullptr || Value == 0.0f) return; const FRotator YawRotation(0, Controller->GetControlRotation().Yaw, 0); // 右方向是 Y 轴在水平面的投影 const FVector Direction = FRotationMatrix(YawRotation).GetUnitAxis(EAxis::Y); AddMovementInput(Direction, Value); }

核心思路是：从 Controller 的 ControlRotation 中取出 Yaw（水平朝向角），用它构造一个只绕 Z 轴旋转的 FRotator。然后通过 FRotationMatrix 把这个旋转转成旋转矩阵，再取 X 轴单位向量作为“前”，取 Y 轴单位向量作为“右”。

为什么要手动构造只含 Yaw 的旋转？因为 ControlRotation 的 Pitch 代表玩家抬头低头角度。如果你直接把完整的 ControlRotation 拿来算方向，角色按 W 前进时，如果玩家正抬头看天空，方向向量会带上很大的 Z 分量，角色就会“往前走的同时往天上飞”。这显然是错误的。FPS 游戏里，地面移动始终应该在水平面上进行，跟你的视线高低无关。所以我们需要把 Pitch 和 Roll 全部清零，只保留 Yaw。

这一行代码：

const FRotator YawRotation(0, Controller->GetControlRotation().Yaw, 0);

就是整个第一人称移动控制里最容易理解、也最容易写错的一行。我见过有人忘掉 Z 轴分量导致走路带飞，也见过有人直接用 GetActorRotation 导致“角色身体朝向决定移动方向”，按下 D 却朝着角色背面移动。

Turn 和 LookUp 的实现更加直白：

void AFPSCharacter::Turn(float Value) { AddControllerYawInput(Value * MouseSensitivity); } void AFPSCharacter::LookUp(float Value) { AddControllerPitchInput(Value * MouseSensitivity); }

AddControllerYawInput 会自动把输入值乘以 PlayerController 里的 InputYawScale 设置，这就保证了即使你不改 MouseSensitivity，玩家也能通过引擎的全局灵敏度设置调整基础手感。这里唯一的坑是：如果你同时修改了 MouseSensitivity 和全局设置里的 InputYawScale，最终效果是两者的乘积，调试时容易晕。

实际测试下来，MouseSensitivity = 1.0 配合 InputYawScale = 1.0 时，鼠标移动一厘米大约能转半圈，对多数人来说合适。但竞技玩家通常会反馈“还是有点快”，那就把这个值调到 0.7 到 0.8 之间。

鼠标横向移动的数学本质是：输入值来自 Controller 的鼠标累积量，每一帧引擎会读取鼠标位移，乘上灵敏度系数，累计到 yaw 角上。所以如果你在低帧率下测试，会感觉“转向变慢、有延迟”，这不是代码问题，而是帧率对视角累积的影响。FPS 开发中，锁定 120 帧以上测试手感才有参考价值，60 帧以下的手感完全不具参考性。

3.4 摄像机转动范围与 FPS 视角限制的细节

第一人称视角有一个必备的约束：视角俯仰角需要限制在 -89 度到 +89 度之间。如果不加限制，玩家向上看的角度超过 90 度时，摄像机就会翻转，整个画面颠倒，瞬间眩晕。

这个约束不需要在角色类里手动加，引擎自带一个变量可以配置。在 PlayerController 或者 CharacterMovementComponent 里都不好找，正确位置是 Character 的 CameraComponent 配置，或者更准确地说是 SpringArm 的 CameraLag 处理。但通常的做法是：在控制器的旋转更新阶段，对 Pitch 做 Clamp。

不过对于纯 C++ 且不打算把控制逻辑拆到 Controller 里的项目，最直接的做法是在 LookUp 函数里限制 Pitch 角：

void AFPSCharacter::LookUp(float Value) { FRotator ControlRot = Controller->GetControlRotation(); float NewPitch = ControlRot.Pitch + Value * MouseSensitivity; // 限制俯仰角，防止镜头翻转 NewPitch = FMath::Clamp(NewPitch, -89.0f, 89.0f); ControlRot.Pitch = NewPitch; Controller->SetControlRotation(ControlRot); }

这里有一个特别隐蔽的坑：Pitch 角不是 0~360 循环，而是 -180~180 的有符号角。如果你用 GetControlRotation().Pitch 拿到的数值是 30 度，然后加了一个 160 度的输入，结果不是 190，而是 -170。中间有跨零问题。所以只加 Clamp 不够，你还需要处理角度归一化。在大多数引擎版本里，ControlRotation 的 Pitch 被保证在 -180 到 180 范围内，所以在 Clamp 前最好先做一次 NormalizeAxis：

NewPitch = FRotator::ClampAxis(NewPitch); NewPitch = FMath::Clamp(NewPitch, -89.0f, 89.0f);

这里 FRotator::ClampAxis 会把角度平滑映射到 0~360，然后 Clamp 会最终限制在 ±89 度。为什么是 89 而不是 90？因为 90 度时方向向量正好在水平面的边界上，会导致某些叉积运算出现零向量，引发奇异矩阵问题。留 1 度余量是业界默认，也是被无数 bug 逼出来的习惯。

4. 移动手感调优与参数背后的物理逻辑

4.1 MaxWalkSpeed、加速度与刹车的关系

FPS 角色移动的“手感”，其实是由一整套参数共同决定的。我见过太多人只调 MaxWalkSpeed，其他参数全部保持默认，结果就是角色快速起步、快速停止，像在玩街机弹球游戏。

核心参数按影响程度排列：

• MaxWalkSpeed：最高速度，只影响最终跑多快
• MaxAcceleration：起步时达到最高速度的快慢
• BrakingDecelerationWalking：松手后多快停下来
• GroundFriction：地面摩擦力，影响滑行距离

这四个参数组合起来的直观体验可以用一个生活场景理解：你在一辆购物车后面推着它走，如果购物车很重，推它的时候加速慢；松手之后，它滑行很远。MaxAcceleration 就是你能多快推动它，BrakingDecelerationWalking 就是它滑行多远才停下。

实际项目中，FPS 需要的是“响应快、停得稳”。所以我给出的建议值：

如果你想做一个“惯性更大”的硬核射击游戏，可以适当降低 BrakingDecelerationWalking 到 1000 左右，角色会有一点滑步感。但这种手感不适合快节奏竞技类 FPS，更适合拟真类射击模拟。

有一个非常重要的物理细节：移动平滑并非来自加速度，而是来自 FInterp 曲线。UE4 里 CharacterMovementComponent 的移动是离散的物理步进，它和渲染帧率不是完全同步的。当帧率波动时，实际位移速度和理论速度之间会产生偏差，手感上就是“忽快忽慢”。如果你在后续版本中想要彻底解决这个问题，需要开启 SubStepping 或者使用自定义移动组件，这里不展开，但要意识到：角色移动手感的高度稳定性依赖满帧运行。

4.2 冲刺与跳跃的实现细节

冲刺的实现思路很多，最简单的就是动态修改 MaxWalkSpeed。我提供一个带切换恢复逻辑的标准写法：

void AFPSCharacter::StartSprint() { UCharacterMovementComponent* MovementComp = GetCharacterMovement(); MovementComp->MaxWalkSpeed = BaseWalkSpeed * SprintSpeedMultiplier; } void AFPSCharacter::StopSprint() { UCharacterMovementComponent* MovementComp = GetCharacterMovement(); MovementComp->MaxWalkSpeed = BaseWalkSpeed; }

我在这里引入了一个 BaseWalkSpeed 概念，称为“基础步行速度”，是一个蓝图可覆写的变量，默认值是 600。为什么不用一个 Magic Number 写死在构造函数里？因为冲刺恢复时需要把 MaxWalkSpeed 恢复成“走路时的速度”，而这个速度在后续开发中可能会被各种技能效果临时修改。你如果写死 600，之后某些 BUFF 把走路速度临时改成 700，BUFF 结束后你想恢复的是 700，而不是回到 600，写死就出大问题了。

跳跃的实现比较直接，绑定 Jump 动作后，引擎会驱动 CharacterMovementComponent 的 DoJump。但有一个常见需求需要处理：连续跳跃的节奏控制。

很多人实现跳跃后发现，角色可以无限快速连跳，按一下跳一下，角色像弹簧一样疯狂抖动。这是因为 CharacterMovementComponent 默认允许 IsJumpProvidingForce 维持。如果你要限制跳跃频率，有两种方案：

• 修改 JumpMaxCount（默认是 1），让角色只允许单跳
• 在检测到跳跃输入后设置一个冷却计时器

我实测下来，JumpMaxCount = 1 加 JumpHoldTime = 0.2 的组合最舒服。JumpHoldTime 表示按住跳跃键后，角色最长持续向上加速的时间。0.2 意味着快速短按效果和长按差别不大。调大这个值，长按跳跃会跳得更高，适合做平台跳跃游戏；调小则更像传统 FPS 的“点按起跳”手感。

4.3 空中控制力 AirControl 的经验值

AirControl 这个参数经常被新手忽略，但它是区分“专业 FPS 手感”和“学生作业手感”的关键。

AirControl 决定角色在空中的横向加速度。默认值大概在 0.05~0.1，这是一个几乎感受不到的数值——角色跳起来后，在空中按左右键，身体只会极轻微地偏转。而 FPS 游戏里，玩家跳起来后需要空中转向、躲避子弹、调整落点，空中有充分的横向控制能力是基本要求。

我给出的 0.6 是一个比较折中的值。低于 0.3，空中转向几乎失效；高于 0.8，角色在空中像在滑翔，落地位置很难精确控制。另外注意，AirControl 会同时影响跳跃中和坠落中的角色，如果你希望“坠落时也能轻微调整落点，但由于很困难”那种拟真感，可以考虑把值定在 0.15~0.2 之间，但我不推荐 FPS 这么做。

如何验证 AirControl 是否正常？最简单的测试方法：在平地跳跃，起跳瞬间按住 D 键。如果角色在空中明显向右漂移，说明 AirControl 生效；如果完全没有漂移，说明参数被某个低优先级设置覆盖了。我遇到过的坑是：在构造函数里设置了 AirControl，但蓝图表里又覆盖了它。蓝图覆盖 C++ 默认值后，你在 C++ 构造函数里写的参数就不生效了，这是 UE4 中很鬼畜的优先级机制。排查方式很简单：在蓝图里搜 AirControl 相关节点，看看有没有被显式赋值。

5. 常见问题与排查技巧实录

5.1 角色出生后视角朝天或者朝地

这个问题的经典原因是摄像机初始旋转没有被正确设置。FPSCharacter 构造函数里，我设置了摄像机的 RelativeLocation，但没有设置初始 Rotation。如果 GameMode 指定的 Pawn 是 Character 子类，且默认玩家的旋转是 (0, 0, 0)，那么摄像机初始朝向世界正 X 方向，不会朝上或朝下。

如果发现角色出生后镜头朝天或朝地，优先检查两个地方：

• Character 的 Actor 旋转是否为 (0,0,0)，可以在蓝图里手动设置 Default Actor Rotation 里的 Pitch
• Controller 的 ControlRotation 初始化逻辑是否被自定义 PlayerController 干扰

还有一个容易忽略的坑：你在项目设置里改了鼠标 Y 轴的 Scale，同时又在构造函数或蓝图里改了 ControlRotation 的 Pitch 初始值，二者叠加可能造成出生瞬间镜头大幅偏转。排查方法：把所有初始旋转设 0，跑一遍测试，再逐个恢复配置。

5.2 角色可以移动但镜头不跟随

这个问题 90% 出在 FirstPersonCamera 的 bUsePawnControlRotation 没有设为 true。可能你把它写成了 false，或者被蓝图覆盖了。它的核心作用是让摄像机始终使用 Controller 的旋转，而不是自身 Actor 的旋转。关闭后，摄像机有自己的旋转，除非你在 Tick 里手动同步，否则镜头纹丝不动。

如果你确实需要使用 bUsePawnControlRotation = false（例如做特殊视角动画），那么请确保在 Tick 中手动同步：

FirstPersonCamera->SetWorldRotation(Controller->GetControlRotation());

但这样会有 1 帧的延迟，FPS 玩家能隐约感知到镜头滞后。除非有特殊需求，否则尽量使用 bUsePawnControlRotation = true。

5.3 角色被碰撞阻挡、穿模、卡墙角

这类问题首先要检查胶囊体尺寸。FPS 角色胶囊体半径 34、半高 92，这个尺寸能通过标准门框（门框宽度约 140）。如果你的地图里有一些更窄的通道，你需要评估胶囊体是否合理，而不是无脑缩小胶囊体——胶囊体会影响物理碰撞、脚步判定、射线检测命中盒，太小会导致人物看起来“飘”或者“穿墙缝”。

另外要说一个物理碰撞方面的经典配置：角色胶囊体应该只对 WorldDynamic 和 WorldStatic 产生阻挡，不应该对 Pawn 产生阻挡。在角色的碰撞预设里，Pawn 通道应该设为 Overlap 或 Ignore，否则两个角色走在一起会互相物理排斥，形成“空气墙”。FPS 游戏里队友之间恰恰需要可以互相穿透。

设置路径：胶囊体的 Collision Responses -> Pawn 设为 Overlap。

5.4 游戏中有移动延迟，但编辑器测试正常

这个问题非常经典，几乎每个做过 FPS 的人都会遇到一次。关键点在于 Tick 中的耗时操作。如果你在 Tick 里做了大量蓝图节点运算，尤其是频繁访问场景中的所有 Actor、或者每帧读取大型数组，就会拉高帧耗时，移动输入的处理也会随之延迟。因为移动组件是物理步进驱动，物理步进又依赖于帧率，帧率越低，物理步进越少，角色的位置更新越慢。

解决方案非常简单：让所有与移动无关的高频逻辑从 Tick 里移出去。比如武器射速计时、UI 刷新、伤害数值飘字，这些都是可以靠 Timer 或者事件驱动来实现的，不需要每帧去查询。

5.5 按键无响应但编辑器不报错

这种情况排查顺序如下：

1. 检查 GameMode 里 DefaultPawnClass 是否已经设成你的 FPSCharacter。如果 GameMode 没指定，或者指定的是默认的 Pawn，角色都不会响应输入。
2. 检查 PlayerController 是否能控制这个 Pawn。在无缝衔接的情况下，Pawn 需要被 Controller 成功 Possess，才会响应输入。可以在角色代码里加一段 UE_LOG，打印 Controller 是否为空。
3. 检查输入映射名字是否拼写一致。项目设置里输入轴的名称必须和 BindAxis 传入的 FName 完全一致，大小写也算。很多人从小写改成大写，中间名称还对不上，又没有编译报错，排查起来非常抓狂。
4. 检查是否在 C++ 里调用过 AutoPossessPlayer。如果角色类设置了禁用自动控制，那么需要手动在 GameMode 里处理。

5.6 角色移动飞快或者蠕动

出现这种情况，第一反应是检查两个地方：

• 是否误触发了 Sprint：可能是 Sprint 的 IE_Released 没有正确绑定，导致冲刺状态一直开启。
• 移动输入是否有累积：MoveForward 中如果没有做if (Value == 0.0f) return;的保护，某些输入设备在静止时仍会返回极小的噪声值，随时间累积就能让角色缓慢移动。这在手柄上尤其明显。

6. 常用参数速查表与实操建议

最后整理一份常用参数速查表，方便你复制到项目笔记里，作为后续调参的起点。

我个人在多个 FPS 项目中反复调参后的体会是：任何参数组合，都不如直接跑 100 遍死亡竞赛模式去验证手感。参数调优不是纸上谈兵，你需要在真实对战场景里感受爆头跟枪、转弯急停、跳跃躲子弹等操作的流畅度。你可能会发现某个参数在“编辑器空场景测试”时完美，但一进入实际战斗地图就暴露出转向延迟、卡楼梯、被低矮障碍物卡住等问题。

另外有一个经验值得分享：角色移动调优一定要放在真实落地场景里进行，而不是简单的 Box 场景。因为 FPS 地图通常会有斜坡、台阶、门框、障碍物、走廊转角，每一种地形都可能暴露出胶囊体与碰撞配置的瑕疵。我见过某开发者在一个白色盒子里把角色调到极其完美，一进入正式地图，角色连一段 20 厘米的台阶都爬不上去，原因是台阶检测的 MaxStepHeight 用了默认值 40，而地图台阶高度是 45。这类问题只有实际地图才能暴露。

这一节的内容覆盖了 FPS 角色移动的完整链路：角色类创建、移动组件配置、输入接入、视角控制、移动参数调优、常见问题排查。下一步你可以在这个基础上继续做武器附着、准星、开火逻辑。记住一个节点：角色移动越扎实，后续所有扩展功能就越省心，尤其是武器后坐力对视角的影响、瞄准时走路减速这种进阶手感，都是建立在移动逻辑之上的。调试下一节内容时，如果手感出了问题，优先回到这一节的参数表里找原因。