buff系统 游戏中

buff系统 游戏中

前言

Buff模块可以说是技能中最核心又最复杂的系统了。一个优秀的Buff系统能够让策划的创意得到最大限度的发挥，大幅增强游戏的战斗深度和可玩性，并且同时也能让开发者轻易的扩展维护，支持更多的效果和功能。本章将为你详细讲述一个强大的Buff系统是如何实现的。(长文预警)

正文

第一节：Buff定义

首先我们将Buff系统分为三个层次，具体继承关系如下：

Buff：所有Buff的基类，包含各类成员函数和基本接口。

Modifier：继承于Buff，代表这个Buff是一个修改器，它可以用来修改当前目标的各种属性，状态等等。抽象Modifier这个类的目的是出于性能优化的考虑。因为当Buff修改角的属性或者状态时，会导致重新计算角的动态属性， 而在游戏中我们很多的Buff并不需要修改角的属性状态，仅仅用来提供一段逻辑。那么如果它是一个Buff不是Modifier，就不需要重新计算角的动态属性。

MotionModifier：继承于Modifier，代表此类Buff提供修改玩家运动效果的功能。因为牵涉到与运动组件的交互，所以抽象出一个新的类。

Buff类层次结构划分了之后，那么Buff需要包含那些成员数据呢？

我们提供BuffTypeId(Buff类型Id)， Caster(Buff施加者)，Parent(Buff当前挂载的目标), Ability(Buff由哪个技能创建)，BuffLayer(层数), BuffLevel(等级)BuffDuration(时长)，BuffTag，BuffImmuneTag(免疫BuffTag)以及Context(Buff创建时的一些相关上下文数据)等等。

在这里，我将说明一下Caster，Ability以及Context这三个成员，这也可能是我们Buff系统中一些独特的点。

Caster代表Buff的施加者，它有可能为空，也有可能不为空，视具体构造时是否传Caster参数而定。但是Buff有一个配置项boCaster(是否强制设置Caster为空)。如果boCaster = true。则Buff的Caster一定为空。

为什么要有一个boCaster设置呢？那是因为我们的Caster不仅仅是一个成员项，它还关系到Buff合并问题。如果存在两个TypeId类型相同的Buff时候，当他们的Caster相同才可以走合并流程(Buff层数增加)，如果Caster不同，则不能合并。当策划有一些玩法需求可以多人给BOSS叠Buff时就可以配置Buff的boCaster=true，这样就不需要开发者在写代码添加Buff的时候小心翼翼的设置Caster参数为空了。另外还有几种情况也需要设置boCaster=true，比如存在一个熔岩地图，或者冰雪地图，玩家每秒掉多少血量，这个时候也可以配置boCaster=true。再比如说一些活动buff，如双倍经验buff，红名惩罚buff，都可以由策划配置boCaster=true。类似于双倍经验，还有红名Buff这种所有需要存盘的Buff，我们都需要设置boCaster=true。也许会有人有疑问，这样能满足需求吗？完全可以，我会在最后的示例部分举出一个例子来解答这个疑问。

Ability代表Buff是由哪个技能创建，它有可能为空，也有可能不为空，视具体构造时是否传Ability参数而定。通过Ability这个成员类型，我们就将Buff与技能联系起来了，我们能在Buff中取得技能的各种数据，通过获取技能的数据，然后由Buff来实现各种各样的技能效果。

BuffTag，BuffImmuneTag由策划配置(基于标记位)，标注这个Buff属于那些种类以及免疫哪些种类。策划可以定义一些Tag如下：Metal = 1 << 1 (金系)

Wood = 1 << 2(木系)

Water = 1 << (水系)

Fire = 1 << 4(火系)

Earth = 1 << 5(土系)

当策划配置BuffTag为Meta | Wood时，则代表这个Buff归属为金系和木系Buff。如果策划配置BuffImmuneTag为Wood | Fire时，则代表这个Buff可以免疫所有木系和火系Buff。由于Tag的实际定义由策划控制，策划可以根据他们的需求组合出各种各样的免疫效果。我将在后面的示例里面描述一些基于Tag和ImmuneTag用法的例子来让读者体会Tag和ImmuneTag者两个概念抽象的简洁之美。

Context代表Buff创建时候的一些上下文数据，它是一个不确定的项，通过外部传入各种自定义的数据，然后在Buff逻辑中使用这些自定义数据。

第二节：Buff执行流程

在Buff从创建到销毁的过程中，我们划分为如下几个阶段：Buff创建前检查当前Buff是否可创建。一般主要是检测目标身上是否存在免疫该Buff的相关Buff，如果被免疫则不会创建该Buff。

Buff在实例化之后，生效之前(还未加入到Buff容器中)时会抛出一个OnBuffAwake事件。如果存在某种Buff的效果是：受到负面效果时，驱散当前所有负面效果，并给自己加一个护盾。那么这个时候就需要监听BuffAwake事件了，此时会给自己加护盾，并且把所有负面Buff驱散。这意味着一个Buff可能还未生效之前即销毁了(小心Buff的生命周期)。

当Buff生效时(加入到Buff容器后)，我们提供给策划一个抽象接口OnBuffStart，由策划配置具体效果。

当Buff添加时存在相同类型且Caster相等的时候，Buff执行刷新流程(更新Buff层数，等级，持续时间等数据)。我们提供给策划一个抽象接口OnBuffRefresh，由策划配置具体效果。

当Buff销毁前(还未从Buff容器中移除)，我们提供给策划一个抽象接口OnBuffRemove，由策划配置具体效果。

当Buff销毁后(已从Buff容器中移除)，我们提供给策划一个抽象接口OnBuffDestroy，由策划配置具体效果。

Buff还可以创建定时器，以触发间隔持续效果。通过策划配置时调用StartIntervalThink操作，提供OnIntervalThink抽象接口供策划配置具体效果。

Buff还可以通过请求改变运动来触发相关效果。通过策划配置时调用ApplyMotion操作，提供OnMotionUpdate和OnMotionInterrupt接口供策划配置具体效果。

Buff由于其有着生命周期可控，低耦合(通过监听事件修改逻辑)，高内聚、易于扩展的特性，因此通过使用Buff来管理逻辑的话，不仅方便处理各种复杂的行为，同时还能有效的减少开发者的维护难度。

例如延迟触发伤害是游戏中非常常见的需求，在一些开发者的设计中就是直接给角挂个定时器触发伤害。简单的游戏里这样做没什么大问题，但是如果技能逻辑稍微复杂点，这样就会带来很多问题。例如某天策划提出需求，如果受到控制效果时需要取消该延迟伤害。此时你怎么办，直接干掉timer？结果策划过了两天又提出了个新的需求，还是受到控制效果时，需要这个延迟伤害立即触发，你又怎么办？再又比如说，当角受到伤害超过1000点时，这个延迟伤害立即触发，你又该怎么做？

这里就体现出Buff的方便之处了，我们可以直接添加一个持续时间为秒的Buff。Buff销毁时触发伤害。如果需求变更为受到控制时取消伤害，那么我们就在Buff中检查当前是否包含有Tag为Control的Buff。如果有，则设置Buff.bTriggerDamage=false，同时自我销毁。然后在BuffDestroy触发的时候检查是否触发伤害，如果bTriggerDamage为false则不触发伤害。同理，当需求为Buff监听伤害超过1000点伤害立即触发时，我们只需要通过Buff监听OnTakeDamage事件，检查当前受到的伤害值是否大于1000点，如果是则销毁Buff，此时立即触发BuffDestroy并执行伤害效果。

从上面的例子我们可以看出整个控制逻辑都是在Buff内部完成的，不需要各种手动开启/取消定时器。只需要Buff扩展下逻辑检查即可，具有非常好的扩展性和高内聚性。

第三节：Buff修改状态(ModifyState)

Buff可以通过修改状态去影响角行为逻辑。以下列举一些最常见的状态：Stun(眩晕状态——目标不再响应任何操控)

Root(缠绕，又称定身——目标不响应移动请求，但是可以执行某些操作，如施放某些技能)

Silence (沉默——目标禁止施放技能)

Invincible (无敌——几乎不受到所有的伤害和效果影响)

Invisible (隐身——不可被其他人看见)

这些状态是高度凝练的精华，抽象到极致的代表。非常多的游戏效果实际上都是这几种状态运动动画的组合。这里很多开发者都会有一个设计误区就是把Buff的状态跟运动和动画耦合在一块，比如：眩晕状态一定就是播个眩晕动画，然后击退状态就是击退位移击退动画。这样最后导致的问题就是状态膨胀，而且各种逻辑耦合，Bug频出，最后维护成本大大提高。

以Stun为例，很多人第一眼看过去就觉得它是个Debuff，是个敌人给我方加的控制Buff。实际上并非如此，Stun可以用到的地方非常多。例如有个技能是野蛮冲撞，释放后2秒内向前移动10米并将敌人推开。那这个Buff的实现就是技能Spell的时候给角加个Buff，这个Buff会有个Stun状态同时带位移突进效果。挂上这个Buff后，技能施放后角2秒内就不会响应角按键移动和释放其他技能的请求了，同时往前突进的效果由Buff控制，将来处理各种位移打断效果也很方便。 再比如说有个技能叫寒冰屏障：你被一道寒冰屏障所笼罩，在十秒内不会受到任何物理和法术伤害，但这期间无法移动、攻击或施法。那这个技能的实现也很简单，就是一个十秒的Buff同时添加了眩晕和无敌这两个状态，如果还需要每秒回血，则StartIntervalThink(interval)，然后OnIntervalThink的时候Heal当前角即可。

除了各类战斗效果之外，我们的Buff甚至可以扩展到一些其他场景。比如说打BOSS前有个播过场动画的需求，此时策划希望隐藏Boss和玩家的血条和姓名。那么此时我们完全可以做个Buff，这个Buff扩展个状态HideHpBar，当有这个状态时即隐藏血条和名字就行了。而且我们还可以让这个Buff加上无敌状态，毕竟播过场动画的时候我们不希望玩家或者BOSS真的受到什么伤害。

总而言之，Buff状态除了上面提到几种高度凝练抽象的状态外，我们还可以根据具体游戏的需求去扩展各种特殊状态，以满足策划的需求，同时方便开发者管理逻辑。

第四节：Buff修改属性(ModifyAttribute)

在游戏中Buff的添加与移除是一个频繁的过程。而玩家的属性来源有很多，如等级，装备，成就，任务，时装等等各种各样的来源。相比于Buff，这些模块修改属性的频率要远低于Buff，所以我们一般将玩家的属性划分为两层，第一层时Core(核心层)，第二层是External(外部层)。Core层是玩家各个其他模块的属性总和，而External层则是Buff修改属性的总和。两者相加既为玩家的实时属性。

第五节：Buff修改运动(ModifyMotion)

现在的MMO中为了增加动作表现力，经常会有很多位移效果，如突进，翻滚，千斤坠，击退，击飞，拖拽，吸引等等。那么这些效果该如何实现呢？而且有时候会遇到各种复杂的运动打断效果，比如击飞时不能被击退，击飞过程又能被冰冻效果定住，然后又有破冰技能击退冰冻物体并解除冰冻效果。面对这些复杂的情况，我们该如何设计呢？

在我们的系统中，运动都是统一通过MovementComponent来管理。因此通过使用MotionModifier来与MovementComponent交互。MovementComponent中有一个CustomMotion，用来具体实现各种运动位移。具体运动实现相关细节我们将在后面的运动章节讲述。

在MotionModifier中，我们会提供一个接口ApplyMotion(motionTypeId，priority, forceInterrupt)来向运动组件请求运动效果。同时通过设置回调UpdateBeforeMovement和UpdateAfterMovement来触发运动前和运动后的Buff效果。下面我们初步介绍下ApplyMotion函数的三个参数：motionTypeId：运动类型id，配置项。包含运动位移参数及相关数据。

priority：运动优先级，每个运动都有优先级，低优先级不能打断高优先级。

forceInterrrupt：是否忽略优先级，强制打断当前的Motion。

通过这三个参数，我们就能实现各类打断需求了。

比如说击退的运动优先级是100，击飞的运动优先级是200。那么在击飞过程中，施加击退Buff调用ApplyMotion的时候会返回false，这时可以销毁掉这个击退Buff，即击飞时无法击退。如果击飞时被冰冻，且冻在半空中停止不动，那么我们就需要设计一个静止Buff：运动优先级是00，作用效果是速度设置为0，不受重力影响，同时修改Stun状态并挂载冰冻特效。当破冰技消除冰冻效果时，则设置破冰Buff的位移效果为击退，设置运动优先级为100，forceInterrupt为true。此时ApplyMotion强制打断运动，冰冻Buff会触发OnMotionInterrupt回调，在此接口中冰冻Buff自我销毁即可。

Buff修改运动仅代表修改运动轨迹。比如说击退仅仅只是以直线移动一段距离。而击飞是以曲线移动一段距离。同理轻功的翻滚，突刺其实都与击退是相同的运动轨迹。他们都是在一定的时间内以直线到达目标地点，且都设置Stun状态。它们不一样的地方其实仅仅只是动画层的表现的不同。(可能策划还会设置不同的Tag和ImmuneTag标记下)

我们要牢牢记住，玩家看起来各种花哨的轻功击退击飞等位移效果实际上是StateMotionAnimation的组合。掌握住了这一点，我们就可以通过简单的组合实现各种丰富的效果了，而不会被各种花哨的效果所迷惑，以为他们都是不一样的效果，导致最后设计出无比庞杂且难以维护的系统了。

第六节：Buff监听事件

Buff可以通过监听各类事件，执行特定逻辑或者修改事件数据来实现各种效果。

最常见的事件监听一般有：OnAbilityExecuted，监听某个主动技能执行成功。常用于被动技能Buff，比如说角施法时有10%概率获得0%的攻速提升。那么我们通常是Buff-A监听OnAbilityExcuted事件，然后10%概率添加Buff-B。Buff-B的作用是修改玩家属性，增加0%攻速。

OnBeforeGiveDamage，OnAfterGiveDamage监听我方给目标造成伤害时触发。比如说对目标造成的伤害有10%概率无法被闪避，那么这个效果我们就可以通过监听OnBeforeGiveDamage的流程来实现。当执行伤害流程时，在计算伤害前我们抛出一个事件event。event里面有当前伤害数据。Buff在调用OnBeforeGiveDamage(event)时，修改event.Damage.DamageFlag |= DamageFlag_otMiss，标注该伤害无法被闪避就行了。又或者如果有一个需求是给目标造成伤害后有10%几率触发DOT伤害效果，那么我们在OnAfterGiveDamage的时候取出event.Target并给这个目标加个DOT类Buff即可。

OnBeforeTakeDamage，OnAfterTakeDamage监听我方受到伤害时触发。如护盾类Buff通常在OnBeforeTakeDamage的时候修改伤害数据。又或者有某些Buff在受到伤害后可以触发各类效果就可以通过监听OnAfterTakeDamage事件来触发指定逻辑。

OnBeforeDead，OnAfterDead监听我方死亡时触发。如免疫致死效果可以通过监听OnBeforeDead事件修改角当前的Hp>0，从而让角提前退出死亡流程以避免死亡。死亡后触发额外效果，如爆炸或者召唤其他生物都可以通过监听OnAfterDead事件来执行。

OnKill事件，监听我方击杀目标时触发。如当击杀目标后获得效果回复即可通过监听到Kill事件时给自己加一个HOT的Buff来实现。

开发者可以通过扩展各类事件列表，让Buff通过监听对应事件就能执行任意逻辑。不需要与任何模块耦合，只需要抛出事件，监听事件，执行逻辑即可获得Buff功能上的扩展。

总结

以上我们通过六个小节讲述了Buff系统主要模块的实现方法。通过这样的设计，我们让Buff的深度和扩展性都能够得到了极大的提升，几乎能实现各种各样的效果。足以让策划的创意得到最大限度的发挥。

示例

为了让读者便于直观理解，我会提出一些具体实现的例子以供参考：问：Buff互斥效果也很常见，怎么做？

答：BuffTag和BuffImmuneTag可轻松实现。比如说火系Buff和水系Buff互斥。无论策划的需求是存在水系Buff的时候无法添加火系Buff，还是存在水系Buff的时候添加火系Buff会驱散水系Buff都可以实现。第一种情况最简单，水系Buff配置Tag 为Water的时候配置ImmuneTag为Fire。此时存在水系Buff的时候即可免疫火系Buff了。第二中情况也好办。配置BuffTag为Water。当OnBuffStart的时候调用驱散接口DispelByTag(Water)，驱散掉所有火系Tag相关Buff即可。

问：霸体效果怎么实现，而且假如说存在破霸体效果又怎么实现，而且Boss的霸体效果完全不受影响又怎么实现？万一还存在特殊效果可以让Boss受到控制怎么办？

答：我们可以定义两个BuffTag：WeakControl(弱控制)和StrongControl(强控制)，普通霸体效果通过Buff配置ImmuneTag：WeakControl即可免疫控制效果。如果是破霸体效果，我们给这个Buff的Tag标记StrongControl就行，同时Boss的Buff配置ImmuneTag为WeakControl | StrongControl(免疫弱控制和强控制)就满足需求了。如果存在某个特殊的效果能让Boss受到控制效果的话，那这个Buff的Tag不要标记WeakControl和StrongControl就行了，这样它就无法被免疫掉了。看起来复杂的霸体破霸体效果实际实现就这么简单，就这么清晰，不需要引入任何新的系统。

问：Buff存盘那块如何处理跟施法者相关的属性数据？如施法者可以给目标添加一个强力的毒Buff，具体伤害数值有施法者属性决定，离线后依旧生效，直到Buff时间结束才移除。

答：这块我们的处理依旧很简单，Buff依然设置boCaster=true。但是在Buff创建的Context里面我们设置Context.DamageValue为根据施法者属性计算出来的伤害数值。然后Buff持续造成伤害的时候直接取Context.DamageValue即可。至于说想要玩家离线再上线，Caster离线再上线后，毒的伤害数值还能实时修改的话，这样的需求是不存在的，如果一定要做，当然也能做，只是麻烦一点而且也没有必要。这样的需求一般仅仅存在测试的大脑中，策划是不会有这样的玩法需求了。

问：常见的基于指定地点延迟触发的AOE效果怎么实现？当技能施法成功后就延迟触发，不会被打断AOE效果。(如果能被打断，我们可以用引导类技能轻松实现)

答：我们将技能标记为可指定目标地点释放，当技能Spell的时候我们先给自己加一个Buff，这个Buff仅仅用于延迟效果(当然可以有更多的可能性，如监听到某种事件立即结束并触发AOE效果)，当Buff持续时间到了的时候在OnBuffDestroy的时候创建AOE效果Buff。这个AOE Buff会调用StartIntervalThink函数，在OnIntervalThink的时候通过Buff:GetAbility():GetCastPosition()为基准位置检查周围的敌方单位是否在AOE半径内，如果是，则施加作用效果。

更多文章：kasan：如何实现一个强大的MMO技能系统——子弹​zhuanlan.zhihukasan：如何实现一个强大的MMO技能系统——序章​zhuanlan.zhihu