技能和BUFF数据编辑架构

卡特铁角

史上第一混子 发表于 2014-10-25 00:56
在moba游戏中我体验下来最高效率的就是通用逻辑走表格，特殊逻辑走脚本的混合使用方式 ...

你们的通用逻辑是一次就确定了的？

卡特铁角

Mr_I 发表于 2014-10-25 10:19
数据结构发生变化，解析不需要重写。
在表里新加一个字段，在程序里可以直接用。
这连我自己写的东西都能 ...

你这么牛逼？

树状XML表格中新增一个节点，或者二维CSV表中多出一张子表，你不用改解析逻辑？不用改数据结构？

表里加的新字段不需要写对应的逻辑来使用？你能保证这些新加入的逻辑一定跟之前的逻辑没有关联？

你真能做到，那就把你的代码秀出来吧。去程序区发个贴，然后@我。

Mr_I

卡特铁角 发表于 2014-10-25 14:50
你这么牛逼？

树状XML表格中新增一个节点，或者二维CSV表中多出一张子表，你不用改解析逻辑？不用改数据 ...

呵呵。你故意扩大问题的前提意在何为呢？

我始终是在说”不需要改解析”，你偏要加上"需要写对应的逻辑来使用”。
废话，加数据当然是为了使用啊。
这和我说的解析不需要重写有冲突吗？

我说“在表里新加一个字段”，你就开始加节点甚至加表。
OK啊，你加好了。

我先和你说说加字段不用改解析的可能性。
我自己常用的方法是用EXCEL输出JSON数据格式。
最终输出的的格式形如：   [{"id":1,"key":...},{"id":2,"key":...},…]
其中每个{}对应EXCEL的一行。
解析JSON我想正常的程序员都很容易做到。
如果你觉得加一个新的"key":"value"需要重新写解析逻辑的话，那我是无话可说。

然后说说我所知道的更通用一些的方法。
那就是除了数据本身的配置，还有一份对数据格式描述的配置。
比如前者可以直接是EXCEL表，后者是一份XML。
然后程序的解析工具逻辑是不变的，在新加数据后，只需要在XML里添加对应的数据描述。

好了，我想你了解这些后应该也能自己写出不错的工具。
然后去程序区发个帖，然后看有没有人说：其实我知道有更好的方法。
如果有，可以@我。

卡特铁角

Mr_I 发表于 2014-10-25 15:54
呵呵。你故意扩大问题的前提意在何为呢？

我始终是在说”不需要改解析”，你偏要加上"需要写对应的逻辑 ...

“数据结构发生变化，解析不需要重写”
树状表中增加子节点，CSV增加子表，这是对应数据结构发生变化——这种情况下你要不要改解析过程？我哪里扩大问题的前提了？

“在表里新加一个字段，在程序里可以直接用”
怎么直接用了？不用添加或者修改对应的处理逻辑它就能按策划的想法运行了？而修改通用逻辑时你总是要考虑它跟先前已实现功能的关联……这很烦人，也很容易出错。

看了你后面说的做法，我大概明白了——你以为“读取文件”就是“解析”。而实际上，我们说的解析通常是指把文件中的原始数据读出来，再按方便处理逻辑的形式将其“组装”成特定的数据结构（对象、结构体、多维数组、链表……）。就算只是增加字段，这依然意味着数据结构会有所改变，虽然这种改变对解析的影响不大，但处理逻辑必须做对应的改动。添加新的子表就更不用说了。

你所说的“更通用”的方法，在那个流产的伪fps项目里，早期就采用的就这个方式——策划提供多张csv/excel表中包含各种字段名和值，xml中以多级节点的方式表达数据的结构或者说解析逻辑。但你觉得这个xml应该由谁来维护？通常策划是不清楚程序对数据结构的需求的，而对程序员来说，改xml和直接改代码有多大区别呢，反正紧接其后的技能处理逻辑也是要改的。

卡特铁角

针对肯定有差异化需求的技能去写“通用逻辑”根本就是一件吃力不讨好的事。

尤其当数据结构比较复杂的情况下——比如那个项目中要处理的技能相关数据有：施放条件表、基础效果表、武器附加效果表、弹药附加效果表、载具防御效果表……——你可以想象一下lua中那个table的样子有多狰狞……差不多有3个月的时间，策划每天都折腾这些表，程序调整xml结构和所谓的“通用技能”处理逻辑（这块代码从一开始的不到300行逐渐膨胀到最后的2400行），你觉得这是不是很蛋疼？

所以最终我们抛弃了这种吃力不讨好的做法，改为我前面说的扁平结构——2个人针对每个技能单独写脚本，只用了不到1个月的时间就完成了当时提出的所有技能需求。总代码量确实比先前更多，但结构简单了，不用再一遍一遍的阅读调试那个2400行的裹脚布。

或许，我这个例子有其特殊性。但就算是技能比较少，技能间差异性不那么大的项目，采用这种扁平结构也没有什么明显的坏处，虽然它看起来不如“通用逻辑”那么高大上……

Mr_I

卡特铁角 发表于 2014-10-25 18:09
“数据结构发生变化，解析不需要重写”
树状表中增加子节点，CSV增加子表，这是对应数据结构发生变化—— ...

“大概明白了”，你还是没明白。或者不想明白？

我说的做法就是包括组装的。
JSON的数据读取后直接就是可以使用的对象。
解析的处理逻辑根本一个代码都不变。

维护描述表关系的XML当然是提交数据的人做的。
你所描述的“通常策划”的标准，也许就是你们之前项目用表实践失败的原因之一。

Mr_I

卡特铁角 发表于 2014-10-25 18:17
针对肯定有差异化需求的技能去写“通用逻辑”根本就是一件吃力不讨好的事。

尤其当数据结构比较复杂的情况 ...

你按A做失败了，之后按B做成功了。
没人说你按B做的方法是错的。

用表来做数据的又不是没有，我也不知道你到底为啥这么纠结。
也许只是有人说按A做也是可能成功的，然后你就没法接受？

快乐杰克

刚才一会居然看完了，感觉卡和M的耐心都不错。

想问下卡你在写哈希表数据结构的时候是否注意到了它的使用风险或者说典型的使用限制。

卡特铁角

Mr_I 发表于 2014-10-27 09:33
你按A做失败了，之后按B做成功了。
没人说你按B做的方法是错的。

之所以坚持扁平化的设计思想，是因为我在对比中看到了技能系统采用扁平化结构的优势。无论对多样性/扩展性要求高的游戏还是传统的简单的游戏，这种结构都不会变得更复杂——就脚本范围来说，各个技能模块之间没有关联；各技能模块与主模块（例如技能事件分发模块）之间是数据耦合（对于简单的技能系统甚至可以做到非直接耦合）。这样的耦合度可以说是理论最低了。

我的观点可以这么表述——B方法在面对复杂的技能设计时优势明显；A方法在面对简单的技能设计时也可以用，但对于复杂的技能设计就会比较蛋疼。既然如此，不如任何时候都用B方法了——反正无论技能简单还是复杂，用B方法都没啥问题。

让相对稳定的团队核心成员适应并熟悉一种更通用的设计思路是有意义的——这能在每个项目的研发过程中省去很多沟通过程，提高开发效率。

卡特铁角

Mr_I 发表于 2014-10-27 09:30
“大概明白了”，你还是没明白。或者不想明白？

我说的做法就是包括组装的。

你用JSON的做法只是把“组装”的结构要求以及具体的数据包含在了JSON文件里而已，跟我之前用CSV+XML的做法没有本质区别。甚至CSV+XML更符合你所谓的“数据与逻辑分开”的理念（虽然在程序员看来，这个问题上数据与逻辑没法分开，但至少处理逻辑与处理数据的人分开了）。

你应该回答我的问题——在用表格描述技能时：是由策划来定XML或者JSON的结构，然后程序写代码时适应这个结构；还是由程序在了解策划的需求变动后自己确定XML或JSON的结构，再由策划来填写数据？哪一种更符合“数据与逻辑分开”的理念？