技能和BUFF数据编辑架构

卡特铁角

Mr_I 发表于 2014-10-22 09:02
所以你也知道LUA可以用任何东西来做下标？

难道数据的ID不是一种下标？

争议1：代码效率问题

哈希查找虽然时间复杂度很好，但也还是要消耗时间的。明明能一次哈希或者遍历就得到的数据为什么要分成多次？使用多级索引，分成多次查找是不是效率更低了？

另外，当数据规模比较小的时候，哈希查找的时间消耗与遍历相比并没有什么明显的优势。


=========================================================
争议2：策划调整技能与程序维护代码是否方便的问题

方向1：如果不要分成多次查找，程序就要把读取的多张表按一定的逻辑规则组合到一个统一的数据结构中。之后每当策划提出新的技能逻辑，或者含有新字段的技能类型，程序都要对之前确定的数据结构和处理逻辑进行修改……你管这个叫数据和逻辑分开？一套固定结构的数据结构，对应一套固定的解析逻辑，在这里把数据和逻辑分开只是策划的妄想。

方向2：就算某程序脑子抽了愿意按照你多次查找获得一个技能数据的方法来处理，也还是无法避免上面说的很有可能反复修改技能数据和解析逻辑的问题。改得不好，整个技能系统都不会好了……

卡特铁角

Mr_I 发表于 2014-10-22 08:58
呵呵。总是拿程序员来做借口。是否刻意回避我之前所说的：

实际上策划编辑的内容怎么拆表，和最终导出给 ...

我只是告诉你，程序员都不太喜欢复杂的表格结构，无论你策划拆还是不拆，是用多张csv还是用一张xml（拆分成多张表也就相当于把树状的xml表中不同层级的节点分类放在不同的表格文件里而已）。对程序员来说他都必须弄明白这一个表或者一套表里面每个字段的意义，并且按照跟策划商定的技能逻辑来解释并使用这些数据。字段越多，表的结构越复杂，代码出错的可能性就越高，而且影响的范围通常都是覆盖整个技能系统的。

不是总拿程序员来做借口，而这根本就是一个程序方面的技术问题，所以这个问题更适合去程序区讨论。

Mr_I

卡特铁角 发表于 2014-10-22 15:16
我只是告诉你，程序员都不太喜欢复杂的表格结构，无论你策划拆还是不拆，是用多张csv还是用一张xml（拆分 ...

说了半天，还是在绕圈子啊。且看：

我说：拆表方便策划。
你说：表多了程序不乐意。
我说：拆表不代表最终给程序的表会变多。
你说：不论拆不拆，表复杂了程序都不乐意。

偷换概念了吧。
整个过程中哪里说到要把系统变复杂了？
同一套数据的配置方法从配一张表拆成配二张表，
最后输出还是那些字段，然后程序就不乐意了？
拜托，我最后给程序的是同一份东西好不好。

这还不在跟我绕圈子嘛？

卡特铁角

Mr_I 发表于 2014-10-22 17:25
说了半天，还是在绕圈子啊。且看：

我说：拆表方便策划。

我的观点——使用脚本处理技能，比使用表格要简单方便得多。

1、关联性很强的数据拆碎了放会不会让程序不爽？
2、复杂的表格是否对应着复杂的解析逻辑，是否也会让程序觉得不爽？
3、表格结构改变，代码中用于读取、处理表格数据的代码是否都要调整？
你可以拿着以上3条去程序区询问程序员们的答案。

另外，你说的整个过程就是在把简单问题复杂化——技能抽象的说是为玩家提供的与游戏中其它对象的交互方式。提出“技能”这个概念的目的就在于让交互方式多样化而不是只有有限的几种甚至只有统一的一种。不同的交互方式又对应着不同的处理逻辑。在这样的前提环境下，硬要使用统一的结构（表格）来描述处理逻辑不同的各种技能，那会导致2个必然后果：
1、处理技能的代码中会有多层的逻辑分支（以便对应不同的技能逻辑，技能间的差异越大，这种逻辑分支越多）
2、表达技能的数据中必须加入额外的类型字段（告诉代码应该按什么样的逻辑来处理当前技能的施放，用什么样的逻辑来处理处理对目标的效果……技能间差异越大，需要区分的类型也越多）

以及1个有可能发生的后果：
在技能差异较大的游戏中，如果不是使用xml形式的树状表格，你的表格中会存在大量的冗余字段（对技能A有用的字段对技能B没有意义）。
而使用脚本与技能一一对应，虽然无法完全避免数据冗余，但好歹让整个结构最大程度的扁平化了（在处理逻辑上不再有技能类型的划分，或者说技能类型直接按技能ID进行划分）。后面新增技能，又或者对原有的某个技能调整修改会更加方便。至于技能的表格……就给数值策划用吧。

最后，我想说，虽然作为程序员我不是特别的专业，但我好歹也写过差不多10万行技能相关的代码（C/C++、AS、lua……）。这真的是一个应该去程序区讨论的问题。

弹你小雀雀

楼上真蛋疼。。我居然还看完了。。

一般MMO是用表格+脚本，因为往往绝大部分技能的相似性较高（数值降耦，降低平衡难度）
需要怪物技能、职业or各种OOXX技能完全可随时创造，便于策划工作
遇到特殊技能在通过脚本进行扩展

MOBA类游戏，因为在养成线的时空维度不长的情况下，可以尝试提高平衡难度，大量制作一些特殊效果的技能
所以全脚本是合适的

DOTA的技能就基本全是JASS单独写的

卡特铁角

弹你小雀雀 发表于 2014-10-22 19:49
楼上真蛋疼。。我居然还看完了。。

一般MMO是用表格+脚本，因为往往绝大部分技能的相似性较高（数值降耦， ...

早先做过两次表格+脚本的项目，那真是比蛋疼到在这里争论技术问题更加蛋疼……所以我现在坚决反对这种做法。

只要是提出技能系统这个东西，那就一定是希望技能间存在差异的，这是设计的出发点——每个技能的施放和作用方式都一样，只是表现不同，那就没必要搞技能系统了。

在开始设计技能系统的时候让策划去总结出最普遍最常见的技能逻辑流程是很困难的——策划自己也不知道以后还会不会引入什么新的战斗机制，或者会怎么修改。所以结果必然是策划不爽，接下来程序不爽，或者像我这样，先作为策划不爽，再作为程序不爽……

与其如此不爽，不如完全用脚本啦——策划描述一个技能，程序根据描述写一段脚本。
而且我们经常会说——先用脚本来做，到性能优化阶段再对相似性高的技能进行统一化，表格化的处理。不过，最终都没有做这一步——脚本在效率上的表现不差啊。

Mr_I

卡特铁角 发表于 2014-10-22 19:27
我的观点——使用脚本处理技能，比使用表格要简单方便得多。

1、关联性很强的数据拆碎了放会不会让程序不 ...

1、拆表 ！= 把关联性很强的数据拆碎
如果真这么做，只能说明策划对数据关系的理解不够。

2、已经说过是复杂度一致的前提下
绕圈+1

3、不需要。
我已经在之前的点评里说过了。那是你们的程序写的工具有问题。
当然，如果你们向来是在逻辑代码里直接解析，而不用任何工具方法的话，当我没说。

弹你小雀雀

卡特铁角 发表于 2014-10-22 20:23
早先做过两次表格+脚本的项目，那真是比蛋疼到在这里争论技术问题更加蛋疼……所以我现在坚决反对这种做 ...

对于MMO，毕竟大部分的基础技能作用机制就那么几种，反复变化冷却时间、伤害加成、作用目标、作用范围、引导时间、附加buff效果就可以迅速构建出多种不同的技能
就算是你说的WOW也是这样。。
这些的 “差异” 已经足够构建一个基本完整但 “不那么有特色” 的技能系统了
剩下的特殊技能就是让职业特性变得更 “特色” 一些
玩起来觉得更不可思议一些

这么说吧。。现在这个项目里技能表的技能数目是411个。。如果都脚本我觉得你会疯的
还不算陆续添加游戏内容时要求加的东西

turwater

这么多人谈了那么多  其实无非就2个字“习惯”
抛弃习惯来说  从项目角度 倾向脚本 注重的是扩展性和特殊性，以及功能丰富性。
哪些什么表可以拉，可以批量如何如何的。 你都可以拉了可以批量了，写个语句会死？
但从现在行业角度，还是倾向表，因为1个团队不可能随便抓个策划都是真正可以独当一面，又在项目中可以充当多面手的角色。大部分人需求的只是1份工作，一份可以叫自己省心，在自己可知范围内完成的工作。并且大部分项目管理者也希望以1个简单的方式管理团队，而不希望出现自己搞不定的问题。

卡特铁角

弹你小雀雀 发表于 2014-10-23 09:46
对于MMO，毕竟大部分的基础技能作用机制就那么几种，反复变化冷却时间、伤害加成、作用目标、作用范围、 ...

不知道你有没有试过将WOW那种技能系统用表格的形式来实现……我试过。就那个伪FPS的MMO项目。一开始是用表格的，仿照WOW技能总结了一套通用的技能逻辑，基本可以实现wow里面大部分类型的技能效果。但随着项目的推进，项目越来越多的显示出与WOW的差异性，并且不断引入新的需求（比如：引入载具战斗这个概念之后，部分技能可以透过载具伤害到里面的玩家）……导致的结果就是，先前确定的技能表格结构越来越复杂，写好的技能处理逻辑被反复的修改，以便适应新的需求。这一块逻辑的代码量也在不断的膨胀，最终自己读起来都觉得困难……

几百个技能的项目我也做过，也就几百个脚本文件而已。脚本文件与技能一一对应，哪个技能要调整，就找哪个文件。每个脚本10多行的代码量，最复杂的技能也就百来行，简单易读好维护，就算出错也不会影响整个技能系统。这不方便么？

从降低系统耦合度的角度来说，当然是越扁平越好了。

而且就项目思想来说，我倾向于把高难度的工作转化为只需要体力和时间的工作。