Godot复刻ALS：AnimationTree实现第三人称动画状态机与移动手感

1. 为什么要在Godot里复刻ALS：一个动画系统的执念

如果你做过第三人称动作游戏，大概率听说过ALS——Advanced Locomotion System。这套在虚幻引擎社区里被反复拆解、学习、魔改的动画框架，几乎成了"角色移动手感"这件事的行业参考。它解决的核心问题很朴素：一个角色从站立到起步、从奔跑到急停、从行走切换到蹲伏，这一连串状态之间怎么过渡才不僵硬、不滑步、不像纸片人。

我第一次在UE里跑通ALS的Demo时，那种"角色真的踩在地上"的感觉是很震撼的。但问题也随之而来：UE的项目体量、编译时间、以及整套系统对引擎特性的深度绑定，让很多想在小体量项目里复用这套逻辑的人望而却步。于是就有了这个开源项目——在Godot里把ALS的核心机制做一次100%复刻。

先说清楚这个"100%复刻"到底指什么。它不是把UE的蓝图节点一个个翻译成GDScript，而是把ALS那套状态机驱动的移动逻辑、动画蓝图的分层混合策略、以及根骨骼运动（Root Motion）与程序化修正的配合方式，在Godot的AnimationTree和Skeleton系统上重新实现一遍。换句话说，复刻的是"行为"和"手感"，不是"代码结构"。

这个项目适合谁？如果你正在用Godot做第三人称角色控制，被AnimationTree的BlendSpace和StateMachine搞得头大，或者你从UE转过来想知道"ALS那套东西在Godot里到底能不能做"，那这篇内容就是给你写的。我会把整个复刻过程中的核心决策、踩过的坑、以及那些文档里不会写的经验，尽量讲透。

需要提前说明的是，Godot 4.x的AnimationTree和UE的AnimGraph在设计哲学上有本质差异。UE是"节点图+状态机+混合节点"三层结构，Godot是"AnimationNode树+StateMachine+BlendSpace"的递归组合。理解这个差异，是复刻能否成功的第一道门槛。

2. ALS的核心机制拆解：复刻前必须想明白的三件事

2.1 状态机不是重点，过渡条件才是

很多人一上来就想画状态机图：Idle、Walk、Run、Sprint、Jump、Fall、Land……画完发现节点连好了，跑起来还是一坨。问题出在哪？出在过渡条件的设计上。

ALS的精髓不在于它有多少个状态，而在于它用什么变量驱动状态切换。核心变量其实就几个：Speed（当前速度标量）、Direction（相对于角色朝向的移动方向角）、bIsMoving（是否在移动）、bIsCrouching（是否蹲伏）、bIsGrounded（是否在地面）。这些变量在UE里是通过CharacterMovementComponent实时算出来的，在Godot里你需要自己在_physics_process里维护。

我踩过的第一个坑就是：直接用velocity.length()当Speed。看起来没问题，但ALS的动画混合需要的是归一化后的速度，而且要区分"输入速度"和"实际速度"。角色撞墙时输入还在，但实际速度是0，这时候动画应该播"推墙"而不是"奔跑"。所以我在项目里维护了两套速度：input_speed（来自输入）和actual_speed（来自velocity），动画混合用后者，状态判断用前者。

2.2 动画分层：上半身和下半身必须解耦

ALS最直观的特征就是角色可以一边跑一边瞄准，上半身和下半身的动画互不干扰。这在UE里是通过Layered Blend Per Bone实现的，在Godot里对应的是AnimationNodeBlendTree里的AnimationNodeBlend2配合骨骼遮罩（Bone Mask）。

具体做法是：把动画树分成两层，底层是全身的移动动画（Idle/Walk/Run），上层是上半身的覆盖动画（瞄准、换弹、投掷）。两层之间用一个Blend2节点连接，blend_amount由是否处于瞄准状态控制。关键在于骨骼遮罩的设置——你需要把Spine_01以上的骨骼全部纳入上层遮罩，下半身骨骼权重设为0。

这里有个Godot特有的坑：AnimationNodeBlend2的blend_amount是线性插值，但骨骼遮罩的权重是乘算的。如果你直接把遮罩权重设成0或1，过渡会非常生硬。我的做法是在遮罩里给每根骨骼设一个渐变权重，比如Spine_01是0.3，Spine_02是0.6，Spine_03是0.9，Neck是1.0。这样上半身的动画会从腰部开始逐渐增强，看起来自然得多。

2.3 根骨骼运动与程序化修正的配比

ALS的移动手感之所以好，很大程度是因为它用了Root Motion——动画本身带着位移，角色跟着动画走，而不是代码推着角色走。但纯Root Motion有个致命问题：网络同步和碰撞处理会很麻烦。所以ALS实际用的是混合方案：Root Motion提供基础位移，程序化修正负责碰撞、斜坡、台阶。

在Godot里，Root Motion的开启方式是给AnimationTree的root_motion_track指定一根骨骼（通常是Root或Hips），然后在_physics_process里读取get_root_motion_position()。但Godot的Root Motion默认是每帧累加的，如果你同时用代码改velocity，两者会打架。

我的解决方案是：Root Motion只负责Y轴（垂直）和旋转，X/Z轴（水平）的位移完全由代码控制。具体来说，在动画里把水平位移烘焙掉，只保留垂直起伏和转身。这样既保留了动画的"重量感"，又避免了碰撞穿模。这个取舍是复刻过程中最关键的决策之一，后面讲跳跃和落地时会再展开。

3. 在Godot里搭骨架：AnimationTree的节点布局与参数映射

3.1 从零搭建AnimationTree的节点树

Godot的AnimationTree和UE的AnimGraph最大的区别是：Godot没有"事件"概念，所有逻辑都靠参数驱动。这意味着你不能在动画里埋Notify来触发音效或粒子，得自己在代码里监听状态变化。

我的AnimationTree根节点是一个AnimationNodeStateMachine，里面放了这几个状态：

• Locomotion：一个AnimationNodeBlendSpace2D，X轴是Direction（-180到180），Y轴是Speed（0到1）。里面放了Idle、Walk_F、Walk_B、Walk_L、Walk_R、Run_F、Run_B、Run_L、Run_R九个动画。
• Jump：一个AnimationNodeBlendSpace1D，根据VerticalVelocity混合Jump_Start、Jump_Apex、Jump_Fall三个动画。
• Land：一个AnimationNodeBlendSpace1D，根据LandVelocity混合Land_Light、Land_Heavy。
• Crouch：一个AnimationNodeBlendSpace2D，和Locomotion类似但用的是蹲伏动画集。

状态之间的过渡用AnimationNodeStateMachineTransition连接，过渡条件用advance_condition或switch_mode。这里我推荐用advance_condition配合Expression，因为Godot的表达式系统可以直接读脚本里的变量，比在代码里手动调travel()要清晰得多。

3.2 参数映射表：从UE变量到Godot参数

复刻过程中最繁琐的就是参数映射。UE的CharacterMovementComponent有一堆现成的变量，Godot里全得自己算。下面是我整理的映射表：

注意Direction的计算：Godot的atan2返回的是弧度，而且坐标系和UE不同（Godot是Y轴向上，UE是Z轴向上）。我一开始直接照搬UE的公式，结果角色往左走动画播的是往右。后来统一用atan2(velocity.x, velocity.z)再转成角度，并且根据角色的rotation.y做相对化处理，才对了。

3.3 代码层的状态同步：别让动画和逻辑脱节

AnimationTree的参数更新必须和物理帧同步，否则会出现动画超前或滞后。我的做法是在_physics_process的最后统一更新所有参数：

func _physics_process(delta): _update_movement(delta) _update_animation_params() _update_state_machine()

_update_animation_params里只做参数赋值，不做逻辑判断。_update_state_machine里根据参数决定是否travel到新状态。这样职责分离，调试的时候也容易定位问题。

还有一个细节：Godot的AnimationTree有个active属性，默认是true。如果你在暂停游戏时忘了关它，动画会继续跑。我在项目里加了一个_on_game_paused信号，暂停时把active设为false，恢复时再打开。

4. 移动手感的魔鬼细节：速度曲线、转身速率与斜坡处理

4.1 速度曲线不是线性的

ALS的移动手感好，很大一部分功劳在于它的速度曲线是非线性的。从静止到奔跑，速度不是瞬间拉满，而是有一个加速过程；从奔跑到停止，也有一个减速过程。这个曲线在UE里是用MaxAcceleration和BrakingDeceleration控制的，在Godot里需要自己实现。

我的做法是用move_toward配合一个自定义的加速度曲线：

var target_speed = input_vector.length() * max_speed var acceleration = acceleration_curve.sample(speed / max_speed) speed = move_toward(speed, target_speed, acceleration * delta)

acceleration_curve是一个Curve资源，横轴是当前速度归一化值，纵轴是加速度系数。我调出来的曲线是：低速时加速度大（起步快），中速时加速度小（巡航稳），高速时加速度再大一点（冲刺有推背感）。这个曲线没有标准答案，得根据你的角色体型和动画节奏反复调。

4.2 转身速率：为什么你的角色像陀螺

很多Godot第三人称教程里，角色转身是直接look_at目标方向，结果角色像陀螺一样瞬间转过去，非常出戏。ALS的做法是限制转身速率，而且转身速率和速度挂钩：速度越快，转身越慢。

我在项目里用了一个rotation_speed变量，基础值是8.0（弧度/秒），然后乘以一个速度系数：

var speed_factor = clamp(speed / max_speed, 0.3, 1.0) var turn_speed = base_rotation_speed * speed_factor rotation.y = lerp_angle(rotation.y, target_rotation, turn_speed * delta)

lerp_angle是Godot内置的，能处理角度环绕问题（比如从350度转到10度不会绕一圈）。这个细节很关键，我一开始用普通的lerp，结果角色在特定角度会突然抽搐。

4.3 斜坡和台阶：Root Motion搞不定的地方

前面说了Root Motion只负责垂直和旋转，水平位移靠代码。但斜坡和台阶是水平位移的"特殊情况"——角色在斜坡上移动时，实际位移应该沿着斜面，而不是水平面。

我的处理方式是：在_physics_process里用move_and_slide之后，检测is_on_floor()和get_floor_normal()。如果地面法线不是垂直的（说明在斜坡上），就把velocity投影到斜面方向：

if is_on_floor(): var floor_normal = get_floor_normal() if floor_normal.dot(Vector3.UP) < 0.99: velocity = velocity.slide(floor_normal)

台阶的处理更麻烦。Godot的CharacterBody3D有个floor_snap_length属性，默认是0.1米。如果台阶高度超过这个值，角色会卡住。我的做法是把floor_snap_length调到0.3，然后在角色前方加一个RayCast3D检测台阶，如果检测到台阶且高度小于max_step_height，就手动把角色往上抬一点。

这个"手动抬"的操作要非常小心，抬多了会穿模，抬少了会卡住。我试了大概二十几次才找到一个稳定的参数组合：max_step_height = 0.4，floor_snap_length = 0.35，射线检测距离0.5。

5. 跳跃与落地：ALS最容易被低估的动画段落

5.1 跳跃的三段式动画：起跳、滞空、下落

很多人做跳跃动画就是播一个Jump，然后等落地。但ALS的跳跃是三段式的：起跳（Jump_Start）、滞空（Jump_Apex）、下落（Jump_Fall）。这三段之间的切换不是靠时间，而是靠垂直速度。

具体逻辑是：起跳后velocity.y > 0，播Jump_Start；当velocity.y接近0时（比如绝对值小于0.5），切到Jump_Apex；当velocity.y < -0.5时，切到Jump_Fall。这个阈值需要根据你的重力和跳跃高度调。我的项目里重力是9.8 * 2.5（游戏里重力通常要加倍才跟手），跳跃初速度是8.0，所以滞空时间大概0.6秒，阈值设0.5刚好。

这里有个坑：Godot的AnimationNodeBlendSpace1D在切换时会有混合过渡，如果你直接用travel切状态，过渡时间设得太短会闪，设得太长会拖。我的经验是跳跃三段之间的过渡时间设0.1秒，落地过渡设0.15秒。

5.2 落地动画的力度分级

落地动画不能只有一种。从半米高跳下来和从三米高跳下来，动画应该不一样。ALS的做法是根据落地瞬间的垂直速度来分级，我在Godot里也是这么做的：

var land_velocity = abs(velocity.y) if land_velocity < 5.0: anim_tree.set("parameters/Land/blend_position", 0.0) # 轻落地 else: anim_tree.set("parameters/Land/blend_position", 1.0) # 重落地

但这里有个细节：落地动画播完之后要自动切回Locomotion，而且切换时机要卡在动画的"恢复站立"那一帧。Godot的AnimationNodeStateMachine有个advance_mode，可以设成Auto，但自动切换的时机是动画播完，不是"恢复站立"那一帧。我的做法是在落地动画的最后一帧埋一个AnimationNodeTransition，用advance_condition手动触发。

5.3 空中控制：别让玩家觉得在开飞机

跳跃过程中玩家还能控制方向，但控制力度要减弱。ALS的空中控制系数大概是地面的30%到50%。我在项目里用了一个air_control_factor = 0.4，在_physics_process里判断is_on_floor()，如果不在就乘以这个系数。

但这里有个反直觉的点：空中控制减弱的是加速度，不是最大速度。也就是说，你在空中还是能达到最大速度，只是加速变慢了。这个区别很微妙，但手感差异很大。我一开始把最大速度也乘了系数，结果跳跃时角色像被空气墙挡住一样，非常难受。

6. 复刻过程中踩过的五个坑与修复方案

6.1 坑一：AnimationTree的BlendSpace2D在边界处抖动

BlendSpace2D的四个角是Idle、Walk_F、Walk_B、Walk_L、Walk_R，但如果你把Idle放在原点，Walk_F放在(0, 1)，Walk_B放在(0, -1)，Walk_L放在(-1, 0)，Walk_R放在(1, 0)，那么在(0.5, 0.5)这个位置，四个动画的权重会互相打架，导致抖动。

修复方案：在BlendSpace2D里多加几个中间点。我在(0.5, 0.5)、(0.5, -0.5)、(-0.5, 0.5)、(-0.5, -0.5)各放了一个混合动画（可以用Walk_F和Walk_L各50%权重合成）。这样插值的时候有中间参考，抖动就消失了。

6.2 坑二：Root Motion导致角色穿墙

Root Motion的位移是动画驱动的，不经过物理引擎的碰撞检测。如果动画里角色往前冲了2米，但前面有堵墙，角色会直接穿过去。

修复方案：在_physics_process里读取Root Motion位移后，不要直接position +=，而是把它加到velocity里，然后走move_and_slide。这样位移会经过碰撞检测，撞墙时会停下来。但这样又会导致动画和实际位移不同步，所以还需要在撞墙时把动画的播放速度降下来，或者切到"推墙"动画。

6.3 坑三：蹲伏状态下的碰撞体切换

蹲伏时角色的碰撞体高度要减半，但Godot的CollisionShape3D不能直接改height，得改shape资源。而且改完之后，如果角色头顶有障碍物，站起来会卡住。

修复方案：用两个CollisionShape3D，一个站立用，一个蹲伏用，通过disabled属性切换。站起来之前先用ShapeCast3D检测头顶，如果有障碍就保持蹲伏。这个检测我放在_physics_process里，每帧都做，开销很小。

6.4 坑四：动画过渡时的骨骼跳变

从Run切到Idle时，如果过渡时间太短，骨骼会瞬间跳变，看起来像抽搐。如果过渡时间太长，又会显得拖沓。

修复方案：过渡时间不能一刀切，要根据动画的差异程度动态调整。我的做法是给每个过渡单独设时间：Run到Idle设0.3秒，Walk到Run设0.2秒，Jump到Fall设0.1秒。而且过渡曲线用Ease In Out，比线性自然得多。

6.5 坑五：多平台输入映射的混乱

Godot的输入映射是InputMap，但键盘、手柄、触屏的输入逻辑不一样。键盘是数字量（0或1），手柄是模拟量（0到1），触屏是虚拟摇杆。如果直接混用，会出现手柄轻推摇杆角色不动的情况。

修复方案：在_input里统一把输入转成Vector2，然后根据设备类型做死区处理。键盘死区设0.1，手柄死区设0.2，触屏死区设0.15。而且手柄的模拟量要做平方处理（input * input.length()），这样轻推慢走、重推快跑的手感才出来。

7. 开源项目的结构设计与二次开发建议

7.1 项目目录结构

这个开源项目的目录结构是这样的：

res:// ├── addons/ │ └── als_godot/ # 核心插件 │ ├── scripts/ │ │ ├── als_character.gd # 角色控制器 │ │ ├── als_anim_tree.gd # 动画树管理 │ │ └── als_input.gd # 输入处理 │ └── resources/ │ ├── anim_tree.tres # AnimationTree资源 │ └── curves/ # 速度曲线资源 ├── demo/ │ ├── scenes/ │ │ └── test_level.tscn # 测试场景 │ └── models/ │ └── character.glb # 测试角色模型 └── project.godot

核心逻辑全在addons/als_godot里，demo只是用来演示的。这样设计的好处是，你可以直接把addons文件夹拷到自己的项目里，改一下输入映射和动画资源就能用。

7.2 二次开发时最常改的三个地方

第一个是动画资源。项目里自带的动画是Mixamo的通用动画，如果你有自己的角色和动画，需要替换AnimationPlayer里的动画，并且重新调整BlendSpace2D的坐标。调整的时候注意动画的帧率和循环设置，Godot的AnimationPlayer默认不循环，要在动画资源里手动勾选Loop。

第二个是速度曲线。curves/文件夹里有三个曲线资源：acceleration_curve.tres、deceleration_curve.tres、turn_curve.tres。这三个曲线决定了移动手感，你可以直接在Godot的曲线编辑器里拖点。我的建议是先把max_speed调到你觉得合适的值，然后再调曲线，不然会互相干扰。

第三个是状态机过渡条件。如果你要加新的状态（比如滑铲、攀爬），需要在AnimationNodeStateMachine里加新节点，然后在als_character.gd里加对应的状态判断。加的时候注意过渡的优先级，Godot的状态机是按连接顺序判断的，排在前面的优先。

7.3 性能优化的几个实测有效的手段

AnimationTree在Godot里是CPU计算的，角色多了会卡。我实测下来，同屏20个角色，每个角色一个AnimationTree，帧率会从60掉到45左右。优化手段有几个：

• 把AnimationTree的process_callback设成Manual，只在需要的时候调advance()。但这样动画会不跟手，适合远处NPC。
• 用AnimationNodeBlendSpace2D的sync模式，让多个动画共享时间轴，减少计算量。
• 把不重要的骨骼从动画树里剔除，比如手指骨骼。我的项目里只保留了Spine以上的骨骼做上半身混合，手指骨骼全部忽略。

这些优化手段不是必须的，但如果你要做多人同屏，迟早会用到。

8. 从ALS复刻延伸出去：Godot动画系统的更多可能性

做完这个复刻之后，我对Godot的动画系统有了新的认识。它虽然不如UE的AnimGraph直观，但胜在轻量和灵活。比如AnimationNodeBlendTree可以嵌套任意层，你可以用AnimationNodeBlend2和AnimationNodeBlend3搭出非常复杂的混合逻辑，而不需要写一行代码。

另一个有意思的方向是程序化动画。ALS的动画是烘焙好的，但Godot的Skeleton3D允许你在代码里直接改骨骼的pose。这意味着你可以做动态的头部朝向（角色看向鼠标位置）、动态的脚部IK（脚踩在不平的地面上自动调整）、甚至动态的受击反馈（被击中时上半身往后仰）。这些在UE里需要写AnimNode，在Godot里用_process直接改骨骼就行。

我目前在尝试把ALS的移动逻辑和Godot的NavigationAgent3D结合，做AI角色的移动。难点在于AI的移动是路径驱动的，而ALS的动画是速度驱动的，两者需要做一个转换层。如果你也在做类似的事情，欢迎一起交流。

最后说一句，这个开源项目的代码我尽量写得直白，变量名和函数名都用了完整的英文单词，没有缩写。注释也写得比较密，尤其是那些"为什么这么写"的地方。如果你在复刻过程中遇到问题，先看注释，再看代码，大概率能找到答案。实在找不到的，可以在项目仓库里提Issue，我看到了会回。