数据驱动编程，之前听大神说过这个词，当时不以为然。如今在工作项目中，切身体会了，才真正感受到了这个词背后的一点点儿思想。
http://www.cnblogs.com/tadi314/archive/2010/03/11/1683795.html
这篇文章与我产生了很多共鸣。
策划喜欢用Excel表来设计游戏关卡，技能，等等。
就拿技能来说，大多都有差异，随着需求越加越多，字段也越加越多，程序越改越多，效率低下。
我觉得，更好的方式是：
1、程序实现最小粒度的功能。（比如，一个技能的效果是，伤害敌人100血，并且眩晕1.5秒）
伤害和眩晕就是最小粒度的功能。这个技能就可以看成是伤害和眩晕的组合。
2、程序实现一套脚本解释工具，或者说文本解析工具。策划只需要简单的写一行语句，就可以对应到程序里面的一个完整的功能。有时间的话，再给策划整一套UI吧，让他们拖拖拽拽就可以自由组合各种功能。这样他们一定会对你很好的，要是个女策划，你懂的！
搜索了一下，《Unix编程艺术》有时间我一定得去读一番。
数据驱动编程的核心出发点是相对于程序逻辑，人类更擅长于处理数据。
数据比程序逻辑更容易驾驭，所以我们应该尽可能的将设计的复杂度从程序代码转移至数据。
书中的值得思考的话：
数据压倒一切。如果选择了正确的数据结构并把一切组织的井井有条，正确的算法就不言自明。编程的核心是数据结构，而不是算法。——Rob Pike
只有跳脱代码，直起腰，仔细思考数据才是最好的行动。表达式编程的精髓。——Fred Brooks
数据比程序逻辑更易驾驭。尽可能把设计的复杂度从代码转移至数据是个好实践。——《unix编程艺术》作者。
不得不感叹国外的游戏策划都是自己写lua语言来实现想要的功能。
unity3d环境下，里面嵌入一个lua解释器，
写好lua脚本后呢（对U3d api的调用啊，对自定义宿主语言写的函数的调用啊）
在runtime时，解释执行。比如：ulua插件，slua插件。
既然逻辑调用是写在文本里，那么自然可以热更新咯。
国内呢，把工种分的太细，工种之间又完全不去过问。比如3D美术建模，导出给程序用时，比例不对，轴向不对。
他竟告诉我，U3d里不是可以缩放嘛，不是可以旋转嘛。我只想说，给程序增加负担真的好吗？？？
还有就是偏见太重，有的人认为，程序就该写代码，美术就该建模、画原画、K帧，策划就该添Excel。
有一次，美术给的Icon太大。交给美术返工，时间又浪费太多，因为之前玩过PS，于是就自己修了起来。
恰巧被一同事瞧见，说：这不是应该是美术干的活吗。我竟是楞住，回不上话来。我只想说，写代码是技术，画画是技术。
都是靠技术吃饭的人，为什么不让自己了解更多的技术。你又不搞科研，有必要分的那么细致、专一。
- 本文固定链接: http://www.shihuanjue.com/?p=91
- 转载请注明: 乔 2015年09月25日 于 是幻觉 发表