第6部分:
现在在PC竞技场中,游戏玩家实际上只有一种声音卡可以选择 为了更好的定义 "这里借用我们的 OpenAL OpenAL 如同Jedi 比如说,在NOLF2的一个屏幕镜头上你听到房子里面坏蛋的声音。你能听到他们,但是他们的声音相当低沉而沙哑。障碍是相似的,但是你和声音之间的障碍物并不是闭合的。一个好的例子就是在你和声源之间有一根柱子。由于房间中的回声你仍然听得到这个声音,但是它和声音直接传递到你的耳朵里是不同的。当然这确实依赖于知道在你的耳朵和声源之间的直线上是什么。而且根据房间的大小,声源到你的距离等等,需要的处理能变得相当耗时。后面我们将会谈到跟踪--足可以说它时常是比较慢的幀速率的原因。Quake 接着是声音物质的特征。大部分声卡可以让你能够用可定义的过滤器作用于声音从而修正播放的声音。例如,在水下,或者在一个布料遮盖的房间中,或者在一个长的走廊中,或者在歌剧院,听到的声音有着很大的不同。能够根据你所处的环境改变你听到声音的方式是相当不错的。 我们回到Eagle… 好,让我们继续吧。 对于游戏机,由于静态的硬件,你的各种可能性会更受限制 实际上任何声音系统最重要的特征之一是把声音混合在一起。根据你所处的位置,空间中声音的位置,每个声音的音量大小,一旦你决定了实际上你能够听到的声音,然后你必须混合这些声音。通常声音卡自己处理这些,这首先是声音卡存在的主要原因。然而,外面有一些引擎决定首先用软件做一次‘预混合’。直到你着眼于一点点历史以前,这并没有真正地带来多大的意义。 当声音卡最初问世的时候,有许多不同的混合方法。一些声卡可以混合8种声音,一些单位16种,一些32种,等等。 通常你会仅仅使用DirectSound为你做声音混合,因为它会可以使用的声音硬件,或者转而依靠软件,很多地方就像DirectX为3D显示卡所做的一样。在 当然,你可以使用 动态音乐就是根据在游戏中目睹的行动改变你的音乐的能力,比如探险用慢节奏的音乐,战斗用快节奏的音乐。预先制作的音乐的一个困难之处是要合拍,因此你可以从一段音乐渐弱到另一段音乐,这对于MIDI音轨比较容易。尽管时常你足够快速地淡出,或者一段音乐在播放另一段音乐之前已经消失了,你能侥幸不被察觉。 在我们离开这个主题之前,顺便说一下,值得一提的是存在一些公司专门为你的游戏创作特定意义的音乐。FatMan(www.fatman.com) 最后,游戏现在的事情自然是MP3格式,允许巨大的11 以上是这一章节的内容,下面将是网络和连线游戏环境的开发。 第7部份: 如今大多数真正有长久生命力的游戏都至少有一些连线成分。最纯粹的单人游戏容易玩一次,也许两次,或者甚至三次如果它是非常好的游戏,但一旦游戏结束,就被束之高阁了。如果你想要有任何长久生命力,那么多人连线游戏就是形势的核心所在,并且那意味着和Internet打交道,为编码者打开了那个潘多拉的盒子。 那么跟Internet打交道包括些什么呢?首先是要理解Internet是怎么工作的,和点对点与客户机/服务器体系结构的快速讨论。点对点就是你在两台机器上运行游戏,并简单地在它们之间共享输入。每个单独的游戏假定它是正确的,并仅仅在它一幀接一幀的刷新中合并来自另外一台机器的输入。客户机/服务器是一台机器有效地运行游戏,别的机器仅仅是一个终端,接受来自玩家的输入,并渲染服务器让它渲染的任何东西。 客户机/服务器的优点是每台机器都将会展现相同的游戏,因为所有的处理都在一个地方完成,没有跨越多台机器,你可以不用考虑每台机器相互之间的同步问题。不足之处是,服务器本身需要有一些重要的CPU可用时间来处理每一个连接的客户机,和一个合适的网络连接来确保每一个客户机及时地接收到它的更新。 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协议,除非它不是一个实时动作游戏。大多数游戏使用 你正在创造的游戏类型在这里有关系 当然如果你有一个很不错的网络连接,比如宽带连接,那么这个问题就远没有那么重要。对比较大的数据包有一个更宽的管道,对你的网络连通时间更快速。事实上,宽带对于游戏的主要优点不比较胖的管道多,但大大减少了延迟,特别是你到ISP的第一跳上。对于56K 请注意,宽带并不总是能解决延迟问题。你仍然受最慢的路由器/服务器和数据包从服务器穿越网络到达你的跳数(反之亦然)的支配。有一个宽带连接确实容易缓和这些,但不可能它们最后就消失了。当然,如果你打算要运行某种服务器,你将会需要一个具有足够快速的向上游的数据速率的带宽,因为仅仅一个调制解调器不能够处理一个服务器产生的负荷。 值得一提的是,如果你想要在PS2或者Xbox上面玩网络游戏,你将需要一个宽带连接,因为它们两者都不支持调制解调器。 好吧,首先必要的是只发送绝对必须的东西给任何给定的客户端,因此他仅仅得到从他的角度观察游戏所需要的东西。发送在他视野以外的人们的数据没有一点意义—他将看不见这些。同时,你最好确保只发送那些每幀之间实际上发生改变的数据。如果一个家伙仍然在播放相同的动画,重新发送数据没有意义。当然,如果数据包丢失时这确实带来一些问题,但这就是为什么好的网络程序员被支付很多金钱,来处理类似这样的东西。 还有一些其他的事情也要处理。最近已经有大量的令人苦恼的连线作弊正在发生。这是某些人修改游戏以给他们不正当利益的地方。尽管严格意义上这不是网络的一部分,但它确实发生了。有时人们会创作一些模块,允许他们立即瞄准进入视野的任何人,或者简单地允许他们看穿墙壁,或者让其他游戏玩家看不见他们自己。大部份时间这些事情可以在网络层内部或者在服务器上被处理。任何有100%命中率的人被简单地踢出游戏,因为在人力所及的范围内那是不可能的。 游戏开发者必须尽一切可能制止作弊行为,但很不幸,人做的东西可以被人突破。所有你能做的就是让作弊变得困难,当确实发生时去尝试发现它。 好吧,现在就到这里了。在第8部分中,我们将会看看游戏脚本系统的趣味世界,根据游戏过程中出现的事件来渲染或使能预先定义的场景和行为,协助故事叙述。 第8部份: RavenSoft 在游戏中设计脚本情节的一个有趣趋势是使用当前极大改进了的3D游戏引擎自己产生剪辑场景。现在这可能像是相当地明显,但是数年以前,当 把脚本和人工智能区分开来可能是个很好的主意。脚本是你完全控制着一个给定场景,建立玩家几乎总是没有控制的事件,游戏者‘沿着轨道’移动到一个给定地点,或者建立一个游戏玩家需要解决的情形。一个好的例子可能是巨石掉在走廊上,需要游戏玩家找到一个新的逃脱方法。 如今有一些不同类型的脚本系统可供程序员或者美术师使用,而且它用非常有条理和逻辑的思想恰当地做这些。第一种是简单的基于文本的,单线索的风格,就像我们程序员习惯的编码。在许多情况,它实际上基於 然后有复杂的东西--允许多重线索,和实际上允许可变情形。可变情形是当脚本开始时你实际上不能确知谁会出现在附近,但是你必须按这样的方式编写脚本以便任何人出现在附近它都将会工作。举例来说--一个正常的简单脚本会有三个家伙,全部被预先定义,全部有一组他们将会讨论的情形。一个可变的脚本将会有三个人,你不能保证是某一个特定的人,并必须按相同的方式工作。或者在一个极端的情形中,也许只有二个,或者甚至一个家伙将会在那里,使得三方交谈有一点困难。 Raven在Star 你能够想象为这些情形编写脚本是何等的困难。但那是今天的非线性游戏路径要求的事情,而且它为何博得了较多的开发支持从而能够努力实现它。 Jim谈了脚本系统和创建一个易用且健壮的系统( 设计一个脚本系统最难的部份是知道何时该停止。一旦你完成了并开始运行,你发现有许多能够利用它的系统。对于Sin,最初的主意只是要有一个比较容易的方法让关卡设计者描述对象怎样动态的在环境中移动。在项目的后期,我们也使用它来让声音和游戏事件与动画同步,在多个关卡跟踪任务目标,控制HUD的布局和游戏内部电脑控制台用户接口,描述人工智能如何对不同的情形产生反应,以及粒子系统。 控制复杂度可能也是相当的困难。当你把脚本的力量放进有创造力的人们手中时,他们开始探究他们所能做的界限。时常,他们受启发做一些刚好轻微超出系统能力范围的事情。很容易陷入到这种增加‘仅仅再多一个特征’就允许他们做他们想做的事情之中。随着语言增长,一个可能对最初的规格有意义的语言结构变得严重过度扩充了。在一些时候,重新思考系统变得有意义,但在那时,你可能已经积累了数量巨大的必须重新编写的脚本。和FAKK2一样,Sin遭受了这样的损失。我没有得到对脚本系统进行大规模彻底检查的机会直到我为Rogue's 阿们,吉姆。-- 其次,Jim谈论了可视化脚本系统。 可视化脚本系统确实有它们的用处,但往往实现更加困难,如果设计得很差,当复杂度上升时就容易让开发者感到困惑。举例来说,人工智能可以用一个流程图似的结构来进行可视化的设计。你能非常容易地可视化地表现人的行为举止方式,用盒子代表状态,箭头代表转化到其它状态,指示角色能够从一个状态转换到另外一个状态的方式。 脚本的一种通常使用是在游戏世界中控制物体,指示他们他们如何在世界中移动。在一个编辑器中可视化地移动物体到关键位置并播放整个运动的能力对一个设计者可能会更加直观。然而,它确实有它的极限,因为将需要另外一个接口来设计物体在它的移动中必须作出的任何决定。那种能力是把脚本动画片断和类似3DS 在一些时候,使用者可能需要一些方法决定一个脚本为何没有做他们所期望的事情。一些形式的除错工具能使这件工作非常容易。至少,决定哪些脚本正在运行和脚本当前位置的一些方法必需的。在脚本中检查变量,开始,停止,和单步执行的能力也是有帮助的。通常,一个程序师能够在他们的调试器中进行除错,但这个过程要比如果有一些内建的脚本调试器可用时花费的时间更长。 第9部分: 你的工具的选择是你引擎设计的一个非常重要的部份,因为这是你将用来给你的游戏产生内容的东西,是最耗时的部份。在这个过程中有助于节省时间和资源的任何东西都是好的。那些不能的东西就是糟糕的。在那里,那是容易的。 当然没有那么容易。有比这更多的事情可能会立刻被注意到。你的工具集的选择,和从工具到游戏的资产路径比它听起来更有技巧得多,并受到很多因素的影响,比如,是否适宜手边的工作,费用,内容生产者的熟悉,市场渗透,工具支持等等。当考虑选择现货成品工具,或者即使当开发你自己的工具时,记得开发者实际在做工作,最好能够做需要借助工具做的。一些现货成品工具能在价格上达到那里,当你陷入多个拷贝许可时,费用猛涨。 然后就有诱人的可能性从头制造你自己的工具,为你游戏和引擎的需要而设计。这当然需要时间,和程序员大量的努力来产生在开发者友好方式中所需要的东西。快速打造基于窗口的文件转换器是一回事情,从头建造一个完整的关卡设计工具又是另外一回事情。另一方面,如果你确实选择这条道路,最后你会有游戏开发者地带其他人没有的工具,因此你的东西将会看起来是独特的。如今与众不同是一件非常值得想望的事情,而且从群众这些天起突出是一件非常令人想要的事物,产生所有的竞争。 当然由于内部的工具开发,你需要某人来做所有那些不可避免的小的改变和修正。但这里真正的意义是这是可能的。使用现成的工具,工具开发者会很少因为你需要的一些特征而改变他们的输出文件格式。这样你的东西最后看起来更加通用一些,否则你必须采用额外的步骤使用另外的工具来得到想要的结果,当然会花费开发者更多的时间。 值得记住的是如今许多有名的3D工具已经有一段时间的历史了,并且正在产生简直没有错误的产品,更重要的是,对他们所做的已经有一定程度的经验了。 如果你选择建造你自己的工具,多半你是,a) 如果你或你的公司打算建造某种类型游戏的工具,那么这些工具一般是从一个项目到一个项目地演变发展,而不是每次都从头重新建造。如果你变换游戏类型,很好,那些产生具有每个多边形命中能力的高分辨率模型的工具明显地不是一款RTS(即时战略)风格游戏所必须的。 Gil "自己开发的工具有能够根据自己产品的需要进行定制的优势,你拥有代码,可以修正任何错误或者增加任何的改进。 自制工具的缺点是建造和维护它们是非常昂贵的,通常成本要比现成工具高很多。在许多情况下,由于应用程序范围的缘故,建立自己的工具是完全不可能的,比如说3D建模和动画软件包或者位图编辑软件。" 当然,如果你想要游戏玩家能够修改你的游戏,而且你自己建立了所有的工具,那么你就必须要向世界发布这些工具。这可能会引起一点点疑惑,记住建立你自己的工具的部分原因是你可以领先你的竞争者。有时侯发布这些工具的源代码甚至可能让你获益匪浅,这确实提供了一种创造内容的方法。再次,Gil "我是支持发布几乎所有的源代码。我认为我们没有任何来自我们的竞争者的害怕的事情,合法的业务不会想到窃取知识产权。游戏迷,业余游戏制作者,以及游戏的普及都能够从发布的源代码获益。" 好,我们的游戏引擎剖析系列到这里,当然我们已经特别讨论了许多和引擎相关的主题,下面让我们继续讨论一些与游戏特定相关的部分。 尝试在某个时候用gamepad玩一个即时战略类游戏--它不只没有乐趣。有时当你被限制在一个特定的输入装置的时候,例如鼠标和键盘,为你的游戏发明新的控制方法会是一个令人筋疲力尽的过程。当Raven开始开发Heretic 假定他们的目标对象是FPS游戏人群,Raven需要找到一个对FPS游戏玩家来说直观的控制乌鸦座(Corvus)的方式。他们这样做了,但确实花费了一些时间,和一些不同的方式—他们应当让照相机固定在一个方向吗,或者让它是浮动的吗?大多数游戏开发努力—除非一个确定类型游戏的一个没有虚饰的实现—倾向于花费一些研发找出物理控制装置和游戏需要的内部控制机制的最直接的合并。这里是一个暗示—一旦你发现一个方式很起作用,就坚持下去。用这种方式控制游戏内在的东西能把视野,直觉,甚至游戏的焦点完全改变成你从未想要过的东西。发现起作用的东西,证明它起作用,然后就别管它。过分设计控制会导致特征偏离和可察觉的游戏概念问题。 像这类特征偏离的一个很好的例子可以在Independence 很明确这里的关键是简单。一个好的经验法则是,在正常的游戏中,如果你的游戏需要比在普通的gamepad的按键或者你手上的手指更多的按键,那么一些事情需要被重做。注意, 控制机制不能被过高估价 在这里我们所谈论的是游戏引擎的 让我们从实体开始。这些可以被定义为‘游戏对象’。现在那不仅仅意谓你在屏幕上看见的模型,虽然实体确定地控制这些 甚至照相机都可能是实体(在几乎所有Raven的产品中都是这样)。照相机在世界中被分配一个有角度的原点,它们每幀都被刷新并告知渲染器应该从哪里得到它的视野数据,and 照相机有许多形式: 自由形式:照相机能去任何地方 仅仅说"嗯,我将仅仅跟随主要的角色"是不够的。这意谓你也可能需要让照相机穿过墙壁,或让它按一些方式移动以致甚至引起一些胃的恶心。让它沿着一些定义的上下运动路径前进也有益处,如同任何玩Descent游戏超过一小时的人可以告诉你的一样。身体和头部习惯于上下是一个静态的变量,并当它不是时,他们不喜欢它。制作Quake 攻击扫描是直接攻击武器。在屏幕上他们产生的效果只是那样,一个效果。当使用它的时候,和武器的实际操作没有任何关系。当你用手枪开火时,子弹被认为立即穿过世界并直接击中在它运动轨迹上的任何人/事物。 基于飞弹的武器有一个占用有限时间穿越世界的真实射弹,从而带给对方一些可以躲避的时间。 基于范围的武器像手榴弹和炸弹一样的东西,不必击中就可以伤害到你;你只是必须处于爆炸范围内。处在那种爆炸范围内的玩家受到飞溅损害。熔岩是另外一种形式的基于范围的武器。 那么你如何决定什么被击中而什么没有被击中呢?很好,这个问题把我们带到了追踪,我们将在接下来的物理学和人工智能章节更多的接触追踪。这是一组函数例程,当给定世界中一条从A点到B点的直线时,比如从枪的末端到预先定义的距离,它告诉游戏什么被击中。追踪很棒,但很昂贵,因为他们必须对那条线上的所有多边形进行‘碰撞检测’来看是否有什么地方被击中,更不用说模型和其它对象了。这也是一些物理学的工作方式,从一个给定的角色做一个笔直向下的跟踪可以知道地板位于什么地方。肆意的滥用追踪 第10部分: 人工智能包括了全部的东西,从在Tetris中决定哪一块新砖头掉落(这很大程度上知识一个随即数产生器), 假设我们的游戏中有坏份子生活在3D世界中,干着他们的事情,而且如果你打搅了他们的正常次序他们就会反抗你(玩家)。你必须决定的第一件事情就是他们正在从事的到底是什么事情呢?他们正在守卫什么东西吗?在巡查?在计划一个聚会?在购买食品杂货?在整理床铺?建立行为的基线是游戏开发者的工作之一。一旦有了这个,你就总有NPC(非玩家角色)或计算机控制的‘人’能够恢复去做的事情,玩家与他们的交互就应当能被完成。 一旦我们知道一个NPC角色需要做什么 当你开始为AI刺激例程增加听觉意识时,这依然变得更加复杂了。但是,这个意识是那些关键的“小事情”之一,这些使得假想的游戏世界似乎更加真实,或者能够去除怀疑的悬念。如果你碰到过这样的事情,请举手:你在枪战中跟一个NPC交战,免除了一个NPC,你绕着角落行走并遇到了另外一个NPC依然保持他的缺省行为模式,没有意识到刚刚发生的事情。现在,枪是嘈杂的事物,枪战可能已经明显地提醒了一个“倾听”的NPC有些事情正在进行。避免这种事情的技巧在于找到一个有效的方式来决定声源(即你武器的发射)的距离是否足够接近到NPC能够听见。 接下来就是决策例程。当我们的巡逻NPC角色能够听到但不能看见某物时,你试图实现什么样的行为呢?他去寻找它吗?不理睬它?你如何决定什么是重要的声音他应该去或者不去调查?如同你看见的一样,这会很快变得非常的复杂。有很多方法来建造处理这些事情的代码,但通常这样是一个好主意,建立一个不是对特定的NPC而是对所有的NPC都起作用的系统,该系统基于你能够在游戏引擎以外的文本文件中建立的属性。这样就不需要程序员为一个给定的角色而改变AI,并且如果你对游戏代码做了改动,它将立即自动地应用到所有的角色,这在大多数情况下是一件好事情。 其他的世界意识问题会冒出来,比如这样的情形,两个守卫彼此紧挨着站立,你用狙击武器干掉了一个,而另外一个站在哪儿完全不知已经发生的事情。再者,遵守真实世界行为的细节是一款好游戏和一款伟大游戏的之间的区别。 让我们说你已经把所有的刺激-响应部分准备好了—你已经扫描了世界,决定NPC应当对正在进行的一些事情作出反应—他听到了玩家角色发出了声响—并且你(游戏开发者)决定了他应当对这个做些什么—他将去调查。现在更加复杂的事情来了。他如何离开现在的位置,到达他认为发出声音的地方,而不会想通常的数字傻瓜一样跑到墙壁里面,碰到家具呢?继续往下看… 世界导航通常被分为两个领域,世界导航和局部导航。二者实际上只是范围上的区别,但大多数的程序员分别对待它们,因为这样处理起来容易一些。世界导航例程处理理解房间,门和一般的地理学,并计算出让玩家或者角色从世界中的A点到达B点的一条路径。“它将让你从A点到达B点”,这是一句很容易说的话,不是吗?说起来容易,但做起来很困难。理解世界是一个非常复杂问题,我已经看到过许多尝试过的解决办法。QuakeIII的机器人遵照建造的预先处理过的地图,一般的说法,使用原来地图的地面。预处理器检测地面元素,由地图建造者作上标记,并自己建造一个只使用地面的世界简化地图。机器人并不关心墙壁,因为他们从不接近它们,就像他们遵照地面的地图一样,设计上已经把避免墙壁构造在里面了。 其他方法在地图本身里面建造一些小的结点,AI可以追随它们。这些结点通常被建造在彼此的视线里面,有从一个结点到其他所有结点的连接,角色AI能够直接‘看见’,所以你就确保了从一个结点移动到另外一个结点时AI不会试图穿越墙壁。如果有门或者降落物,你能够事先用这些结点对路径的信息编码,于是NPC能够采用适当的行为—等候电梯,打开一扇门,或者从一点跳到另外一点。这实际上是HereticII使用的系统,也是Raven在他们其他的大多数游戏中使用的系统。 关于这个主题,3D "导航在许多方面是个巨大的挑战,主要是当游戏中有大量正在发生的事情和一些非计划性的东西,比如障碍。为了避免和(或)真实地对非计划性的障碍物导航(例如像另外的AI),AI需要很好地知道正在它周围发生的事情。比较而言另外一个巨大的挑战就是真实感。如果AI正在表现玩家在实际生活中看到的一些东西,比如说一个人,或者一条狗, 然后就是局部导航。我们可能有一条路径让我们的 在局部导航中最大的问题是其他的NPC。给定一个发现路径的具体例程,如果你在相同的一般区域中有不止一个NPC,他们都试图到达世界的同一地点,结果是他们都非常容易有相同的路径。然后他们试图沿着这个路径行进,结果彼此遇到一起,然后花费他们所有的时间试图将彼此分开,并且一旦成功地分开了,他们再次试图到达目标,然后我们又再次看到同样的事情发生。这一切看起来都是非常的愚蠢,这不是大多数人想要的效果。所以需要一些路径发现中的变化来避免这种情形,需要一些妥善处理避免的代码。有大量能够帮助解决这种情形的算法。 "此刻我能告诉你,我们在平滑移动上正有着最大的困难。在一个多丘陵的长满草的丛林中试图让五个角色在彼此附近行走是一个非常困难的问题。让底层系统完美是重要的,因为除非角色在较低层次上(避免墙壁,适当的动画)看起来真实,他们不能够有效地表达任何较高层次决定的智能。由于这个单独的原因,动画和底层的移动是最重要的和最难实现的。它确实需要完美。" 因此我们已经让我们的角色从A点到达了B点,他自己穿越世界,在途中避免障碍物,正确播放动画,现在到达了这里。他看见了你。接下来做什么呢?很明显更多的是作出决策。他将向你射击。太棒了。你回应射击。现在干什么?当他试着逃走的时候,现在你再次经历全部同样的事情。 为了让这些情形看起来令人信服,你看见了这里必须要处理的大量问题。如果你建立你的AI使用没有动画的行为让NPC执行,这能被混合。一些Soldier 想知道隐藏的难点吗?看看我前面所有的描述,然后试着将它应用到一组NPC上,这些NPC彼此必须说话,设定目标,彼此沟通,但不妨碍彼此的方式。一旦你这么做了,试试那些代码,作为玩家的队友做上面所描述的这些,然而不要在枪战中妨碍他。现在这是复杂的。然后这成为乐趣。这是最困难的部分。Raven的 "我认为反馈是AI的一个极大的问题。如果角色对于他周围环境的变化不产生反应,游戏的真实感就被完全打破了。这有许多明显的例子(听见枪炮声,看见同伴被击中...),以及一些更加微妙的事情(当两个人通过门厅时看着彼此并点头致意)。玩家是乐意接受一些生硬和可预测性的,但是这些事物容易把游戏带到现实生活。" 并且Jess "平衡是非常重要的… 这里应当处理一个被称为“自然发生的游戏”的专业术语。 举例来说,象棋能被认为是自然发生的游戏。有一组规则,但游戏能够陷入各种程序员不能够以个别方式处理的情形。你不能为每一种可能的棋局情形编码规则。很清楚,游戏玩家每次不会总是面临相同的游戏情景。一定程度上,进行中的游戏情形会根据他的行动而发生变化。Black 有可能把基于规则的,自然发生的游戏方式和FPS环境混合在一起。Half 第11部份: 大体而言HUDs应该是不引人注意的,只提供你需要的关键信息;这本身会在设计团队中引发争议。Soldier 在一个完美的世界中HUD是可配置的,因此你能决定显示什么,在哪里显示,显示多久。如果你觉得不需要局部雷达,那么它应当可以被移除掉。任何显示的HUD信息应当有一定程度的alpha(透明度),因此如果需要你能透过它们看见后面的事物。 说到配置,我是一个游戏个人设定的十足的狂热者。因为没有即时存储设备存储配置文件,在游戏机游戏上不是广泛地可以获得配置,这足够公平。但是随着PS2和Xbox硬盘驱动器的来临,我期待在将来看见配置被更多地使用。能够被定制的每件事物都应当这样,如同我看见的一样。很明显,也应当为每件事物提供合理的缺省配置,因此玩家不必一屏一屏地进行枯燥的选择过程---一会儿我们将更多地讨论这个---玩家应当能够根据个人的喜好和可获得的计算能力定制游戏经历。 回到缺省事物,保持必需的修改最小化非常重要。作出最少的决定而快速进入游戏总是一件好事情。Mortal 藉由关于配置和HUDs(连同前面十个章节的大量信息)的简要论述,我们最终结束了关于现代游戏引擎的主要建造元素的讨论。当然,依赖于游戏的类型和谁在制作它们,每个特定的游戏对这个清单有它自己的添加(或者减少)。然而,有一些对于游戏引擎实际上不是引擎设计部分的其他元素,但是它们却需要一些关注。 藉由LithTech,Unreal和Quake,你确实得到了完全的解决方案 Unreal有名的Tim "我认为我能公平地比较游戏引擎 它们针对那些想要一个完全的,现成的解决方案的开发者,以便他们能够把精力集中在游戏可玩性和内容上。像RenderWare这样的游戏组件针对那些正在开发他们自己的技术但不想在一些已经很完善的技术领域做重复开发的开发者。 游戏引擎有解决游戏开发中全部技术问题的优点,有容易把一些包括游戏类型的假设建立在里面的缺点。举例来说,Unreal已经被用来制作第一人称射击游戏,第三人称动作游戏,角色扮演游戏,甚至弹球游戏。但是没有人用它制作飞行模拟类游戏—它不是适合这种游戏的技术。游戏引擎带着完整的源代码而来,这是祝福 游戏组件有解决所关注领域的技术问题的优点,如渲染或者物理学,不用花费大量的时间在这方面就可以比典型的开发者做得更好。他们的缺点是把这些组件整合进你的引擎其余部分就是你自己的事情了,这有时候会相当复杂。游戏组件一般没有完整的源代码伴随,因此并不总是很清楚他们内部做了些什么。" 谢谢Tim,很精妙的分析。 Quake引擎经历时间有更加完整的进化发展。相应于Id公司下一个游戏的一组需求,当John 建造技术或者完整的引擎不是件容易的事情。当今的游戏引擎需要许多,许多的系统,就如同许多人们尝试创造‘下一个大的引擎’时所发现的那样,从屏幕上文本的简单显示到高级人工智能。并且如我前面提到的,不断发展的新技术使得建造一个快速,高效的引擎是一个变化的目标。事实上,我见到有人仅仅为了让一个带alpha的纹理正确地显示而在PS2的混合模式上花了四天时间。 值得考虑的其他引擎有Garage 在网络上有一些你可以下载的自由引擎---首先想到的是Crystal 还有就是最初的Quake 确实,这一切都是时间与金钱的事情。如果你没有时间开发一个新的引擎,就不要介意花钱使用第三方的引擎,去购买一个吧。注意,对于要求使用他们引擎的团队,如今大多数引擎许可团体有很合理的途径。尽可能地让许多人们使用他们的技术,因此这种经验变成了工业标准,这对他们有好处。 游戏 一些游戏是如此的流行以致于他们每年都有事件发生。比如说,Quake有一个QuakeCon,在Mesquite 如今你制作的任何游戏需要或者有杀人者可多人玩的经验,或者有可以非常容易修改的内容这样连线‘修改者’能利用你的游戏并制作出其他游戏来。这一切延长了你游戏的生命,有希望卖出更多,人们购买它,可以下载mods来玩最新的Quake 作为一个开发者,你需要在那里可以见得到,并为那些在家中想利用你的游戏和用它做点别的什么的人们提供经验和帮助。这种支持可以有许多形式----一个亲切友好的词语,一段代码,建议,宣传或只是金钱。只要有这个它时常不介意采用何种形式。 在这里你选择哪个第三方工具用来建造内容可能是至关重要的。在Raven,过去我们已经做了一些开发决定,在这方面没有什么帮助,由于我们为大多数的建模和所有的动画需求使用了SoftImage。虽然它是制作我们需要的动画的最好工具,对于家庭业余爱好者来说它太过昂贵了。这就给那些家庭业余爱好者在扩充我们制作的内容时带来了问题,因此他们容易抛弃我们转而寻求那些比较容易制作内容的游戏。在建造或者选择一个引擎时这确实是值得留意的事情。为了响应制作游戏mods,Discreet在市场上发布了一个3D 最后在线游戏的成功时常能追踪到 游戏产品工作。业余时间他为GameBoy (全文完)
声音系统
由于人们玩的游戏在种类和技术上的进步,声音和音乐近几年来在游戏中正逐渐变得重要起来(声音是一个实际游戏的可玩特点,比如在Thief和其它同类游戏中的听觉提示)。现在四声道环绕系统在游戏玩家的宝库中是负担得起的和平常的事。给定空间的声音,噪音的障碍和闭塞,和动态的音乐,如今许多游戏使用这些提高玩家情绪上的反应,更多的关注投入到这个领域就不足为奇了。
另外的一个系统是Miles声音系统。Miles是一家公司,它为你的代码生产插件,在充分利用每块声卡时处理所有必须的到特定声音卡的说话(比如Sound
声音术语
让我们开始障碍和闭塞。它们听起来一样,但不是这样。闭塞基本上意谓着一个声音在播放时听者在他们之间有一些闭合的障碍物。
位置的声音--一个复杂的世界
现在有一些很少有处理的声音空间化问题。我说的是把声音放在一个真实的3D世界中。有四个扬声器在你周围是一个很棒的开始,但这仍然只是在二维方向。在你的上方和下方没有扬声器,你没有真正获得3D声音。有一些声音调制过滤器试图解决这个问题,但实际上没有真实东西的代替物。当然真实地大多数游戏多半只是在二维方向上,因此这仍然不是太大的问题。
Music
我们没有过多的谈到游戏中的音乐生成。传统的有两种方法,一种是简单的音乐
网络游戏
我记得一些年前坐在GDC(游戏开发者大会)听负责开发X-Wing
了解IP
我们都已经听说过TCP/IP(传输控制协议/网间协议)和UDP(用户数据包协议),
客户端预测
因为
包大小,智能数据传输,和反作弊
别的必须被处理的事情是数据包的大小。如果你在一个游戏里面64个人都在跑来跑去相互攻击,从一台机器发送到另外一台机器的数据包能变得相当大,达到了一些调制解调器没有带宽处理这些数据的程度。这正在变得特别和那些有着很大的地表系统的游戏有关。这里增加的问题是,因为你有这个很好的地表系统,你能够看得很远,因此能够看见许多其他游戏玩家,使得你为了精确渲染所需要的来自服务器的数据数量以很快的速率增长。我们能做什么呢?
脚本系统
我们从第七部分的游戏网络问题来到了脚本系统,因为其呈现的故事叙述机会,最近已经形成一种很大的游戏元素。在一个需要以受控制的方式解释的情景,预先编制的电影脚本是解决问题的方法。在电影中,这通常用来处理或者由主角向一个伙伴解释情形,或者敌人对英雄解释。当然,有其它的方法来做这件事情
Jim
去年底我访谈了Jim
可视化脚本系统
第二种类型的脚本是可视化脚本系统。使用这种方法,而不是文本文件的编码方式,实际上你能够在真实的游戏环境中使用真实的角色建立你的脚本。你能够追踪角色在世界中行走的路径,定义使用的动画,并且通常得到关于你的脚本实际上将看起来如何的更好的主意。它对我们已经讨论的非线性问题没有太大的真正的帮助,但它确实可以很快速地生成最初的脚本。
以上就是第8部份,在接下来的章节中我们将讨论使用现成产品和定制的游戏引擎设计工具的功过得失,然后探究游戏控制机制,开发游戏对象,和一些刺激有趣的事情
现成产品与定做的设计工具
我们从第8部份的脚本引擎来到这一章节中的许多主题,我们认为那些铁杆游戏玩家和有志成为游戏开发者的那些人将会发现它们相当有趣。我们将开始讨论现成产品与定制的设计工具。
插件和目的建造工具
通常大多数的游戏开发过程最终都是这样的混合,自己开发的文件转换器工具,现成的内容创造工具,和通常那些要增加一些必须的特殊功能的工具的一些附加插件。现成工具在提供你不可避免会需要的功能方面有很长一段时间了,但是正如不可避免,总有一些很有用的,有帮助的,或者完全必须的东西你不能得到。一个小的插件可能是一个很好的替代品,而且时常那就是所走过的路。为特定目的建造的预处理程序也是可用的,比如把TGA文件转换为一个对PS2友好的格式,或者那些相关的东西。
游戏控制机制
控制机制能够对开发中的游戏带来巨大的差别,有时甚至表明你正在建立的游戏的种类或者风格。
实体和照相机
现在我们来到了引擎不太令人愉快的部份,也是定义得最少的部分。当游戏运行的时候,游戏在这个部分能变得极端地多出错,耗时间,或仅彻底的极限。
脚本:照相机可以沿着一条设定的路径前进
游戏时间:照相机有必须要遵循的定义的行为
武器系统
游戏模块的另外一个部份是武器系统。大多数的游戏有武器系统或类似的东西。
好吧,又一个章节结束了,仅仅剩下两个章节了。下面我们介绍人工智能和搜索的更多细节。
人工智能(AI)
我们上面已经用了其他九个章节介绍了游戏引擎,现在让我们深入到非常有趣和重要的人工智能主题。人工智能如今正在变成被谈论得最多的仅次于游戏引擎渲染能力的游戏开发领域之一,确实如此。直到大约两年半以前,游戏似乎主要是在考虑你能够渲染多少个多边形,眼睛是多么的漂亮,和…
有关正确的路径
快速,准确的世界导航(
人工智能和角色动画问题
当然,当角色自己在世界中行走时你必须完全地决定你想要角色播放什么动画。听起来无足轻重?不是的。关于这个主题,Raven的
游戏规则与自然发生的游戏
在我们关于AI的所有描述中,我们采用的是FPS的方式。有不止一种的AI。我们已经描述的是处理3D世界一组规则。AI远远不止这些。时常最好的AI实际上非常的简单。它就是一组规则,玩家必须响应和处理的响应(或开始)动作的规则。
好吧,下面还有一个章节,仅仅还剩下一个章节了。在最后的章节里,我们将讨论头顶显示,菜单系统,游戏定制和配置,游戏引擎版权与建造,最后是游戏“mods”。
前端
你已经看到了菜单系统,你可能理解游戏内的头顶显示(HUDs)时常是游戏经历中被忽视和诽谤的部分。最近,这个领域开始被给人印象非常深刻的Black
游戏引擎许可与组件
如今如果你要制作一款游戏,时常最快的开始方式就是购买现有的游戏引擎许可证并在此基础上开发---这就是Raven所做的事情,最近使用Quake3引擎编写了Star
建立你自己的游戏引擎?
你可能建立自己的引擎而不是购买许可证。这避免了谁拥有什么,版税等所有的法律纠纷,而且如果你产出了质量足够好的东西,你甚至能够向别人出售许可证。然而,正如已经指出的那样,这需要时间和金钱来完成,更不用说绝对优秀的程序员了。LithTech
‘Mod’社区
看一眼任何在线游戏服务器的统计数字,显示出Counter
有关作者
Jake
本文链接:https://my.lmcjl.com/post/15410.html
4 评论