来源不清,随笔


本帖最后由 依克西昂 于 2010-12-9 18:06 编辑程序员


以前提到要写一篇关于脚本语言技术的文章,我也确实认真的写了,只是完成以后我发现,这篇文章实编程

在是太“专业”了一些。且不说读者是否可以理解,单就趣味而言,这篇文章也是索然无味。
我想,其实脚本语言并不是游戏开发中的专有技术,而是广泛应用于各类软件项目的一种技术。若是单独工具

介绍这种技术,未免会远离与游戏相关的话题。因此我决定从新立题,以专门介绍脚本语言在游戏开发性能

中所起到的做用为立意,重写这篇文章。因而,便有了如下这篇拙文。还望你们多多指正。
做为引擎技术中的一项分支技术,脚本语言是一个很是重要的模块。那么,这种技术对于游戏业的发展开发工具

起到了什么影响?请耐下新来听我慢慢讲述这个过程。
我想各位都知道,早期的游戏制做人、监制、或者说的时髦些叫作导演也好,至少是半个程序员,并且测试

每每仍是懂得“汇编语言”这种“甲骨文”的那种。由于那时候的开发工具和环境都十分简陋,若是一优化

个制做人想要实现本身想法,最直接的方式就是本身把代码写出来!但,假使这位制做人(好比宫本茂调试

先生)对于编程一窍不通,那么他只能尽量地和负责程序编写工做的同事进行沟通,让程序员经过代接口

码将制做人的想法描述出来。当然,程序员可能没法很好地理解制做人的意图,最初编写的游戏运行结游戏

果可能和制做人的描述有所区别。不过这并非什么大问题,制做人能够进一步和程序员进行沟通,对

程序进行修改。若是这种沟通工做作得足够好的话,毫无疑问,制做人的意图最终会准确地表如今游戏

中。
至少在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内存那样的死磕了。事实上,有时候为了游戏的总体

效果和开发的便捷性,必须牺牲一部分性能。

http://192.168.0.22/avatar_real/pic/0/0/112/0/0/0/113/114/115/0/116/0/0/0/0_0_112_0_0_0_113_114_115_0_116_0_0_0.swf?v=0

相关文章
相关标签/搜索