技能和BUFF数据编辑架构

快乐杰克

卡特铁角 发表于 2014-10-28 10:51
哈希表查询跟指针的概念还是有差别的。

指针在C/C++中是存储内存单元地址的变量。

严格来说是有 区别的，所以才用“指针”这种形式。

Mr_I

卡特铁角 发表于 2014-10-28 10:25
像上面那样采用多级节点来描述数据，一方面是为了提高表格的可读性。另一方面的原因则是——我们的脚本结 ...

对于不同事件访问同一节点的东西，之前我说的方法对只有一层的情况还是能很好处理的。
就是在输出是同一行中支持数组形式，形如{"id":1,"array_name":[1,2,3,...]}
这里的一个数组中的内容就可以用来作为子节点数据调用。

关于数据难理解的问题，实际上表格对策划来说更友好。
我想我的出发点，就是希望“编辑器”对设计者更加友好，而不是凡事最后都要程序来搞。
可悲的是，很多项目甚至没有专门的工具组，策划没法期望程序做各种方便的工具。
只能退而求其次地让程序怎么方便怎么来。这其实算不上是好的开发方式。

在我看来，SWIFT的对底层效率优化、对设计者交互优化的“双向优化”，才代表着生产力发展的方向。程序语言本身的发展，也是越来越人性化的。难道不是这样么？

iamtaro

看完了，有必要在策划区讨论这种问题么，策划创意比这个更重要？

《刀塔传奇》就是用配置表+脚本实现的，扯了这么多有比它更成功的游戏的么？

（当然我是更支持程序定义基本接口+策划写脚本的方式实现技能，但也仅支持一点点。如果你的程序足够强大，做成WE这样的编辑器无疑是最好的）

卡特铁角

Mr_I 发表于 2014-10-29 17:57
对于不同事件访问同一节点的东西，之前我说的方法对只有一层的情况还是能很好处理的。
就是在输出是同一 ...

做工具的目的是为了提高项目的开发效率。现在国内大多数公司都走“短平快”路线，不做我之前说的那种超复杂的项目。因此，要给团队专门配备一个“工具组”不太现实。但找两个新手程序员按策划具体需求写写逻辑脚本还是很容易的。

我说的重点不是让程序方便怎么来，而是通过扁平化的思想降低各功能间的耦合来降低工作的复杂程度，从而提高开发效率——功能间耦合度越低，对需求变动的描述就会越简单，修改程序所涉及的范围越小，策划与程序间需要沟通的内容也越少，因此策划与程序工作的复杂程度都会降低。

要说“通用”，我觉得抽象得越彻底的东西才能越通用。

再说对策划友好，我觉得最好的方法就是让策划做设计时不被技术层面的问题所干扰——以技能系统为例，让策划用尽量无歧义的自然语言描述每个技能就好了，不用去理会程序需要什么样的表格结构和统一规范；另一方面，程序写代码时也不用去处理不同技能在逻辑上的矛盾之处——无论从策划（自然语言）还是程序（代码）的角度来说，描述一个具体功能总是更容易的。

卡特铁角

iamtaro 发表于 2014-10-30 13:09
看完了，有必要在策划区讨论这种问题么，策划创意比这个更重要？

《刀塔传奇》就是用配置表+脚本实现的， ...

创意再好，做不出来等于0啊……

多少项目在技能系统这块反复折腾纠结……把人折腾跑的都有！

Mr_I

卡特铁角 发表于 2014-10-30 16:30
做工具的目的是为了提高项目的开发效率。现在国内大多数公司都走“短平快”路线，不做我之前说的那种超复 ...

没错，自然语言。在我看来当然更好的是这种流程：
自然语言->工具->看到效果；程序员->工具

而不是：
自然语言->程序员->改代码->看到效果

多了一道人为因素，感觉上就好像写代码用了别人不开放的库。

卡特铁角

Mr_I 发表于 2014-10-30 17:58
没错，自然语言。在我看来当然更好的是这种流程：
自然语言->工具->看到效果；程序员->工具

自然语言→工具→看到效果……这个短时间内是很难实现的了。
自然语言太过复杂，要让电脑正确理解自然语言太难。学编译原理的时候，词法解析，语法分析……这些已经彻底把人伤透了好么？

工具总归还是人做的，其适用范围总是有限的。很难应对项目开发过程中的各种变数。
所以我选择的流程是：自然语言→程序员→改少量简单的代码→看到效果。如果你的策划够牛逼，很快掌握了这些代码的修改方法，那也就是你希望的流程了。

但让程序开发一个尽量通用能应对多种不同需求的工具……那出现需求变动时就可能导致以下的结果：自然语言→程序员→修改工具（大量复杂的代码）→自然语言→工具→看到效果→不符合需求→自然语言……直到程序员怒了，丢下一句话——新需求无法实现！

卡特铁角

其实大部分策划还是能看懂 if else一类的语句的。而如果脚本结构设计的合理，接口命名详细准确，简单一点的逻辑，文案策划都可以写。

我自己就教过文案策划写脚本——只用了不到一天的时间，那个中文系毕业的文案策划就掌握了简单对话任务脚本的写法。最后，几乎整个任务链都是他自己写的。

史上第一混子

卡特铁角 发表于 2014-10-25 14:36
你们的通用逻辑是一次就确定了的？

这部分的抽象提取会有一些反复~但95%以上的肯定是一次确定

卡特铁角

史上第一混子 发表于 2014-11-23 15:42
这部分的抽象提取会有一些反复~但95%以上的肯定是一次确定

你应该不是写代码的人吧……

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

对于通用逻辑，很少的需求变动就可能要修改很多相关的东西了