技能和BUFF数据编辑架构

史上第一混子

卡特铁角 发表于 2014-11-23 18:26
你应该不是写代码的人吧……

95%以上肯定是一次确定——这个说法已经出卖你了。

当然~我是个策划！

卡特铁角

史上第一混子 发表于 2014-11-23 19:36
当然~我是个策划！

在那个把我折磨到至今仍记忆犹新的奇葩项目里，我很不幸的就是写那段代码的人……同时，也是负责技能系统的策划

史上第一混子

卡特铁角 发表于 2014-11-23 19:47
在那个把我折磨到至今仍记忆犹新的奇葩项目里，我很不幸的就是写那段代码的人……同时，也是负责技能系统 ...

:-( 我们需要策划写脚本的只是极为特殊的那一部分，比如：子弹的五角星形弹道之类的~

卡特铁角

史上第一混子 发表于 2014-11-24 11:49
:-( 我们需要策划写脚本的只是极为特殊的那一部分，比如：子弹的五角星形弹道之类的~ ...

当是我是脚本组（这是个跨部门的组，组里有程序也有策划）的组长。按照规划，出去UI的交互逻辑，整个游戏的上层逻辑都由这个组实现。任务系统、角色属性成长、NPC及怪物AI、技能……
其实现在想起来，如果不是那项目经理顶不住几位高层的压力，不停的加入新东西。采用这样的开发方式应该会很顺利——策划跟脚本组程序的沟通内容仅限于逻辑层（也就是脚本），当脚本有新的需求无法实现时，再由负责脚本的程序去跟负责下层程序沟通，请求新的接口。最大程度减少了策划与程序沟通的障碍。

史上第一混子

卡特铁角 发表于 2014-11-24 13:57
当是我是脚本组（这是个跨部门的组，组里有程序也有策划）的组长。按照规划，出去UI的交互逻辑，整个游戏的 ...

我们就是这种模式啊~开发效率很高~核心的就是需求控制了~

firstfish

卡特铁角 发表于 2014-11-23 18:26
你应该不是写代码的人吧……

95%以上肯定是一次确定——这个说法已经出卖你了。

作为一个写过并且正在写而且很喜欢写技能系统的程序员，我赞同卡特铁角的看法。

如果策划能在立项的时候就把技能系统的东西全考虑完，并且保证100%不变。我觉得一个有经验的，有点追求的程序员，应该是想，并且能写出一套技能逻辑框架，并且设计好程序用的和策划用的数据结构，以及相应的配置工具出来的。

但现实情况是怎么样呢？史上第一混子是个靠谱的策划，他也说，能确定95%的需求就不错，而恰恰那5%就是最特殊最变态的技能，那些技能决定了你的框架是不稳定的，需要修改逻辑的。

如果我是一个强势的程序员，那我会拒绝这5%的变化，或者温和一点的方式，就是大家坐下来想想有没有折衷的不改逻辑（比如通过表现来让玩家来误以为是一个新技能）的方式。

如果我在项目中人轻言微，那我够负责任的话，或者说眼光够长远的话（事实上如果坚持改代码，最苦的将会是自己），应该采用一个技能一个脚本的方式来实现，这样能保证开发的进度，或者至少我可以预估项目的开发进度，像卡特说的，拿体力来攻克瓶颈，是一个好事。

但。。。即使上面这么说，我是一个犯贱的程序，即使策划现在不能把技能系统定案，但我还是坚持一套逻辑就搞定。。。谁让我是处女座呢。。。

话说回来，还是擅长什么，习惯什么，就用什么方式好了，没必要讨论这么多。3+6等于9，4+5也等于9。


PS：基本上看了楼上两个人的争论，我的看法是，“数据的生成和解析”这块是完全可以一点不修改而适应策划的各种变化（因为我早就实现了），但“数据的使用”，只要策划一修改，程序逻辑是必然要相应的修改的，不管是大改还是小改。。。没可能策划今天说伤害按攻击力算，明天一拍脑袋又说要可以按剩余血量算，我程序一行不改就能适应吧？

卡特铁角

firstfish 发表于 2014-11-25 19:58
作为一个写过并且正在写而且很喜欢写技能系统的程序员，我赞同卡特铁角的看法。

如果策划能在立项的时候 ...

我的看法是，“数据的生成和解析”这块是完全可以一点不修改而适应策划的各种变化（因为我早就实现了）——这是我感兴趣的东西。可以详细说下不？

你怎么适应“增加子表或者树状结构中增加非叶子节点”这种变动？

firstfish

卡特铁角 发表于 2014-11-25 20:54
我的看法是，“数据的生成和解析”这块是完全可以一点不修改而适应策划的各种变化（因为我早就实现了）— ...

啊，可能我说的让你有点误会，没有这么高大上。
我指的生成解析只是打包解包，至于要生成程序能理解的数据结构，我把它归于“使用”里了。

很多现成的东西都可以完成这个功能，比如json，xml，或者proto buff动态解析。这些数据结构都能很好的承载“自己描述自己”的工作。

我的做法是不使用表格，做了一个编辑器，可以使用动态语言的反射功能来打包解包任意数据结构，实质上和上面是一样的。

卡特铁角

firstfish 发表于 2014-11-26 09:30
啊，可能我说的让你有点误会，没有这么高大上。
我指的生成解析只是打包解包，至于要生成程序能理解的数据 ...

明白了。是我对“数据解析”这个概念的理解不够准确。如果只是打包解包，确实有很多办法可以自动适应表格结构的变化。

当时还没有听说过json，所以我们用的是XML。主要是考虑到子表比较多，而且层次比较复杂，把所有的子表以树状结构放到同一个xml表中更方便读取。

madak1

LZ，条件表的结构是什么样的，还有么