前两期我把技能释放和角色数值池的处理思路讲完了这一期专门拆 Buff 系统。在 RPG 框架里Buff 系统属于那种“一开始不觉得难功能越加越痛苦”的模块。战斗里常见的增伤减伤、中毒灼烧、护盾免疫、眩晕嘲讽、变身变形都会被做成 Buff。如果 Buff 模块结构选得不好后面每加一个新技能或新状态都要去改伤害计算、移动速度处理、动画表现和 UI 图标Bug 也会跟着越来越多。这篇文章会把 Buff 系统的搭建思路按实际落地顺序拆一遍先讲清楚 Buff 本质上管理哪些事再给一套配置、实例、效果三层的代码结构然后看生命周期和战斗结算怎么接入最后补叠加规则、常见排错和验收标准。内容偏工程框架不绑定具体引擎但代码示例用的是 C# 风格放到 Unity、Godot、自研引擎里都可以做类似映射。1. Buff 系统为什么会变成“改一个加一个”1.1 最容易犯的错在伤害函数里堆满 if很多项目一开始是没有独立 Buff 模块的。实现“火伤提高 30%”的时候直接在伤害公式里写if (hasFireBuff) { damage damage * 1.3f; }实现“受到物理伤害降低 10%”的时候又在受伤函数里写if (hasPhysicalShield) { damage damage * 0.9f; }这种写法单看一次没问题所有状态叠加起来就开始失控。等到技能系统、装备系统、Buff 系统几个模块同时给玩家添加状态时你根本不知道一个属性在某个时间点到底被多少系统改过。更麻烦的是顺序问题。如果一个角色同时有“受到伤害降低 10%”和“受到火属性伤害提高 20%”这两个修正谁先谁后会让最终数值出现不同结果。伤害逻辑里靠 if 顺序决定结果意味着这个序列非常脆改动一次伤害公式Buff 效果就可能悄悄变了。1.2 Buff 本质不是状态标记是三件事我在做第 1 期和第 2 期框架的时候把技能和属性模块的接口定得比较清晰到了第 3 期才发现Buff 要稳定需要把它拆成以下三件事处理立刻生效并持续存在的事件例如“每秒恢复 2% 生命”。被动修正数值的事件例如“攻击力提高 15%”。改变战斗流程判定的事件例如“免疫一次致命伤害”或“眩晕期间不能行动”。这三件事如果都靠技能伤害函数里打标记控制Buff 自然到处蔓延。如果换一种思路让 Buff 系统只负责“产生一个实例、维护这个实例的周期、在正确时机触发事件”战斗系统只负责“读取当前属性或注册事件”两边就有明确的边界。所以我建议所有做战斗系统的人先不要急着封装一堆 Buff 对象的 API。先确认你的项目里有哪些类型的状态它们影响的是数值、是行为还是结算结果。大多数 Buff 系统的混乱不是缺少代码而是“影响点”不明确。2. 落地数据模型配置、实例、效果三件套2.1 静态 Buff 定义和运行时状态分开设计 Buff 系统第一个要遵守的原则是Buff 模板和 Buff 实例是两回事。模板表示“这种 Buff 长什么样”实例表示“当前这个角色身上带着的那一份状态”。同一个中毒 Buff可以被多个角色携带每个角色的剩余时间、层数、来源技能都不同。如果只用一份对象来表示就会出现角色 A 的毒伤结束角色 B 的毒伤也跟着没了的诡异现象。示例配置public class BuffConfig { public int id; public string buffName; public float duration; public int maxStack; public bool canRefresh; public bool killClean; public ListIBuffEffect effects; }示例实例public class BuffInstance { public int instId; public int configId; public int currentStack; public float remainTime; public int tickCount; public BuffState state; public BattleEntity source; public BattleEntity owner; }这样配置表可以策划填实例由战斗运行时产生。添加同一个 Buff 时先去找角色当前身上有没有同 configId 的 Buff如果有就进入叠加或刷新逻辑如果没有就创建新实例。2.2 伤害、治疗、护盾、属性修正不要全塞一个数组里刚开始写 Buff 效果时很容易用一个枚举加一个数值数组来表达“类型是伤害值是 50间隔是 2 秒”。这种简化在少量 Buff 时很好用但后续会遇到几个问题每个效果的参数数量不一样。DOT 需要间隔、每次伤害、伤害类型修改攻击力需要修正百分比或固定值护盾需要吸收上限控制效果需要处理免疫优先级。如果所有效果都放在同一个数组里每种效果只能通过大 switch 来区分新增效果类型时所有读取入口都要加一段分支。不好做配置序列化。策划写配置时可能漏字段代码一边读一边判断容易把问题留到运行时才暴露。我建议使用接口方式组织效果同一效果类型是一个独立类。核心思路是Buff 实例自己不直接去计算伤害或修改属性而是把一项工作委托给 effect 对象。例如public interface IBuffEffect { void OnAdded(BuffContext ctx); void OnRemoved(BuffContext ctx); void OnTick(BuffContext ctx); }然后不同效果实现自己的逻辑。这样做最大的好处是以后加“吸血 Buff”“反射伤害 Buff”只是在 effects 列表里新增一个类不需要去改 Buff 主流程。主流程只负责遍历、调用生命周期回调。2.3 运行时实例要记录“来源体”和“累计参数”建立 BuffInstance 时除了记录目标角色、Buff 配置之外至少还要存两个信息source是谁施加了这个 Buff。currentStack当前层数带来的累计强度。source 很重要。很多 Buff 的生命周期和施法者绑定。比如“召唤火焰结界施法者死亡后结界消失”如果不记录 sourceBuff 就无法在施法者死亡时正确清理。还有一些判定要追溯来源比如“击杀者获得回血”如果没有 source就很难判断击杀归属。currentStack 不只是数量的叠加还可能改变效果值。比如“每层减速 10%最多 5 层”这些效果值在计算时要根据 currentStack 去动态求值。如果做成“添加 Buff 时一次性把数值算死”后续层数变化、持续时间刷新都会很难处理。建议不要把 Buff 的效果值在添加时一次性写死除非你的战斗里不存在层数变化。正确的做法是在每次结算时从当前层数和来源属性去算。这样即使玩家中途换装备、升级属性Buff 的伤害或增益也能跟随当前状态避免“Buff 添加时很强几秒后玩家角色变弱了但 Buff 伤害还保持高数值”的奇怪表现。3. 生命周期状态机先让 Buff 能正常挂上去再谈扩展3.1 一个 Buff 从添加到结束要经过哪些阶段有些项目只做两个状态存在和不存在。Buff 添加时触发一次结束时移除。但实战里会漏掉很多关键时机添加后效果还没生效UI 应不应该显示角色处于免疫状态时这个 Buff 是添加失败还是等待免疫结束再添加Buff 移除时身上的属性移除和 UI 清理顺序谁先谁后战斗结束时正在倒计时的 Buff 要不要清除为了避免这些遗漏我建议把状态控制在四个以内public enum BuffState { Pending, Active, Removing, Removed }Pending 表示已加入目标列表但还未触发生效逻辑Active 是正式生效Removing 是已经开始移除但不能重复移除Removed 表示已完全销毁。状态并不是越多越好而是保证“同一个 Buff 不会在一次生命周期里被重复触发”。添加 Buff 的标准顺序是先创建实例加入拥有者的 Buff 容器然后进入 Active触发 OnAdded。移除 Buff 的推荐顺序是先标记为 Removing调用 OnRemoved再把实例从容器中删除。最好不要在遍历 Buff 列表的过程中直接修改列表否则容易出现迭代跳项或访问空引用。3.2 Tick 驱动方式优先于“在 Update 里每帧检查”Buff 系统里有大量周期性效果常见如“每 2 秒扣一次血”“每 5 秒恢复一次蓝”。许多初学者会在 Update 里对每个 Buff 都做一帧检查然后判断有没有到时间点。如果 Buff 数量少这没问题。可一场战斗如果有几十个怪物每个怪物身上又有多个周期 Buff帧循环里做频繁遍历就会增加无意义的开销。更好的做法是让每个 Buff 自带剩余 tick 间隔在统一的 BuffUpdate 方法里只做两件事更新剩余持续时间。到达 tick 节点时调用对应 effect。一个足够简单的框架示例public void OnUpdate(float delta) { for (int i buffList.Count - 1; i 0; i--) { var buff buffList[i]; buff.remainTime - delta; if (buff.tickWaitTime 0) { buff.tickWaitTime - delta; if (buff.tickWaitTime 0) { DoBuffTick(buff); } } if (buff.remainTime 0f) { RemoveBuff(buff, BuffRemoveReason.TimeOut); } } }从后往前遍历是因为移除一个 Buff 后当前位置后面的元素会向前移动倒序遍历可以避免漏处理。3.3 角色死亡、战斗结束、清状态时到底怎么处理没有一套 Buff 框架能覆盖所有游戏但有几个点一定要提前约定。第一角色死亡时身上哪些 Buff 保留哪些清除一般受击类控制效果和持续伤害会在死亡后移除但有些“死后复活”专用 Buff 需要保留。最简单的方法是给 Buff 配置一个 killClean 标记或者 buffCategory 分类避免在角色死亡函数里写死清除所有。第二战斗结束和副本结算时Buff 容器要支持一次性清空。此时需要给每个 Buff 发一个 RemoveReason 参数让“战斗结束移除”“效果时间结束移除”“被驱散移除”可以区分。否则你写日志时只能看到一行 Remove根本不知道是逻辑主动删除还是自然消失。第三竞技场或野外挂机场景中如果你把角色切到后台后再回来要自己检查分钟级或小时级的时间差。很多基于 Update 的框架在页面切到后台时delta 可能被暂停或累计很大这时要专门处理长间隔补算不能直接把一个大 delta 塞进每个 Buff 里否则有些 Buff 可能被瞬间结算很多次。4. Buff 进入战斗结算减伤、免疫、伤害吸收和护盾怎么排4.1 结算拦截点是 Buff 和伤害系统耦合的地方Buff 真正影响战斗体验的不只是“攻击力增加了多少”更重要的是它在伤害流程中出现在哪个环节。同一个减伤技能如果写在“计算攻击力”之后就和写在“最终伤害”之前效果不同对玩家的观感也不一样。为此伤害系统应当预留一套统一的事前和事后处理节点让 Buff 可以在这些节点中修改伤害上下文public class DamageContext { public BattleEntity source; public BattleEntity target; public float finalValue; public float rawValue; public bool isImmune; }Buff 做一个“受伤修正器”时不应该直接回调伤害函数外部的一堆逻辑而是把 Buff 注册到目标实体的事件列表里当实体即将受伤时遍历这些修正器。修正器可以修改 finalValue、设置 isImmune、把直接伤害改成吸收伤害等。这套设计说难不难关键只是你不要把结算逻辑散得满项目都是。推荐把流程固定在造成伤害前触发主要处理免疫、格挡、分摊、闪避。计算修正阶段处理百分比减伤、属性减伤、护盾吸收。最终伤害生成后处理反击、吸血、伤害回蓝、记录伤害事件。Buff 系统只要能够在这些节点上插入自己的处理函数就可以实现绝大多数战斗效果。4.2 同优先级到底谁先谁后实际项目中经常出现几个减伤 Buff 同时存在例如“受到物理伤害降低 20%”和“受到伤害降低 10%”。这类通常属于乘法叠加还算直观最终伤害 原伤害 × (1 - 20%) × (1 - 10%)。可如果出现“减少敌方攻击造成的伤害”和“把所有伤害转移到护盾”这种偏机制型效果就不适合靠乘法公式调节了。我们要先定义 Buff 的执行优先级。低优先级修正先执行高优先级后执行或者反过来关键是同一个项目里只采用一套约定。我在框架里通常会给每种 Buff 效果配置一个 order 字段或者按 buffType 分大类固定优先级。例如控制类、格挡类、无敌类、护盾类、属性类它们的默认执行顺序是固定的无敌和闪避类直接让这次伤害无效。免疫控制类不进入后续控制结算。护盾吸收类优先扣护盾值。减伤修正类修改最终伤害。记录伤害类统计和触发反击。注意顺序本身没有绝对正确但必须有统一实现并且要能在配置表表达。不要在没有明确优先级的情况下靠代码顺序解决因为代码顺序很难给策划做灵活配置。4.3 控制类 Buff 的效果怎么做更不容易出错控制效果和普通属性 Buff 不同它会直接影响行动系统。比如眩晕后角色不能放技能、不能移动冰冻后可能也不能被击退嘲讽后普通攻击只能打特定目标。如果控制只是给角色打个“不能再动”的标记那么角色在移动、转向、AI 选目标这些地方都要做条件判断。一个更可控的方式是让整个行动系统拥有“可行动能力”和“当前主动状态”两个概念。控制 Buff 负责给行动系统注入受控状态。行动系统统一在“准备执行任何动作”之前检查控制状态而不是在技能按钮响应函数里判断。这能避免一个典型 Bug玩家被眩晕时还能触发被动闪避反击。被动反击也是一种行为如果被动技能逻辑没有检查控制状态就会造成“眩晕状态下还能反击”的奇怪问题。所以控制类 Buff 应该影响更底层的行动能力入口而不是靠每个技能自己处理。5. 同类型 Buff 叠加、刷新、移除时的常见坑5.1 同 ID 的 Buff 是叠层还是刷新不同游戏有不同的算法选择。很多 MOBA 和动作游戏再次获得同类 Buff 时会刷新持续时间不叠加层数。MMORPG 里同一 DOT 的来源不同可能允许各挂一份各自跳伤害。回合制游戏里同类减益经常允许层数上限例如最多 3 层“脆弱”每层减少一定比例防御。设计数据模型时最好在 BuffConfig 中明确表达这个规则而不是在 AddBuff 函数里硬写public class StackRule { public bool allowMultiSource; public bool refreshOnAdd; public int maxStack; public float maxDurationAfterRefresh; }addBuff 的逻辑可以概括为如果角色身上已有同 configId 的 Buff并且 allowMultiSource 为 false那么走刷新或叠层逻辑。如果 allowMultiSource 为 true并且同来源 Buff 已存在再决定刷新还是另开一个。如果 maxStack 已满新的添加可以选择“刷新最长时间”或“拒绝添加”具体由玩法决定。这里最容易错的是同来源和多来源混在一起时玩家视角看到的是“我放了两层毒”但数据层可能已经出现多个实例UI 层也可能重复显示图标。建议至少在 BuffComponent 里维护一个便捷方法GetBuffByConfigId、GetBuffStackCountByConfigId。5.2 刷新时数据和表现要一起刷新当 Buff 被刷新时不只是剩余时间发生变化。如果 Buff 有层数刷新后要重算新的 tick 间隔、剩余 tick 等待时间、下次伤害值。如果技能等级更高刷新后可能还要替换效果强度。表现层往往比数据层慢。所以只改 remainingTime 而不通知 UI会出现读秒结束但图标还在的情况只更新图标不重算数值又会出现“显示 3 层实际只按 1 层计算”的问题。我建议在 BuffComponent 内部提供一个统一接口比如RefreshBuff(instId)。它负责修改实例数据同时发出一个 buffChanged 事件。这个事件是 UI、伤害编辑器、战斗日志共同订阅的同一个入口不会漏。5.3 移除时最容易出两件事清不干净和多清一次Buff 移除时有两个高发 Bug。一是 Clea 不干净。属性加成类 Buff 在效果结束时没有把原来加成的属性减回去。例如加 20 点攻击力移除时只移除 15 点角色属性就会越来越膨胀。解决方法是所有属性修改都走一个统一的属性附加系统Buff 模块只做“提交修改”属性系统记录完整修改来源。移除 Buff 时从修改来源列表里删除对应项然后重新计算角色基础属性。不推荐在 Buff 内部自行把属性减回去这样很容易因为加算顺序错乱产生误差。二是多清一次。Buff 状态机如果缺少 Removing/Removed 判断一次移除事件可能同时由“时间到”和“角色被净化”触发。第二次遍历到这个 Buff 时可能已经是空引用。所以移除入口要检查状态已经在 Removing 的 Buff 不能重复执行 OnRemoved。6. 排错思路和最小测试用例6.1 先复现再改逻辑Buff 相关的 Bug 通常很恶心因为错误不会马上暴露。比如“某个 Buff 在叠加到第二层时伤害少了”你不一定立刻发现。如果你打算给战斗系统写 Buff 框架我强烈建议准备一个小型战斗演示场景场景里只做一个木桩和一个施法者。通过控制台命令直接给木桩添加任意 id、层数和时长的 Buff。这个演示场景不需要美术资源白盒碰撞体都行。核心是能稳定地重复一套操作比如添加 Buff A等 3 秒看生效次数。添加 Buff A 两次检查层数和剩余时间。在 Buff A 存在时添加 Buff B观察两者是否有意外的属性覆盖。移除 Buff A再查看木桩属性是否完全还原。Bug 能不能快速解决往往取决于你能不能快速复现。像 Buff 这种受持续时间、事件顺序影响很大的系统纯靠脑内推演很难定位。6.2 日志要带上实例 ID 和来源 ID给 Buff 系统加日志时不要只输出一行“Add Buff”。实例 ID、配置 ID、目标、来源、层数、剩余时间都值得记录。尤其是多个角色同时战斗时没有实例 ID 根本看不出是哪一份 Buff 出了问题。推荐在关键节点输出类似这样的文本[Buff] Add instId1024 cfgId105 stack1 source1002 owner1001 remain5.0 [Buff] Tick instId1024 cfgId105 stack2 damage45 remain3.0 [Buff] Remove instId1024 reasonTimeOut stack2 owner1001如果以后出现数值不对直接拉日志对比操作输入和输出很多问题都能看到。6.3 一定要跑过的几个边界用例我没必要列一份特别宽泛的测试清单但有几类问题每次重构都容易踩Buff 自身时间结束和被外部 Clean 同时发生。角色在 Buff 持续中死亡复活后属性没有恢复到正确状态。拥有 Buff 的敌人从场景中移除时Buff 容器没有释放可能造成泄漏。施加 Buff 的施法者在 Buff 持续中死亡Buff 是否需要消失。Buff 效果执行期间重复添加高层级 Buff会不会触发两次同样的即时治疗或护盾。这五类都不要只测一次最好每次调整 Buff 状态机后都回归测一遍。因为这些问题和数据状态顺序强相关改一次执行顺序可能就会把某个隐式依赖打碎。7. 本阶段打磨到什么程度算合格7.1 从功能角度验收这一期 Buff 系统做到底不是看写了多少个类和接口而是看能不能稳定表达常见战斗状态。我在自己的 RPG 框架里会拿几个典型效果做验收物理易伤和魔法易伤叠加。持续伤害每 2 秒触发一次同时目标身上有护盾。玩家施放加速 Buff 后又被减速速度最终按预期公式计算。一个 Buff 被移除后角色属性面板立即还原。控制效果触发时目标不能执行主动技能。如果这几个场景都能跑通并能通过一批测试用例反复回归说明基础框架是可用的。如果只是代码能编译却没有自己的状态机描述后续还是很容易失控。7.2 从扩展性角度验收判断一个 Buff 框架到底合不合格有一个非常简单的标准给你一个新的 Buff 需求时你要改几个文件如果你是“改一个 if”就能实现说明结构可能已经被局部逻辑腐蚀如果改一个配置数据建议通过处理通用配置覆盖通过新增 effect 对象覆盖更多场景这种效果更好。框架不是越复杂越好。好的框架应该让你 80% 的新增 Buff 都只需要填写配置数据或新增一个 effect 类而不是每次都要动伤害计算、移动逻辑和 UI 表现。我在实际使用中还发现一个点Buff 系统不要太早追求“支持一切”。只要它支持了伤害、治疗、护盾、属性修正、控制、周期触发这些核心效果并留有干净的事件接口后面加入“击退”“嘲讽”“变形”就只是扩展问题而不是推翻重来的问题。7.3 下一步要处理的事第 3 期做完 Buff 的数据和生命周期下一步我通常会补三块Buff 的 UI 表现层。图标挂载、倒计时刷新、层数显示、来源技能说明。配置导出和排错工作台。让策划可以在不写代码的情况下配置 Buff并在编辑器里预览剩余时间和触发节点。Buff 与网络同步的规则。如果要做联机服务器给客户端下发哪些 Buff 状态哪些表现本地预测都需要单独约束。这期先把框架本身的地基打牢后面再接表现和联机时会轻松很多。做战斗系统最忌讳的就是急着把效果铺满却让 Buff 状态变得无据可查。希望这篇梳理能帮你在自己的 RPG 框架里少踩一些 Buff 相关的坑。