UE4 2D游戏制作：从蓝图数学到手感优化的核心计算指南

做2D游戏做到中后期，真正拉开项目差距的，往往不是美术素材好坏，也不是蓝图节点连得有多花哨，而是数据计算做得够不够细。UE4虽然被很多人当成“3D引擎”，但它的2D游戏制作能力其实一直被低估，尤其是计算这一块：横版动作游戏里的帧计算、碰撞盒与伤害判定之间的联动、镜头跟随的弹性手感，处处都离不开数学。这篇接在系列前面的文档后面，专门把2D游戏制作里最容易踩坑、也最能提升手感的部分拆开讲一遍。

如果你已经能搭出一个能跑能跳的2D角色，但总觉得跳跃生硬、攻击判定不对、镜头跟得很死，那这篇内容正好对症。我下面会把重点放在几个核心计算场景上：位移与速度、攻击与伤害、镜头跟随、UI数值反馈和材质像素计算。蓝图为主，但里面的每一个算式，换到C++里思路完全一致，所以不用担心学了没用。

1. 2D游戏里的“计算”到底在算什么

1.1 从角色数据到屏幕图像的三个计算层级

很多初学者拿到UE4做2D项目时，第一反应是去下载素材、搭关卡、连输入映射，结果角色动起来以后发现手感稀烂。原因就在于，他们只完成了“蓝图逻辑”这一层，但没搞懂数据是怎么一层层变成屏幕上的画面的。

我习惯把2D游戏的计算分成三个层级来看。

第一个层级是角色行为数据计算，也就是角色当前的速度、加速度、生命值、攻击力、技能冷却时间这些“幕后数字”。这个层级的核心是：这些数据不是一拍脑门写死的，而是由输入、碰撞、时间共同运算出来的。比如玩家按一下跳跃键，角色的垂直初速度到底是多少，决定了跳多高、落多快；连续按两次攻击，第一击到第二击之间的间隔是多少帧，决定了连招的流畅度。

第二个层级是逻辑与画面的换算。UE4虽然支持2D，但底层坐标依然是三维的。你的角色明明是个2D纸片人，它依然有一个世界坐标位置，以及一个胶囊体的碰撞体积。你需要把设计层面的概念，比如“攻击距离”“攻击高度”，换算成碰撞盒的位置和大小，再换算成玩家看到的攻击动画帧。这一步很多人会忽略，最后就出现“剑明明挥到了，怪却不受伤害”的经典问题。

第三个层级是渲染层的数值映射。屏幕上显示的UI血条、角色的受击闪白、攻击特效的扩散速度，这些本质上都是数值计算。血条不该直接从满血变半血，而应该在一小段时间内平滑移动；受击闪白不该突然出现又突然消失，而应该有一个由时间驱动的透明度曲线。这一步做得好，游戏就“精致”了。

1.2 动手做项目前，我先列的计算清单

我每次开始一个新2D项目，不会急着往场景里放Actor，而是先在表格里列一遍“这个项目会涉及哪些计算项”。这张表我用了很多年，基本能覆盖横版动作、平台跳跃、弹幕射击、俯视角2D RPG这几类主流玩法。

这七类覆盖了绝大多数2D项目的战斗和表现层需求。你未必每个都要做到极致，但至少在开工前要知道它们存在。否则做到后期，你就不是在“做游戏”，而是在“补计算漏洞”。

2. 蓝图数学库与计算节点的正确打开方式

2.1 蓝图里最常用的几个数学节点，以及我的习惯用法

UE4蓝图提供了完整的数学节点库，分布在“Addition”“Subtraction”“Multiply”“Divide”“Modulo”以及“Random Float in Range”这些节点上。很多人觉得数学节点太基础，不值得单独研究，但实际上，蓝图里数学节点有几个细节非常容易踩坑。

先说除法。蓝图里的“Divide”节点，需要区分整数除法和浮点数除法。整数除以整数，结果直接向下取整，比如7除以2，结果是3而不是3.5。这个特性在很多“攻击次数限制”“资源换算”场景里特别隐蔽。你算出来的次数少了1次，画面看不出问题，但对玩家来说就是“为什么我打第4下没伤害”。所以我现在的习惯是：凡是除法，尽量用浮点数节点，或者先把整数Convert to Float再算。

再说取模（Modulo）。这个节点用来算余数，最常见的是“循环切换”：比如当前武器索引加1之后对武器总数取模，就能实现按一下切换一把、到最后一把再回到第一把的效果。如果你做的是一个数字跳动效果，比如飘字伤害“-153”，想让它在屏幕上持续0.5秒后消失，也可以用“游戏时间对持续时间取模”的方式来做生命周期判断。这个节点看上去简单，但在UI计时、动画帧切换、循环纹理滚动里是真正的老朋友。

随机数节点我用的频率仅次于加减法。做攻击飘字、命中特效、暴击提示时，给数值加一个上下浮动区间，游戏才会“活”。我记得以前做套路化伤害时，每次伤害数字都一模一样，玩家反馈说像打木桩。后来我在每个伤害数值上加了正负10%的随机浮动，配合暴击判定，整个打击感立刻上来了。这里的重点是Random Float in Range节点，记得把种子（Seed）留空或设为固定值。如果你把种子写死，那每次游戏运行随机序列完全一致，相当于假随机。

2.2 Vector才是2D游戏的好朋友

不少做2D的新手会习惯性地把位置拆成X、Y两个数组来算，走两步就要取一下“Get Actor Location”再拆引脚。这样做不是不行，但非常浪费。UE4里更推荐的做法是直接用Vector2D或Vector进行计算。

以横版2D游戏为例：角色的移动方向，本质是一个沿X轴的向量。输入系统给你的是InputAxis值，范围在-1到1之间。你不应该直接把这个值塞给速度，而是把它乘上一个“前进方向向量”，得到一个带方向的移动输入。然后用“Add Movement Input”节点把它喂给角色，或者直接做“Set Velocity”计算。

有一个非常容易被忽略的点：2D游戏在UE4里默认的前方是X轴正方向，但不同美术资源做出来的人脸朝向可能不同。如果你的角色素材默认朝左，那你按下右键时，输入轴给的值是正数，角色却往左移动，视觉上就完全反了。遇到这种情况，我通常在角色蓝图里加一个“FacingDirection”变量，初始值按美术资源来设，1或-1。所有基于方向的攻击偏移、抛射物生成方向、击退方向，都乘以这个变量。这样做的好处是，以后换美术资源时，只需要改一个变量，不用动任何计算逻辑。

向量运算里还有一个必备技能：Normalize（归一化）。它的作用是把任何长度的向量变成方向相同、长度为1的单位向量。做敌人追踪玩家、子弹瞄准目标、攻击朝向这些计算时，先算“目标位置减去自己位置”，得到一个方向向量，然后Normalize，再乘以速度值，就能得到稳定的目标速度。这个操作我几乎每个项目都会用，甚至在UI小地图的箭头指向功能里也是一样的原理。唯一要注意的是：不要对一个长度极小的向量做Normalize，否则会得到异常值。后面我会专门讲到这种NaN问题的排查。

2.3 DeltaTime：所有帧计算的地基

如果你想做出一款手感合格的2D游戏，有一件事必须刻在骨子里：所有和时间有关的数值变化，都要乘以DeltaTime。

DeltaTime也就是“上一帧到这一帧的时间间隔”。因为游戏不是匀速运行的，同一段代码在不同机器上，每一帧的耗时不一样。如果你把“每秒移动600像素”写成了“每帧移动600像素”，那在60帧的机器上，角色一秒钟跑了36000像素，直接飞出屏幕；在30帧的机器上看起来又像开了慢动作。正确写法是“每秒移动600像素”：600 * DeltaSeconds，这样不管机器是30帧还是144帧，一秒钟移动的总距离都恒定在600左右。

在UE4蓝图中，几乎每个Tick事件节点上都有“Delta Seconds”引脚，事件驱动里也有“Get World Delta Seconds”节点。如果你写的是Event Tick，直接引下来用；如果是Timer驱动的循环逻辑，就要用Get World Delta Seconds或自己在计时器回调里记录上次时间。

我见过不少新手有一个坏习惯：为了省事，用“目标值增量法”写逻辑，比如“每帧血量加5”。这个逻辑在帧率稳定时看着没问题，锁60帧的游戏里一秒钟加300，但一旦显卡波动掉到40帧，加血速度就变成200了。玩家不会看帧率数字，他们只会感觉血条有时候快有时候慢。所以所有增量、衰减、插值，都必须带上DeltaTime。这点我怎么说都不嫌啰嗦，因为它是很多游戏手感“玄学”背后最实际的物理基础。

3. 角色行为里的核心计算：从移动到攻击再到受伤

3.1 移动速度与加速度：从“生硬”到“手感好”的插值计算

平台跳跃和横版动作游戏里，角色移动的体感，很大程度取决于“从静止到最大速度”的过程。如果你直接设置速度为目标值，角色按一下就瞬间满速，松键就瞬间停住，这感觉就像在玩冰上滑行——没有质量。真正的做法是给一个简单的加速度过渡。

我用得最多的节点是FInterp to Value（浮点插值），也有人叫它Lerp。它的作用是：当前值以一定速度向目标值靠近。比如“当前水平速度”向“输入方向 × 最大速度”这个目标插值，插值速度设为每秒8到12个单位（这里的单位是插值速率，不是像素），角色就能呈现一个自然的起步加速过程。松键的时候，目标速度变成0，角色不会瞬间停下，而是快速减速，看起来就有惯性了。

有一个细节决定手感上限：跳跃时要不要保留水平速度？很多游戏为了操作精度，会把空中水平控制力削弱为地面的70%左右。怎么实现呢，简单做法是给空中加速度乘一个0.7的系数，或者设置一个“AirControl”变量。这样的话，玩家在空中依然能左右调整，但不会像地面一样灵活。我见过不少项目因为忽略这个计算，导致空中操作像飞一样飘，或者完全不能转向，两种都不是好体验。

另外，如果角色有冲刺或滑铲这类技能，不要把“最大速度”直接加在移动速度上，而是设计一段独立的冲刺速度，然后让它在冲刺持续时间里线性或曲线衰减回正常移动速度。这个衰减用的也是FInterp或者Curve节点。用曲线的好处是可以用编辑器实时调整手感，不用反复改蓝图逻辑。

3.2 攻击判定：攻击框开关、朝向修正与帧数计算

攻击判定是2D战斗游戏的重头戏，这里的计算项目多且容易出错。我先说一个总原则：攻击判定的框架应该是“动画驱动逻辑”，而不是“输入直接驱动逻辑”。也就是说，玩家按下攻击键后，角色进入攻击状态，播放攻击动画；动画进行到特定帧时，系统开启攻击碰撞盒；再过几帧，碰撞盒关闭，攻击结束。这个“按帧开关”的思路是老派格斗游戏验证过的经验。

在蓝图里，我一般用动画通知（AnimNotify）来做这件事。攻击动画里放两个Notify：一个叫Attack_Start，一个叫Attack_End。触发Start时，角色蓝图把攻击碰撞盒的碰撞开关设为On，并把碰撞盒临时移动到角色前方；触发End时，把碰撞盒关掉。这样的好处是，动画多长，攻击就持续多久，两者天然对齐，不会出现动画播完了伤害还没判完的错位。

这里有一个必须计算的参数：攻击碰撞盒的偏移量。因为角色可能会左右翻转，FacingDirection变量是1或-1。攻击盒默认放在角色的局部坐标X轴正方向，如果角色面朝左，这个盒子的X偏移必须乘以-1，才能真正出现在角色前方。否则你朝左攻击，伤害判定却还是打在右边。这个错误我早期在项目里踩过，当时玩家玩家反馈“明明背对怪打，怪却掉血”，排查了半天才发现是翻转时没算攻击盒偏移。

攻击帧数的设计同样需要计算。以一套标准的三连击为例：第一击从按下的第1到第8帧出伤，第二击从第24到第28帧出伤，第三击从第50帧到第55帧出伤。它们之间的空档不是随便填的，而是要保证动画切换的流畅感。更讲究的项目还会在攻击前摇和出伤判定之间加入一个极短的停顿缓冲，让玩家有机敏感地看到角色动作先到位、然后伤害才爆发。这个算的不是具体数值，而是“时间轴节奏”。

3.3 伤害数字、击退与浮空高度的比例计算

伤害计算是数值策划和程序最容易扯皮的地方。一个成熟的公式往往不是单一乘法，而是“基础值、加成、减免、随机、暴击”这几个环节的叠加。

我常用的一套公式是：

最终伤害 = （基础伤害 + 攻击加成） ×（1 + 暴击倍率） - 防御减免

这里的攻击加成可能是技能的固定数值加成，也可能是属性百分比。防御减免可以是固定值，也可以设计成百分比。如果做的是关卡闯关类游戏，防御减免建议用固定值，配合成长数值，玩家能明确感受到“我变强了”是因为数字提高，而不是公式换来换去。如果做的是刷装备类游戏，用百分比减免更合适，但这意味着数值膨胀曲线需要严格控制。

公式之外，我最想强调的是“伤害数字的表现计算”。当角色受到伤害时，不只是生命值减少，还要产生击退和可能的浮空。击退向量的计算是：受到攻击的方向 × 击退力度。如果攻击来自左边，角色应该被往右边推。用向量算就是“攻击者位置减去受击者位置”，归一化后乘以击退力度。对于那些攻击是范围AOE、没有明确方向来源的情况，可以为技能指定一个固定的击退方向变量，再乘以力度。

浮空高度的计算也同理。角色腾空时，给垂直方向一个初速度，然后让重力加速度把它拉回地面。UE4里做这个最简单的方式是“Launch Character”节点，它允许你直接设置一个冲量。跳跃高度和浮空高度不同，跳跃高度是玩家可控的，浮空高度是敌人受击不可控的。所以浮空初速度通常要设计得比跳跃更低，配合一个短促的弧线，让角色快速被“压回地面”，这样才有打击感。如果浮空速度给太大，敌人会被打到屏幕外，玩家反而觉得很假。

3.4 追踪型抛射物的向量计算

做弹幕、飞刀、追踪弹之类的2D玩法时，抛射物的移动计算是核心。最基础的追踪弹逻辑如下：每帧都做一次“目标位置减去子弹位置”，得到方向，归一化后乘以速度，再用Set Actor Location或Add Actor World Offset把子弹移过去。

单纯这样做会有一个问题：子弹如果飞得很快，可能会“穿过”一个非常小的敌人。碰撞检测没测到，子弹就直接飞过去了。这个技术叫“隧穿效应”。2D游戏里要解决它，我能想到的靠谱方案有三种：一是给子弹开“Sweep”选项，让移动函数做扫描检测；二是子弹用Projectile Movement组件，它会自动做连续碰撞检测；三是纯计算方案：每帧检测子弹与目标之间的距离，如果小于某阈值就视为命中。

追踪弹的“追踪感”也来自计算细节。如果你直接把子弹方向每帧立刻转向目标，那它看起来就像一枚精确制导导弹，几乎没有摇晃。如果你想让追踪弱一点，可以用“当前速度方向”向“目标方向”做插值转向，而不是直接赋值。我常用的方法是：先算出目标方向，再让当前方向向量以每帧一定角度向它旋转，旋转速度决定了追踪强度。做得好的追踪弹，会有一种“挣扎后依然命中”的感觉，这种表现力来自中间的插值过程，而不是最后的命中结果。

4. 相机运镜与镜头偏移中的数学

4.1 平滑跟随：从即时定位到带弹性的插值计算

2D游戏的镜头看似简单，但“跟手”和“死板”的区别，其实就是计算方式的不同。最偷懒的做法是：每帧让摄像机位置等于玩家位置。结果是镜头跟着角色走，不留任何余量，玩家稍微动一下镜头就晃，视觉上非常累。稍微好一点的做法是，让摄像机位置向玩家位置做插值。

UE4本身自带的Camera Component有Lag功能，可以方便地实现平滑。但如果要精细控制，我建议手写插值逻辑：在Camera Actor或角色Camera的Tick里，使用“FInterp to Value”或者“VInterp to”节点，把摄像机的X、Y分别插值到目标坐标。插值速度系数一般设在5到15之间，系数越大跟得越紧，越小越有延迟感。横版游戏通常设计的插值系数是地面8、空中5。因为跳跃时玩家希望镜头稍微留出高空视野，插值速度降低一点，天空的场景自然就多露出来一些。

还有一个细节是“镜头死区”。如果用鼠标来控制2D角色移动，摄像机如果始终对准角色中心，画面会显得特别死板。更好玩的做法是，根据鼠标位置相对于屏幕中心的偏移，给镜头加一个预览偏移量。具体计算方式是：鼠标屏幕坐标减去屏幕中心坐标，除以屏幕宽度的一半，得到一个范围大概在-1到1之间的归一化偏移值，再乘以你设定的镜头偏移最大范围，比如200像素。这样实现出来的效果是，鼠标指向上方时，镜头会稍微往上方偏，看到更多前面的场景。这个功能在PC端的2D射击游戏里尤为重要。

4.2 震动与击退：随机偏移与衰减计算

镜头震动是2D动作游戏里最廉价的打击感增强器，但它背后的计算不算复杂，很多人却做不好。原因是他们没有做“衰减”，震动从头到尾都一样剧烈，看起来像屏幕抽风。

正确的做法是：每次触发震动时，定义一个震动强度值（比如1.0），然后在接下来的0.3秒内逐帧衰减到0。每帧的镜头偏移量等于：震动强度 × 随机偏移区间。随机区间可以是X方向-20到20、Y方向-15到15，这样每帧的偏移都不同，看起来才有“抖”的感觉。要让它逐渐停止，只要把强度值每帧乘以0.85，或者线性减去一个衰减值。

镜头击退是另一个容易被忽视的细节。当玩家受到重型攻击时，镜头应该顺着攻击方向抖一下，再由阻尼系数拉回原位。实现方式是：记录一个“镜头击退偏移量”变量，在受击瞬间把它设置为攻击方向向量乘以击退幅度；每帧让这个偏移量向0插值，同时把它加到正常镜头位置上。这个“被打了镜头往后让一点”的细节，会让打击感上一个台阶。很多游戏带来“手感好”的评价，并不是因为特效多，而是这些细微的计算全都对了。

4.3 关卡边界约束：Clamp值的灵活使用

如果一张2D地图是有限的，那镜头平滑跟随肯定不能无限跟，否则就会看到边界外的灰蒙蒙背景。这个问题的标准解法是给镜头位置做范围限制，蓝图里直接使用“Clamp”节点。

具体做法是：场景里放两个标记点，一个标记地图的左上边界，一个标记右下边界。每次算完跟随目标位置之后，把目标坐标用Clamp限制在这两个边界以内，再设置给摄像机。这里的边界不是指地图的总长度，而是“地图总长度减去屏幕半宽”，这样镜头停在地图边缘时，刚好把画面填满地图区域。

有一个常见的坑：如果你把地图边界设成固定世界坐标，然后地图做成了上下层结构，比如角色从一层掉到二层，镜头在Y轴上的跟随范围就会出错。解决方式是把Y轴边界拆分成两组变量，在角色通过某个传送点时切换镜头边界。玩家从一层跳下深坑，镜头需要展示下层画面，边界就要即时更新。这些更新逻辑本身也是一组计算判断，不要把它们写死在蓝图Tick里，尽量用“进入触发器区域时更新边界”的方式，性能更好。

5. UI与材质层面的计算：让2D画面更细腻

5.1 血条、能量条的平滑变化与数值映射

游戏UI表现力的核心是“数值映射”。开发者手里的生命值可能是0到1000，但UI血条的长度可能只有0到300像素。你不能直接把血量绑给进度条，需要做一个映射：血条百分比 = 当前血量 / 最大血量，然后让进度条的百分比值等于这个结果。

这里说的虽然是小学数学比例，但大多数表现粗糙的UI，问题不在于比例公式，而在于“即时生效”。玩家挨了一刀，血量从800直接变成650，血条瞬间缩短到81%，这个反馈确实快，但太“硬”了。更好的做法是设计一个“显示血量”，它不等于真实血量，而是以一定速度向真实血量靠近。当你挨打后，真实血量少了，显示血量慢半拍才跟上，玩家就能看到血条“拖尾”的效果。这个拖尾速度通常设置成每秒30%到50%，也就是说大约2到3秒完成全部修正。

同样的思路可以应用到能量条、连击条、状态计时器上。只要涉及“条”的UI，都应该把“当前值”和“显示值”分开。用一个“UpdateDisplayValue”函数做插值计算，再把显示值给UI。集中处理的好处是，以后所有UI改动都只改这一个函数，不会出现各个UI各自为战的混乱。

5.2 缩放、旋转、UV偏移的材质计算

当2D游戏需要特效表现时，比如刀光、爆裂冲击波、水面波纹，这些本质上都是材质层面的计算。对不了解材质的开发者来说，最容易上手也最常用的就是UV偏移。

在UE4的材质编辑器里，TexCoord节点表示贴图的UV坐标。要做出横向流动的纹理效果，只需要把UV的X分量加上“时间乘以速度”。材质里通常用Time节点或CustomTime节点获取运行时间。这个“纹理滚动”的技巧可以应用在：刀光拖尾、传送门漩涡、熔岩流动、瀑布下落。基本都是同一个套路，只是修改UV坐标的方向和速度而已。

旋转型的特效需要多一点计算。比如一个旋转的齿轮图标，可以用Rotator节点生成一个随时间变化的角度，然后把它转换成旋转矩阵应用到UV坐标上。很多新手在这一步会卡住，但本质上只需要记住一个公式：新的UV坐标 = 旋转中心 + 旋转矩阵 ×（原始UV坐标 - 旋转中心）。你完全不需要自己写旋转矩阵，材质节点里有一个现成的“Rotator”表达式，输入旋转中心和角度即可。

透明度的动态变化也很常见。受击闪白、死亡消散、敌人刷新时的渐隐，都靠计算Alpha通道来实现。核心是给透明度一个随时间变化的目标值，再配合曲线（Curve）节点控制节奏。比如死亡消散，想让角色从内向外扩散消失，就需要同时计算一个“距离中心越远透明度越低”的遮罩值，本质是一个SmoothStep计算。这些数学节点堆积起来，就是所谓的“高级画面表现”，其实每个拆开来都只是最基础的数值运算。

6. 常见计算问题与排查技巧实录

6.1 蓝图计算结果变成NaN的两个经典原因

NaN是“Not a Number”的缩写，代表一个既不是正数、也不是负数、也不是零的非法数值。蓝图里如果出现NaN，通常角色的位置会瞬间变成不可思议的地方，比如跑到几十亿像素之外，或者攻击伤害变成负数。这是2D游戏项目里最恐怖的bug之一，因为画面表现出的现象千奇百怪，但根源基本就两个。

第一个原因是除数为0。任何一个数除以0，在蓝图里都会产生NaN或无穷大。实践中常见的场景是：你先计算了一个“距离”值，然后用它做除法，比如“攻击力度 = 固定数值 / 距离”，如果角色和目标重叠，距离刚好是0，除法直接爆炸。这类问题的防御方式很简单：所有除法之前，先检查分母的绝对值是否小于一个很小的数，比如0.001，如果是，就直接给一个默认值。

第二个原因是对负数做非整数次方或平方根。在蓝图里，Sqrt节点如果输入负数，会返回NaN。有时你为了做抛物线或跳跃高度计算，可能很自然地就用了平方根，结果因为数值变成负数直接爆炸。我排查过的一个真实案例是：某个敌人AI启动时，用“玩家位置减自身位置”得到一个向量，然后取它的长度，再对这个长度做平方根运算，指向某个缩放值。当玩家和这个敌人重叠时，长度变成0，平方根虽然没出错，但后续计算里出现了一个除以长度的操作，直接除0。排查方式是用Print String节点把每一步计算的关键值打出来，跑到出问题的瞬间看哪个数值变成了NaN，然后反向追踪。

排查NaN还有一个利器：蓝图断点。在怀疑出问题的节点上右键“Add Breakpoint”，运行游戏时执行到该节点会暂停，你可以在细节面板里查看每个输入的当前值。这个操作比盯着Print String逐帧判断效率高出太多。我强烈建议复杂计算链条一定挂断点看数值，不要凭感觉猜。

6.2 整数除法和四舍五入带来的隐蔽错误

蓝图里默认的整数除法会直接舍掉小数点后的部分，这个特性容易引起一类“差一错误”。比如你做掉落物逻辑：击杀敌人后，按“当前关卡等级 / 5”来决定是否掉落稀有材料。当关卡等级是9时，9除以5等于1.8，整数除法结果为1，玩家会在第5关和第9关看到一模一样的掉落配置，这显然不是设计意图。

另一些情况下又需要四舍五入，而不是向下取整。比如显示“暴击率”百分比时，你并不想让小数一直在界面上跳动。UE4里有一个“Round”节点，可以做到四舍五入；也有“Ceil”（向上取整）和“Floor”（向下取整）。我的建议是：所有涉及玩家可见数字的除法，明确记录下设计意图是用哪种取整方式，并且写注释。蓝图里加注释是一个容易被忽略的好习惯，但对后来说维护项目的人来说，注释就是救命稻草。

还有一个小陷阱是“0到1映射时的偏移”。比如把0到100的进度值换算成0到1的百分比，你可能会写“进度值 / 100”，进度值取整80的时候，结果应该是0.8。但如果你是整型变量，悄悄用整数除法，得到的就是0，UI上就完全看不到进度条。UE4的蓝图在实际连接时会自动做隐式类型转换，但节点显示上很难区分，最稳妥的办法是拿到数字后，先用“Convert to Float”节点显式转换。

6.3 防御式计算习惯：Clamp、Abs、MapRange

在多年项目里，我总结出三个防御性计算习惯，能避免至少一半的边缘bug。

第一个习惯是给所有外部输入做Clamp。玩家输入、网络同步数据、配置表数值，都不应该直接参与核心运算。比如角色的移动速度如果是从数据表读取的，某天设计师填了一个负值，你的角色就会倒着走还倒退。给所有关键变量设置合理范围，比如速度Clamp到0到5000，攻击力Clamp到1到9999，能提前把错误拦截在计算之前。

第二个习惯是多用Abs（绝对值）。判断两个Actor是否面对面的方向逻辑，经常会用到差值的正负。如果你只是判断“距离是否小于攻击范围”，用Abs取绝对值是最稳妥的。因为Abs之后，无论傻子怎么填参数，都不会出现负数距离。

第三个习惯是熟悉“Map Range”节点。这个节点可以把一个范围的数值映射到另一个范围，本质上是数学上的线性映射。举一个实用例子：角色的“威力值”设计为0到100，但你希望屏幕闪屏强度在0到5像素之间，于是用Map Range做一次映射，再配合Clamp做上限保护。用这个节点，可以避免自己在蓝图里手写“目标值 = （输入值 - 输入最小值） / （输入最大值 - 输入最小值） × 输出范围”这种公式，既省事又不会算错。记住，Map Range有这个节点，不用自己写公式。

6.4 调试计算结果的三件趁手工具

第一件是Print String节点。可以把它连接到任何分支的关键节点，输出拼接字符串。我会在调试时把“目标X位置”“当前X位置”“插值速度”这些值一起打出来。加了“Print to Screen”开启，和控制台输出勾选，出错以后一眼就能看到数值的走势。

第二件是Actor的调试线段。在场景里画一条从攻击框到目标位置的线，可以直观看到计算出的攻击方向是否正对目标。使用“Draw Debug Line”节点，或者直接调用蓝图函数库里的Debug相关节点，做攻击判定的方向调试会非常高效。我调试攻击判定时，一定会把攻击方位置、目标位置、攻击框顶点都画出来，几个向量一目了然，省得一边想一边猜。

第三件是“Visual Logger”，但这个工具偏高级一点，主要用于记录很长时间的运行轨迹。如果你在做一个复杂的敌人AI，想回看它过去10秒内的追击路径和决策节点，Visual Logger可以把这些记录下来。对2D计算来说，这个工具稍微重型，但当你被一个“偶现”的bug折磨到第三天时，就会知道它能救你命。

7. 我做了这么多2D项目后的几点真实体会

我现在做2D项目，已经养成了三个固定习惯。第一个习惯是统一单位。UE4默认单位是厘米，但是2D游戏里通常用像素思考。如果美术给的是像素尺寸，在程序就要明确“1像素对应引擎多少厘米”，并在导入设置里统一设定。这个问题不解决，等到做镜头边界、攻击范围时，所有数值都会差出一个奇怪的倍数，排查起来极其痛苦。

第二个习惯是计算要集中，不要散落在各处。我会把所有涉及“角色数值变化”的计算，尽量集中在少数几个函数或自定义事件里。比如“TakeDamage”负责所有伤害结算，“UpdateMovement”负责所有位移计算。这样当数值不对劲时，只需要盯住这几个入口函数，而不是在十几个不同的蓝图里找哪段代码改了血量。项目越大越要这样做，否则改一个公式，要找半天引用的地方。

第三个习惯是记录数值感觉表。每次调完跳跃手感、攻击范围、镜头速度，我都会把一组关键参数记录在表格里，附上“太硬”“刚好”“太飘”的备注。这样以后回到项目时，不需要重新从零试参数，那份表格就是最完整的参考。这也是我为什么建议每个开发者都建立自己的“手感数据库”，因为手感本身不是玄学，它就是一组被验证过的计算参数。

最后，再说一句给打算入2D方向开发者的私心话：别怕UE4的数学。它看上去门槛高，但实际用到的无非是加减乘除、插值、归一化、Clamp和取模。2D游戏计算篇，说到底是把玩家感知翻译成数值，再把数值翻译回画面的一整套习惯。这套习惯建立起来，你会发现UE4做2D，真的比想象中要顺手太多。