如果你和我一样第一次照着教程写完第三人称控制角色移动的代码按下 WASD 那一刻角色确实是动了但总有一股说不出的别扭转向像穿着冰刀在滑松手之后还要漂出去半米镜头一晃就分不清东南西北。这个功能在 Unity 里之所以被很多人叫做易上手、难调好是因为它真正的门槛从来不在怎么让角色位移而在怎么让移动这件事符合人脑的预期。本文想聊的就是这后半件事第三人称移动的控制方案选型、相机跟随、输入方向转换、手感参数调优以及我踩过的一系列坑希望能给正在被角色像在溜冰折磨的开发者一些参考。1. 动手之前先把移动手感这个词拆开再写代码很多刚接触第三人称的开发者会直接搜角色移动脚本拿到一段transform.Translate或CharacterController.Move的代码就往上贴但贴完之后发现手感不对又不知道该调哪里。这不是代码的问题而是我们一开始就把移动理解成了一个数学问题输入方向乘以速度然后让角色位置发生变化。实际上对玩家来说移动手感由三个完全不同的东西共同组成。1.1 大多数教程省略的部分为什么直接改位置会滑我在帮 A 同学调试一个 Demo 的时候他贴给我的代码长这样void Update() { float horizontal Input.GetAxis(Horizontal); float vertical Input.GetAxis(Vertical); Vector3 moveDir new Vector3(horizontal, 0, vertical); transform.position moveDir * speed * Time.deltaTime; }单独看这段代码逻辑没有错。但实际跑起来角色每帧都被直接硬搬到一个新坐标上完全没有任何过渡。玩家按下 A 键的瞬间角色立刻以全速横移松手瞬间角色立刻归零。这会导致两个观感第一角色像悬空木偶没有重量感第二如果同时按下斜向方向键moveDir的模长会因为两个轴叠加变成约 1.414 倍斜向跑会比直线跑快 41%这就是同样输入但速度不一致的隐患。真正的移动控制不该直接改position而是应该管理一个当前速度让这个速度每帧朝着目标速度逼近。Unity 里的CharacterController之所以推荐用Move不是因为它是唯一方案而是因为它顺带帮你处理了碰撞、坡度、台阶等问题并且让你能以速度向量为中介来控制位移而不是每帧硬修改坐标。1.2 我先定一个协议输入、请求速度、实际速度我在项目里习惯把移动拆成三层避免后面调的时候无从下手输入层读取按键、手柄摇杆或触屏虚拟摇杆输出一个Vector2取值范围在 -1 到 1 之间请求层把输入向量结合相机朝向转换成世界空间里的目标速度Vector3它表示角色此刻想以多快、往哪个方向跑实际速度层让角色当前速度向目标速度逼近逼近的快慢由加速度和减速度控制最后把这个速度交给CharacterController.Move或Rigidbody。这样拆分之后手感就变成了几个非常具体的参数加速度多大、减速度多大、转向速度多快、最大速度多少。调参的时候不再靠感觉瞎试而是知道改的是哪一层。这也是我建议新人在写移动前先做的事不要一上来就写位移代码先在纸上或者建模工具里确认清楚你到底是想要即时的街机手感还是偏重的写实手感。两种手感对参数的要求完全相反后面所有代码都是围绕这个目标展开的。2. 选型比写法更能决定上限CharacterController 与 Rigidbody 的取舍Unity 里做第三人称移动最经典的选型分歧就是用CharacterController还是用Rigidbody。很多教程会告诉你CharacterController 适合动作游戏Rigidbody 适合物理游戏但实际操作中远没有这么简单。2.1 两套方案的实际表现差异CharacterController本质上是一个可以移动的碰撞胶囊体它的Move方法替你处理了碰撞检测但它不是一个刚体不会受到物理引擎的力、力矩、摩擦等影响。这意味着角色不会因为碰撞反弹也几乎不受外部力的影响移动完全由你控制的velocity决定非常适合精确控制角色但它没有惯性、摩擦如果代码里不做平滑处理就会出现开灯即亮、关灯即灭的生硬移动。Rigidbody方案则是把角色当作真正的物理物体配合capsule collider使用。优点是和场景里的物理交互更自然比如被爆炸冲击、被移动平台带动缺点是你要花很多精力去压制物理引擎的自然行为——比如角色站在斜坡上会滑动、被小障碍物卡住、摩擦力不好控制等。我在实际项目里的经验是如果你的目标是传统的动作冒险、第三人称射击、RPG默认选择CharacterController会让你把精力集中在手感上而不是和物理引擎搏斗。如果你的玩法本身以物理为核心比如制作传送门式的解谜或者需要很多物体推动、角色被击飞、角色站在浮板上这时候Rigidbody会省掉大量外部交互的代码。2.2 什么时候必须换用物理方案有一种情况我建议果断换 Rigidbody角色需要在移动平台之间跳来跳去并且要求角色在平台移动时自然粘在平台上。CharacterController在这种情况下要写很多额外逻辑判断脚下的地面是不是移动的然后把移动平台的位移叠加给角色。Rigidbody 则天然会跟随彼此碰撞接触产生的约束。另外如果你在做一个多人在线游戏同步移动状态时通常只同步位置和朝向而不是速度的话CharacterController 和 Rigidbody 差异不大。如果非要同步速度做插值Rigidbody 方案的速度值更符合物理直觉预测插值更平滑。但这种情况比较进阶刚起步的开发者不需要纠结。我的建议是不要因为喜欢某套方案就强行让玩法去适配它。先回答两个问题角色是否需要频繁被外部物理力影响你是否有精力处理摩擦和斜坡滑动的细节一个否选 CharacterController两个都是是选 Rigidbody。这个决策在写任何移动代码之前做能帮你躲开后面一大半返工。3. 输入处理与相机相对方向解决按W它往屏幕左边跑第三人称移动最容易让人困惑的地方之一就是输入方向到底以什么为参考。如果你直接把摇杆的 X 轴对应transform.rightY 轴对应transform.forward然后让角色朝这两个方向移动那么角色的朝向就直接决定移动方向。大多数情况下这不符合第三人称的需求。3.1 为什么不能直接用世界坐标的方向键设想一个典型的第三人称视角相机在角色身后上方略微俯视前方。玩家按下向前键即 W 或摇杆向上他心里的预期是角色朝屏幕上方移动也就是朝相机朝向在地面上的投影方向移动。但如果你把 W 映射成Vector3.forward世界坐标的 Z 轴正方向那么当相机旋转了 45 度时角色按 W 会往地图的正北跑而不是朝屏幕向上跑。玩家就会觉得方向完全不对。更糟糕的是如果相机本身是自由视野玩家转动视角后角色移动方向不会跟着调整很快就会让玩家晕头转向。正确做法是把输入向量从屏幕坐标系转换到相机当前的朝向坐标系。3.2 把输入旋转到相机坐标系公式与代码实现上先拿到相机的朝向和右向将它们投影到地面上消除俯仰角并归一化然后用这两个向量乘以输入值合成移动方向Transform cameraTransform Camera.main.transform; // 取相机正前方向在地面上的投影 Vector3 forward cameraTransform.forward; forward.y 0f; forward.Normalize(); // 取相机正右方向在地面上的投影 Vector3 right cameraTransform.right; right.y 0f; right.Normalize(); // moveInput 是读取到的摇杆/键盘输入范围 [-1,1] Vector3 moveDir right * moveInput.x forward * moveInput.y; moveDir.Normalize(); // 防止斜向移动速度叠加过快这个公式没什么高明之处但它是所有第三人称移动的基石。这里有两个细节容易出问题第一相机正前方向量如果直接拿来用会因为相机的俯仰角而产生 y 分量导致角色朝下或朝上移动所以必须把 y 清零再归一化第二moveDir.Normalize()必须在合成之后做否则斜向移动速度会比直线移动快约 40%这是很多角色斜着跑特别快问题的根源。在 Unity 的旧版 Input Manager 里Input.GetAxis(Horizontal)和Input.GetAxis(Vertical)已经是平滑的模拟值直接用即可。如果用的是新版 Input System则通常通过playerInput.actions[Move].ReadValueVector2()读取需要注意它的默认更新模式是动态Dynamic Update和旧版每帧同步更新的时机不同可能会导致输入响应有轻微延迟这在移动端的虚拟摇杆上要额外注意。3.3 两种常见的相机参考模式除了上述相对于相机视方向的模式外还有两种模式需要区分固定相机参考移动方向始终基于一个固定世界方向或固定相机方向。常见于世界地图的 45 度视角俯视角游戏。此时输入向量不需要跟相机实时绑定直接用平面上的固定 forward/right 合成即可。角色相对参考移动方向始终以角色自身朝向为参考。常见于坦克式操作的设计角色朝向移动方向玩家需要转向时角色也旋转。这种模式下位移方向等于角色 forward输入只管前后左右旋转。到底用哪种取决于你的游戏设计。大部分第三人称动作游戏采用相对相机模式因为玩家可以自由控制镜头视角角色的移动方向自动跟随镜头操作门槛最低。如果能配合角色朝向转向移动方向的处理就能实现移动跟手的效果。4. 相机跟随并不简单平滑插值、碰撞避让与镜头抖动第三人称移动的体验有一半由相机决定。相机调好了角色手感即使差一点也可以接受相机调得烂角色手感再好玩家也会骂。这一章节说说我在实际项目中踩过最多的坑。4.1 不要让相机成为角色的子物体很多新手会把相机直接拖到角色模型下做成子物体这样角色移动相机自然跟随。但这样做会立刻引发两个严重问题角色旋转时相机跟着旋转玩家视角会一起转极易眩晕而且角色在移动过程中如果有任何微小的朝向抖动相机也会跟着抖画面观感非常不稳定。正确的做法是相机完全独立于角色通过代码在每帧LateUpdate之后更新位置让相机始终看向角色身上的一个注视点并在这个期望位置和当前相机位置之间做平滑插值。public Transform target; // 角色的注视点通常是头部或胸口 public Vector3 offset; // 相机相对注视点的偏移比如 (0, 1.6f, -3.2f) public float smoothing 8f; void LateUpdate() { // 期望位置是注视点中心加上偏移量 Vector3 desiredPosition target.position offset; // 使用基于指数衰减的平滑避免帧率影响 float t 1f - Mathf.Exp(-smoothing * Time.deltaTime); transform.position Vector3.Lerp(transform.position, desiredPosition, t); // 始终看向注视点 transform.LookAt(target.position Vector3.up * 0.2f); }这里的核心细节是t 1f - Mathf.Exp(-smoothing * deltaTime)。很多教程会直接写Vector3.Lerp(a, b, 0.1f)这在 60 帧下看着还行但到了 30 帧或者有掉帧时插值系数跟着每帧时间变化相机的平滑就会失真快帧时追得紧慢帧时拖得很远。用指数衰减公式后插值系数和帧率无关无论什么帧率相机跟随时长都一致。4.2 相机穿墙与避让不要用 Linecast 解决所有问题第三人称最糟糕的体验莫过于墙挡住你之后镜头直接怼到角色脸上或者穿过墙面。一般做法是从角色的注视点向相机期望位置打一条射线或者 SphereCast如果中间有遮挡就把相机位置拉回到碰撞点然后再加一个很小的distanceFromWall偏移比如 0.3 米。推荐用SphereCast而不是单纯的Linecast。因为在墙角或者窄走廊里球体检测的半径能模拟相机本身的体积避免镜头贴着墙面还是穿进去半边的现象Vector3 lookAtPosition target.position Vector3.up * 0.2f; Vector3 desiredPosition lookAtPosition offset; if (Physics.SphereCast(lookAtPosition, 0.2f, desiredPosition - lookAtPosition, out RaycastHit hit, offset.magnitude, obstacleMask)) { // 在碰撞点基础上向相机方向偏移一段距离凑近主角 desiredPosition hit.point - (desiredPosition - lookAtPosition).normalized * 0.3f; }这段逻辑建议放在 LateUpdate 里配合前面的平滑插值一起用。注意一个问题如果你给相机套了obstacleMask一定要把角色身体自己所在的 Layer 排除掉否则射线一打到自己就立刻把相机拉到脸上镜头就抖得没法看了。这个问题我遇到过不止一次调了半天才发现是射线把自己的碰撞体也算进去了。4.3 镜头抖动方向向量归一化的坑另一个常见抖动来源是相机期望位置计算中如果LookAt的目标点或者角色朝向因为控制器判定二帧间产生了微小抖动相机也会跟着一起抖动。特别是角色在奔跑后突然停住、速度向量归零的瞬间如果角色的注视点绑定在角色头部骨骼上骨骼动画的微小位移就会直接反映到镜头。解决办法有两个一是把注视点放在一个固定高度的Transform上而不是直接绑定动态骨骼二是在相机旋转之前把Vector3方向归一化后再使用避免乘以零向量导致LookRotation产生全零 Look 方向时 Unity 的自动修正行为造成滑丝。我经常用下面的代码做一个软注视Vector3 lookPoint target.position Vector3.up * 1.2f; Quaternion desiredRot Quaternion.LookRotation(lookPoint - transform.position); float rotT 1f - Mathf.Exp(-cameraRotSpeed * Time.deltaTime); transform.rotation Quaternion.Slerp(transform.rotation, desiredRot, rotT);这样即使角色在细微晃动镜头也不会突然被拽着走旋转速度完全由参数控制手感容易调很多。5. 手感调优的关键参数与实测记录把数值调到感觉代码都跑通之后真正的重头戏才开始调手感。我在项目里通常会暴露四个参数然后在 Play 模式里一边跑一边调直到角色跑起来不滑、不呆、不飘。5.1 加速度和减速度解决像滑冰的核心很多人做出来的角色滑本质上是因为移动代码里只有目标速度而没有速度变化过程。角色每帧直接跳到目标速度玩家按下方向键的瞬间角色就开始全速移动松手瞬间速度归零。真实世界里的人和动物移动都有惯性加速和减速需要时间。所以在代码里我通常会维护一个currentVelocity每帧向targetVelocity逼近public float maxSpeed 6f; public float acceleration 12f; public float deceleration 24f; Vector3 currentVelocity; void Update() { Vector3 targetVelocity moveDir * maxSpeed; // 根据是否有输入选择使用加速度还是减速度 float speedChange moveDir.sqrMagnitude 0.01f ? acceleration : deceleration; currentVelocity Vector3.MoveTowards(currentVelocity, targetVelocity, speedChange * Time.deltaTime); characterController.SimpleMove(currentVelocity); }Vector3.MoveTowards的好处是速度变化是线性的不会因为帧率波动导致加速度忽大忽小比Lerp更容易调试。在实际项目里acceleration我一般取值 8 到 12deceleration取值 20 到 30。加速度小于 6 时角色起手会感觉很肉像脚底有黏胶减速度小于 10 时松手后会滑出去一大截就是大家熟悉的冰面感。如果游戏需要更真实的惯性比如模拟载具或者角色冲刺后的惯性漂移可以把减速度调低到 5 到 8并且把currentVelocity.Normalize改成保留一小部分速度余量让角色自然减速到停。但这个设计对操作精度要求较高用于竞速类游戏比较多。5.2 转向速度角色朝向和移动方向的一致性第三人称里角色肢体面向方向与移动方向的关系直接影响玩家对角色的跟手判断。比如你按向前角色应该跑步如果角色头部和身体还面相屏幕中央就会很违和。我们需要让人物模型平滑朝向移动方向。常见做法是让模型自身朝向实时追向移动方向但不要采用硬切。硬切会导致角色瞬间转头动画还没跟上视觉上像被扯了一下。我用的是if (moveDir.sqrMagnitude 0.01f) { Quaternion targetRotation Quaternion.LookRotation(moveDir, Vector3.up); modelTransform.rotation Quaternion.Slerp( modelTransform.rotation, targetRotation, rotationSpeed * Time.deltaTime); }注意旋转的是模型子物体modelTransform而不是控制器本身。这样可以保持CharacterController胶囊体的碰撞朝向不变不受角色外观朝向影响。如果整个角色对象跟着旋转那么相机的相对方向会因为角色的旋转而产生细微抖动万一移动方向和相机 x 轴正好垂直会产生自主振荡表现就是角色转圈。rotationSpeed取值上动作游戏我习惯 12 到 18写实类可以降到 6 到 8让转身有迟钝感。如果你在做一个 3D 平台跳跃游戏最好把转向速度调到 25 以上保证跳跃方向精确可控。5.3 教练视角三组实测手感参数参考下面这张表是我在测试第三人称演示项目时记录的实际参数并非绝对标准但可以作为起步参考参数作用我的起始值手感偏软手感偏硬最大奔跑速度全速速度6.0 米/秒4.57.5加速度从静止到全速12618减速度松手后刹停24835转向平滑系数角色转身速度0.10.050.2相机俯仰角相机看向角色的角度15 度1020相机跟随速度相机追角色的快慢8412我建议先按表格里的起始值跑通然后只改其中一个参数感受它对手感的影响再做组合调整。一次改太多参数你根本不知道是哪个参数导致手感变化。6. 动画同步与根运动让移动看起来像走而不是滑行代码控制位移跑到 60 帧动画却在模型上播放如果两者脱节玩家看到的就是角色在冰面上滑行。动画系统必须和移动状态对齐。6.1 Blend Tree 与本地速度分解第三人称移动动画一般用 Animator 的 Blend Tree把移动动画待机、走、跑、转向按速度值混合。关键点在于给 Blend Tree 的两个参数不是直接拿输入向量传进去而是把角色的实际速度转换到角色本地坐标系下再传给 AnimatorVector3 localVelocity transform.InverseTransformDirection(characterController.velocity); animator.SetFloat(ForwardSpeed, localVelocity.z); animator.SetFloat(LateralSpeed, localVelocity.x);为什么要转换到本地坐标因为 Blend Tree 里的x和z是相对模型朝向而言的。如果你的移动方向和模型朝向在某个瞬间不一致这段差值会被修正动画就能准确播放对应的转向和位移动作。如果你直接把世界方向的velocity塞给 Animator角色往右横移时Blend Tree 会认为此时应该播放后退动画表现就会错乱。另外需要注意characterController.velocity包含重力导致的 y 分量如果直接用ForwardSpeed会被往下偏移。在实际处理中我会先把velocity.y清零再转换Vector3 planarVelocity characterController.velocity; planarVelocity.y 0f; Vector3 localPlanarVelocity modelTransform.InverseTransformDirection(planarVelocity);这样 Blend Tree 的向前参数只反映水平移动速度重力对动画方向没有任何影响。6.2 Root Motion 的取舍动画驱动还是代码驱动Unity 动画组件默认带Apply Root Motion勾选项。当动画片段里包含位移时勾选后角色位置会被动画中的位移驱动。在第三人称移动中我建议默认关闭Root Motion改用代码驱动位移。原因很简单玩家输入是即时的代码驱动的响应速度远高于动画数据流的响应动画里就算有一点位移你把它当成辅助表现即可不要让它参与主移动逻辑。什么时候要开 Root Motion当某个动画片段要求精确的演出位移时比如翻滚、被击退、跳跃滞空中的身位变化、剧情动画中的角色走动。这些场景如果代码去模拟动画位移很容易出现动画手已经按地角色却还在空中的穿帮。我通常的做法是普通移动代码驱动特殊演出动画开启 Root Motion 并通过动画事件在特定帧播放两者互不干扰。还有一个常见问题如果坚持使用 Root Motion位移和代码速度会叠加导致角色移动速度翻倍。如果确实要在某个动画里开启 Root Motion记得在进入状态的那一刻把代码移动速度清零或者用Animator.applyRootMotion false在普通状态下强制关闭等需要时再打开。7. 高频问题排查斜坡滑移、贴墙抖动与相机穿墙即使原理都懂了实操中仍会遇到一些不易排查的问题。我整理了下面几个项目里反复出现的情况如果你遇到类似表现可以顺着这个思路排查。现象常见原因解决思路角色下坡时飘离地面重力累积速度不足或落地检测延迟每次 Move 前先叠加重力落地时给 y 速度一个 -2 的小压地值避免悬空浮空角色拖拽在墙上抖动Move向量被墙体阻挡后速度归零但动画还在播放位移判断CollisionFlags是否包含Side如果含侧向碰撞就把水平速度清零并播放推墙动作镜头穿进墙壁相机插值追得太慢导致期望位置在墙后在期望位置计算后加入 SphereCast 避让并把镜头距离墙边偏移留出 0.3 米斜向跑得比直线快moveDir没有归一化在合成方向后显式调用Normalize保证任意方向速度一致7.1 下坡飘离地面的具体处理很多团队把重力计算放在Update里每次只叠加很小一个量结果就是角色走下坡时重力还没来得及把它拉回地面半秒内角色会处于悬浮状态。正确做法是把重力累加到velocity.y上再在Move之前判断是否在地面上if (characterController.isGrounded) { velocity.y -2f; // 保持与地面贴合防止悬空 } else { velocity.y Physics.gravity.y * Time.deltaTime; } characterController.Move(velocity * Time.deltaTime);注意velocity应该是每秒的速度而Move接收的是每帧位移所以乘了deltaTime。这个-2f的小值是很多项目里会忽略但非常关键的细节它确保角色站在任何轻微斜坡上时都能紧贴地面而不是因为重力前一帧累积不足而被地面弹起。7.2 CharacterController 的 slopeLimit 和台阶CharacterController的slopeLimit默认是 45 度超过该角度的坡面会被视为墙壁角色无法登上。如果游戏里有较陡的坡道你需要实测并调高这个值或者用自定义的爬坡检测。stepOffset默认值只有 0.1 到 0.2 米如果台阶高度略高于它角色会被卡住。要处理台阶可以把stepOffset调大到接近角色的膝盖高度但注意它不能超过capsule collider高度的一半否则角色会把门框、低矮障碍也跨过去产生新的穿模问题。7.3 输入延迟的排查旧的 Input Manager 与新的 Input System如果你使用新版 Input System 后感觉角色操控肉检查一下 Player Settings 里的 Active Input Handling。如果旧项目从默认改为 Input System 后仍然在 Update 里读取Input.GetAxis会发现读取不到任何值因为旧的输入 API 不再工作。新版 Input System 还支持在FixedUpdate和Update中对动态输入的读取行为不同若项目里有FixedUpdate中的移动逻辑输入会每隔固定物理帧读取一次这会造成明显的操作延迟。解决方案是把输入读取放在Update中而把位移计算放在FixedUpdate或者Update中保持一致。最后再分享一个小技巧独立调完第三人称移动之后我发现最容易被忽视的是真机测试。反复在编辑器里调好的参数拿到手机上可能完全不是一回事一方面是屏幕刷新率差异另一方面是触屏虚拟摇杆的响应和键盘完全不同。我现在的习惯是每个项目在进入手感调优阶段之前先做一个最简单的真机 Build把摇杆和跟随相机的基本功能跑通一次然后再开始调参。每次调完参数后不是只在编辑器里按几次方向键而是实际跑上十来分钟让手指和眼睛都适应一遍。只有在真实设备上跑过你才会发现比如松手后角色仍然往前走半步这类问题光是盯着编辑器里的帧数据是看不出来的。希望这篇随笔记能让你在第三人称移动这件事上少走几圈弯路。