1. 为什么一个伤害数字值得单独拿出来做做Unity项目的人尤其是做动作类、RPG类或者塔防类玩法的几乎都会碰到同一个需求角色挨打或者打出伤害时屏幕上要飘出一个数字告诉玩家这一下打了多少。听起来特别简单不就是显示个数字吗但真动手做的时候你会发现这里面的门道比想象中多得多。我最早做这个功能的时候想法很朴素在受击点生成一个Text然后让它往上飘飘完销毁。结果上线测试第一天就被反馈说“数字看不清”“数字叠在一起像一坨”“暴击和普通伤害分不出来”。后来前前后后改了好几版才把这套东西打磨到能用的程度。所以这篇内容不是给你讲一个“Hello World”级别的Demo而是把我踩过的坑、做过的取舍、以及最终沉淀下来的一套可复用的方案完整讲清楚。这套方案的核心目标很明确在Unity里实现一套性能可控、视觉清晰、易于扩展的伤害数字显示系统。它需要解决四个问题——数字怎么生成、怎么飘动、怎么区分类型、怎么回收。适合所有正在做战斗表现、但还没把伤害数字当回事的开发者也适合已经做了一版但效果不理想的同学对照优化。关键词就三个伤害数字、对象池、飘字动画。这三个词基本概括了整个系统的技术骨架。下面我会从设计思路开始一步步拆到代码级别中间穿插我实际项目里遇到的真实问题和解决方案。2. 先想清楚伤害数字到底该用什么载体2.1 Text、TextMeshPro还是Sprite选型决定后面所有事很多人一上来就纠结用哪个组件其实这个问题的答案取决于你的项目规模和美术需求。我把三种常见方案拉出来对比一下你一看就知道该选哪个。方案优点缺点适用场景UGUI Text上手快和Canvas体系无缝集成性能差每个数字都是一个DrawCall字体渲染模糊原型验证、极少量数字TextMeshPro渲染清晰支持富文本和材质特效性能优于UGUI Text需要额外导入资源世界空间配置稍复杂绝大多数正式项目Sprite数字图集性能最好美术可控性最强支持逐位动画需要美术出图数字位数变化时逻辑复杂高品质动作游戏、大量同屏数字我的建议很直接只要不是纯原型一律上TextMeshPro。原因很简单UGUI的Text在世界空间下缩放后边缘会糊而伤害数字恰恰是需要频繁缩放和移动的元素。Sprite方案虽然性能最好但美术成本高而且数字位数不固定时要做动态拼接维护起来很烦。TextMeshPro在清晰度和开发效率之间取得了最好的平衡。选型确定之后还有一个容易被忽略的点渲染层级。伤害数字必须显示在角色和场景之上但又不能盖住UI面板。我的做法是单独建一个Canvas设置成Screen Space - Overlay或者World Space然后通过Sorting Layer控制它和主UI的先后关系。如果你用的是World Space Canvas记得把它的位置固定在摄像机前方一个合适的距离否则数字会跑到摄像机后面去。2.2 世界空间坐标和屏幕空间坐标的转换陷阱伤害数字的位置通常来自受击点这是一个世界坐标。但如果你用的是Screen Space Canvas就必须把世界坐标转成屏幕坐标。这里有个经典坑Camera.main的调用开销。在频繁生成数字的场景下每帧多次调用Camera.main会触发内部查找性能损耗不容忽视。正确的做法是在系统初始化时缓存主摄像机引用private Camera _mainCamera; void Awake() { _mainCamera Camera.main; }然后在需要转换时直接用缓存Vector3 screenPos _mainCamera.WorldToScreenPoint(worldPosition);还有一个更隐蔽的问题当受击点位于摄像机背后时WorldToScreenPoint返回的坐标是反的数字会出现在屏幕错误的位置。判断方法很简单转换后检查z值是否小于0Vector3 screenPos _mainCamera.WorldToScreenPoint(worldPosition); if (screenPos.z 0) return; // 在摄像机背后不显示这个判断不加你的伤害数字就会在某些角度下突然飞到屏幕另一边测试的时候很容易漏掉因为只有特定视角才会触发。3. 对象池不是可选项是必选项3.1 为什么不能直接Instantiate和Destroy我见过太多项目在战斗逻辑里直接Instantiate(damageTextPrefab)打完再Destroy。在低频战斗里这没问题但一旦同屏出现几十个伤害数字GC垃圾回收就会开始频繁触发表现为周期性的卡顿。这种卡顿在动作游戏里是致命的玩家会觉得“手感不对”。对象池的核心思想是数字用完了不销毁而是藏起来下次要用直接取。这样整个运行过程中几乎不产生新的内存分配GC压力降到最低。Unity 2021之后官方提供了UnityEngine.Pool命名空间下的ObjectPoolT可以直接用。但如果你用的是老版本或者想要更精细的控制自己写一个也不复杂。我倾向于自己写因为伤害数字的池子需要一些定制逻辑比如预热数量、最大容量、溢出策略等。3.2 一个够用又不臃肿的池子实现下面是我实际项目里用的简化版对象池去掉了一些项目特有的逻辑保留最核心的部分public class DamageTextPool : MonoBehaviour { [SerializeField] private DamageText prefab; [SerializeField] private int prewarmCount 20; [SerializeField] private int maxSize 100; private QueueDamageText _pool new QueueDamageText(); private int _totalCreated; void Awake() { for (int i 0; i prewarmCount; i) { var item CreateNew(); item.gameObject.SetActive(false); _pool.Enqueue(item); } } private DamageText CreateNew() { var item Instantiate(prefab, transform); _totalCreated; return item; } public DamageText Get() { if (_pool.Count 0) { var item _pool.Dequeue(); item.gameObject.SetActive(true); return item; } if (_totalCreated maxSize) { return CreateNew(); } // 池子满了强制回收最早的那个 // 实际项目中这里可以做得更优雅比如回收当前最旧的活跃对象 return null; } public void Return(DamageText item) { item.gameObject.SetActive(false); item.transform.SetParent(transform); _pool.Enqueue(item); } }这里有几个设计决策值得说明。预热数量设20是因为大多数战斗场景同屏数字不会超过这个数提前创建好可以避免战斗开始瞬间的卡顿。最大容量设100是防止极端情况下池子无限膨胀超过就返回null由调用方决定怎么处理。回收时重置父节点是为了让池子对象在Hierarchy里保持整洁不然用久了层级会乱成一团。注意对象池的Return方法一定要确保每个数字在生命周期结束时都被调用否则池子会越用越少最后退化成每次都新建。我建议在数字的动画结束回调里统一处理回收而不是散落在各个地方。3.3 池子预热时机的选择预热放在Awake里是最简单的但如果你游戏启动时有很多系统同时初始化可能会造成启动卡顿。另一种做法是在场景加载时预热或者干脆在第一次进入战斗前预热。我的经验是如果预热数量不大20以内放Awake没问题如果数量大考虑异步预热或者分帧创建。分帧创建的做法是用协程每帧创建几个直到达到预热数量。这样虽然预热时间变长但不会造成单帧卡顿。对于伤害数字这种对启动速度不敏感的系统分帧创建是很划算的。4. 飘字动画的曲线设计比你想的重要4.1 线性移动为什么看起来“很假”最朴素的飘字动画是让数字以恒定速度往上移动到达某个高度后消失。这种线性运动在视觉上非常生硬因为现实世界里几乎没有东西是匀速直线运动的。玩家看到这种动画潜意识里会觉得“这是个程序在动”而不是“游戏世界里的反馈”。好的飘字动画应该模拟一种先快后慢、略带随机的运动。具体来说数字出现时有一个向上的初速度然后逐渐减速同时水平方向有一个微小的随机偏移让每个数字的轨迹不完全一样。这样看起来就自然多了。我用的是Mathf.SmoothStep或者自定义的缓动曲线。下面是一个典型的飘字动画协程IEnumerator PlayAnimation(DamageText text, Vector3 startPos) { float duration 0.8f; float elapsed 0f; float horizontalOffset Random.Range(-30f, 30f); float riseHeight Random.Range(80f, 120f); while (elapsed duration) { elapsed Time.deltaTime; float t elapsed / duration; // 垂直方向先快后慢 float y Mathf.SmoothStep(0, riseHeight, t); // 水平方向轻微偏移 float x Mathf.Sin(t * Mathf.PI) * horizontalOffset; text.transform.localPosition startPos new Vector3(x, y, 0); // 后半段开始淡出 if (t 0.6f) { float alpha 1 - (t - 0.6f) / 0.4f; text.SetAlpha(alpha); } yield return null; } _pool.Return(text); }这段代码里有三个细节。SmoothStep让垂直运动有缓入缓出的效果比线性自然得多。水平偏移用Sin函数这样数字会先往一边偏再回来形成一个轻微的弧线比直线更有动感。淡出从60%进度开始而不是从头就开始淡这样数字在上升阶段保持清晰只在最后阶段消失可读性更好。4.2 随机化是避免“整齐划一”的关键如果所有伤害数字的动画参数完全一样连续打出多个数字时它们会像阅兵一样整齐地往上飘看起来非常机械。解决办法是给每个数字的动画参数加随机扰动。我通常随机的参数包括上升高度80到120像素、水平偏移-30到30像素、动画时长0.7到0.9秒、缩放曲线出现时从0.5倍弹到1.2倍再回到1倍。这些随机值不需要很大但能让每个数字看起来都是独立的个体。提示随机化的时候要注意水平偏移不要太大否则数字会飘到屏幕外面去。我一般控制在30像素以内这个范围在大多数分辨率下都是安全的。4.3 暴击数字的特殊处理普通伤害和暴击伤害如果只是数字不同玩家很难一眼分辨。我的做法是给暴击数字一套独立的视觉参数更大的字号、不同的颜色、更强的缩放弹跳、额外的粒子或描边效果。具体实现上我会在DamageText组件里暴露一个SetStyle(DamageStyle style)方法根据传入的样式类型调整TMP组件的属性public void SetStyle(DamageStyle style) { switch (style) { case DamageStyle.Normal: _tmp.fontSize 36; _tmp.color Color.white; _scaleMultiplier 1f; break; case DamageStyle.Critical: _tmp.fontSize 52; _tmp.color new Color(1f, 0.85f, 0.2f); _scaleMultiplier 1.4f; break; case DamageStyle.Heal: _tmp.fontSize 40; _tmp.color new Color(0.3f, 1f, 0.4f); _scaleMultiplier 1.1f; break; } }这样调用方只需要决定“这是什么类型的伤害”具体的视觉表现由DamageText自己处理职责清晰扩展也方便。以后要加“真实伤害”“护盾吸收”之类的类型只需要在枚举和switch里加分支就行。5. 从受击事件到数字生成中间隔着一层解耦5.1 直接调用生成的问题最直觉的做法是在受击逻辑里直接调用DamageTextManager.ShowDamage(position, value)。这在小型项目里没问题但一旦项目规模变大战斗逻辑和表现逻辑就会纠缠在一起。比如你以后想加一个“关闭伤害数字”的选项或者想在特定副本里换一套数字样式就得去改战斗代码这显然不合理。更好的做法是用事件或者消息机制解耦。战斗逻辑只负责发出“某位置受到了某数值的某类型伤害”这个事实至于要不要显示数字、怎么显示由表现层自己决定。我常用的是C#的event或者UnityEvent。定义一个伤害事件结构public struct DamageEvent { public Vector3 Position; public int Value; public DamageStyle Style; }战斗逻辑里触发public static event ActionDamageEvent OnDamage; // 受击时 OnDamage?.Invoke(new DamageEvent { Position hitPoint, Value damage, Style isCritical ? DamageStyle.Critical : DamageStyle.Normal });表现层订阅这个事件收到后生成数字。这样战斗逻辑完全不知道伤害数字的存在表现层也可以随时开启或关闭互不影响。5.2 事件订阅的生命周期管理用event有一个经典坑忘记取消订阅导致内存泄漏。如果表现层对象被销毁了但事件还持有它的引用就会出问题。所以订阅和取消订阅必须成对出现void OnEnable() { BattleEvents.OnDamage HandleDamage; } void OnDisable() { BattleEvents.OnDamage - HandleDamage; }用OnEnable和OnDisable而不是Start和OnDestroy是因为对象可能被反复启用和禁用用前者能保证订阅状态和激活状态一致。注意如果事件是静态的在场景切换时一定要确保所有订阅者都取消了订阅否则上一个场景的对象会被下一个场景的事件意外触发。我一般会在场景卸载的钩子里做一次清理或者干脆用非静态的事件管理器。5.3 同帧多个伤害的合并问题有些技能会在同一帧对同一个目标造成多段伤害如果每段都生成一个数字屏幕上会瞬间出现一堆重叠的数字完全看不清。这种情况有两种处理方式合并显示和错开显示。合并显示是把同帧同位置的伤害累加只显示一个总和。错开显示是给每个数字加一个微小的延迟或偏移让它们依次出现。我倾向于合并显示因为玩家关心的是“这一下总共打了多少”而不是“分了几段”。实现上可以在表现层做一个缓冲每帧收集所有伤害事件按位置分组同组内累加数值帧末统一生成。这样既避免了重叠又减少了数字数量对性能也有好处。6. 性能优化里最容易被忽视的几个点6.1 TMP的材质实例化问题TextMeshPro有一个特性当你修改某个TMP组件的材质属性时Unity会自动为它创建一个材质实例。如果你在代码里频繁修改颜色或字体大小每个数字都会持有一个独立的材质实例DrawCall会暴涨。解决办法是尽量通过预设的材质变体来切换样式而不是在运行时修改材质属性。比如普通伤害和暴击伤害用两个不同的Material Preset切换时直接换材质引用而不是改材质参数。如果确实需要动态改颜色用_tmp.color这种顶点色属性它不会触发材质实例化。6.2 数字数量上限和降级策略再好的优化也扛不住无限量的数字。我一般会设一个同屏上限比如50个。超过之后新的数字要么不显示要么替换掉最旧的。这个策略要根据游戏类型来定动作游戏可以激进一点策略游戏可以宽松一点。降级策略还包括距离摄像机远的数字降低更新频率、被遮挡的数字不显示、低画质模式下减少数字数量。这些在移动端尤其重要因为移动设备的填充率有限大量半透明数字会迅速拉高GPU负载。6.3 用Profiler验证而不是凭感觉我见过很多开发者凭感觉优化觉得“应该差不多了”结果一上真机就卡。伤害数字系统的性能瓶颈通常在两个地方Canvas重建和DrawCall数量。用Unity Profiler看两个指标就够了Canvas.SendWillRenderCanvases和Batches。如果前者每帧都很高说明Canvas在频繁重建可能是数字的Transform变化太频繁。如果后者很高说明DrawCall太多可能是材质实例化或者层级设置有问题。我的经验是把伤害数字放在独立的Canvas上这样它的重建不会影响主UI。同时确保同一个Canvas下的数字共用材质这样Unity才能合批。如果数字数量确实很大可以考虑用Sprite方案或者GPU Instancing但那是另一个量级的优化了。7. 一些实际项目里攒下来的零碎经验7.1 数字的可读性比炫酷更重要刚做这个功能的时候我喜欢加各种特效描边、阴影、发光、粒子。结果测试的时候玩家反馈“看不清数字”。后来我做了个简单的对比测试发现纯白字加黑色描边的可读性远高于各种花哨效果。现在我的默认样式就是白字黑边暴击用黄字黑边治疗用绿字黑边简单直接。字号也很关键。太小了看不清太大了挡视线。我的经验值是在1080p分辨率下普通伤害36号字暴击52号字这个比例在大多数场景下都合适。如果你的游戏视角比较远可以适当放大。7.2 伤害数字的位置偏移数字生成的位置不应该是受击点本身而应该稍微偏上一点。因为受击点通常在角色身体中部数字从那里冒出来会被角色模型挡住。我一般会在受击点基础上加一个向上的偏移偏移量大约是角色高度的三分之一。另外如果同一个位置连续出现多个数字后来的数字应该稍微往上错开避免完全重叠。这个错开量不需要很大每个数字加10到15像素就够了视觉上能区分开就行。7.3 暂停和慢动作的处理很多游戏有暂停菜单或者子弹时间。伤害数字的动画应该受Time.timeScale影响吗我的答案是暂停时应该冻结慢动作时应该跟着变慢。这样才符合玩家的直觉。实现上如果动画用的是Time.deltaTime它会自动受timeScale影响。但如果你用的是Time.unscaledDeltaTime就需要手动处理。我建议统一用Time.deltaTime然后在暂停时把整个伤害数字系统的更新停掉。还有一个细节暂停时已经生成的数字不应该继续飘否则恢复游戏时它们会突然跳到一个奇怪的位置。解决办法是在暂停时记录每个数字的动画进度恢复时从记录点继续。如果嫌麻烦也可以在暂停时直接隐藏所有数字恢复时重新显示但这样会有闪烁感。7.4 多摄像机场景的适配有些游戏用了多个摄像机比如主摄像机加UI摄像机或者分屏。这种情况下伤害数字应该显示在哪个摄像机下我的做法是跟随受击对象所在的摄像机。如果受击对象在主摄像机视野内数字就显示在主摄像机下如果在分屏的某个视口内就显示在对应的摄像机下。实现上可以在生成数字时判断受击点与各个摄像机的视口关系选择包含它的那个摄像机。如果同时被多个摄像机看到比如分屏边界就选主摄像机。这个逻辑不复杂但不做的话分屏游戏里数字会出现在错误的一侧。7.5 本地化和数字格式如果你的游戏要支持多语言伤害数字的格式也可能需要调整。比如中文习惯用“万”作单位英文用“K”和“M”。这些格式化逻辑应该放在表现层而不是战斗逻辑里。战斗逻辑只负责传出原始数值表现层决定怎么显示。我一般会写一个FormatDamage(int value)方法根据当前语言和数值大小返回合适的字符串。比如string FormatDamage(int value) { if (value 1000000) return (value / 1000000f).ToString(0.#) M; if (value 1000) return (value / 1000f).ToString(0.#) K; return value.ToString(); }这样战斗逻辑完全不用关心显示格式以后要改也只是改这一个方法。8. 把这套东西串起来一次完整的调用链路说了这么多最后用一个完整的流程把各个环节串起来方便你对照自己的项目检查。第一步战斗逻辑检测到伤害。计算伤害数值确定伤害类型获取受击点的世界坐标。第二步发出伤害事件。通过静态事件或者事件管理器广播DamageEvent包含位置、数值、类型三个信息。第三步表现层接收事件。伤害数字管理器订阅了事件收到后先做同帧合并检查然后从对象池取一个可用的DamageText。第四步初始化数字。设置文本内容、样式、初始位置调用动画协程。第五步动画播放。数字按照缓动曲线上升、偏移、淡出期间每帧更新位置和透明度。第六步动画结束回收。协程结束时调用池子的Return方法数字被隐藏并放回队列等待下次使用。整个链路里战斗逻辑和表现逻辑完全解耦对象池保证了性能动画曲线保证了视觉效果样式系统保证了扩展性。这套方案我在几个不同规模的项目里都用过从独立小游戏到中型商业项目基本不需要大改就能直接套用。如果你现在项目里的伤害数字还是直接Instantiate和Destroy我建议你至少先把对象池加上这一步的收益最明显。然后再逐步优化动画曲线和样式系统。不用一次做到位但方向要对。