数据驱动设计

游戏客户端三大部分：1.显示。2.数据。3.逻辑。这三大部分的拆分是客户端必须要做好的。在unity3d这种一体化游戏开发工具出来之前，可能大部分游戏制作者几乎是用纯代码的方式制作游戏的时候，这个拆分尤其重要。

本文先讲述之前游戏的数据驱动设计是如何做的。再谈谈unity3d出现以后，数据驱动设计是如何进化的，unity3d帮我们把哪些之前的数据驱动做好了，而哪些是我们还需要做的。

 

1. 旧时代（我个人把unity3d这种开发模式出现之前的游戏研发时代称之为旧时代）的数据驱动设计。

1.1. 什么是数据和逻辑？逻辑部分定义游戏引擎的核心原则和算法。数据部分则提供其内容和行为的具体细节。而数据部分应该从文件载入。

1.2. 文本文件的真正意义在于不用修改一行代码，你的整个小组，包括测试人员和游戏设计人员就能进行各种新尝试，并改变不同的东西来进行测试。

1.3. 不要硬编码常量，应该把常量放进文本文件中，这样进行改变是就不用重新编译代码了。

 

2. 再谈谈脚本系统。

2.1. 脚本化数据和简单的游戏逻辑，也是数据驱动的一部分。脚本是一种在代码外定义行为的方法。脚本对于定义游戏中的步骤顺序或需要触发的游戏事件非常有用。例如cut-scene和环境触发器等都是数据驱动思想的极好例子。

2.2. 什么时候不适合脚本？当脚本中出现状态信息并需要进行分支时，脚本就成了一个有限状态机。当状态的数量增多时，策划的工作就会变得抓狂。通常来说，将AI行为写进脚本中并不好，然而拥有一个脚本触发系统使得世界能够进行互动却是个好主意。其原则应该是，如果逻辑太复杂，他应该放在代码中。脚本语言需要保持简洁。

 

3.对旧时代的数据驱动做一个总结就是。创建文本文件系统，这里面包括各种游戏的配置，常量和数据。创建简单的脚本系统，用脚本来做cut-scene和trigger等简单的流程化的游戏内容。

 

4.那么现在出现了unity3d这种一体化的游戏制作工具以后数据驱动又变成怎样了呢？

4.1. 其实u3d这种游戏引擎帮我们做了很多的数据驱动的事情。例如场景编辑。编辑好的场景形成的文件就是数据驱动的部分。类似的还有动画编辑，prefab编辑，粒子编辑等。这些都属于数据驱动的部分。在新游戏引擎系统下这些几乎成了规范。

4.2. 我们还需要做好哪些数据驱动呢？我们仍然需要文本文件系统，但是更多的是控制游戏内容本身和一些配置部分。例如游戏窗口大小，游戏质量的各种参数，游戏难度，关卡数据（也许你需要做一个关卡编辑器来导入导出关卡数据）。流行趋势上来讲，我们都是尽可能将抽象的各种游戏参数和游戏数据通过可视化编辑工具的导入导出来进行，这样不仅直观容易操作，使得游戏策划能更加得心应手的调整游戏。而游戏逻辑甚至是AI这种复杂的逻辑部分也在往可视化工具方向发展。例如虚幻引擎的blueprint，行为树behaviac等都是新的数据驱动的方式。在将来，游戏客户端就是各种可视化工具的集合，将数据驱动进行到牙齿。