1. 从一行飘字说起为什么伤害数字值得单独做一套系统做Unity项目的人尤其是做动作类、RPG类或者塔防类玩法的几乎都会碰到同一个需求角色挨打或者打出伤害时头顶要飘出一个数字告诉玩家“这一下打了多少”。听起来特别简单不就是显示个数字吗但真动手做的时候你会发现事情没那么单纯——数字要跟着目标走、要会往上飘、要会淡出、要能暴击变色、要能同时出现十几个不打架、还要考虑性能不能因为几个数字就掉帧。我最早做这个功能的时候直接在受击逻辑里Instantiate了一个带Text的预制体然后写了个协程让它往上移动。单次测试没问题结果一进战斗场景屏幕上二十几个数字同时飘帧率直接从60掉到40多。后来一点点改从对象池到动画曲线从世界坐标转换到Canvas层级管理踩了不少坑也总结出一套比较稳的做法。这篇内容就是把这套“简单伤害数字显示”的完整思路拆开讲清楚。所谓“简单”是指核心逻辑不复杂不需要引入什么重型插件但“简单”不等于“随便写”里面有几个关键决策点如果一开始没想明白后面返工的成本会很高。适合正在做Unity战斗表现、刚接触UI与3D坐标转换、或者想给自己项目加一套轻量飘字系统的朋友参考。不管你是刚学Unity几个月还是已经做过几个完整Demo这里面的细节应该都能对上你的某些实际场景。2. 整体设计思路先想清楚数字到底“活”在哪个空间2.1 世界空间还是屏幕空间这是第一个岔路口伤害数字的显示方式本质上只有两条路一是把数字作为3D世界里的物体World Space二是把它渲染在屏幕空间的UI Canvas上Screen Space。这两条路没有绝对的对错但适用场景差别很大。World Space的做法是让数字直接成为场景里的一个对象挂在目标头顶用TextMeshPro的3D版本或者普通TextMesh。好处是它天然跟随目标摄像机旋转时数字也会有透视变化看起来更“融入场景”。缺点是渲染排序麻烦多个数字重叠时容易穿插而且受光照和后期影响颜色控制不如UI直观。Screen Space的做法是把数字放在一个Screen Space - Overlay或者Screen Space - Camera的Canvas上通过WorldToScreenPoint把目标的世界坐标转成屏幕坐标再设置UI元素的位置。好处是渲染层级清晰、颜色和透明度控制精准、不受场景光照干扰而且所有数字共用一个Canvas批处理友好。缺点是需要每帧做坐标转换目标离开屏幕时还要处理边界。我现在的项目基本都选Screen Space方案原因是战斗场景里数字出现频率高、数量大UI层的可控性明显更好。尤其是暴击、治疗、闪避这些不同颜色和字体的需求用UI做起来非常顺手。下面讲的实现也以这个方案为主World Space的思路会在注意事项里补充。2.2 对象池不是可选项是必选项前面提到我最早用Instantiate直接生成结果性能崩了。原因很简单每次生成和销毁都会触发内存分配和GC数字一多GC频繁触发帧率就会周期性抖动。伤害数字这种“短生命周期、高频率出现”的对象是对象池最典型的应用场景。对象池的核心思想是预先创建一批数字对象用的时候从池子里取用完不销毁而是归还到池子里等待下次复用。这样运行期间几乎没有新的内存分配GC压力极小。Unity自带的ObjectPool类可以用也可以自己写一个简单的栈结构池子。我倾向于自己写因为逻辑简单、可控性强而且不需要额外依赖。池子的大小需要根据战斗强度估算。一般单个角色同时最多飘3到5个数字如果同屏有10个角色在战斗那同时存在的数字大概在30到50个。池子初始容量设50最大容量设100基本能覆盖大多数场景。如果超出最大容量可以选择扩容或者复用最老的那个数字这个后面在问题排查里会细说。2.3 动画方案协程、Animator还是Tween数字飘动的动画常见有三种实现方式。第一种是用协程手动控制位置和透明度每帧yield return null代码直观但每个数字都要开一个协程数量多了有开销。第二种是用Animator做状态机美术可以在编辑器里调曲线但每个数字一个Animator组件性能不如纯代码。第三种是用Tween库比如DOTween链式调用写起来很舒服性能也不错但引入第三方库需要评估。我的选择是如果项目已经用了DOTween那就直接用DOMove加DOFade几行就搞定而且自带缓动曲线。如果不想引入额外依赖就用协程配合AnimationCurve把位移和透明度的曲线暴露在Inspector里让策划或美术也能调。协程的开销在几十个数量级下完全可以接受真正需要注意的是协程里不要做字符串拼接和GetComponent这类操作这些应该在初始化时缓存好。3. 核心细节拆解一个数字从生成到消失经历了什么3.1 预制体的结构设计一个伤害数字预制体看起来就是一个文字但内部结构有讲究。我的标准结构是这样的根节点挂DamageNumber脚本下面一个子节点挂TextMeshProUGUI组件。根节点负责位置和动画控制子节点负责渲染。为什么不把脚本和Text放在同一个节点上因为动画需要同时控制位置和缩放如果和Text在同一节点缩放会影响文字本身的布局容易出现模糊或者偏移。分开之后根节点做位移和缩放子节点保持原始大小文字渲染更稳定。TextMeshPro的选择也有原因。Unity自带的Text组件在字体渲染质量、描边、渐变这些方面比较弱而TMP支持材质预设、描边、阴影做暴击数字时可以直接换材质效果更好。而且TMP的SetText方法在频繁调用时性能优于旧Text的text属性赋值因为它内部做了字符串缓存。预制体上还需要注意Raycast Target要关掉。伤害数字只是显示不需要接收点击开着会白白增加UI事件系统的检测开销。这个细节很多人会忽略但在数字多的时候影响不小。3.2 世界坐标到屏幕坐标的转换这是整个系统里最容易出问题的地方。核心API是Camera.main.WorldToScreenPoint(worldPos)它把世界坐标转成屏幕像素坐标。但这里有几个坑第一Camera.main每次调用都会做一次查找虽然Unity有缓存但在每帧每个数字都调用的情况下最好在初始化时缓存Camera引用。第二如果目标在摄像机背后WorldToScreenPoint返回的z值是负的这时候数字会出现在屏幕错误的位置需要判断z值小于0时隐藏数字。第三如果用的是Screen Space - Camera模式的Canvas还需要把屏幕坐标再转成Canvas的本地坐标用RectTransformUtility.ScreenPointToLocalPointInRectangle。我一般用Screen Space - Overlay模式这样屏幕坐标直接就是UI坐标在Canvas Scaler的参考分辨率下少一步转换。但要注意Canvas Scaler的设置如果用了Scale With Screen Size屏幕坐标和UI坐标之间还有一个缩放比例需要除以canvas.scaleFactor。这个细节在分辨率变化时特别明显1080p下调好的位置到2K屏上可能就偏了。3.3 跟随逻辑每帧更新还是只在生成时定位伤害数字要不要一直跟着目标走这取决于游戏类型。如果是即时战斗数字通常只在生成时定位一次然后自己往上飘不再跟随目标。如果是持续伤害或者目标移动很快数字可能需要短暂跟随。我的做法是生成时定位然后在飘动的前0.2秒内轻微跟随目标之后脱离。这样既有跟随感又不会让数字追着目标满屏跑。实现上可以在Update里判断一个followTimer大于0时更新位置小于等于0时停止。跟随的时候用Vector3.Lerp做平滑避免数字抖动。如果目标在跟随期间被销毁要有判空处理否则会报MissingReferenceException。这个异常在战斗激烈时特别容易出现因为敌人死亡和数字生成几乎是同时发生的。3.4 动画曲线与参数调优数字的飘动动画核心是两个维度位移和透明度。位移一般是从生成点向上移动一定距离比如80到120像素时间0.8到1.2秒。透明度从1渐变到0通常在后半段开始淡出这样数字有足够时间被看清。位移曲线我推荐用AnimationCurve默认的EaseOut效果就不错——开始快后面慢像物体被抛上去又减速的感觉。透明度曲线用线性或者EaseIn都可以关键是淡出不要开始太早否则数字还没看清就没了。我的参数是总时长1秒位移前0.7秒完成透明度从第0.5秒开始下降第1秒归零。暴击数字可以做得更夸张位移距离加大到150像素时长延长到1.3秒初始缩放从0.5弹到1.2再回到1.0配合一个缩放曲线视觉冲击力明显更强。这些参数没有标准答案需要根据项目的美术风格和节奏感来调但上面这套数值是一个比较稳妥的起点。4. 完整实操流程从零搭一套可复用的飘字系统4.1 创建预制体与脚本框架先在场景里建一个Canvas模式设为Screen Space - OverlayCanvas Scaler设为Scale With Screen Size参考分辨率1920x1080匹配模式选0.5兼顾宽高。然后在Canvas下创建一个空物体命名为DamageNumber添加RectTransform大小设为200x80锚点设为中心。在它下面创建一个TMP文本子物体设置好字体、字号建议36到48、对齐方式为居中。接着写DamageNumber脚本核心字段包括TextMeshProUGUI textComponent、RectTransform rectTransform、CanvasGroup canvasGroup、AnimationCurve moveCurve、AnimationCurve fadeCurve、float duration、float moveDistance、Color normalColor、Color critColor。CanvasGroup用来统一控制透明度比单独改Text的alpha更方便而且不会影响子物体。初始化方法Init接收三个参数伤害值、是否暴击、世界坐标。在Init里设置文字内容和颜色计算初始屏幕位置重置所有动画状态。这个方法在对象从池子里取出时调用确保每次复用都是干净的状态。4.2 对象池的搭建与调用写一个DamageNumberPool类内部用一个QueueDamageNumber存储空闲对象。Get方法从队列取如果队列为空就Instantiate一个新的或者根据最大容量决定是否复用最老的。Return方法把对象重置后放回队列。池子本身做成单例或者通过GameManager持有方便全局调用。调用时机是在伤害计算完成之后。比如角色受到伤害计算出最终伤害值然后调用DamageNumberPool.Instance.ShowDamage(damage, isCrit, targetTransform.position Vector3.up * 2f)。这里的Vector3.up * 2f是让数字从头顶偏上的位置出现避免和角色模型重叠。偏移量根据角色高度调整一般1.5到2.5之间。注意对象池的Return一定要在动画结束后调用不能在动画中途归还否则下次取出时状态是乱的。我一般在协程的最后一行调用Return并且加一个isReturned标志位防止重复归还。4.3 动画协程的完整实现协程的主体逻辑是这样的记录起始位置和起始时间然后在while循环里计算已过去的时间比例t (Time.time - startTime) / duration。如果t 1结束循环归还对象。否则用moveCurve.Evaluate(t)计算位移比例更新rectTransform.anchoredPosition用fadeCurve.Evaluate(t)计算透明度更新canvasGroup.alpha。每帧yield return null。这里有个优化点AnimationCurve.Evaluate在每帧调用是有一定开销的如果数字数量特别多可以预先采样成数组用查表代替实时计算。不过对于几十个数字的量级直接Evaluate完全够用没必要过度优化。暴击的缩放动画可以单独加一段在前0.15秒内localScale从0.5线性插值到1.2然后再用0.15秒回到1.0。这段逻辑可以放在同一个协程里用if (isCrit)判断。缩放的中心点是数字的中心所以RectTransform的pivot要设成(0.5, 0.5)。4.4 不同伤害类型的视觉区分普通伤害用白色或浅黄色暴击用橙色或红色并加大字号治疗用绿色护盾吸收用蓝色闪避用灰色并显示“Miss”。这些区分不需要不同的预制体只需要在Init里根据类型设置颜色和文字即可。颜色建议用Color类型的预设值不要每次new Color避免不必要的分配。字号的变化可以通过textComponent.fontSize直接改但要注意TMP修改字号会触发网格重建频繁修改有开销。更好的做法是预制体上准备两套字号或者用localScale缩放代替改字号。我实测下来用localScale缩放到1.3倍来模拟暴击大字效果和改字号差不多但性能更好。5. 常见问题与排查技巧实录5.1 数字位置偏移或抖动这是最常见的问题原因通常有三个。一是坐标转换时没有考虑Canvas Scaler的缩放因子导致不同分辨率下偏移量不一致。解决方法是统一用canvas.scaleFactor做除法或者直接用RectTransformUtility.ScreenPointToLocalPointInRectangle。二是目标物体的中心点不在脚下transform.position取的是模型原点可能在腰部或头部需要根据实际模型调整偏移。三是摄像机在移动而数字只在生成时定位导致视觉上数字“跟不上”目标。如果游戏里摄像机经常移动建议在数字存活的前0.3秒内持续更新位置。5.2 数字被场景物体遮挡Screen Space - Overlay模式下UI永远在最上层不会被3D物体遮挡。但如果用的是Screen Space - Camera模式Canvas的Plane Distance设置不当数字可能被场景物体挡住。解决方法是把Plane Distance设小一点让Canvas靠近摄像机或者直接用Overlay模式。如果确实需要数字被某些物体遮挡比如墙壁后面的敌人数字不应该显示那就需要做射线检测判断目标和摄像机之间是否有遮挡物有的话隐藏数字。这个逻辑在战术类游戏里比较常见。5.3 大量数字导致帧率下降如果同屏数字超过100个即使有对象池也可能出现性能问题。排查思路是先用Profiler看是CPU还是GPU瓶颈。如果是CPU大概率是每帧的坐标转换和动画计算太多可以考虑降低更新频率比如每两帧更新一次位置。如果是GPU可能是Overdraw太严重数字的半透明区域叠加太多可以尝试缩小数字尺寸或者减少同时存在的数量。另外TMP的材质如果每个数字都不同比如不同颜色用了不同材质实例会打断批处理尽量用顶点颜色或者材质属性块来统一。5.4 对象池归还时的状态残留有时候数字复用时上一次的透明度或位置没有重置干净导致新数字出现时闪一下或者位置不对。解决方法是在Return方法里把所有可变状态重置canvasGroup.alpha 1、rectTransform.anchoredPosition Vector2.zero、rectTransform.localScale Vector3.one、textComponent.text 。不要依赖Init里的重置因为Init可能在动画开始后才调用中间有一帧的间隙会显示旧状态。5.5 常见问题速查表问题现象可能原因排查方向解决方法数字位置偏移Canvas Scaler缩放未处理检查scaleFactor坐标除以scaleFactor数字在摄像机背后显示WorldToScreenPoint返回负z判断z值z0时隐藏数字抖动每帧更新位置但目标在移动检查跟随逻辑用Lerp平滑或限制跟随时间帧率下降数字数量过多或OverdrawProfiler分析降低更新频率或缩小尺寸复用时状态残留归还时未重置检查Return方法重置所有可变状态暴击颜色不生效材质实例未更新检查TMP材质用顶点颜色或SetColor数字不消失协程被意外中断检查对象是否被销毁加try-finally确保归还提示如果项目里用了时间缩放Time.timeScale协程里的Time.time会受影响导致数字动画变慢或暂停。如果希望数字不受时间缩放影响用Time.unscaledDeltaTime代替Time.deltaTime用Time.unscaledTime代替Time.time。这个细节在暂停菜单或者子弹时间效果里特别重要。6. 进阶扩展让飘字系统更贴合项目需求6.1 伤害数字的合并显示在持续伤害或者多段攻击的场景里短时间内同一个目标可能跳出好几个数字视觉上很乱。一种优化是合并显示如果0.3秒内同一个目标已经有数字在飘就不生成新的而是把新伤害累加到已有数字上并做一个轻微的放大反馈。实现方式是在目标身上挂一个DamageNumberTracker组件记录当前活跃的数字引用和时间戳。这个逻辑不复杂但能显著提升战斗画面的整洁度。6.2 数字的堆叠避让多个数字同时从同一个位置生成时会完全重叠只能看到最上面那个。简单的避让策略是给每个新数字一个随机的水平偏移比如在-30到30像素之间随机。更好的做法是检测已有数字的位置如果太近就往上或往旁边错开。我一般用随机偏移就够了因为数字飘动本身就有时间差完全重叠的概率不高。如果追求更精细的效果可以用一个简单的物理模拟让数字之间有一个排斥力但这属于锦上添花大多数项目用不上。6.3 与伤害计算系统的解耦伤害数字系统不应该和伤害计算逻辑耦合太深。理想的结构是伤害计算模块只负责算出最终伤害值和是否暴击然后通过事件或者回调通知表现层。表现层收到通知后决定怎么显示数字。这样如果以后要换一套飘字风格或者加一个“伤害数字开关”的设置选项都不需要动核心战斗逻辑。我通常定义一个DamageEvent结构体包含伤害值、类型、目标位置然后用ActionDamageEvent或者UnityEvent来传递。6.4 性能监控与动态降级在低端设备上如果数字太多导致帧率下降可以做一个动态降级当同屏数字超过阈值时自动缩短动画时长或者降低更新频率。比如正常情况每帧更新超过50个数字时改为每两帧更新一次。这个逻辑可以用一个简单的计数器实现不需要复杂的自适应算法。实测下来每两帧更新一次在视觉上几乎看不出差别但CPU开销能降低接近一半。7. 一些个人体会和踩坑记录这套飘字系统我从最早的一版到现在前后改了大概四五次。最大的体会是不要一开始就追求完美先把核心链路跑通——生成、定位、飘动、消失、回收这五步走通之后再去加暴击、加颜色、加缩放。我见过有人一上来就设计了一套特别复杂的动画状态机结果连数字跟随目标都没做好最后推倒重来。另一个坑是坐标转换。我最早做的时候没注意Canvas Scaler在编辑器里测试一切正常打包到手机上一看数字全偏到屏幕外面去了。后来查了半天才发现是scaleFactor的问题。从那以后我养成了一个习惯任何涉及屏幕坐标的代码先在两种不同分辨率下各测一遍确认没问题再继续。对象池的归还时机也值得多说一句。我遇到过数字动画还没结束就被归还的情况原因是目标死亡时触发了一个“清理所有相关对象”的逻辑把正在飘的数字也一起回收了。结果就是数字突然消失或者复用时状态错乱。后来我在DamageNumber里加了一个OnDisable回调在里面强制归还并重置状态这样即使外部逻辑误操作也不会留下脏数据。最后分享一个小技巧如果你觉得TMP的默认字体在飘动时不够清晰可以在材质上开一点描边Outline宽度设0.1到0.2颜色用深色。这样数字在浅色背景和深色背景上都能看清而且描边会让文字显得更“厚实”战斗反馈感更强。这个改动很小但效果提升很明显你可以试试。