游戏设计基本流程全解析（二）

　　上一篇我们讲到第5点，关于角色扮演游戏的升级系统研究，接下来我们继续第6点。

       6、游戏中的智能系统处理

　　游戏中的智能对手

　　AI在游戏中最普通的形式是创建计算机控制的对手。因为大多数游戏是单人游戏，所以要设计游戏者在游戏中必须战胜对手。为了达到这个目的，你可以使用某种类似A*搜索的简单AI算法，以帮助对手穿过迷宫向游戏者发起进行。你也可以使用简单的算法预测游戏者的反应。

　　但是，记住没有必要创建世界上最强大的对手。你的对手只要能给游戏者提供足够的挑战性就可以了。还有，要注意游戏的内容。例如：一个战棋式RPG游戏中策略占的是主要地位；而在纯RPG中故事情节和角色开发就更重要一些。千万不要因为计算机对手太强大而让游戏者们陷入失败的泥沼。

　　游戏中的非智能对手

　　通常，在游戏开发中AI技术是与计算机对手紧紧联系在一起的。这是因为早期的大部分类似角棋的游戏是一对一的。但是，任何好的探险游戏或RPG游戏开发者都知道，AI同样可以用于非对手角色。例如：如果你正在建立一个RPG游戏并且你想让你的世界活起来，这就是说，让城市里的人以智能的方式活动，那么你可以使用某种算法确定在一天中的某个时候，角色应该在那里。你可以使用类似于AI算法如A*来辅助你将一个对象从一处移动到另一处并绕过障碍物。

　　游戏中的智能系统

　　游戏中的AI在本质上是最具有模仿性的，但它们基本上是依赖一些AI要素。你可以将所有具有决策功能的对象在一个游戏中融合为一个整体。例如：在一个战争游戏中，你的各个部分可以依据各自所处的具体环境来做出各自的AI决策。

　　使用这种方法，你得把精力集中于怎样在各个独立的决策个体之间建立联系，以及这些联系怎样才能使游戏成为融会贯通的整体。是用一个高级决策影响其它决策，还是各个决策个体之间平等地互相影响呢？举个战争游戏来说，你有十辆坦克，它们的思维模式基本相同。所以它们都决定去攻击敌人阵营中HP值最低的一辆坦克。但是这时其中一辆坦克说：“这个敌人归我了！”那么剩下的九辆坦克就应该依据这条信息各自调整下一步的攻击目标。当你建立智能个体时，要考虑在一个智能系统整体环境下，它应该如何行动。

　　7、电脑游戏中的人工智能制作

　　电脑游戏随着硬件执行效率与显示解析度等大幅提升，以往很多不可能或非常难以实现的电脑游戏如此都得以顺利完成。虽然电脑游戏的呈现是那么地多样化，然而却与我们今日所要探讨的主题，人工智能几乎都有着密不可分的关系。

　　在角色扮演游戏中，程序员与企划人员需要精确地在电脑上将一个个所谓的“怪物”在战门过程中栩栩如生地制作出来；所以半兽人受了重伤懂得逃跑，法师懂得施展攻性法术。

　　目前能让人立刻想到与人工智能有密切关系的游戏有两种：

　　一是所谓的战棋／策略模拟游戏，二则是棋弈游戏。人工智能的比重与深浅度，在不同的游戏类型中各有不一。有的电脑游戏非标榜着高人工智能不可，不然没有人买；有的则是几乎渺茫到让玩家无法感觉有任何人工智能的存在。

　　导向式思考

　　AI最容易制作的的方式，同时也是早期游戏AI发展的主要方向就是规则导向或称之为假设导向。在一些比较简单的电脑游戏中，程序员可以好不困难地将游戏中的规则与设定转化成一条条的规则，然后将它们写成电脑程序。让我们以角色扮演游戏为例。决大多数的企画在设定所谓电脑怪物时，所设定的属性通常有以下几种：

　　生命值攻击力防御力法力属性

　　最后一个“属性”是我在设定时喜欢增加的项目之一。透过这项属性的设定，我可以把怪物设定成“贪生怕死的”，也可以把战士设定为“视死如归”。以目前我们所掌握的资料，在战门系统中的大纲如是诞生了：

　　规则一

　　

　　规则二

　　

　　由以上一连串的“如果－－就－－”规则设定，建立了最基本的ＡＩ。说这样的制方式只能建立基本ＡＩ其实并不当然正确。只要建立足够及精确的规则，这样的方式仍然有一定水准的表现。

　　规则导向的最大优点就是易学易用。在没有深奥的理论概念的前提下，仍有广大的使用群。所以很多老道的玩家常常没两下就摸清楚敌人的攻击策略，移动方式等等。

　　推论式思考

　　相信曾经接触过电脑语言课程，或是自习过相关书籍的朋友们，都曾曾经听过一个著名的程序，那就是井字游戏。用井字游戏作为讨论AI的入门教材，我个人觉得是最适当的例子。或许有人还不知道井字游戏怎么玩。只要任何一方在三乘三的方格中先先成一线便胜利了。我们在前面谈过的规则导向，在这里也可以派得上用场。

　　

　　有一次我在某本电脑书上，同样地也看到某些以井字游戏为介绍的范例。不同的是，我几乎看不到任何规则导向的影子。但在仔细分析该程序码后，我得到了极大的启发，原来AI是可以不用这么多规则来制作的。它用的方法正是在电脑AI课程中重要的概念：极大极小法。我在这里只说明这法则的概念。继续以井字游戏为例，电脑先在某处下子，接着会以假设的方式，替对方下子，当然，必须假设对方下的是最佳位置，否则一切则毫无意义。在假设对方下子的过程中，自然又需要假设我方的下一步回应，如此一来一往，直到下完整局游戏为止。

　　国外的一些论坛曾举行过256字节的游戏设计比赛。作品非常多，其中有一件作品正巧也是井字游戏。作者用区区两百多行就写了与上述程序演算方式完全相同的作品，可见功力确实了的。另外，我也很希望类似的活动能在国内推展起来。对了，在这样的比赛条件限制下，除了汇编语言外，几乎没有其它的选择了。

　　7、游戏引擎小谢

　　早想写一点游戏设计的文章与大家交流,一是经验的问题,二是公司正在紧张的游戏制作期,实在抽不出多少时间,一直没有动手,今天忽然头脑发热,写了一段,以后准备陆续写一些游戏创意,策划,制作,流程管理,和制作工具等方面的文章供大家参考。

　　我们的游戏设计经验主要是冒险游戏和角色扮演游戏,但我们设计游戏工具时尽量适应其余题材,不过是否可行未经检验。写这篇文章的意图一是想为游戏界做点事,抛砖引玉吧,另外是公司正在寻找志同道合的战友,我写一点文章交一交朋友,许多东西仅仅是我们的经验,不一定很好。参考而已吧

　　游戏设计工具包括游戏编辑工具和游戏引擎两块;

　　编辑工具:交互编辑游戏数据,生成游戏引擎所需的数据文件,包括以下几个功能块:图像编辑,场景编辑,物品编辑,动画编辑,人物编辑,事件编辑等,具体介绍在以后的文章介绍。

　　先从游戏引擎说起。

　　语言:VC5。0

　　操作系统:WIN95

　　图像引擎IRECTX5。0

　　支持游戏风格:各种类型和视角以及多层次的冒险游戏和角色扮演游戏

　　整个游戏引擎包括以下功能块:

　　资源管理:图像库CIMGLIB,声音库CSOUNDLIB,通过编辑工具形成的资源文件来定义,每种资源包括定义管理和一些操作接口。图像库图“像包括多种格式(BMP,GIF。AVI,FLC等)以及他形成的内存格式定义,子图定义(每一张图片包括许多小图,需定义它的小图位置,当然可以自动生成),游戏需要的特殊定义,比如行走,身体性质,中心定位点,触发区,可以根据自己的要求扩充各种性质定义。图像最好允许图像组合定义。声音库包括WAV和MID的定义和再现。资源由IMGLIB。DAT和SOUNGIMG。DAT定义,调试版本中最好不要将资源打包,而是指向正常的文件名,发行版本中再打包,这样修改和不同工作人员协调容易一些,否则最好有一个自己的资源管理器。我们在调试版本中数据文件采用文本描述格式。许多数据可以手工编写而不需要专门的编辑工具。

　　资源管理对象还包括内存管理,比如设置时间阀释放长期不用的资源。

　　声音管理:CSOUND,包括Creat(),Sound(char*fileName。。。),SetPos(),等,DirectSound有一些函数,我们要做的是封装简化,减少对外的接口。

　　窗口系统:接管标准窗口系统,一个完善的游戏引擎最好有一个自己的界面系统,至于简单还是复杂根据自己情况具体分析,一个具备基本功能的界面系统1000行程序就可以对付下来,需要窗口系统的原因是一般的图像引擎不支持标准窗口,二是可以便于移植到别的操作系统。在我们的游戏引擎中,游戏只是窗口系统的一种特殊控件(CWINGMCTR),因此可以实现多窗口游戏等特殊要求。

　　CWINGMCTR是一种特殊控件,通过他来控制游戏。包括控制和显示。

　　图像引擎:所使用的图像引擎的管理,我们使用的是DirectX,包括Creat(),CreatSurface(),OutToScr(),Bilt()等对外接口;他不是游戏的重点,我们尽量将图像引擎细节封装起来。

　　图像管理:这是处理图像的中心,一般处理游戏显示喜欢以某种图像引擎为中心来设计,我觉得最好设计自己的对象来封装别人的图像引擎,这样不会因某引擎而受限制,移植也比较容易,我们虽然使用的DIRECTX,但实际上对外的接口是一种CPICPAGE的界面,他不但包括DIRECTX的surface,也包括标准的位图,AVI界面,GIF动画界面,以及自定义的格式,他将各种类型的图像统一起来,对外使用统一操作,比如DRAWTEXT,BILT,LINE等标准图形图像操作,以及扩充的ALPHA通道,透明度等操作。为了减少内存的需求,特别是16M高彩,不要将全部图像使用DIRECTX的表面,对一些刷新不多的图像,比如背景,可以使用标准256色位图,甚至一种GIF表面,需要时再解压,我们还使用一种单色位图用来从背景中抠图,比如一所场景中一棵巨大的树,只要不是动画,我们可以用单色抠图的形式从背景中扣除来作为另外一层,这样我们可以大大降低图像的内存需求。因此采用全部手绘(或3D场景),而不是小图拼贴的场景成为可能。通过各种手段可以节约60%的内存需求。

　　CPICPAGE可以通过TimeTrace()以及多线程来改写内容,比如AVI的改变。

　　游戏控制:这部分包括显示和控制,由CGAME->CGAMEPAGE->CGMOBJ对象组成,CGAME是总控对象,包括许多CGAMEPAGE游戏页,CGAMEPAGE是一个具有连续场景的游戏片断,有点类似于游戏的一关,CGAMEPAGE由一系列CGMOBJ组成,CGMOBJ是游戏的基本对象,由他继承出地图,物体,物品,人物,武器,动画,触发器,多媒体按钮等特殊

　　游戏对象,这是一个根据游戏要求不断丰富和改写的部分,对外的接口是:SendDraw(),Draw(),TimeTrace(),AcceptMsg(),SendNetMsg(),AcceptNetMsg()等,他是通过CWINGMCTR来调用,每种对象有许多控制参数,对象之间允许通讯,以及有自己的生长死亡发展的控制,尽量做到对象与外界减少直接接口,通过消息实现交流。

　　对象分为两类:景色对象和活动对象,

　　景色对象定义了组成场景的元素,包括背景和前景两层,可以是由整个图片组成或由RPG常用的图片拼贴法的组成,它的特点只作为背景或前景,活动物是在他们的之间活动,一般定义后不做改变,也不做控制,由于支持图像界面多格式,所以我们可以方便地使用AVI或GIF动画作为背景来增加场景的效果和真实性。景色还包括了行走性质定义,我们采用的是8x8为一单元,每个单元定义了一种性质,比如平地,草地,障碍物等。

　　活动对象是在背景和前景之间活动,他们之间有相互的位置关系,前后关系随着位置改变会不断改变,因此他在所属的CGAMEPAGE中次序是动态的。对象的关系一般是由Y轴定义,由于要支持斜视角和复杂的地形结构,光靠Y轴是不够的,我们引入了地基线的概念,通过在地基线之上还是之下来判断前后关系,地基线的定义在图像定义中描述。活动对象有复杂的参数,可以接受外界消息,可以有自己的各种反应。我们在引擎中使用了一种描述语言来描述他们的反应,比如对鼠标击打,人物经过等产生参数改变,发声,对话等的回应。描述语言将作为专门的一章来介绍。游戏显示过程是这样的,在每次刷新期时窗口的游戏控件调用他所属的游戏页CGAMEPAGE->SendDraw();游戏页将要显示的对象按前后次序送往窗口,同时注明此对象是否改变,窗口分析改写的区域,调用每个对象的Draw()接口来刷新活动的区域,为了增加速度,并不是显示所有的区域,而是只改写活动区域,因此我们设计了一个CCLIP的对象来管理刷新定义,它的原理是将表面分为16*16的单元,最终显示时计算出优化后的多个剪切区域。整个窗口系统和每个游戏控件拥有自己的CCLIP对象。另外一项增加速度的方案是游戏控件拥有一个比显示窗大两倍的显示页,这样场景滚动时只要将显示位置改变即可,不用刷新所有区域。游戏控制的过程是这样的:AcceptMsg()来接受各种消息调用脚本来改变自己参数和状态并影响别的对象,另外每次时钟来时,调用每个对象的TimeTrace()来改变状态,比如动画改变,运动轨迹改变,观察周围的对象做出反应等。

　　系统控制模块:对系统的参数做出反应。不同的题材控制不一样,比如即时战略等。只要改写这部分以及扩充游戏对象,引擎便能支持不同的题材。至于人工智能,智能行走,只是对象的方法,比较简单,只是需要时间。游戏控制部分比较复杂,每一种游戏对象都有许多控制的细节,在这篇文章里不做具体描述,以后再说吧。

　　最后一个是网络模块:我们正在开发的是国内第一个图形化MUD游戏,网络是它的核心部分,介绍网络的内容很多,需专门文章。我们使用的不是DirectPlay,使用的是WinSoct,考虑的是UNIX作为服务器的需求。网络要解决的难点是安全,同步和数据压缩,这里要用到许多技巧。

　　游戏是通过数据文件来定义:

　　数据文件格式:数据文件包括资源定义文件和游戏定义,界面定义文件,文件的数据格式我们采用的是文本形式,类似于WEB的文本,这样的好处一是版本升级容易处理,二是可以减少前期对编辑工具的功能要求,因为我们可以用文字编辑器处理大部分数据,然后有时间再设计一个强大的工具比较现实,当然,最终提供给用户的是处理后的数据文件。他中间有一个转换模块。

　　游戏的运行流程描述(不是真正的过程,按DOS格式描述):

　

　　我们这里介绍的是单线程结构,许多部分可以用多线来加快游戏速度,但结构是一样的,就不多介绍了。

　　游戏引擎的系统分析是游戏设计技术方面的成功关键,是最容易走弯路的部分,希望我们的文章能给大家一点启发,由于今天的游戏趋向于多类型综合,设计引擎时一定不要拘泥于某一单项题材,我们在策划这套引擎时要求他支持的游戏非常广,甚至支持多媒体设计,这套引擎只要扩充或改写参数管理以及游戏对象,便能支持各种风格的2D类游戏。将来我们要做的是一套可以交互设计各种游戏的开发平台,当然不是<<游戏工厂>>似的玩具。

　　今天就写到这里,这只是对引擎结构的大概介绍,其中每一点将来都有详细的描述,欢迎同志商讨。我们尽量回答朋友们的意见,欢迎加入我们的队伍。

　　8、脚本语言浅介

　　今天，我想先以一套游戏使用的技术为蓝本，导入实务设计的范畴。你听过“ZZT”这套共享游戏吗。

　　如果没有，别太在意，这是91年发行的文字模式角色扮演游戏。我们不谈游戏本身，而把焦点放在游戏的开发系统当中。ZZT虽然老，所引用的“物件导向”设计概念可是一点都不含糊。

　　为什么需要额外设计一套游戏专属的程序开发系统？利用现有的程序语言难到不可以吗？首先，现今常见的程序语言中，大多半都是通用语言，当然也有不少专用语言，严格说来，没有一套游戏设计的专用语言。（不过，早在八位电脑时代，已有一套名为“游戏制作者”的软件，它允许使用内建的语言来开发游戏）就目前游戏主要使用的C语言以及汇编语言来说，程序员必须从无到有，制作出游戏的引擎系统。

　　如果有一套游戏开发系统，制作游戏（特别是续集）会大幅度降低程序设计制作游戏所花费的时间与精力。让我们来看看几个实际的例子：Origin的创世纪系列（人物行程管理、对话皆有专属系統）等。只要游戏开发系统规划得适宜，一旦制作完成，对日后制作的游戏程序，绝对有大补益。

　　我不想在这里就编辑器、编译器之间的差异以及设计的详细原理做讨论。虽然这些都与设计一套游戏开发系统有密切关系，但这些都属于“系统程序”课程的范畴，我们只需了解就行了。将程序与游戏资料独立安排有许多好处。你不会因为仅需要修改游戏资料，就必须重新进行“修改代码、编译、连接”等繁琐的过程。

　　你是否了解上面的程序，这类经过大量简化后的控制程序，我们把它称做脚本语言。脚本语言除了接近口语化的设计外，另加上简化后的语法。（除了内建的命令外，通常仅需简单的逻辑判断与数值计算即可胜任）因此用脚本语言制作游戏，不在是再是非程序员不可的工作（除了系统本身的修订），企画人员也可以很快地进入状态。另外，如果将来需要将游戏移植到其他平台时，比起程序与资料的盘根错节的设计，利用脚本语言来开发的游戏，只需要修改系统本身，脚本语言部分本身毋须更动，相形之下出现问题的机会与范围就缩小了很多。

　　这次以ZZT游戏为例，就是想对脚本语言部分的设计作了概念性的介绍。

　　9、RPG游戏的对话系统

　　我要和各位谈谈角色扮演游戏中的最重要的一个部份～那就是交谈系统。若是各位玩者接触的角色扮演游戏够多的话，应该会知道在角色扮演游戏中有着单句式以及关键字两种完全不同的交谈系统，今天我们就来看看这两个不同系统。

　　要怎么分辨单句式和关键字系统呢？我们可以简单的从在游戏中玩者和游戏中的人物交谈时是如何获得信息来看。在一般国内的角色扮演游戏中，经常使用的就是单句式的交谈系统，也就是那种玩者只要和角色对话，对方就会一股脑的将所有的消息告诉你，而玩者也就可以获得所有的信息，这种就是属于单句式系统（如大宇的轩辕剑系列、仙剑奇侠传等等）。就算是有的游戏用比较刁钻的方式，会要求玩者多问几次才会出现真正需要的信息（像精讯的乱世伏魔录），也不过是这一种系统的延伸使用罢了。

　　那么关键字系统呢？我想最有名的应该就是创世纪系列，在创世纪的前几代中，玩者需要自行输入各个关键字，来询问各式各样的问题，随着玩者输入不同的关键字，就会有不一样的答案。但是也因为这个原因，使得一些英文程度不好的玩者在接触那几代的游戏时相当的辛苦（反过来说，也有一些玩者因为玩这个游戏而使得英文程度大增），也使得许多的玩者不愿意接触创世纪。但是到了创世纪七代的时候，由于采用了滑鼠来进行游戏，因此整个关键字系统就做了很大规模的改进了，玩者可以由画面选择要问的关键字，因此不再会有找不到关键字来问的状况发生了。

　　那么我们来看看国内的几个采用关键字系统的角色扮演游戏吧。在笔者的印象中，好像只有精讯的聊斋志异、大宇的妖魔道、以及软体世界早期推出的一个侠影记而已。在这几个游戏中，笔者觉得精讯聊斋志异的关键字系统是最成功的，至于为什么笔者会这么认为，绝对不是因为笔者自己曾经叁与过这个游戏的制作，而是从关键字系统的结构来看，这个游戏才是真的使用到关键字系统的精髓。

　　所谓的关键字系统，正如同它的名称一样，是一个以关键字来串连游戏剧情的交谈系统，因此玩者必需要能够从某一个游戏中人物的口中获得某个关键字后，再使用此一关键字到另一名人物的口中发挥作用，这才能说是使用了关键字的妙用。在聊斋志异这个游戏中，玩者要获得第一座塔～金形塔的八字真言，就必需要先从一位书生的口中获得四字真言，然后再到酒店里找一位酒女，用这前四个字的真言向她询问后四个字的真言。而所谓的关键字系统的巧妙，也就是当玩者若是没有获得前一个关键字的时候，在后面的那个人口中是无法取得下一个关键字的。在聊斋志异这个游戏中，若是玩者不能先由书生的口中套出前四个字的真言，那么在酒女的对话选单中是不会出现那四个字供玩者选择，因此玩者就无法获得后四个字了。也就是说，关键字系统是一个凭着玩者选项不同会有不同情况的对话系统。

　　那么我们回过头来看看另外两个游戏的关键字系统吧，首先我们来看看大宇的妖魔道吧。在这个游戏中也有关键字系统，但是它的关键字系统所发挥的作用并不是在对话上，而是当某些任务还没有解决时，这些关键字就会出现在对话的选单中，让玩者可以选择它取得所需的资料，当这一项任务或是事件解决了后，这个关键字就会从选项中消失。这种作法并没有真正发挥「关键字」的作用，只是用它来提供玩者多次获得相同的问题解答而已。

　　接下来我们看看侠影记这个游戏，这可以说是关键字系统使用的错误范例，因为在这个游戏中，提供玩者选择的关键字并没有影响其他地方事件的作用，反而把原来简单的可以在单句中表现的信息切成一段一段的文字，让玩者需要将所有的关键字选择完之后才可以知道全部的信息。再加上一些关键字所得到的信息又都是没有用的信息，使得这个游戏的交谈系统完全没有表现出关键字系统应有的特色。

　　现在我们就来探讨一下这两种系统在资料结构上究竟有什么不一样的地方。首先我们来看看单句式的资料结构，记得在讨论剧情结构的那一篇文章中（第５２期），笔者曾经举过一个单线式剧情的范例吗？那种的结构就是单句式交谈系统的标准结构。因为在单句式交谈系统中，在玩者遭遇一名游戏中的角色时，角色会依据当时游戏中的剧情发展情况，决定出要说那一句话，若是在剧情没有改变的情况下，就会重复的使用这一句话。

　　在这种系统中，当玩者控制的角色和游戏中的角色交谈时，程式会依据这名角色所相对的几个旗标，判断出目前该显示出什么样的信息。若是同时有几个旗标都成立的话，也只会以最优先的旗标为准。在这种系统之下，信息的结构相当的单纯，程式也只要将每一句对话编上相对的代码，然后用判断式就可以决定出要显示出那一句信息。同样的，这种系统的资料结构也比较单纯。

　　接下来我们看看关键字系统的资料结构吧。在前面说明单句式系统的时候，笔者曾经说过要以旗标来判断显示那一句信息，其实这个所谓旗标就是游戏中控制剧情目前发展到那里的指标。同样的在关键字系统中这些旗标也存在着，只不过除了它们之外还要再加上一组关键字的旗标，而这些关键字的旗标就是这种交谈系统的重心。

　　在游戏中，当玩者从其中一位角色的口中获得一个关键字之后，这个关键字的旗标就会打开，之后若是有遇到对这个关键字有所了解的角色时，在交谈的选单中就会出现这个关键字。

　　在这种系统中，交谈的时候，程式会先判断目前玩者已经获得那些关键字，然后再看这一名交谈的对象对于那些关键字会有反应，接下来在在选单中就会出现这些有反应的关键字让玩者选择。在选择了某个关键字之后，相关的信息就会显示在画面上，同时若是有某个关键字会因为问了这一句话之后打开，也会在信息显示之后将此一关键字的旗标打开。接下来我们看看下面这个例子：

　　在这个例子中，会有某甲以及某乙两个人，在游戏的过程中玩者必需先从某甲的口中获得一句暗号，然后用这个暗号向某乙询问，才可以获得所需的资料。因此在游戏中某甲的资料如下：

　　某甲【无关键字】：喔，是你呀。我相信你一定是想要加入这个秘密的组织，不过若是没有组织的口令的话，是不可能加入的。

　　◎在这句信息后关键字「口令」打开

　　某甲【口令】：你想要知道口令？好吧，那我就告诉你，我们的口令就是神出鬼没。

　　◎在这句信息后关键字「神出鬼没」打开

　　某甲【神出鬼没】：不对不对，这句口令不是对我说的，必需要找到我们组织的某乙，然后对他说出这个口

　　令，就可以加入我们的组织了。

　　因此在这个地方我们可以看到，在开始的时候玩者和某甲交谈时会先获得「口令」这个关键字，接下来这个关

　　键字就会出现在交谈的选单中。而玩者选择口令这个关键字之后，就可以再获得进一步的资料以及「神出鬼没

　　」这个关键字。之后再以神出鬼没这个关键字向某甲询问，就可以得知这个关键字的使用方式。接下来我们再

　　看看某乙方面的资料：

　　某乙【无关键字】：对不起，我什么事都不知道，

　　请你不要来打扰我好吗。

　　某乙【神出鬼没】：你知道我们的口令，那么你可以加入我们的组织了。我们的任务是要推翻目前的政府，希望你也为这件事尽一份力。

　　◎成功的加入判乱组织了

　　从这里我们可以看到，若是玩者在还没有获得神出鬼没这个关键字的时候来找某乙交谈，那么是无法从某乙的口中获得任何的消息。但是当玩者从某甲的口中获得了「神出鬼没」这个关键字之后，在交谈的选单中就会出现这个选项，选择后从某乙处就可以得到回应，也就可以加入判乱组织了。这一种的交谈信息结构，也就是关键字系统真正能够发挥作用的地方。

　　在设计关键字系统的时候有一件事要注意，那就是需要适时的将某些没有作用的关键字关掉。就以上面的例子来说，当玩者成功的加入了判乱组织之后，这一部份的事件可以说是已经结束了，此时就可以将「口令」以及「神出鬼没」这两个关键字关闭。不过若是这两个关键字还有作用的话，就不可以这么轻率的关闭它。

　　说到这里也许有人会说其实这种剧情不需要用关键字系统，就算是单纯的单句式结构就可以处理了。但是请各位想想看，这里的剧情若是当玩者一和某甲交谈，某甲就将所有的消息一股脑的都说了出来，那么不是很没有意思吗？除此之外，关键字系统在玩者被游戏卡住的时候，还可以让玩者重复询问相同的关键字来获得信息，比起单句式结构那种不小心没有看到就会被卡住的情况来说，是不是也显得比较人性化呢？

　　前面所说的都是关键字系统的好处，但是为什么目前的游戏很少使用关键字系统呢？那都是因为要设计关键字系统的话交谈的资料结构就绘变得比较复杂了。各位想想看，原本在规划交谈的信息资料时只要针对每个游戏中的角色，配合不同的剧情段落配上信息就可以。但是在关键字系统中，设计者必需要将关键字妥善的分配到

　　各地的剧情对话中，才能使关键字系统真正的发挥作用，因此在设计剧情的时候有比较多的困难。除此之外，目前国内的公司大多有将游戏推向国外的计划。由于中国字并不是拼音系的文字，因此这些关键字一但翻译成其它国家的语言（像是韩文、英文等等）时，就会发生翻译出来的单字变成好长一串的文字，若是勉强的将一串文字删成适度的长度时，又会有可能会文不对题的问题（这种情况就好像魔法门三代中的问题被变成中文的问题那样奇怪），或是因此要增加文字显示的区域。也因为这些原因，使得国内的公司尽量的不去碰这样的系统，以免自找麻烦。

　　事实上关键字系统其实是个扩展性相当大的系统，就连游乐器的游戏中也曾经有采用过这样的系统。正因为它对于剧情的掌握比单句式的要强，以及它更结构化的资料结构，它绝对是一个完美的交谈系统。

　　10、完成制作的关键：推动力

　　我最近听到一个说法：每开始制作50个游戏，最终只有一个游戏能制作完成。这个说法可以由几个原因来解释。制作者可能太超前了以致于在技术上完成不了；项目太复杂了或制作者们在协同工作时有分歧并导致开发停止。还有更多的原因显示了这种可能性：为什么98％的游戏不能最终完成。

　　然而，我坚信以上的这些问题的影响都比不上在进度中失去推动力。成功的游戏制作者与失败的游戏制作者之间的区别并不是因为前一组成员更有才能，更聪明或更有经验。仅仅是因为前一组成员能完成他们的游戏。

　　（1）聪明，才智和经验

　　聪明，才智和经验在你的游戏制作过程中和生活中将帮助你克服困难。让我们看看，简单地击键动作并不需要大脑的思考活动，但它需要一些你正在使用的计算机语言的知识，对操作系统的一些概念。大多数知识都能通过阅读帮助文件，相关的书籍，一些示例的源代码来获得，并且你并不需要透彻了解每样事件是如何运行的。

　　举个现实生活中的例子，录像机有很多复杂的功能，你可能并不会用这么多的功能，但你仍能很好地使用录像机，使用遥控板上的放，前进，后退这几个键来操作就足够了。其它功能你并不需要掌握如何操作，那么你并不需要。编程也一样，做很多事情并不需要透彻地了解每个方面。当你进入一个新的领域，通常会阅读相关的资料来获得所需的信息。我学习一门计算机语言的方法是：简单地运行示例程序并不断地修改它，运行它，看看运行结果，来最终了解这种语言的。

　　我并不暗示你不需要去努力学习，只是举例说明这些知识并不是决定性的。如果你不了解你的游戏软件和操作系统将怎样配合工作，那么你就需要去了解操作系统本身。尽可能多地去了解你的操作环境，直到你感到能够自如地工作，只会偶尔遇到几个问题时为止。

　　（2）麻烦和推动力

　　社会的各行各业中，一个项目的完成都需要参与者的努力工作，项目完成所需的时间越长，人们就越可能会遇到更多的麻烦。游戏制作过程也不例外。

　　游戏制作工业具有多变的本质，大众对游戏画面的要求，对某种游戏类型的喜爱，对游戏趣味性的要求，会经常发生变化。所以在制作期间及时了解业界的最新动态和互相交流是必须的。否则当你开始制作一个游戏，经历过一个较长的开发周期后，你制作的游戏可能已经落伍了。

　　当你是独立制作游戏时，每次当你遇到一个问题时都可能会落入困境，特别是没有外部的支持时。制作中若有一个阶段达不到预期的目标，都可能会令你泄气。这对独立游戏制作来说是致命的。

　　对不同的人来说，解决困难的动机是不同的。对有些人来说可能是需要成功以得到其它人的尊敬，或者得到一些报酬，金钱或其它形式的。对其它人来说，动机仅仅是一种创作自己心目中游戏的渴望。无论你的动机具体是怎样的，你都需要依赖它，在制作过程解决遇到的各项麻烦。忽视麻烦或中止开发一段时间，这简直和取消项目是一样的。所以制作者必须习惯于面对各类难题。

　　保持推动力的一个方法是不断地尝试制作新的事物。每当你制作完成一个作品后，无论对你的自信心还是工作经验来说，都会更上一个台阶。如果你做了大量的工作但不能及时地看到结果，这会令你很不满意，并逐渐丧失推动力。如果你能及时地看到你的工作对作品的改变，那么制作人与作品之间的这种互动性很容易就能使你保持较高的推动力。这就是为什么强烈建议那些游戏制作的新人从一个小项目开始的原因。长周期的大项目往往需要一周或一个月的时间才能看到变化，这往往使新手变得沮丧，并最终不能完成他们的第一个游戏。

　　（3）中断一会

　　在工作中适当地中断一会是十分重要的。如果你不适当地休息一会儿，你的注意力会渐渐变得分散，工作效率会下降。我曾看过关于注意力方面的研究报告，它指出大多数人在40分钟持续的做某件事后注意力将变得分散。很明显，每隔40分钟就休息15分钟将会浪费大量的时间。然而仅仅是去拿些饮料喝或去察看有没有新邮件到来，或者做任何别的事，都会帮助你长久地保持对工作的热情。

　　在高强度的工作后，最好中断较长的一段时间。如果你遇到了一个特别困难的问题，那么最好在你开始工作前先休息一会，再解决它。短暂的休息能使你集中精力来工作，但是在你处理一件事的过程中最好不要中断，要一鼓作气。如果这个事件处理的过程很长，那么在完成一个阶段后再休息，并且做好中断点的记录，以便于下次能容易地接下做。当你在工作时，适当地中断一会对保持你工作的动力是很重要的。长时间的工作而不休息更有可能使你的游戏半途而废。

　　现在来了解什么时候该休息，什么时候该继续工作。如果你处在一个工作气氛很浓的环境中，而且制作的进度很快，那么这时你最好尽你的所能持续地工作，把你所有的热情都投入其中，渴望产品的最终完成日。产品的最终完成日就像灯塔的顶部一样，在那里，你能够回想起你在制作过程中所有的努力。要记住，当你离开你的工作时必须确定，这个中断点在你回来后能够很容易地继续下去。这意味着如果你是一个程序员，若你的代码在编译时有一些错误，那么最好不要把这些错误留到明天再去解决，因为这会使你忘记是什么原因导致了这些错误。

　　11、十分钟学会DirectX中的COM技术

　　DirectX是按照微软的COM(ComponentObjectModel)搭起来的。设计COM是希望它能提供一个更安全，易升级，可移植的软件模块。COM用的面向对象的模式比一般的C++更严格。例如，COM只能永远通过成员函数(memberfunction)进行访问，并且不能拥有公用数据成员(publicdatamembers)

　　COM异常严格地对待对象(object)和接口(interface)。而且就不让你直接访问对象，COM竟然都不给对象起名字，让你老老实实通过接口来访问对象。在DirectDraw编程中，我们讲：“访问对象”，其实都是在访问接口。叫惯了也就不改了。

　　所有的COM接口都从IUnknown接口中派生出来。“I”打头是COM接口的标识(IforInterface)。所有的DirectDraw接口都以“I”打头，但莫明其妙的是在很多编程手册中都把“I”略去。所以看书时要做到心中有爱(I)。

　　IUnknown接口提供三个成员函数，其余所有的COM接口，都继承这三个函数。

　　

　　AddRef()和Release()支持COM的一个特色功能，名字叫“活着封装”(lifetimeencapsulation)。“活着封装”是一个协议，用来让对象在崩溃时(destruction)自己负责自己的后事。

　　“活着的时候”(lifetime)每个对象内部有一个值用来跟踪记载自己用过的指针(pointer)，或引用(reference)。当这个对象建立时，该值为1。然后随着对它的调用/被调用，该值递增。反之递减。当本身崩溃时(destroyitself)，该值为0。

　　AddRef()就是用来加计数器的。你可能不用亲自调用它。你在用DirectDrawAPI时，AddRef()就被自动调用了。

　　Release()则是对着干。减值。你常常要亲自用到它，因为程序可能会异常退出AddRef的作用域(scope)。如出错控制中。

　　QueryInterface()用来问COM一个接口是否可用。如可用，则返回一个相应接口的指针。

　　问对象是否支持一个接口用QueryInterface,那么怎么问？当然要知道接口的ID。我们用GUID来表示，GUID=GloballyUniqueIDentifier。(全局单一证认)。GUID是一个128bits的数。所有DirectX中接口的GUID值都可在DirectX的头文件中找到。　　

      12、结论

　　在你制作游戏时会遇到很多的障碍，你必须学会面对它们。推动力确实是完成你游戏的关键所在，要牢记，成功的游戏制作者首先必须先完成他们的游戏。