技能和BUFF数据编辑架构

storm1986

游戏中的技能和BUFF（状态），是实现游戏数据控制的最重要的两个对象。技能：是瞬时改变对象某些属性，或是给对象加一个或多个BUFF，或者是二者的结合。BUFF：是持续控制对象某些属性的变化。 技能和BUFF结合设计，就能对数据全面实时控制。这是基于固定技术的策划设计模式，而且也是平衡游戏的基础。







相关主题：
武侠游戏技能架构图：http://bbs.gameres.com/thread_292664.html
游戏过程设计相关事物联系图：http://bbs.gameres.com/forum.php?mod=viewthread&tid=292654

卡特铁角

对于技能比较简单的游戏，定义技能表格结构并非难事。

对于技能多样性较高的竞技游戏……用脚本吧

自打负责过一个伪fps玩法的mmorpg项目技能系统的设计，只要技能系统的多样性要求接近甚至超过WOW，我就一定坚持用脚本来做技能——我用脚本一个一个写技能更有效率，维护起来也更为方便。要把差别那么大的多种技能归纳到一套处理逻辑里面，在设计上困难不说，在运行效率上也是极不划算的——你需要大量逻辑判断来确定当前的技能是属于什么类型，应当如何触发，当前的状态会导致该技能产生什么样的效果……

Mr_I

可以规定一套核心流程，用表实现。
然后在逻辑流程的各阶段插入脚本接口，来实现多样性。
对特定技能来说，是否在某个阶段调用脚本是可选的。
这样可以在生产力和多样性之间达到某种平衡。

卡特铁角

Mr_I 发表于 2014-10-15 10:06
可以规定一套核心流程，用表实现。
然后在逻辑流程的各阶段插入脚本接口，来实现多样性。
对特定技能来说， ...

又是表格又是脚本的……程序结构会比较复杂，降低代码的可靠性。

如果不是有特别高的运行效率要求（大部分游戏都不会在这一块上遇到效率瓶颈），使用脚本对程序员来说更为省事。就我自己来说，我宁可一个技能一个脚本文件，哪个技能有问题，我就找对应的脚本文件来分析、调试、修改。不用担心修改这个技能的逻辑会影响到其它技能。

其实就算是技能比较简单的游戏，我也倾向于用脚本来开头——如果到最后技能没有进一步复杂化，直接把这个脚本逻辑“固化”下来作为模板就好了，不同的技能也就改改脚本里面的各种参数而已。再进一步，也可以让程序把这个脚本的逻辑用C++等效率更高的语言来实现，把那些要根据不同技能来变化的参数提取出来做表格就行了。

好些项目里面，最折腾程序和策划的就是怎么设计技能系统了——策划希望技能丰富多彩，于是技能表格上的参数项越来越多，结构越来越复杂；程序则希望有一套确定的规则，不用总是面对一张结构不断变化的表格。

Mr_I

卡特铁角 发表于 2014-10-15 16:12
又是表格又是脚本的……程序结构会比较复杂，降低代码的可靠性。

如果不是有特别高的运行效率要求（大部 ...

这就是我说的生产力了。
表格毕竟比脚本好维护，也便于数值做统一处理。
一个人能搞定的规模，当然全脚本也没什么。
一旦涉及到协作，表格就比较容易调用数据以及查错。

此外，更关键的一点是，尽量不要把数据和逻辑放在一起。

卡特铁角

Mr_I 发表于 2014-10-15 17:31
这就是我说的生产力了。
表格毕竟比脚本好维护，也便于数值做统一处理。
一个人能搞定的规模，当然全脚本 ...

你的希望是不要把数据和逻辑放在一起，但一个表格本身也对应着特定的解析逻辑。

表格的包含的参数越多，结构越复杂，其对应的解析逻辑也就越复杂。

一个复杂的表格，如果不配上详细的描述文档，接手的人很难弄明白其含义。但脚本就不同，就算一行注释都没有，具有一定经验的程序员还是能猜个八九不离十的。就算实在读不懂……把需要修改的技能重新写一个脚本也不是太麻烦。

卡特铁角

表格相对于脚本的优势仅仅在于方便批量处理。但在大多数项目中，不会有大批量调整技能数值的情况——对于一个有经验的数值策划，一定不会在定下基础属性数值之前就填写了大量的技能数值。

Mr_I

卡特铁角 发表于 2014-10-15 20:34
你的希望是不要把数据和逻辑放在一起，但一个表格本身也对应着特定的解析逻辑。

表格的包含的参数越多， ...

表格复杂，是设计有问题。
不知道你是否了解表格拆分的设计技术。

这样解释吧，就是把某个子流程的数据包装到另一个表里，而在主表只用一个字段来描述。
比如“护甲类型”，可能最后到程序应用表里是对所有伤害类型的减免比例构成的。
但是在主技能表里，只用一个字段就可以了。
设计技能的策划，不用具体考虑各护甲类型的伤害比例，那张表完全可以交给数值去维护。

卡特铁角

Mr_I 发表于 2014-10-16 10:22
表格复杂，是设计有问题。
不知道你是否了解表格拆分的设计技术。

对策划而言，把一张复杂的表进行拆分，有利于理解表格的含义，一定程度的方便修改。

但对程序来说拆分与否差别都不大——最终在代码的数据结构里面都要反应这些表-子表之间的关系，解析过程无法简化。

甚至程序员通常都不喜欢把一张表拆成多张表的做法——如果在代码的数据结构上也进行这么多的拆分，那就意味着为了获得一个技能的数据就要查找甚至遍历多张表，效率低，而且更容易出错。（PS：我是亲自写过这一块的代码的）

至于表格复杂是不是设计出了问题，这不一定的——有些项目的技能需求就是这么复杂。

GOODLUCK！

“蜗牛这公司做的游戏历来画面很不错，但策划水准很一般了”---以前总听到别人这么说，看到楼主，我现在信了。