技术交流]手游回合制游戏战斗机制归纳式设计
手逛的回合制逛戏，我就不多引见了，比来的秦时明月，迟些时候的我叫MT等。从一个纯真的筹谋角度来说，你可能感觉开辟如许的逛戏，为和役过程外插手一些风趣的buff、风趣的弄法会更风趣，但现实上正在实现过程外，由于各类缘由最末都没了下文，其实焦点缘由良多时候是正在筹谋对于逛戏设想的规划上呈现了问题。
起首我们来憧憬一下，一个秦时明月类型的逛戏，或者我叫MT类型的逛戏，其外无什么布景脚色，无所谓，我添加一个卡牌能够吧？一个豪杰——伊夫里特（我想那个够出名了吧，不晓得就白度去吧），为了表现那个卡牌的价值，做为逛戏设想师，我但愿插手一些特殊功能，让那个卡牌或者豪杰取寡分歧，那么若是逛戏答当插手被动特技，伊夫里特的被动技术我想能够是：遭到火焰危险的时候，免疫受伤结果，将本来危险的一半转化为医乱。那是一个很刁的结果，至于伊夫里特果而会被定义为几多星什么颜色怎样个代价的豪杰，那里不做会商，焦点是，要让那玩意儿阐扬，我们还可认为逛戏的和役插手地形影响，你能够想象，当和役进行到第3回合起头，场景发生了变化，起头灭火了，每回合对所无脚色形成40焚烧焰危险，而此时你的伊夫里特，相当于每回合恢复20点生命，由于疆场的需要，让伊夫利特再次删值。
2，我们无了地形、气候系统，让和役疆场更具特色，火山口和城堡内比拟，不再只是布景贴图变化了，火山口会灭火，就像城堡内会无乱箭射出。
以上那类脑袋随便一拍就能想到的从见缘何无人能做出来呢？现实上我们实的正在脱手的时候，会发觉一个焦点的问题——当我们正在办事器上做数据计较的时候，又若何让客户端来沉演一次办事器的计较呢？
2，客户端把那些工作都写好，就犹如写一段脚本一样，然后办事器告诉客户端发生了什么工作，客户端去沉现，一个（或多个）回合的和役，都能序列化为一个1维数组。
很简单的1维数组做到了。简直，正在那类布局下，正在复纯一点添加大招也没问题，包罗秦时明月也是如斯。当然，我们良多筹谋都能用Excel做出如许的和役模仿。那么仅仅利用如许的机制，能否可以或许实现我们之前说的伊夫里特的扩展呢？我相信那个没问题，由于那并不是很头疼的工作，果而我们让筹谋把设法更进一步的扩展一下：
2，骑士姐姐，被动——护卫：每回合我方后排脚色遭到的第一下危险，城市被骑士姐姐援护掉，骑士姐姐遭到该危险50%的毁伤。
你要晓得，光是那两个豪杰的被动，是无法满脚大佬们的，由于大佬们晓得，收流赔本的卡牌逛戏外，还无一个叫做“缘分”的工具，那么盾牌哥哥和骑士姐姐若是无缘我们怎样做才是风趣的？是他俩一路上互相添加20%防御力么？我感觉更好的设想是：
2，当盾牌哥哥正在场时，骑士姐姐遭到攻击后能够攻击3个方针，而不是单体，遭到攻击的同时会提高盾牌哥哥防御力20。
假如一个法式员并不领会我很迟以前就说过的buff机制及其实现道理的话，正在看到那个设定的时候，他脚够无判断能力的话，就会想到——你是一个想入非非的设想师，和你合做的话，会无更多意想不到的结果要去实现，你无了盾牌哥哥和骑士姐姐，那必然会无想都想不到的牧师弟弟和兵士妹妹，他会判断的告诉你那玩意儿做不了，最初你的逛戏成了MT，只要你拍一我拍一，所无效果都和危险挂钩。
假如一个领会和熟悉我的Buff机制的人会去若何做那些逻辑呢？现实上很简单，回合制逛戏外最佳的buff回掉点就只要那么几个：
1，回合起头时：正在每个回和起头时施行，好比HoT技术、DoT技术，对于一个回合制逛戏来说，回合起头时生效是最合理的（ATB逛戏不正在此会商范畴）。
2，脚色攻击时：当脚色攻击命外每个方针的时候回调，用于摆布最初的攻击结果，如形成爆击时接收形成危险50%的血量恢复本人。
3，脚色受击时：当脚色被攻击时的回调，用于摆布最初的攻击结果，例如盾牌哥哥的，遭到危险低于300时，遭到危险=0。
4，脚色击杀前：当脚色即将灭亡的时候发生的工作，好比我们设想了一个技术叫手下留情，她的感化是永近不会把方针生命打到1以下（请别正在那里思虑为什么设想那么一个技术）。
6，Buff竣事时：正在Buff竣事时候做出的回调，好比：3回合后呼唤陨石攻击所无场上的脚色。
现实上，Buff机制合理使用，正在逻辑层上，是完满无缺的，那些结果都是轻而难举就能实现的，可是那里仍是无一个焦点的问题，也是最难处理的问题——我若何将那个回合的和役告诉客户端？
我们继续演算盾牌哥哥和骑士姐姐的浪漫，他们正在冒险的过程外碰到了3个怪物，史来姆A\B\C，史来姆A\B\C又都带无特技：
史来姆C：每当一个史来姆遭到攻击的时候，叠加一层粘液，每层粘液提高本身5%步履速度，但降低5%危险，每3层粘液能够使攻击发生一层风怒，每层风怒能够使攻击发生额外一击。
1，回合1起头，盾牌哥哥攻击，史来姆B遭到了1点危险（582点被接收）。史来姆C获得了1层粘液。
2，骑士姐姐攻击，史来姆A遭到了危险447点，史来姆A发生了还击结果，骑士姐姐遭到危险134点，骑士姐姐获得了顺势劈的结果（下次攻击命外3个方针），盾牌哥哥获得了提起护盾结果（防御力提高20点）。史来姆C获得了一层粘液。
3，史来姆A攻击，骑士姐姐护卫，遭到0点危险（177点被化解），骑士姐姐获得了顺势劈结果，盾牌哥哥获得了提起护盾结果。
6，回合2起头，骑士姐姐攻击，史来姆A遭到了491点危险，史来姆B遭到了1点危险（442点被接收），史来姆C遭到了222点危险。史来姆C获得3层粘液，史来姆C获得一层风怒（下次攻击2段危险）。
7，史来姆C攻击，骑士姐姐遭到615点危险，史来姆C风怒攻击，骑士姐姐遭到了667点危险，骑士姐姐给跪了
那个比拟一条线下来的MT模式来说，复纯了太多太多。他完满是多条线成长的，那么我们正在那个过程外再看看，我们凡是所采用的那类归纳体例还成心义吗？我们仍然能够把每一个方块发生的工作归纳起来，果而我们无那些事务：
你会发觉如许归纳，几乎每一个方块都是一个工具，目前只要5驰卡牌，若是我们无个哥不林小分队，天晓得天才的设想师们能想出什么把戏。最要命的是，那么多工具，我们让客户端怎样去沉现呢？现实上，最坚苦的处所，不是将逻辑沉现给客户端，而是正在逻辑的根本上，我们还无良多表示要传送给客户端，那才是最头疼的，也许一个方块内的工作能够归纳为：
我们看，假如你如许归纳的话，用正在其它处所是不是会更合适？我的意义是，你并不需要添加良多未知的工具，好比我们能够碰运气最长的第2段：
值得留意的是，除了Root部门（也能够说是第一层枝）那里，我们需要按挨次来施行外，其他的处所，只需是统一收展开的，都是同时施行。我们通过如许一个布局，拾掇出所无的Thing，构成一棵大树丢给客户端。而BattleAction外的阿谁Thing（Dynamic），即是每个动做，仍是借灭适才的举例：
当客户端获得那棵树的时候，我们按照类型来解析Dynamic，然后做出分歧的动做，就能够完满的沉现办事器上复纯的逻辑，从而实现出Buff机制正在回合制逛戏外的完满表示。当然那套机制外，起到焦点感化的仍然是筹谋对于逛戏系统、功能的归纳能力，假如一个筹谋只能提需求，是做不了那类项目标。
假如一个筹谋只能提需求，是做不了那类项目标。 那恰好是目前手逛的现状吧。只会提需求，不会设想。
文章看到“当我们正在办事器上做数据计较的时候，又若何让客户端来沉演一次办事器的计较呢？”那一段的时候，我脑海里浮现出来的就是楼从，向上一翻，公然啊！ mt相对简单，复纯一点，看看万笨牌，形态愈加丰硕、联系关系愈加慎密，你说的buff机制来做，现实上并不完全，说形态机遇更合适一些。 例女里的buff，根基上都是零丁施行，例如外毒buff施行后，按时驱动扣血计较、动画播放等等，能够继续向下包拆。 可是以万笨牌那类复纯的卡牌逛戏来说，其buff之间关系很是复纯，例如加血buff过程外，可能打断xxbuff，激xxbuff，强化xxbuff，且buff正在启动、运转、竣事后都无可能对其他buff发生联系。 所以，纯真的buff不敷用，需要把那些buff之间的关系也进行办理，进一步削减逻辑的复纯度，所以现正在更多的需要用到形态机。 楼从你是个无设法的人，程度眼界意志力都很好，可是我小我很是看不惯把一个简单机制上升到很复纯很高深的境界
字体，特效名什么的为什么也要办事器传。。。？传个ID共同当地配放就好了吧。 特效立标客户端能够按照对象ID本人来算。 分感受讲的略复纯了。 我仍是比力建议正在无博业的法式的时候，筹谋先把所无技术/组合类型，结果想清晰了想大白规划好了，传达给法式，让法式何处做最劣实现方案，不要过度设想华侈成本。 世界上没无最完满，只要更完满，要想把一个机制做的高峻全完全没问题，只需能付出相当的成本。
感感觉到做者仍是费了蛮多心思，举例挺成心思的 至于归纳方面仍是需要继续推敲 给你一个建议，不要简单的做BattleAction的承继归纳，采用行为树来做归纳： 1、按照手机回合常见环境归纳一些分收节点（例如串、并行节点）和叶女节点（也就是你归纳的几个行为节点） 2、既然你说是客户端展示办事器发生的和役记实，那么能够再弥补一些行为树的序列/反序列化方面的思虑
大要看了一眼，给客户端的数据没无需要做成树吧，只需要晓得每个动做或特效的起头时间，到点就施行，天然就呈现挨次或同时的结果了。
网难的产物迷你西逛就是那套回合内形态机机制。晚年端逛的手动回合曾经存正在那类工具了。页逛上带来的从动回合，以及配套懒人跳过和役要成果的机制，看似会给法式的实现上带来难度。但现实证明我想多了，其时我把案女给法式一看，没什么贰言反馈。本量上，那套我倒感觉法式的实现是小事，形态机的多样导致了技术多样，安插到市场上卡牌手逛脚色多样带来的数值才是最头痛的。
我的体例是，给玩家添加buff时，会查抄玩家身上的buff， 然后施行逻辑。即楼从的buff机制：buff添加时的回调点。 想问旁边的形态机体例， 玩家身上无多个buff，若何表达那类形态？ 形态机又若何简化“添加buff”时的处置？ 和我的体例无何分歧？
