源码下载地址:http://code.google.com/p/loon-simple/downloads/list
根据wikipedia的解释：脚本语言（Script language，scripting language，scripting programming language），是为了缩短传统的编写-编译-链接-运行（edit-compile-link-run）过程而创建的计算机编程语言。此命名起源于一个脚本“screenplay”，每次运行都会使对话框逐字重复。早期的脚本语言经常被称为批次处理语言或工作控制语言。一个脚本通常是解释运行而非编译。脚本语言通常都有简单、易学、易用的特性，目的就是希望能让程序设计师快速完成程序的编写工作。
对于脚本语言，想必我们这些Java程序员都再熟悉不过，因为我们每天都在使用的Java，从严格意义上讲也是一种解释型语言——毕竟class是凭借JVM进行字节码解释才得以执行，故而长期被排斥于编译型语言的门槛之外（但是，由于Java有编译过程，若CPU支持字节码那么class就可以脱离JVM限制，说Java是纯粹的解释型语言似乎也很不妥＋︿＋……期待java cpu普及中……）。
在这个讲解AVG游戏开发的系列博文中，为什么会提到脚本引擎的制作及应用呢？笔者将在下面加以说明。
在游戏开发中，我们将无可避免的遇到很多重复性工作，比如角色A-Z的创建，物品0-n的编辑，对话x->+∞的添加等等——这些并不是需要复杂的编码，甚至仅是单纯的数据录入，但由于数据量庞大，通常也会耗费相当的时间进行设定。
如果让您来做，要怎么办呢？以最直观的方式来说，可能有些人会考虑硬编码，直接编码似乎能省去很多的麻烦事。
OK，或许我们完全可以采过硬编码方式解决问题，比如建立一个对应物品的class，而后为其添加各种对应字段。
那么，假设现在我们在某个同人游戏的开发中这样干了，并且将游戏对外发布。三天后，问题来了，有人反映某物品——我虚构个名字，就叫[对抗网瘾专用电棍]吧。有人反映它杀伤力太低，且对[网瘾]状态无伤害加成……嗯，我们考虑后认为有道理，怎么办呢？一个字——改，反正就是一两行代码的事情，重新编译，打包，发布——简单简单。
这下高枕无忧了吧？可惜，出乎我们意料之外的事情又再次发生，又过了两天，有玩家反映我们的最终BOSS[真.红色有角.砖家叫兽地狱鬼畜模式]的大招[终极网瘾扩散]会将所有我方角色全体[网瘾化]，并且会持续投掷[对抗网瘾专用电棍]攻击我方角色，由于改版后的[对抗网瘾专用电棍]攻击力太强，并对[网瘾]状态有极强的伤害加成，我方角色很容易便会被BOSS团灭。
你问我这下怎么办？硬编码的还有什么新鲜，只能再重新编译……用户就是上帝，上帝让改就改吧……但是，尽管我们非常努力，却总有欠缺在这个游戏中存在，如果这样改下去，三次、四次、十次、二十次|||，次次都需要重新编译及发布，就是再简单也受不了了（做Java还好，搞C/C++的很多人都经历过守夜等编译结果吧……），恐怕最终此游戏只好停止发布，烂尾了事。如果你将每个物品都直接编码到游戏当中，那么毫无疑问你将会陷入到噩梦一般的处境。
为什么我们不能选择更加简单的方式来处理呢？既然每次重新编译、重新发布程序那么麻烦，干什么不将配置放在游戏外面呢？实际上，我们完全可以创建一个文本文件记录下所有物品参数，而每次更新时，我们仅需修改此文本文件便可以改变整个游戏中的属性设置，再也不必事无巨细都重新编译、重新发布整个游戏了。
事实上，笔者之所以耗费笔墨写这么一个例子，无非是为了说明脚本应用背后的基本准则——简化软件制作流程，避免硬编码。
脚本可以使你真正在游戏引擎之外编写代码，然后再将这些代码加载到游戏引擎之中并对它加以执行。一般情况下，脚本是按照它们自己的语言格式进行编写的，使用何种语法完全由脚本引擎决定，脚本就好像是运行在游戏程序内部的小程序，它们的工作原理和其他的普通程序一样，你可以使用一个普通的文本编辑器来编写它们，然后在你的主程序中执行它们。脚本通常使用它们自己的编译器或者解释器，它们对游戏主引擎并没有任何影响——除非你希望它这么做。
同时，游戏和脚本之间通常是分离的。你可以像加载图形、声音，甚至早期的物体描述文件一样加载脚本。但是，你并不能在显示器上将它们显示出来或者是通过喇叭把它们播放出来，取而代之的是，你可以执行它们，它们也可以和你的游戏进行通信，而游戏也可以作出应答。
简单的说，如果我们将游戏引擎和游戏数据理解为人与积木，那么脚本就是用来搭建积木的图样；如果我们将游戏引擎和游戏数据理解为海洋与大陆，那么脚本就是通行在海洋与大陆间传递资源的货轮。
游戏脚本是游戏引擎不可或缺的最佳搭档。
可能您会问，既然脚本有这么多的好处，想必制作起来很麻烦吧？
关于这点，需要从不同的角度来加以考虑。如果我们以groovy、ruby、python、lua、angelscript这些已经成熟或接近成熟的脚本语言为标准来看，那么开发一种脚本语言的确是件很复杂的事情，涉及到易用性、执行效率、安全性、资源回收、并发等等许多的“额外”问题，而且既然有groovy、ruby、python、lua、angelscript这林林种种，我们也大可不必耗费心智来重复发明轮子。
但是，如果我们从与游戏引擎交互，减少游戏代码量的角度出发，那么自己设计的脚本与自己游戏引擎间的藕合性当然会较第三方的脚本为高，代码量也当然会更少，而且维护管理也更为简便。况且交给脚本来执行的部分，通常也不会对运行效率有太高的要求，我们与大师的差异，也仅仅是体现在决定成败的“细节”方面，单就构建脚本解释器本身而言，完全算不得难事，甚至简单到一两个小时就可以搞定一个具有初步功能的脚本引擎（别说脚本，很多80后乃至90后的程序员都开始自己写编译器玩了|||……）。
比如TJS（就是做吉里吉里那个）及RGSS (Ruby Game Scripting System)等，都是为了更加适应自身游戏引擎而开发出来的游戏脚本语言。
下面我将提供一个非常简单的脚本解释器代码，主要功能被集中在一个Command类中。
最低0.47元/天 解锁文章
6812
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
