5.7 KiB
前言
作者首次接触到这个词，大概是20年，当时我正在探索技能实现的正确方案。在这期间，我了解到Dota2编辑器的存在，而Dota2的技能扩展就提到了“数据驱动”这个词。
不过，Dota2并没有对数据驱动这个词下定义，也没有解释数据驱动的优缺点 —— 即为什么要这么做，再加之他们的技能设计和我的想法差异过大，我便没有深入研究他们的设计。
我真正理解数据驱动，是在将行为树成功引入战斗系统后。在将行为树引入战斗系统后，为了支持编辑技能和Buff，我将既有的行为树编辑器修改为了通用的数据结构编辑器 —— 不再限制节点的类型，就像这样：
这样以后，对于简单的技能，策划就可以在编辑器中直接实现；而特殊的技能，也只需要程序提供特殊的节点即可。也就是做完这件事，我便理解了Dota2的数据驱动是什么意思。
那什么是数据驱动？
我们编辑器导出的是Json格式（以后会调整），其内容虽然和Dota2有区别，但内核是一样的，那就是：用数据描述行为。
你可以将策划的配置（数据）看做是更高层的代码，而我们的程序则相当于解释器，解释配置实现对应的行为。
不过，数据驱动还有另一个解释：通过修改数据，改变对象的行为。
这个解释侧重最终目的，而非过程（怎么做）；因为数据描述行为的情况下，数据改变，行为自然改变。
这两个解释都应该知晓，前者可以指导我们该怎么做，后者可以检验我们设计的正确性，也可以告知他人我们的设计目的。
它主要干了什么事情？
它其实就干了一件事：分离接口和实现。
注意，这里是分离接口和实现，而不是分离数据和行为（面向过程）。面向过程下，数据只是数据，它不关心它如何被处理；而技能的配置是完整约定了技能行为的，它不仅仅约定了函数名，还约定了函数参数。
所以，策划的配置起的是接口的作用，而我们的代码则是对接口的实现，所以是接口和实现的分离。
数据驱动的优点：
- 更好的扩展性和灵活性 —— 显而易见
- 更好的可读性和可维护性
- 解放策划的生产力，减少程序的工作量
- 跨语言：配置通常采用语言无关的文本格式
数据驱动的缺点：
- 不确定性（安全性）
- 解析开销（脚本实例化开销）
不确定性，是我在向策划提供技能编辑器以后最苦恼的事。在编辑器里组合节点是很容易的——就连个线，但行为之间可能存在数据（上下文）依赖，由于策划并非专业的程序员，对程序运行时的上下文也并不完全了解，因此可能拼出错误的逻辑，而这些错误难以在开发期检测出。
所以，即使在有编辑器的情况下，我还是会经常被策划喊：“磊哥，你看看我这个技能怎么不好使呢？”
所以，即使是有编辑器，对战斗策划要求仍然是比较高的 —— 但已然降低不少。
如何实现数据驱动？
有几个关键点：
- 控制反转：将（部分）控制权交给策划
- 组合模式：将大块的逻辑，拆分为一个个独立的单元，允许组合使用
- 函数无状态：函数的输入完全来源于黑板
- 保持数据结构简单：只使用简单的数据类型集合
- 上下文使用黑板类型
- 好的文本格式和序列化工具
数据驱动随处可见
在游戏开发中，数据驱动有着大规模的应用，只是以前我们没有关注到这个词而已。我们的场景编辑器，任务编辑器，剧情编辑器，都是数据驱动的案例。甚至Unity，都可以说是数据驱动的，它的资产文件就是数据，我们通过数据告知Unity动画该怎么播，UI该怎么展示。
所以，虽然你可能不了解数据驱动这个词，但工作中其实一直在使用。
数据驱动与编辑器有关吗？
无关。配置（数据）是可以手写的，编辑器的作用只是简化了配置方式 —— 算是简单的图形化编程。
那以前策划通过Excel组合不同的技能效果算数据驱动吗？
严格意义上来说，是算的，但我更想说不算。
因为通过Excel配置技能的方式，程序的工作并不轻松，策划的工作就更是艰难。此外，使用Excel配置技能的结果是：数据，数据不清楚；行为，行为不清楚，那谈什么数据驱动呢？
对于技能这种复杂的数据，应该舍弃Excel，使用Json或Lua等来配置，只有数据和行为都清楚了，才算得上数据驱动。
结语
游戏开发中有许多的词汇，这些词汇通常代表着一些模式， 了解这些词，可以让我们对项目的设计认知更为清楚。