解释型脚本是大量游戏中需要用到的，用以控制触发器、规则系统和数据系统的一个重要措施。RPG游戏中尤其大量用到了脚本来控制剧情的变化、战场细节等等。即便是在非RPG类游戏中，各种各样的脚本也是被大量运用的。

这里的脚本，并不指代那些"材质脚本""Shader脚本"，对我而言，那些不能叫脚本，而只是配置文件，这两个的意义有些不同。脚本是用来执行的，而配置文件则是用来配置、调制的。无论其表现形态如何，是XML？是INI？还是别的，只要是被解释器装载、逐行解释并运行，就是解释型的脚本。

解释型脚本简单易学，耐用。就像名枪AK47，结构简单，经久耐用，高寒、干旱、湿热条件均可应用，每一本编译原理书其实都会花很大的功夫来讲解释原理，正可谓是资源取之不尽用之不竭。我们当时的编译原理课时严重不足，来得及讲完的也不过就是解释原理而已，可惜如何在目标机器上编译出来目标代码、如何把目标代码连接为机器码，都没有学到，惭愧！遗憾！

既然没学过真正的编译原理，因此目前为止所作的也不过就一个很简单的解释器而已。

可惜的事情来了，既然没有学过编译原理，把代码编译为机器代码几乎是不可能的事情，难道写C++或者C的代码，最后交给C++或者C的编译器去编译？虽然这样有先例，但那样也没什么意义，还不如直接硬编码。

后来想想，干嘛把问题考虑得这么复杂，编译，为何要编译？解释器的关键在于逐行解释，每一次运行解释脚本都会重新解释，对于很多游戏来说，这是一个无法容忍的行为。编译的作用就是把脚本代码一次编译为连续的、固定的指令序列的集合，只要脚本没变、以及除开随机数的影响，两次执行同样编译后指令的结果应当是完全相同的。其他还有吗？应该没有了。

其实现在已经有这种编译器，在游戏中也有所应用，Python等脚本语言都提供了编译功能，这种编译其实相对就简单很多。

可以这样理解编译过后的代码：那是一系列指令或者说基本元素的集合，没必要把这些基本元素复杂到细微到Push、Pop、Jump等汇编级别，实际上根据需要，我们可以非常粗略地给出基本元素：按照功能可以把元素划分为行为子和算子，例如GetHP指令获取某物件的HP（如果有），或者MoveTo将某物件设置为MoveTo某位置的状态，最后的算子最为简单而不可或缺，如：与或非、加减乘除、位算符、地址算符、域算符（用于基于对象）等等。这样的一系列代码，对于上层的使用者来说很简单，不必要注意一些不需要注意的细节，同时又能保证扩展性，如果需要新的元素，只需要添加新元素就可以了。就像CISC那样，我不用精简指令，用的就是复杂指令，需要就添加一个复杂指令，效率？要效率的话你就不要玩这个了，去玩机器代码吧，那个效率最高。这本就不准备注意效率，而是去注意开发的效率。在中国，开发了5年的游戏有几个？大部分2、3年就撑不住了，还等你有时间去折磨5年？那只有在特大规模的公司和企业才可能，在中国目前的情况：物力、人力财力是不可能做到的。除了行为子和算子外，更重要的是数据，如何把数据——更多指的是变量——在运行时对应到每个指令上去？这个编译原理的教材中都会提到，我还没有动手，因此就不随便写了，等做完了再写吧。

编译的开始，逐行扫描分析脚本指令，将之打散为基本元素的关系集合。如果脚本是过程性的，那就需要注意出入栈的问题，而如果是基于对象或者面向对象的，目前还没有思考过。最后将所有的基本元素以一种更为精简快速的数据格式存储到某个文件中，作为编译后的目标代码。在执行游戏的时候，我们预先装入这些目标代码，将之转化为用数组或者其他数据结构存储的指令序列。这样就不用解释脚本了，每次运行到目标代码的时候，只需要提供相应的数据，然后调用For循环运行所有的指令就可以了。

我原来用过3DGS，当时听说那个是编译的脚本，刚刚写完解释器的我受触动很大，后来我狠狠查了查3DGS的文件，觉得3DGS好像没有真的把脚本编译为机器码。3DGS的脚本相对是比较RISC的，指令大凡都是简单指令，因此写起来非常难受，比写C还难受。CISC还是RISC是一种具体做法的区别，前者省了脚本编纂者的事情，但是比较费力，不好把握，后者会让脚本编纂者头疼，但是比较好把握，而且挑错比较容易。

粗略写写，请大家帮我看看有没有什么疏漏，期待与您的交流。

发表于 @ 2004年12月10日 16:45:00|评论(loading...)|编辑