游戏buff系统设计

少于 1 分钟读完

内部运算 1、是否包含技能效果?(提高/降低 攻击 命中 闪避 移动速度 群体伤害 替换技能ID 等 ) 2、是否包含阶段效果?(BUFF分为多个阶段,不同的阶段有不同的效果,比如影之哀伤) 3、是否包含计时器?(持续时长计算、叠加时长计算 总之所有关于持续性时间的问题 都丢这里) 4、是否包含计数器?(用来计算阶段、剩余生效次数、比如影之哀伤 LOL电刀) 5、是否具备分类规则?(魔法效果 诅咒效果 中毒效果 用于进行归类 方便程序进行的 驱散筛选判断) 6、是否可以被驱散? (魔法效果只能用祛除魔法解除 中毒效果只能用解药祛除) 7、是否具备优先级?(附加优先级,低等级BUFF会被高等级BUFF替换,低等级BUFF无法附加给高等级怪) 8、是否保留母体信息?(比如传染性的DEBUFF,感染者传播一次,母体会获得额外巴拉巴拉。。。多个项) 9、是否共享同步规则?(比如多个角色共享一个BUFF状态,一个人的BUFF被祛除则其他人也被祛除) 10、以上功能可以进行再补充,没有需求则可以逐个剔除。

外部表现 1、是否显示BUFF图标?(传奇里道士的BUFF是不显示图标的) 2、是否不同阶段表现不同的图标? 3、是否显示计时器? 4、是否显示计数器? 5、是否显示BUFF文字说明?(对BUFF类型、效果的描述) 6、是否改变角色外形?(DNF里的冰冻、WOW里的变形) 7、以上表现功能可以进行再补充,同上。

首先我想说的是,这是一套机制,并不是单独的一个系统,所谓机制就是一种从逻辑思想到代码实现的小窍门的组合,只有当你把它运用到一个实际项目中去了,它才能帮助你建立一个系统。我不敢说它是最好的,但这套东西帮我完成了一个又一个项目的制作,我觉得现在可以简单的拿出来和大家分享下思维。事实上这也并不是什么很玄乎的东西,我的Buff的机制更像是Flash的Dispatch机制。更简单的说,你可以把它理解为一种回调机制,在必要的时候进行逻辑回调。我想这一句话应该是可以概括整个机制的工作原理了。

  举个简单的例子来说明,作为一个设计师,在设计系统的同时应当思考好这个游戏的系统中的各个回调点,而他们也正是Buff系统发挥能量的地方,Buff回调点有哪些(当然我可能会把它歪到WoW,毕竟这最早的设计灵感来自WOW)?我简单列一些:

1,BuffOccur

  我认为这是最核心的回调点之一,应该说你把这套机制运用在任何游戏中他都必须由这个时间点,就是当任何情况Buff被添加到一个角色身上的时候(可能来自技能、可能来自道具、可能来自GM命令,等等等等),往往他最杰出的作用就是改变角色的属性、或者是被控制状态。之所以说这是机制是思维方式,因为它并不关心你的游戏有哪些状态或者属性,但是这里有一点比较容易搞混的就是初级策划往往会认为昏迷就是一个Buff(debuff),可是事实上昏迷是一种组合状态,他在LoL里面的形态是剥夺移动能力、剥夺攻击能力、剥夺商店使用能力的组合(我不知道是不是真的,但是我在做起凡三国争霸2的时候是这么做的,这套机制最早运用的游戏就是那个,虽然我离开起凡后这套系统的代码被删除了)。因此在BuffOccur这个回调点,有着很多的事情会需要做,那么同样的,BuffRemoved回调点也就有了同样的职责。

2,BuffOnTick

  也就是通常我们最常见的,每3秒造成伤害、治疗;或者我们可以做每3秒制造一个AOE,甚至每3秒为自己添加一个护盾等等,他的核心在于没一定时间触发一次,但请你注意不是所有的游戏都适用这个回调点。

3,BuffRemoved

  在移除Buff的时候,重新计算属性等肯定是需要在这个时间点工作一次的,那么事实上还有很多的效果也可以在这个时间点被调用,典型的是痛苦无常和生命绽放(都来自WOW),痛苦无常是当驱散的时候对驱散者造成伤害并且沉默,因此我们需要传入导致buff终结的人(可能是null)和BuffRemove的时候剩余时间,由此判断是否真的完成了,那么剩余时间越多造成伤害越高也就成了可能的设计;而生命绽放则更加简单,在Removed时候给持有者进行治疗就可以了。

4,BuffBeHurt

  在受到攻击的时候触发,大多盾类技能由此而生,这个回调点应当Return一个Int或者Float,用于传递给下一环,已获得新的伤害,而当所有的执行完毕之后,造成的最终伤害就会是这个数字,那么把受到的伤害变成治疗是多么简单的事情?可是否应该有,还得看游戏的Patterns。

5,BuffOnHit

  在攻击的时候产生,虽说字面上是OnHit,你仍然可以把isHit像isCrit一样传给回调函数,战士的压制(老版本)在攻击被闪躲时可以发动,更早的猎人在闪避攻击后可以提高招架?其实都是这个时间点来做的。

6,BuffBeforeKilled

  很多时候BuffBeHurt并不能完成一些设计,比如说必定能杀死目标的伤害被完全吸收(贼爷爷的假死),这时候我们要确定这个角色原本应该死了,因此就需要设定出这样一个回调点。

7,BuffAfterKilled

  当杀死一个角色的时候,恢复自身X%的HP,这时候你就需要这个回调点,精确的在角色死亡后发生。

  机制始终是机制,或者说是思维方式,他真正的运行还是取决于游戏本身,回调点我只是随便举个例子而已,事实上根据游戏不同,完全可以增加或者删除回调点,比如一个MT卡牌游戏他就完全不需要onTick这样的回调点,但他可以有BeforeMove(角色行动前)等回调点,这取决于游戏本身机制。同样的每一个视觉特效都可以在每一个回调点去播放,你可以设计好这样的规则不是吗?

  接下来,我们就在这个机制的基础上分析一下LoL的一些技能,我印象最深的那些,我已经很久不玩LoL了:

  1,蛮王的6秒真男人,一个Buff,在BeforeKilled时候调用,Return1作为最后设定的HP,并被写在回调代码的最后。

  2,盲僧、瑞文的连续技能,事实上这也是你肉眼看不到的Buff(机制正是如此奇妙,未必被直接运用,正如我所说,他是一种思路),当有Buff的时候技能A变成技能B,移除后恢复,OnSkillCast的回调点(往往技能施展中会需要回调点,因此回调点还是根据游戏具体分析出来的)。

  3,火男的昏迷,火男的法术会为目标添加一个Buff,而法术在OnHit的时候会检查如果存在这个Buff则执行XX效果导致昏迷,否则普通效果。

  4,安妮的昏迷,你如果有仔细看了2并思考了,这不是问题。

  5,大嘴的自爆,在角色死亡的时候产生免疫性Buff,Buff结束时产生AOE,如果你这么思考,这会简单很多。

  这套机制在实际工作中,我们需要如何去分工呢?事实上已经很清晰了:

  策划:需要设计出所有的回调点,事实上策划如果完全不了解程序的效率等问题是无法设计好的,最好还能大概了解所谓回调机制,因为除了回调点意外,你还需要设计出回调时候传的参数,以及返回给程序的参数及其工作顺序,除此之外一些基础的表象也需要去制作,如buff的名称,那么在做表的时候会有2种风格,在起凡的时候我可以不用太关心,因为每个人都会用Lua写回调函数,但之后的项目中,我是用了我常推荐的Tag机制,比如策划填写一个Buff效果些daze_60之类的我就可以把它分析为60%几率昏迷目标等。在设计这些东西的时候为了更有效地避免夸夸其谈,策划对于实现的了解还是非常重要的,而事实上我们这里已经是策划动手写逻辑代码了,这问题就相对好办些。策划除此之外还应该归纳出特效播放点、数据同步时间点等等和游戏核心机制相结合的东西。这世界上也有很多好的创意,但你必需知道机制士兵不能帮你实现的,更重要的是你要知道自己想做什么和怎么去做,因此设计buff的时候切勿滥用机制,机制用的不好反而弄巧成拙,而合理的拆分Buff的效果也是一个策划的价值所在。

  程序:程序的工作则是优化好回调点和策划可能滥用到家的循环,这是非常头疼的事情,因此很可能需要更好的机制替他们实现一些该死的逻辑优化,可是这并不是最重要的,最主要的工作还是完成一些底层接口功能,比如在某个绑点上播放某个特效之类的,这些是策划都是即使会写逻辑代码也写不好的东西,也正是程序员强势所在(因此我并不认为游戏程序员非得精通游戏,但必须了解一二,才能大概思考一些优化、渲染的逻辑)。

  美术:视觉特效肯定少不了你的,搞不好还得弄动作,音乐跑的了音效跑不了,做吧,策划会整理出大量的需求列表的,如果上面说做那就做了。

  在你了解了Buff的工作机制之后,你才有资格进一步的谈创意,不然都是胡扯蛋,你都不知道怎么去做,你怎么去创造呢?那么假如让我把吕布加入到LoL中,我会给他设计什么样的被动技能呢?就让我们一起YY下(确切的说知道实现方式的YY才是有价值的):

  被动:人中吕布,任何普通攻击(我想LoL的普通攻击应该也是有标记的,起凡当时是skillId==28近战、30远程,事实上我不太赞成这样的skillId特殊标记法)的时候会为吕布添加1层“人中吕布”(另外一个buff) “人中吕布”到15层、25层、35层、45层、50层时更换视觉特效(BuffOccur BuffRemoved)。人中吕的特性是15层开始普通攻击有几率造成双倍伤害,25层开始受到伤害有几率减少20%,35层开始释放技能获得导致目标昏迷2秒,45层开始释放技能恢复自身25%生命,50层时技能对20%生命以下目标一击必杀,死亡是损失一半层数(beKilled)。这么牛逼的效果?是啊,中国人当然应该牛逼了。慢来,才YY开始,这算设计好了?早呢,为了这些效果,你需要在“人中吕布”Occur Remove中去根据当前层数添加删除Buff:

  人中吕布_双倍伤害,普通攻击OnHit投随机数决定是否伤害x2。

  人中吕布_几率免伤,BeHurt时候投随机数决定是否降低一定的伤害。

  人中吕布_强力攻击,Onhit判断不是普通攻击则给目标一个2秒的Buff1层。

  强力攻击_昏迷,Occur携带者昏迷属性为true,Remove就不需要设置false了,因为他可能还有别的buff让他昏迷,但是Remove和Occur的时候都要重新计算一次属性状态就对了。说到这里,这个Buff互相堆叠又是很讨厌的逻辑,2个SS可以给同一个目标释放腐蚀术,产生2个,但是自己却只能对1个目标上1个,等等等等。

  人中吕布_技能恢复,OnCast的时候(事实上LoL应该只有OnHit,这也可以),判断不是普通攻击则回复生命。

  人中吕布_斩杀,OnHit判断目标生命比,决定是否造成999999伤害。

其实如你楼下一层说的,这个机制的最大优势在于,它可以实现很多难以预料的功能,如果策划足够给力的话。 实际的经验是,一个项目中产生很多沟通问题的本质是,策划并不能归纳出自己想要什么,而程序员更不可能提早知道你想做什么,预判是一道鸿沟,无法跨越,因为我们都不是先知,而年轻的策划很多神奇的想法更是无法预判的,但如果放弃这些想法中的一些精化会非常可惜。因此在项目开发中尽可能去做一些能够更有“包容性”的设计,是非常重要的事情,这解决了后期的很多问题。 你可以发现我提倡的很多机制或者想法都具有“包容性”或者说“预判性”,包括Tag机制本身,很多年轻的策划或者程序并不能理解为什么明明我们可以用id数字分段做的事情非要想的如此复杂,但事实是当你需要把你的分段规则详细的说给后来的人知道的时候,你甚至需要花费几周时间,还未必能说清楚,更糟糕的是,也许你自己都忘了当初的约定。 Buff机制也是如此,它的优势在于程序员、包括策划自己并不需要一开始就知道我要具体做什么,但是我们可以先把框架搭起来或者说可以开始动手制作项目了,而后期灵感突发的时候,并不是非得“放到下一个项目”的。 而技能机制,在我看来反而只是一个辅助的体系,因为它只是一套简单的流程,作为一个入行的新人都应该轻松的完成他的开发,但是很多不太好的做法却是把技能的效果复杂化了,以至于程序员被误导,后期很难对技能维护。因此技能的效果,事实上就是Hp_Dmg(这么多年了我都用这个函数来造成伤害,因为名字很有趣),CreateBuffObj,CreateAoEObj,就是这么简单,一个技能的效果可以同时调用多条这样的功能,但只限于这样的功能。至于花哨的东西,就让Buff系统去完成。 因此这里还说了一个重点,对于策划来说,研发最大的技巧就是“拆”,如何把你的想法拆成最基础的元素,这样大家在实现的时候就不会有很多不必要的麻烦,在之后的debug中也会方便很多——比如我说的昏迷插法。一个优秀的程序员(至少我不是)他/她一定是把心思放在读书上,至少在学习计算机编程的时候他/她们非常棒,这也导致了他们不太可能像我们策划一样了解游戏,因此不应该把一些“难以理解”的东西拿来去塞给程序员做(事实上难以理解本身是因为它有太多的“专业名词”和超乎自然的地方,这也是游戏魅力所在),你也许没见过把“沉默”做成了“禁言”功能的程序员,他认为法师释放了一个沉默法术后,对方玩家就不能发送聊天内容了,因为被“沉默”了。 降低研发成本,从设计师角度来说主要还是沟通成本,现在已经成为了很多公司必须面对的课题了,明明一个简单到10小时能完成的逻辑,在很多公司居然能花费好几个人用好几十天去做,并且没能完成(因为策划总是在添加和改变想法,而程序员却陪太子读书了)。 “猴子”这个称呼并不适合一个200多斤的人img,龙与地下城——欧美人眼中最强的生物和它的巢穴,都是字母D开头中间用and连接,它骨子里是一套分析世界的数学模型,骰子实现了世界上很多所谓运气的东西;猴与花果山,它应该是中国人的DND,猴象征着欧美人眼中的中国人,也是孙悟空的表现,花果山则是孙悟空的住所,Monkey and Mountain,前后2个M,就是巧妙的地方,15年前我想做一套中国人的DnD,但至今没法实现,很多原因导致我们在娱乐方面缺少类似骰子这样的基础文化。

相关链接

  • https://zhuanlan.zhihu.com/p/150812545

分类:

更新时间:

留下评论