用数据驱动思想来设计游戏

  游戏由两部分组成，逻辑和数据。这是一种对游戏的有效划分。逻辑部分定义游戏引擎的核心原则和算法，数据部分则提供其内容 和行为的具体细节。在最初的游戏开发的过程当中，你们老是喜欢将逻辑和数据都写入代码中，这样的代码可移植性不好，重用性也差，还容易出现数据的不统一。若是要进行些许修改，甚至有可能牵一发而动全身。 linux

    数据驱动设计能够比喻成是一种面向对象的游戏设计，它将游戏数据存储在文件中，而再也不是嵌入在代码里面。游戏过程当中，经过动态的载入并读取和写入数据文件来对数据进行操做。在游戏开发过程当中使用数据驱动思想须要注意如下几点。程序员

   如今稍稍比较专业点的游戏都是采用数据驱动的思想来进行开发，但程度各异。而如何最大限制度的利用数据驱动的思想开发游戏，使游戏更具备自定义特性，提升玩家的游戏参与感，是将来游戏的主流。 
算法

数据驱动编程的核心编程

数据驱动编程的核心出发点是相对于程序逻辑，人类更擅长于处理数据。数据比程序逻辑更容易驾驭，因此咱们应该尽量的将设计的复杂度从程序代码转移至数据。数据结构

（数据比程序逻辑更易驾驭。尽量把设计的复杂度从代码转移至数据是个好实践）ide

数据驱动编程的核心函数

数据驱动编程的核心出发点是相对于程序逻辑，人类更擅长于处理数据。数据比程序逻辑更容易驾驭，因此咱们应该尽量的将设计的复杂度从程序代码转移至数据。spa

真的是这样吗？让咱们来看一个示例。.net

假设有一个程序，须要处理其余程序发送的消息，消息类型是字符串，每一个消息都须要一个函数进行处理。第一印象，咱们可能会这样处理：设计

上面的消息类型取自sip协议（不彻底相同，sip协议借鉴了http协议），消息类型可能还会增长。看着经常的流程可能有点累，检测一下中间某个消息有没有处理也比较费劲，并且，没增长一个消息，就要增长一个流程分支。

按照数据驱动编程的思路，可能会这样设计：

下面这种思路的优点：

一、可读性更强，消息处理流程一目了然。

二、更容易修改，要增长新的消息，只要修改数据便可，不须要修改流程。

三、重用，第一种方案的不少的else if其实只是消息类型和处理函数不一样，可是逻辑是同样的。下面的这种方案就是将这种相同的逻辑提取出来，而把容易发生变化的部分提到外面。

隐含在背后的思想：

不少设计思路背后的原理其实都是相通的，隐含在数据驱动编程背后的实现思想包括：

一、控制复杂度。经过把程序逻辑的复杂度转移到人类更容易处理的数据中来，从而达到控制复杂度的目标。

二、隔离变化。像上面的例子，每一个消息处理的逻辑是不变的，可是消息多是变化的，那就把容易变化的消息和不容易变化的逻辑分离。

三、机制和策略的分离。和第二点很像，本书中不少地方提到了机制和策略。上例中，个人理解，机制就是消息的处理逻辑，策略就是不一样的消息处理（后面想专门写一篇文章介绍下机制和策略）。

数据驱动编程能够用来作什么：

如上例所示，它能够应用在函数级的设计中。

同时，它也能够应用在程序级的设计中，典型的好比用表驱动法实现一个状态机（后面写篇文章专门介绍）。

也能够用在系统级的设计中，好比DSL（这方面我经验有些欠缺，目前不是很是肯定）。

它不是什么：

一、 它不是一个全新的编程模型：它只是一种设计思路，并且历史悠久，在unix/linux社区应用不少；

二、它不一样于面向对象设计中的数据：“数据驱动编程中，数据不但表示了某个对象的状态，实际上还定义了程序的流程；OO看重的是封装，而数据驱动编程看重的是编写尽量少的代码。”

书中的值得思考的话：

数据压倒一切。若是选择了正确的数据结构并把一切组织的层次分明，正确的算法就不言自明。编程的核心是数据结构，而不是算法。——Rob Pike

程序员一筹莫展。。。。。只有跳脱代码，直起腰，仔细思考数据才是最好的行动。表达式编程的精髓。——Fred Brooks

数据比程序逻辑更易驾驭。尽量把设计的复杂度从代码转移至数据是个好实践。——《unix编程艺术》做者。