1.3  通过将逻辑和具体实现相互分离来改善这种方法

简单地说，现在问题的关键就是你需要一种更加高明的、高度结构化的方法将游戏代码和游戏内容加以分离。当你在编写游戏引擎代码时，根本不需要考虑那些无休止的物品描述。同样，当你在解决物品描述问题时，也根本不需要考虑游戏引擎方面的编码问题。就像你在处理美术、音乐和声音这些问题时所遇到的情况一样，即便是游戏已经编译完成，只要觉得有必要，你就应该能够随时对物品进行大量的修改。想想你马上就可以解决缓慢而又耗时的重新编译问题，想想你马上就可以随意摆弄你想拥有的所有物品，想想你能够在同一个可执行文件中立刻就可以观察到你所进行修改的效果，这种方法听起来是不是像是一个很大的提高？

不过，更大的方便之处就在于这种方法易于实现。此时，当你检测所做修改的效果到底如何时，你就不需要再关心图形和声音等其他的游戏媒体了。就像我们在前面曾经了解到的那样，它们不像编译游戏内容那样还需要一个单独的编译器，你只需要简单地修改这个部分的内容，最多也就只需要重新打开游戏。为什么会是这样呢？这是因为此时物品的描述和游戏引擎分别存放在不同的文件里面。在游戏代码中，和这些描述数据唯一有联系的地方就是从磁盘读取这些数据的那部分了。这些描述数据在运行时被加载进来。因为它们和游戏源代码没有什么其他的联系，所以在编译的过程中，两者甚至不需要存放在同一张磁盘上。游戏引擎并不关心这些数据具体是什么，它只是负责将它们读取出来，然后“扔”到某个地方就行了。所以你需要以某种方式将游戏内容交给外部文件来加以处理。这样一来，你就只需要编写一段短小而又紧凑的代码并在某一段时间将所有这些物体描述由硬盘上加载进来就行了。这种方法到底有多么的高明，可参看图1.2。如果能将你的物品描述转移到外部文件中存放，那么它们就会像图形和声音一样灵活了。因为如果采用这种方式加以处理，你就只有在运行的时候才需要使用它们。

图1.2  逻辑和具体实现相互分离的方法

这样做的第一步就是你要确定到底该如何在文件中存放如下的这些内容：

ItemArray [ 1 ].pstrName = "Magic Potion Lv 6";

ItemArray [ 1 ].iType = MAGIC_RESTORE;

ItemArray [ 1 ].iPrice = 250;

ItemArray [ 1 ].iPower = 60;

单纯就这一个例子而言，它的转换过程将会非常简单。你只需要将等号右边的所有内容提取出来，然后存放到某个ASCII文件中即可。尽管这些载入过程是由一个名为loader的程序负责完成的，但它们毕竟是真实值。下面就是Magic Potion在新的、更加灵活的、基于文件的格式中所采用的表示方法：

Magic Potion Lv 6

MAGIC_RESTORE

250

60

几乎和前面的表示方法完全相同，唯一的区别就在于它所封装的所有C/C++代码都是被分离的，这些代码将会在后面部分进行处理。就像你所看到的一样，这种物品描述文件的格式非常简单，物品的每个属性值都占据单独的一行。下面就来看一看该采用什么样的步骤来将这些内容装载到游戏当中：

（1）打开文件并确定物品描述数组里面的哪个索引是用来存储相关内容的。你可能会以循环的方式来存放这些内容，所以这里就涉及到一个简单的循环计数问题。

（2）读取第一个字符串并将其存放到变量pstrName中。

（3）读取下一行，如果本行的内容是HEAL，就将变量iType赋值为HEAL。如果是MAGIC_RESTORE，就将其赋值为MAGIC_RESTORE。依此类推。

（4）读取下一段内容，将其由字符串类型转化为整型并将其存放到变量iPrice中。

（5）读取下一段内容，将其由字符串类型转化为整型并将其存放到变量iPower中。

（6）重复上面的第（1）～（5）步，直到所有的物品都被赋值为止。

或许你已经注意到当从文件中读出数据后，并不能直接将它赋值给iType。这是因为在ASCII类型文件中，所有的物品描述都是以字符串的形式存放的，但是在C/C++文件中它们却是以整型常量的形式表示。同时，也需要注意到在第（4）步和第（5）步中，在进行赋值之前需要先将字符串类型转化为整型，这同样也是因为ASCII文件仅仅处理字符串类型的数据。

好了，你现在已经很好地完成了任务。如果你将每个物品都直接编码到游戏当中，那么毫无疑问你将会陷入到噩梦一般的处境。现在好了，你已经把自己从这个问题中解脱出来了。你现在可以很随意地修改和调整你的物品，并且不需要再像以前那样耗费大量的时间。同时，你现在也已经取得了很大的进步，已经真正明白游戏脚本编程的概念了。虽然这个例子非常具体，而且也仅仅只是本书关注焦点的一个前奏（这个问题稍后将会详细地加以讨论），但是它却清清楚楚地说明了所有类型的脚本编程背后的基本准则——如何避免硬编码。