脚本语言作用.docx

脚本语言在游戏发展中的作用作为引擎技术中的一项分支技术，脚本语言是一个非常重要的模块。那么，这种技术对于游戏业的发展起到了什么影响？请耐下新来听我慢慢讲述这个过程。 我想各位都知道，早期的游戏制作人、监制、或者说的时髦些叫做导演也好，至少是半个程序员，而且往往还是懂得“汇编语言”这种“甲骨文”的那种。因为那时候的开发工具和环境都十分简陋，如果一个制作人想要实现自己想法，最直接的方式就是自己把代码写出来！但，假使这位制作人（比如宫本茂先生）对于编程一窍不通，那么他只能尽可能地和负责程序编写工作的同事进行沟通，让程序员通过代码将制作人的想法描述出来。固然，程序员可能无法很好地理解制作人的意图，最初编写的游戏运行结果可能和制作人的描述有所区别。不过这并不是什么大问题，制作人可以进一步和程序员进行沟通，对程序进行修改。如果这种沟通工作做得足够好的话，毫无疑问，制作人的意图最终会准确地表现在游戏中。至少在PS之前，制作人和程序员都在以这样的方式良好地合作着。然后，SS和PS来了，3D来了，大容量CD来了，空前复杂的游戏逻辑来了，然后，问题随之而来了。我们可以想象一下，问题最早是在这样的一种情形下爆发的：某天下午，我们制作人愉快地来到了程序员的办公桌旁，像往常一样问道：“程序君，请你修改一下勇者手中宝剑的作用，我希望当这把宝剑砍中敌人的时候，会使敌人产生中毒的效果。” 程序员：“咕，事实上这可能要花些时间，你可能要等上3个小时后才能看到结果。制作人：“什么！3个小时！我只是改动一把宝剑的作用就要花上3个小时！可是昨天你把宝剑的攻击力从15改为34的时候只花了几分钟而已啊。” 程序员：“是的，那只是改动一个数值而已，我只需要修改一下数据文件而已。但是，产生中毒效果是一个逻辑事件，如果我要修改该逻辑事件的话，就必须重新编译程序，这个编译过程可能要花费3个小时。”制作人：“为什么？为什么修改该数据不需要重新编译，而修改该逻辑事件却要重新编译？”程序员：“这个问题很难用一两句话解释清楚。”（出于同样的原因，我也不打算向各位解释这个问题，否则这篇文章恐怕会变成一篇超过5万字的技术论文。）制作人：“但也不至于要3个小时吧，之前开发SFC项目的时候，你每次不是只花了十几分钟就编译好了么？”程序员：“这个问题也很难用一两句话解释清楚。”（同上）制作人：“哦，天啊，如果改动一点点逻辑都要这么长时间的话，我们怎么调试游戏呢！” 事实上，以上的情景是一个十分极端的例子，但凡一个合格的制作公司，都不可能到了PS时代还在延续SFC时代的开发方式。但，这个例子确实反映当时游戏开发中的一个普遍问题：由于游戏越来越复杂，编译一个游戏所要花费的时间也就越来越长。由于当时技术的落后，程序员往往会把游戏中的“逻辑事件”直接写在代码中。这样一来，当“逻辑事件”改变时，代码就必须改写，而改写后的代码就必须重新编译。如此一来，每一次改动“逻辑事件”都意味着漫长的编译过程。诸位玩过“暗黑破坏神”的玩家可以想象一下，暗黑中的武器平衡性都经过了漫长的测试和调试。如果暗黑采用的是之前的例子描述的方式来开发的话，那么上百件武器的每一次调整都要经历漫长的编译过程，这是多么恐怖的事情.而脚本语言就是为了解决这个问题而被引入到游戏开发技术中来的，关于脚本语言的实现原理，我不在这里做详细的说明。各位只要知道，有了脚本语言之后，游戏中的逻辑事件可以作为一种资源被加载。简单地说，“会使敌人产生中毒的效果”这个事件不再是写在游戏的代码中，而是写在一个独立的文件中。当游戏中的勇者使用宝剑的时候，游戏的核心程序中的“脚本语言解释器”会去读取这把宝剑所对应的事件文件，如果事件文件中写着“会使敌人产生中毒的效果”，那么宝剑就会获得“会使敌人产生中毒的效果”的能力。而如果制作人突发奇想，想要这把宝剑能够使敌人被传送到某地，那么程序员只要将这个文件中的内容改为“能够使敌人被传送到某地”即可，而不用重新编译整个程序。这一功能极大地方便了游戏的调试和开发，可以想象如果没有这种技术，复杂的游戏几乎没有被开发出来的可能性。（这里我要说明一下，虽然我之前以暗黑为例，但暗黑采用的不是脚本语言技术，实际上解决一个问题有很多种方法，脚本语言也并非适用于所用情况的“万用技术”。）说道这里，如果你是一个思维敏捷的人，应该会很容易想到，其实不只是宝剑的属性，游戏中的所有逻辑都可以用脚本来描述。那么当所有的逻辑都被以脚本来描述的时候，游戏程序中剩余的核心代码还剩下些什么呢？应该只有绘图，声音播放，输入输出等功能了，当然，一定还包括一个用于解读这些脚本语言的模块。如此一来，剩下的这些核心代码不就正是一个“引擎”了么！于是，很自然地，引擎技术将脚本语言作为一个子模块引入了进来了。有了这一技术，引擎更是如虎添翼。如果抽象地解释这一作用，大家可能很难理解。大家可以回忆一下CS，这个游戏是有两个高中生在暑假完成的。两个高中生为什么能够在如此短短的时间内使用当时第一流的3D引擎完成一个如此复杂且有有趣的游戏呢。原因就在于CS所使用的HL引擎引入了一套非常完善的脚本语言。有了脚本语言之后。这两位高中生不再要考虑如何合理地调用引擎中的各种接口，而只要用脚本语言描述自己所要制作的游戏中所包含的规则即可。HL引擎中的脚本语言解释器会加载这些规则，并向引擎的核心层解释这些逻辑。核心层根据游戏逻辑去自动处理复杂的底层操作。 引擎屏蔽了硬件层和一些最底层的复杂操作，而脚本语言进一步屏蔽了引擎的最底层的复杂操作。于是，现在的游戏开发者只要描述游戏的规则即可，而且由于脚本语言远比传统语言简单，所以只有一点程序基础的人，都可以用脚本语言编写出复杂的游戏来。这不但使得传统游戏开发行业大大受益，也是的大量的独立制作人得以蓬勃发展。可以说，没有脚本语言，就没有今天种类如此丰富数量如此之多的游戏。最后想说一点，和所有的技术一样，脚本语言也有缺点，最明显的一点就是，使用脚本语言大的游戏，运行效率相对较低。因为脚本语言解释器会消耗大量的系统。虽然，这些消耗对于PS3或360级别的主机只是九牛一毛，但是对于NDS等掌机或移动平台来说还是不小的。不过这已经不再本文讨论范围之内。谈到这些也只是想让大家了解到，现在对于游戏的优化已经不可能像FC时代那样1k内存那样的死磕了。事实上，有时候为了游戏的整体效果和开发的便捷性，必须牺牲一部分性能。实例：setScreenPos(287,193) /屏幕停在(287,193)这个坐标上 screenStay(10) /画面暂停1秒 moveRole(-5, -3, 18) /主角朝左上方移动18步 say(-1, 落星, 斯沃特，你去哪？！) /落星说话，把落星的头像贴在屏幕左边 setRoleDir(ru) /主角的面向设置为右上 say(0, 斯沃特, 你管不着!) /主角说话，头像放在右边 say(-1, 落星, 你找死！) /落星说话，把落星的头像贴在屏幕左边 setVibra(20) /屏幕震动2秒 say(0, 斯沃特, 你敢打我!) /主角说话，头像放在右边 以上就是一段脚本程序，其中的中文是我加的注释，大家可以看到实际上就是在写游戏剧情，而且很简单，一个谁都能看懂的英文单词+几个参数就OK了，原来写游戏就是这么简单？呃、 的确，写脚本“看上去”的确就是那么简单，但仅仅是“看上去”而已。名词解释：1：ss 相当于游戏机，是SEGA世嘉集团继MD（世嘉5代）后第一个32位元主机，他的出现基本标志着32位主机时代的到来（32为指的是游戏机CPU的处理位元）也是世嘉集团历史上最成功的主机，无论在支持厂商和普及量上都达到了该公司历史的颠峰。2：ps 相当于游戏机，是索尼集团进入游戏界第一步，由于其与任天堂公司开发3