游戏引擎全剖析(三)

来源:百度文库 编辑:神马文学网 时间:2024/03/29 15:54:52
2007/12/12 10:43 P.M.
第7部份: 网络和连线游戏环境
网络游戏
我记得一些年前坐在GDC(游戏开发者大会)听负责开发X-Wing Vs TIE Fighter的家伙们题为“淹没在Internet” 的演讲,全是关于让网络游戏实时地在Internet上工作的东西。他们选择那个题目是多么的正确啊。当它开始处理数据包的丢失,乱序,潜伏(一个数据包发送到它的目的地所花的时间)等等时,它确实淹没了。然而它是可能的。对于Internet需要一些聪明和经验,但它是肯定可能的。看看今天大量的连线游戏,从Quake III,Unreal Tournament,Counter Strike一直到EverQuest和Ultima Online。
如今大多数真正有长久生命力的游戏都至少有一些连线成分。最纯粹的单人游戏容易玩一次,也许两次,或者甚至三次如果它是非常好的游戏,但一旦游戏结束,就被束之高阁了。如果你想要有任何长久生命力,那么多人连线游戏就是形势的核心所在,并且那意味着和Internet打交道,为编码者打开了那个潘多拉的盒子。
那么跟Internet打交道包括些什么呢?首先是要理解Internet是怎么工作的,和点对点与客户机/服务器体系结构的快速讨论。点对点就是你在两台机器上运行游戏,并简单地在它们之间共享输入。每个单独的游戏假定它是正确的,并仅仅在它一幀接一幀的刷新中合并来自另外一台机器的输入。客户机/服务器是一台机器有效地运行游戏,别的机器仅仅是一个终端,接受来自玩家的输入,并渲染服务器让它渲染的任何东西。
客户机/服务器的优点是每台机器都将会展现相同的游戏,因为所有的处理都在一个地方完成,没有跨越多台机器,你可以不用考虑每台机器相互之间的同步问题。不足之处是,服务器本身需要有一些重要的CPU可用时间来处理每一个连接的客户机,和一个合适的网络连接来确保每一个客户机及时地接收到它的更新。
了解IP
我们都已经听说过TCP/IP(传输控制协议/网间协议)和UDP(用户数据包协议), 在Web网络上有大量关于这些协议的深奥的技术资讯。实际上,在Cisco网站上有一些极好的TCP/IP指导。我们将在较高层面上介绍一些TCP/IP的基本知识,目的是让你更好地了解使用这些标准协议的网络游戏设计者面临的挑战。
TCP/IP和UDP/IP是两层的通信协议系统。IP层负责网际数据包的传输。UDP或者TCP层将大的数据包传给IP,IP将数据包分割为小的子数据包,为每个数据包加上一个信封,计算出目的地的IP地址,应该如何到达那里,然后将数据包发送到你的ISP,或者不管怎样你连接到网络。 这实在象是在一张明信片上写下你要发送的,贴上邮票,写上地址,塞进一个邮箱,它就送走了。
UDP和TCP是从你编码者或者游戏接收数据包的高层协议,并决定该如何处理这些数据包。UDP和TCP的区别在于TCP保证数据包的传送和有序,而UDP不保证。UDP是一条直接和IP对话的小路,而TCP是在你和IP之间的一个接口。它像是在你和你的邮件之间有一个管理员助手。使用UDP你会自己为你的信打字,把它们放进一个信封等等。使用TCP你会仅仅向你的管理员口授信稿,管理员会做全部的工作并追踪确认信件送到了。
然而,所有这些令人惊奇的为你完成的工作伴随着代价。为了确定数据包通过Internet完好无损地送到了目的方,TCP期待从目的方为它发送的每个数据包发回一个应答包(网络用语是ACK)。如果它在一定时间内没有收到ACK,它就停止发送任何新的数据包,重新发送丢失的数据包,并且将继续这样做直到收到目的方的回应。当你访问一个网页时,我们都已经看到了这种情形,在半途中下载停止了一会然后又重新开始了。可能是一个数据包在什么地方丢失了(假定不时ISP的问题),在任何更多的数据包被发送以前TCP要求重新发送它。
这一切的问题是,在认识到出了差错的发送者和实际上正在送达的数据包之间出现了延迟。有时这能花上数秒钟,如果你仅仅只是下载一个文件或一个网页,这不是什么大碍,但如果这是一个游戏数据包而且每秒至少有十次,那么你真的是遇到麻烦了,尤其是因为它停止了其他一切事情。实际上就是这个问题所以几乎没有游戏选择使用TCP作为它们主要的Internet协议,除非它不是一个实时动作游戏。大多数游戏使用 UDP--他们不能保证有序或可靠送达,但它确实很快—或者结果是至少通常比TCP/IP更快。现在我们了解这些了,接下来呢?
客户端预测
因为 UDP 明显的是快速响应游戏的方式,我们将必须自己处理数据包的丢失和乱序。边而且这是技巧所在。不用说出太多的代码秘密,我就能说有方法。作为开始,有客户端预言,一个被谈论得相当多的词语。当你作为一个客户端连接到一个大的服务器,但是不能连贯地看见来自服务器的更新,客户端预言开始起作用了。正在你的电脑上运行的游戏部分看着你正给它的输入,并在缺乏来自服务器的任何弃绝信息的情况下,对它认为将继续进行的事情作出‘最好的猜测’。它将会显示被猜测的数据,然后当它得到来自服务器的世界的最新状态时,改正它自己,如果需要。你可能会对这个方法的效力感到惊讶。大体而言,大部分时间数据包不容易丢失—大多数时候是一秒的几十分之一,这种情况下游戏没有太多的时间偏离服务器实际上认为正在发生的事情。偏离确实会随着时间变的比较大,大多数游戏里面有一个超时功能,当出现很长时间没有来自服务器的联络时就停止游戏。
你正在创造的游戏类型在这里有关系 -- 第一人称射击游戏不需要这样有效的客户端预言,因为它多数情况下仅仅处理“我在哪儿,我是否要射击?”。在第三人称游戏中,你必须更加精确,因此你能够正确地预测你的角色正在播放的动画,并且动作流畅。在这种情形中流畅的动画是完全必要的。Heretic II在这方面有很大的问题,并且是当它开始网络编码时Raven一直不得不处理的最困难的事情之一。
当然如果你有一个很不错的网络连接,比如宽带连接,那么这个问题就远没有那么重要。对比较大的数据包有一个更宽的管道,对你的网络连通时间更快速。事实上,宽带对于游戏的主要优点不比较胖的管道多,但大大减少了延迟,特别是你到ISP的第一跳上。对于56K 调制解调器,第一跳典型的延迟是100ms,这已经严重地增加了你到网络上任意一台游戏服务器的潜在连通时间。对于宽带连接比如像DSL,第一跳的延迟时间多半是20ms。使用Windows中一个叫做TraceRoute(TRACERT.EXE)的命令行程序并指定一个目标IP地址或者域名,你能够找出你的第一跳的连通时间。仔细观察第一跳,因为这几乎总是你到你的ISP的网络连通时间。并且观察你在你的ISP的网络内部用了多少跳直到你看见在一个给定跳上列出的一个不同的域名。
请注意,宽带并不总是能解决延迟问题。你仍然受最慢的路由器/服务器和数据包从服务器穿越网络到达你的跳数(反之亦然)的支配。有一个宽带连接确实容易缓和这些,但不可能它们最后就消失了。当然,如果你打算要运行某种服务器,你将会需要一个具有足够快速的向上游的数据速率的带宽,因为仅仅一个调制解调器不能够处理一个服务器产生的负荷。
值得一提的是,如果你想要在PS2或者Xbox上面玩网络游戏,你将需要一个宽带连接,因为它们两者都不支持调制解调器。
包大小,智能数据传输,和反作弊
别的必须被处理的事情是数据包的大小。如果你在一个游戏里面64个人都在跑来跑去相互攻击,从一台机器发送到另外一台机器的数据包能变得相当大,达到了一些调制解调器没有带宽处理这些数据的程度。这正在变得特别和那些有着很大的地表系统的游戏有关。这里增加的问题是,因为你有这个很好的地表系统,你能够看得很远,因此能够看见许多其他游戏玩家,使得你为了精确渲染所需要的来自服务器的数据数量以很快的速率增长。我们能做什么呢?
好吧,首先必要的是只发送绝对必须的东西给任何给定的客户端,因此他仅仅得到从他的角度观察游戏所需要的东西。发送在他视野以外的人们的数据没有一点意义—他将看不见这些。同时,你最好确保只发送那些每幀之间实际上发生改变的数据。如果一个家伙仍然在播放相同的动画,重新发送数据没有意义。当然,如果数据包丢失时这确实带来一些问题,但这就是为什么好的网络程序员被支付很多金钱,来处理类似这样的东西。
还有一些其他的事情也要处理。最近已经有大量的令人苦恼的连线作弊正在发生。这是某些人修改游戏以给他们不正当利益的地方。尽管严格意义上这不是网络的一部分,但它确实发生了。有时人们会创作一些模块,允许他们立即瞄准进入视野的任何人,或者简单地允许他们看穿墙壁,或者让其他游戏玩家看不见他们自己。大部份时间这些事情可以在网络层内部或者在服务器上被处理。任何有100%命中率的人被简单地踢出游戏,因为在人力所及的范围内那是不可能的。
游戏开发者必须尽一切可能制止作弊行为,但很不幸,人做的东西可以被人突破。所有你能做的就是让作弊变得困难,当确实发生时去尝试发现它。
好吧,现在就到这里了。在第8部分中,我们将会看看游戏脚本系统的趣味世界,根据游戏过程中出现的事件来渲染或使能预先定义的场景和行为,协助故事叙述。
第8部份: 脚本系统
脚本系统
我们从第七部分的游戏网络问题来到了脚本系统,因为其呈现的故事叙述机会,最近已经形成一种很大的游戏元素。在一个需要以受控制的方式解释的情景,预先编制的电影脚本是解决问题的方法。在电影中,这通常用来处理或者由主角向一个伙伴解释情形,或者敌人对英雄解释。当然,有其它的方法来做这件事情 -- 叙事者,倒叙,等等 – 但通常是使用实时情景的人们和事件来完成。当然,游戏是不同的,游戏开发者在他们平常的FPS中不应该做太多的倒叙,因为通常会需要载入新的环境或者关卡,以及新的纹理和/或模型。所有这些额外的处理和渲染能影响到主要的游戏序列的性能。你可以重用已经存储在内存里面的场景元素来倒叙,但那样会看上去明显比较粗陋。
RavenSoft 的Star Trek Voyager: Elite Force广泛利用了脚本序列产生游戏中的事件和使用游戏引擎本身的剪辑场景。
在游戏中设计脚本情节的一个有趣趋势是使用当前极大改进了的3D游戏引擎自己产生剪辑场景。现在这可能像是相当地明显,但是数年以前,当 3D 图形卡还比较简单的时候,剪辑场景通常使用高端3D工作站制作,得到的3D动画然后被记录为一个数字视频文件,以流式文件存储在CD-ROM。你从剪辑场景的漂亮图形画面回到真实游戏的相对粗陋的3D画面,这是相当令人不愉快的失望的事情。但像Half-Life 和 Star Trek Voyager : Elite Force这样的游戏很好地利用了它们自己的引擎产生所有的剪辑场景,结果是剪辑场景和游戏之间的过渡更加平滑。
把脚本和人工智能区分开来可能是个很好的主意。脚本是你完全控制着一个给定场景,建立玩家几乎总是没有控制的事件,游戏者‘沿着轨道’移动到一个给定地点,或者建立一个游戏玩家需要解决的情形。一个好的例子可能是巨石掉在走廊上,需要游戏玩家找到一个新的逃脱方法。
如今有一些不同类型的脚本系统可供程序员或者美术师使用,而且它用非常有条理和逻辑的思想恰当地做这些。第一种是简单的基于文本的,单线索的风格,就像我们程序员习惯的编码。在许多情况,它实际上基於 C,尽管以一种非常简单的形式。 大量这种类似“if this,then do that”的东西。大部分脚本倾向在范围内是相当线性的—意味着它通常由许多在次序上彼此相接的命令组成。在世界中移动角色A指向B。当完成以后,让他讲话,完成以后,移动他指向C。相当简单的事情。
然后有复杂的东西--允许多重线索,和实际上允许可变情形。可变情形是当脚本开始时你实际上不能确知谁会出现在附近,但是你必须按这样的方式编写脚本以便任何人出现在附近它都将会工作。举例来说--一个正常的简单脚本会有三个家伙,全部被预先定义,全部有一组他们将会讨论的情形。一个可变的脚本将会有三个人,你不能保证是某一个特定的人,并必须按相同的方式工作。或者在一个极端的情形中,也许只有二个,或者甚至一个家伙将会在那里,使得三方交谈有一点困难。
Raven在Star Trek Voyager: Elite Force中面临的一个很大的问题是这样的情形,使用者可能会想要把一个角色从一条船的某个地方带到另外一个地方,但是从A点到B点的路径可能会随着每次游戏根本地改变。举例来说,他们需要让Munro(你所扮演的游戏主要角色)从发动机舱室到输送舱。 不幸的是由于游戏的非直线性,在事件到达这一点以前你可能已经破坏了涡轮升降机,或者也许 Jeffries 管被损害不能通过。假定当脚本开始的时候我们不知道世界的状态,我们不得不为几乎各种可能发生的事情编写脚本以便适用于这些‘如果。。。怎么办’的情形。而且它仅仅从那里变得更加糟糕。我们能建立的一些情形提供了如此多可能的组合情形,以致于为了一个满意的结论而准确测试每一个可能发生的事情几乎是不可能的。请和在SiN, Star Trek Voyager : Elite Force or Deus Ex中工作的任何人谈谈。QA部门传统地憎恨这些类型游戏,因为这已经使他们的工作比以前更加困难了 50 倍。
你能够想象为这些情形编写脚本是何等的困难。但那是今天的非线性游戏路径要求的事情,而且它为何博得了较多的开发支持从而能够努力实现它。
Jim Dose关于脚本系统的论述
去年底我访谈了Jim Dose--Ritual的前任开发者,现在是Id Software的一个开发者,Doom3脚本系统(和其他一些事情)的设计者。尽管这次访谈有些久了,但仍然是很有洞察力。
Jim谈了脚本系统和创建一个易用且健壮的系统( 与包含设计者传统想要使用的所有特征相反):
设计一个脚本系统最难的部份是知道何时该停止。一旦你完成了并开始运行,你发现有许多能够利用它的系统。对于Sin,最初的主意只是要有一个比较容易的方法让关卡设计者描述对象怎样动态的在环境中移动。在项目的后期,我们也使用它来让声音和游戏事件与动画同步,在多个关卡跟踪任务目标,控制HUD的布局和游戏内部电脑控制台用户接口,描述人工智能如何对不同的情形产生反应,以及粒子系统。
控制复杂度可能也是相当的困难。当你把脚本的力量放进有创造力的人们手中时,他们开始探究他们所能做的界限。时常,他们受启发做一些刚好轻微超出系统能力范围的事情。很容易陷入到这种增加‘仅仅再多一个特征’就允许他们做他们想做的事情之中。随着语言增长,一个可能对最初的规格有意义的语言结构变得严重过度扩充了。在一些时候,重新思考系统变得有意义,但在那时,你可能已经积累了数量巨大的必须重新编写的脚本。和FAKK2一样,Sin遭受了这样的损失。我没有得到对脚本系统进行大规模彻底检查的机会直到我为Rogue's 'Alice'.重写了脚本系统。
阿们,吉姆。-- Raven已经看到这个恰好在他们的ICARUS系统中出现了。ICARUS 实际上是一种与Jim在上面描述的相同种类的脚本系统,而且负责在Star Trek: Voyager: Elite Force中的所有脚本事件。它在Soldier of Fortune II和Jedi Knight II : Outcast中被重复使用。为了解决系统需要处理的新问题,这些问题在最初的实现中没有被预见/不需要,脚本系统的很多部分已经被重新编写了。
可视化脚本系统
第二种类型的脚本是可视化脚本系统。使用这种方法,而不是文本文件的编码方式,实际上你能够在真实的游戏环境中使用真实的角色建立你的脚本。你能够追踪角色在世界中行走的路径,定义使用的动画,并且通常得到关于你的脚本实际上将看起来如何的更好的主意。它对我们已经讨论的非线性问题没有太大的真正的帮助,但它确实可以很快速地生成最初的脚本。
其次,Jim谈论了可视化脚本系统。
可视化脚本系统确实有它们的用处,但往往实现更加困难,如果设计得很差,当复杂度上升时就容易让开发者感到困惑。举例来说,人工智能可以用一个流程图似的结构来进行可视化的设计。你能非常容易地可视化地表现人的行为举止方式,用盒子代表状态,箭头代表转化到其它状态,指示角色能够从一个状态转换到另外一个状态的方式。
脚本的一种通常使用是在游戏世界中控制物体,指示他们他们如何在世界中移动。在一个编辑器中可视化地移动物体到关键位置并播放整个运动的能力对一个设计者可能会更加直观。然而,它确实有它的极限,因为将需要另外一个接口来设计物体在它的移动中必须作出的任何决定。那种能力是把脚本动画片断和类似3DS Max或者Maya 这样的程序产生的动画区分开来。
在一些时候,使用者可能需要一些方法决定一个脚本为何没有做他们所期望的事情。一些形式的除错工具能使这件工作非常容易。至少,决定哪些脚本正在运行和脚本当前位置的一些方法必需的。在脚本中检查变量,开始,停止,和单步执行的能力也是有帮助的。通常,一个程序师能够在他们的调试器中进行除错,但这个过程要比如果有一些内建的脚本调试器可用时花费的时间更长。
以上就是第8部份,在接下来的章节中我们将讨论使用现成产品和定制的游戏引擎设计工具的功过得失,然后探究游戏控制机制,开发游戏对象,和一些刺激有趣的事情 (武器系统)。
第9部分: 现成产品与定做的游戏引擎设计工具,游戏特定主题
现成产品与定做的设计工具
我们从第8部份的脚本引擎来到这一章节中的许多主题,我们认为那些铁杆游戏玩家和有志成为游戏开发者的那些人将会发现它们相当有趣。我们将开始讨论现成产品与定制的设计工具。
你的工具的选择是你引擎设计的一个非常重要的部份,因为这是你将用来给你的游戏产生内容的东西,是最耗时的部份。在这个过程中有助于节省时间和资源的任何东西都是好的。那些不能的东西就是糟糕的。在那里,那是容易的。
当然没有那么容易。有比这更多的事情可能会立刻被注意到。你的工具集的选择,和从工具到游戏的资产路径比它听起来更有技巧得多,并受到很多因素的影响,比如,是否适宜手边的工作,费用,内容生产者的熟悉,市场渗透,工具支持等等。当考虑选择现货成品工具,或者即使当开发你自己的工具时,记得开发者实际在做工作,最好能够做需要借助工具做的。一些现货成品工具能在价格上达到那里,当你陷入多个拷贝许可时,费用猛涨。
然后就有诱人的可能性从头制造你自己的工具,为你游戏和引擎的需要而设计。这当然需要时间,和程序员大量的努力来产生在开发者友好方式中所需要的东西。快速打造基于窗口的文件转换器是一回事情,从头建造一个完整的关卡设计工具又是另外一回事情。另一方面,如果你确实选择这条道路,最后你会有游戏开发者地带其他人没有的工具,因此你的东西将会看起来是独特的。如今与众不同是一件非常值得想望的事情,而且从群众这些天起突出是一件非常令人想要的事物,产生所有的竞争。
当然由于内部的工具开发,你需要某人来做所有那些不可避免的小的改变和修正。但这里真正的意义是这是可能的。使用现成的工具,工具开发者会很少因为你需要的一些特征而改变他们的输出文件格式。这样你的东西最后看起来更加通用一些,否则你必须采用额外的步骤使用另外的工具来得到想要的结果,当然会花费开发者更多的时间。
值得记住的是如今许多有名的3D工具已经有一段时间的历史了,并且正在产生简直没有错误的产品,更重要的是,对他们所做的已经有一定程度的经验了。
如果你选择建造你自己的工具,多半你是,a) 重新创造车轮到某种程度 b) 陷入那些建造现成工具的人们已经遇到过的相同的问题之中,只是他们已经解决了这些问题。时常人们建造一个单一特定的工具花费了相当的时间和努力,并产生了一个远远超出你自己的个人需求的工具。还有,他们有代表性地收编了一些你或者认为是没有用的,或者没有时间自己实现的特征。加上他们典型地有吸收特征你或会没有想有用,或没有时间实现你自己. 这是第三方软件无法争辩的。
插件和目的建造工具
通常大多数的游戏开发过程最终都是这样的混合,自己开发的文件转换器工具,现成的内容创造工具,和通常那些要增加一些必须的特殊功能的工具的一些附加插件。现成工具在提供你不可避免会需要的功能方面有很长一段时间了,但是正如不可避免,总有一些很有用的,有帮助的,或者完全必须的东西你不能得到。一个小的插件可能是一个很好的替代品,而且时常那就是所走过的路。为特定目的建造的预处理程序也是可用的,比如把TGA文件转换为一个对PS2友好的格式,或者那些相关的东西。
如果你或你的公司打算建造某种类型游戏的工具,那么这些工具一般是从一个项目到一个项目地演变发展,而不是每次都从头重新建造。如果你变换游戏类型,很好,那些产生具有每个多边形命中能力的高分辨率模型的工具明显地不是一款RTS(即时战略)风格游戏所必须的。
Gil Gribb,Rave Software的技术带头人,对‘现成的工具’和‘自己动手建造’的问题是这么说的:
"自己开发的工具有能够根据自己产品的需要进行定制的优势,你拥有代码,可以修正任何错误或者增加任何的改进。
自制工具的缺点是建造和维护它们是非常昂贵的,通常成本要比现成工具高很多。在许多情况下,由于应用程序范围的缘故,建立自己的工具是完全不可能的,比如说3D建模和动画软件包或者位图编辑软件。"
当然,如果你想要游戏玩家能够修改你的游戏,而且你自己建立了所有的工具,那么你就必须要向世界发布这些工具。这可能会引起一点点疑惑,记住建立你自己的工具的部分原因是你可以领先你的竞争者。有时侯发布这些工具的源代码甚至可能让你获益匪浅,这确实提供了一种创造内容的方法。再次,Gil Gribb阐述这个主题:
"我是支持发布几乎所有的源代码。我认为我们没有任何来自我们的竞争者的害怕的事情,合法的业务不会想到窃取知识产权。游戏迷,业余游戏制作者,以及游戏的普及都能够从发布的源代码获益。"
好,我们的游戏引擎剖析系列到这里,当然我们已经特别讨论了许多和引擎相关的主题,下面让我们继续讨论一些与游戏特定相关的部分。
游戏控制机制
控制机制能够对开发中的游戏带来巨大的差别,有时甚至表明你正在建立的游戏的种类或者风格。
尝试在某个时候用gamepad玩一个即时战略类游戏--它不只没有乐趣。有时当你被限制在一个特定的输入装置的时候,例如鼠标和键盘,为你的游戏发明新的控制方法会是一个令人筋疲力尽的过程。当Raven开始开发Heretic II时他们决定做的第一件事情之一就是为用鼠标使用第三人称照相机尝试和找出一个直观的方法。在这以前,大多数游戏采用的是Tomb Raider风格的照相机(第三人称预兆的追逐)他们发现这时常不能正确地工作,在很多情形下会给玩家带来挫折。照相机时常会得到任意的视角,如果可能的话移动相机,而且有时改变玩家的方向。
假定他们的目标对象是FPS游戏人群,Raven需要找到一个对FPS游戏玩家来说直观的控制乌鸦座(Corvus)的方式。他们这样做了,但确实花费了一些时间,和一些不同的方式—他们应当让照相机固定在一个方向吗,或者让它是浮动的吗?大多数游戏开发努力—除非一个确定类型游戏的一个没有虚饰的实现—倾向于花费一些研发找出物理控制装置和游戏需要的内部控制机制的最直接的合并。这里是一个暗示—一旦你发现一个方式很起作用,就坚持下去。用这种方式控制游戏内在的东西能把视野,直觉,甚至游戏的焦点完全改变成你从未想要过的东西。发现起作用的东西,证明它起作用,然后就别管它。过分设计控制会导致特征偏离和可察觉的游戏概念问题。
像这类特征偏离的一个很好的例子可以在Independence War中看到。这款游戏有着如此多的模式,按键,等等,仅仅熟悉和操纵游戏都不可能。
很明确这里的关键是简单。一个好的经验法则是,在正常的游戏中,如果你的游戏需要比在普通的gamepad的按键或者你手上的手指更多的按键,那么一些事情需要被重做。注意, 我不是说一款游戏不应该有灵活性—Soldier of Fortune必定有许多可能的按键设定。但通常,当你认为它们大多数实际上都是不需要的时候Quake引擎有一个很好的方式。是的,你可以选择你想要使用什么武器,但你不是必须这样。游戏将会自动地为你那样做。这就是灵活性和过度设计之间的不同。如果游戏需要你按下某个键来选择一个武器,那将会有问题。你理解这个了吗?
控制机制不能被过高估价 -- 一款游戏时常将会根据玩家觉得他们对事件或者主要角色有多少控制而获得成功或失败。如果控制被改变,重新定向,或仅仅简单地从他们哪儿移除,它能导致游戏自身缺乏参与,不用说,那是一件很糟糕的事情。在这上面花费时间并让它保持简单,将会有巨大的帮助。
实体和照相机
现在我们来到了引擎不太令人愉快的部份,也是定义得最少的部分。当游戏运行的时候,游戏在这个部分能变得极端地多出错,耗时间,或仅彻底的极限。
在这里我们所谈论的是游戏引擎的 "游戏" 部份。这个部分使用所有的其它技术让一些事物显示在屏幕上,到处移动,让它对你产生反应并且让你对一些事物产生反应。这个系统有许多方法,但现在我将紧扣Quake的方法因为那是我最熟悉的。
让我们从实体开始。这些可以被定义为‘游戏对象’。现在那不仅仅意谓你在屏幕上看见的模型,虽然实体确定地控制这些 -- 实体也可能是其他的事物。基本上它是游戏在任何给定时间需要知道的任何事物,例如让事情继续进行的定时器,模型的碰撞检测盒,特效,模型,游戏玩家,等等。
甚至照相机都可能是实体(在几乎所有Raven的产品中都是这样)。照相机在世界中被分配一个有角度的原点,它们每幀都被刷新并告知渲染器应该从哪里得到它的视野数据,and off we go。典型地实体是为了返回到游戏早先的状态而被存储和装载的那些东西。通常在装载过程中使用的方法是把游戏地图装载进来,好像你正在重新开始一个关卡一样,然后装载所有存储的实体,这样他们就返回到游戏存储时它们的状态。Voila,即刻返回一个存储的游戏。当我理解Heretic II的方法时这并不是那么的容易—装载/存储几乎比其他任何事情带给我的问题还多,特别是在协作模式。
照相机有许多形式:
自由形式:照相机能去任何地方
脚本:照相机可以沿着一条设定的路径前进
游戏时间:照相机有必须要遵循的定义的行为
仅仅说"嗯,我将仅仅跟随主要的角色"是不够的。这意谓你也可能需要让照相机穿过墙壁,或让它按一些方式移动以致甚至引起一些胃的恶心。让它沿着一些定义的上下运动路径前进也有益处,如同任何玩Descent游戏超过一小时的人可以告诉你的一样。身体和头部习惯于上下是一个静态的变量,并当它不是时,他们不喜欢它。制作Quake 1的 Mike Abrash,曾经告诉我即使当它被定义,他仍然处理 的麦可 Abrash 地震 1,曾经告诉我即使当它被定义,他仍然从他们正制作的游戏感到运动恶心。他提到,对于他来说,离开制作Quake 1一年时间才让他的胃安定下来。啊哈,我们所作出的牺牲。
武器系统
游戏模块的另外一个部份是武器系统。大多数的游戏有武器系统或类似的东西。 这是在世界中影响其他的物体,而且使他们对给定情形产生反应的东西,--比如说被射击。通常武器系统由许多不同的类型组成;攻击扫描,基于飞弹的,以及范围形式。
攻击扫描是直接攻击武器。在屏幕上他们产生的效果只是那样,一个效果。当使用它的时候,和武器的实际操作没有任何关系。当你用手枪开火时,子弹被认为立即穿过世界并直接击中在它运动轨迹上的任何人/事物。
基于飞弹的武器有一个占用有限时间穿越世界的真实射弹,从而带给对方一些可以躲避的时间。
基于范围的武器像手榴弹和炸弹一样的东西,不必击中就可以伤害到你;你只是必须处于爆炸范围内。处在那种爆炸范围内的玩家受到飞溅损害。熔岩是另外一种形式的基于范围的武器。
那么你如何决定什么被击中而什么没有被击中呢?很好,这个问题把我们带到了追踪,我们将在接下来的物理学和人工智能章节更多的接触追踪。这是一组函数例程,当给定世界中一条从A点到B点的直线时,比如从枪的末端到预先定义的距离,它告诉游戏什么被击中。追踪很棒,但很昂贵,因为他们必须对那条线上的所有多边形进行‘碰撞检测’来看是否有什么地方被击中,更不用说模型和其它对象了。这也是一些物理学的工作方式,从一个给定的角色做一个笔直向下的跟踪可以知道地板位于什么地方。肆意的滥用追踪 — 如,在游戏的一幀中多次使用它们 -- 对于今天许多游戏的速度下降是有责任的。在Jedi Knight II:Outcast,他们的光刀战斗已经遇到了这个问题,因为他们不仅需要知道光刀是否击中了某处的什么和它现在的位置,而且对于它们之间的所有点都得这样,他们对光刀做了多次追踪。
好吧,又一个章节结束了,仅仅剩下两个章节了。下面我们介绍人工智能和搜索的更多细节。