Patrick Wyatt:魔兽争霸的制作过程(3)

英文原文:Patrick Wyatt,编译:CSDN-王然

在之前的关于Warcraft开发的文章中,Warcraft之父Partrick Wyatt开启了一个“为什么Blizzard Entertainment成为了世界上最有名、最受欢迎的游戏公司之一”的话题,并从Warcraft和StarCraft开发回忆当初在Blizzard奋斗的过程,一步一步为我们描绘出Blizzard从普通的工作室开始的“征途”。

应该怎么评价这第一个多人游戏Warcraft?按Patrick的话说就是“它既是一场压倒性的胜利,也是可怜的败局,同时也能说是平分秋色。”似乎有点难以理解,这其中有个小故事。这个故事贯穿了开发的整个阶段——游戏经济学、单位创建、AI编程、战争迷雾等等。

 

如果你没有看过之前的文章,可以点击这里:

● Patrick Wyatt:魔兽争霸的制作过程(1)

● Patrick Wyatt:魔兽争霸的制作过程(2)

 

在Warcraft: Orcs vs. Humans于1993年开始开发6个月之后,终于可以称之为游戏了,而不再是一个可扩展的技术demo了。最初的几个月里,我是项目唯一的全职工作者,这限制了游戏的开发速度。之后有幸获得Ron Millar、Stu Rose等的帮助,他们主要负责项目设计;还有一些画师也在空闲时间帮助设计了Warcraft的图形原型。

Warcraft团队人员稀少,因为整个开发都必须自助,公司的资金只能拿开发中的项目和Interplay、SunSoft这样的游戏出版商签订合同来获取,而且并不多。

那时候,我们正在同时开发4个16位电视游戏:The Lost Vikings 2、Blackthorne、Justice League Task Forc以及Death and Return of Superman。通过开发这些游戏以及接受其它奇怪的活动,我们获得了游戏初期发展的资金。

 

游戏开发中的经济学

在游戏工业的历史中,独立游戏开发工作室——我是说工作室,而不是哪一个游戏零售出版商——通常是通过和这些出版商公司签订合同来获取资助,即出版商“赞助”项目开发。除“赞助”之外,出版商还负责宣传、营销、制造、零售分销、客户支持等等。

回到上世纪90年代初,那时候的游戏零售出版商比现在要多得多,但随着游戏开发的成本持续增加,特别是游戏发行成本的增加,导致了规模巨大的行业合并以免于破产或者被收购。所以现在提到游戏零售出版商时,你首先想到可能是Activision-Blizzard(动视暴雪)、EA或者Ubisoft(育碧软件),而非20年前多如牛毛的中型公司。

在所有行业中,合同都是以资金提供商盈利最大化为首要目的的。除此之外还有另外一个黄金法则:“有钱人制定规则。”尽管从理论上说,这些协议是结构化的,游戏卖得很好时开发者会受到奖励;在音乐和影视行业,出版商会攫取绝大部分的利润;(游戏)开发者往往只能获得足够生存的钱,只有足够幸运的情况下才能签署另外一份合约。

我所提到的出版商“赞助(advances)”,更正确的说法应该是“比例预付版税(advances against royalties)”,也就是开发者可以获得贷款,然后通过游戏销售的版税来还贷。这听起来很美好:开发游戏,然后可以从游戏的每一份拷贝中获得收入。但这样结构化工作的实际结果是,大部分游戏开发都入不敷出。既然工作室经常被迫放弃游戏和续集的权利,这些合同也就成为了一直空文。

为了追求更好的交易形式,工作室通常会自己掏钱开发游戏原型,然后把这个原型作为和出版商交易“筹码”。开发者能够自助的时间越长,越有利于签订好的合同。

Valve Software公司也许就是其中最好的例子。Gabe Newell通过从Microsoft中获得的财富支持Half Life(半条命)的开发,在一定程度上获得了开发进度的控制权,因此保证了在游戏高质量之后才发布了,而不是按照Sierra Entertainment(游戏出版商)所想——为季度营收目标过早地发布产品。更重要的是,Gabe的资金为Half Life赢得了在线分销权——在网络上销售数字化下载版本,这也成就了该工作室之后巨大的成功。

自给自足的缺点在于,如果游戏并没有被出版商签约,那么开发者也需要自己承受开发成本——通常这会导致工作室的夭折。

我所任职的公司——当时叫做Silicon and Synapse——就在自助开发Warcraft,同时开发的还有Games People Play,一款包括填字游戏、boggle以及其它在机场书架上为停留旅客打发时间的类似游戏。公司所有者期望通过同时开发两款针对不同人群的游戏来创造多条收入来源,相比于在核心娱乐市场(就像你我这样的核心用户)赌上一把更加可靠。

当然,同时开发多个项目也有它的风险,公司会因为无法满足顾客需求的产品导致品牌声誉降低。Blizzard现在最大的优势之一正在于其品牌价值——用户愿意在未亲眼见到的情况下购买游戏,因为他们信任Blizzard游戏的品质。同时开发低成本的休闲游戏和高成本AAA+游戏很难获得这样的荣誉,因此Sierra Entertainment在重复这件事的过程中破产了。

无论如何,Games People Play被认为是一大败笔,因为开发休闲娱乐产品让核心程序员感到非常伤心,导致这个项目在成熟前就已经夭折了。或许这算不上是一个错误,Warcraft和Games People Play项目的合并让当时世界上第二大教育软件公司Davidson & Associates决定收购Silicon & Synapse。

 

我们的新主人

Davidson & Associates是由创办的多元化教育软件公司,后来她的丈夫也加入了进来,它的成功增长离不开Math Blaster这款游戏。这款游戏是个教育和娱乐相结合的典范,Davidson & Associates也从中获得了不菲的报酬。

说点偏题的话:作为一款教育应用,Math Blaster也许能在使用正确的情况下有点价值,但我看到的更多的还是愚蠢的用法。我所在的高中的记者班会和助学班共享计算机室来编辑报纸,我们亲眼见到助学班12年纪的学生使用计算器来玩这款游戏,这勉强还可以说得上是在学习,至少他们成功地愚弄了老师,但我不认同他们浪费时间的方式。

通过良好的管理和激励领导,Davidson & Associates开始进军游戏制造(制作&包装零售合),游戏发布(为零售商和中间分销商提供包装盒)以及教学游戏领域。他们看到了深入娱乐行业的机会,但早期开发娱乐游戏的经验告诉他们:收购一个有经验的游戏开发工作室会是一个更好的选择,毕竟他们的员工更熟悉的是教育而非刀剑&魔法。

因此,阻碍Warcraft开发的现金流转问题因为收购事项一下就解决了,有了财大气粗的Davidson & Associates撑腰,Silicon & Synapse(在交易后改名为Blizzard)可以专心开发游戏,再也无需为寻找出版商花费心思。

我们用被收购所获得的现金雇佣了一批新员工,因此我们的项目一下子就得到了足够的开发人员,Warcraft的开发进度也应此大幅提升了。

 

设计之“路”

“有机”应该是最适合描述Blizzard早期“开发”模式的词了,过程只能说是非常混乱。“正式的”设计讨论经常会在走廊和会议或者吃饭时进行。

有的特性取自设计文档,但大部分来于个别程序员的心血来潮;有的艺术设计是按预定有条不紊地进行,更多的出于画师在深夜中的追求独特的灵感;其它元素也是这样即兴地创作的,Warcraft的故事和知识体系直到发布前几个月才定下来。

因为项目进展的不确定性,最终的成功给人带来非常大的惊喜。因为我们团队成员都是计算机狂热爱好者,开发过程演化成了玩、玩、玩。最终我们在IBM PC上发布了我们第一款游戏——Warcraft,以最佳(也是最差)的姿态登场了——至少在那个时代成为了典范。

 

Warcraft单位创建系统是怎样诞生的

正如生物学家所知,如果进化的的起点错误,那么整个分支进化树都会灭绝,开发也是这样。在没有说明书帮助、对照的情况下,我们不得不实验每一种无法成功的可能,这是一项有意识、有规则的活动,但也经常出自事件、讨论或者性格差异。

其中一个就是关于如何创建游戏单位。在开发早期,还没有创建游戏单位的用户界面时侯,只能通过“作弊”命令创建单位,我们一直在思考如何才能做到最好,因此尝试过很多想法。

Ron Millar是为Blizzard早期很多游戏贡献出想法和设计贡献的画师,他提出玩家应该先建立农场,然后在人口限制下定期地产生基本的工人单位,后来被称为农民(人族)或者苦工(兽人族),可以直接采矿、伐木以及建造,但不擅长战斗。

空闲的“苦工”可以在玩家的指引下进入军营接受训练,因此它们会在地图上消失一段时间,最终作为熟练的战斗人员回来。除了军营之外,还有其它训练场所来制造高级兵种,如:弓箭手和巫师。

我们最终没能成功给它“填满血肉”,失败的原因在我们的开发中非常常见——因为缺少正式的设计文档来指导该如何实现。所以这个想法在我们正式开始实现前被我们这群非正式设计团队(几乎也就是我们整个公司)讨论来讨论去。

在我们开始编程实现前,Ron和公司总裁Allen Adham一起参加了一场展销会(好像是冬季Consumer Electronics Show——消费电子展CES)。就在他们缺席的这段时间里,一个突发事件彻底改变了Warcraft系列的发展——我称之为“Warcraft设计政变”。

Stu Rose,另一位元老级画师/设计师进入了公司(我们的第六位伙伴)。一天下午,他来到我的办公室讨论另外一种完全不同的思路,Stu认为Ron设计的单位创建原理有很多复杂度可能难以实现,而且和我们在RTS游戏中应该给予玩家的控制方式背道而驰。

新一代RTS游戏对玩家的要求要远高于之前任何一代RTS游戏,玩家不应该长时间专注一个地方,因为有太多地方需要注意:建造/升级古树、发展经济、创建单位、放置建筑、探索地图、监督作战以及单体微操技术。游戏中最有限的元素就是注意力,所以增加认知、间接单位制造都会给玩家增加注意力负担和游戏难度。

比如:要创建单位“野猪”,需要把闲置或者低优先级任务的农民关进畜栏来(对野猪)进行培训,给游戏增加了不必要的难度(Stu的观点)。

我正等着他的表态呢!我和他的观点类似(虽然没有整理好),都不认为单位制造是值得做重大变革的地方。Dune II,Warcraft借鉴了设计的那款游戏,它的单位创建方式还要简单得多:点击面板UI上的工厂就会在一段时间后产出一个单位。这并不是个新奇的想法——也是从更早的游戏上复制过来的——但就是有效!

Stu认为我们应该立刻采用这种方法,不要再做无谓的争论了。所以接下来的几个日夜里,我全身心地投入了这种创建游戏所必要的开发中去,这个设计模式在Ron回来之前就已经成为了既定事实,而整个Warcraft也在他们回来前成了一个没有AI的“可玩游戏”。(之后的敌军AI的开发又花了几个月的时间。)

Warcraft此时已经算得上是一个游戏了,尽管简单但是有趣!我们从不后悔。

 

支持多人游戏

1994年6月,也就是在10个月的开发之后,游戏引擎已经基本上支持多人对战了。随着代码集成的进行,我感到越来越兴奋,因为马上就可以使用Warcraft进行多人对战了!虽然我一直忙于游戏核心逻辑的设计、实现(事件循环、单位调度器、路径寻找、战术AI单位、状态栏、游戏内UI、高级网络代码等等),其他程序员已经开始着手多人对战相关功能的开发了。

Jesse McReynolds ,Caltech(加里福利亚理工大学)的毕业生,完成一个低级网络库的开发,可以在局域网络内发送IPX包。这些代码的实现得感谢id software John Carmack(3D游戏之父——约翰·卡马克)刚刚开源的Doom源代码,虽然IPX中间层只有几百行C代码,但它能很完美地跟网卡驱动结合,保证一个游戏客户端发出的信息能够传送到另一个玩家那里。

Bob Fitch,Cal State Fullerton(加州富乐敦州立大学)的硕士,开发了“glue screens”的原始版本,自此玩家已经可以创建或者加入多人游戏。Bob的办公室紧贴着我的,因此我们可以密切地合作,把他开发的“创建/加入游戏”功能融合进我设计的游戏事件循环中也因此变得非常方便。

在合并了这些更改之后,我把游戏客户端重新编译了一遍,并复制到网络共享盘中,Bob也紧接着回到办公室加入游戏。奇迹发生了,没有任何问题!就这样,Warcraft开始支持多人游戏。

在游戏过程中,我感受到前所未有的兴奋,在之前玩过的所有游戏中都没有这样的感觉。如此激动的原因一部分是因为我自己参与了部分代码编写;另两个更重要的原因在于:我是和人类做对手,而不再是计算机AI(Artificial Intelligence,人工智能);更特别的地方在于,因为“战争迷雾”的存在,我并不知道他在做什么。这甚至给我带来了心理上的恐惧感。

 

战争迷雾

Patrick Wyatt:魔兽争霸的制作过程(3)

一个小村庄被战争迷雾所包围着,那里究竟发生了什么?!?

早期的游戏里,视野外的敌人是隐藏的,这正是“战争迷雾”设计的原型。除非有友方单位探测过,否则地图将会被黑色的图形层覆盖,以此来模拟真实战斗中无法获知敌人的调度和行动。

EmpireWalter Bright(“D语言”之父)大约17年前所开发的游戏,也出于同样的目的使用了战争迷雾。如果地图上的某一块并没有被探索过,那么它将处于烟雾笼罩之下,所以游戏初期的一个重要任务就是去探索(未探索过的)地图。

心理上的恐惧源于我无法得知对手正在做什么,正如历史上很多将军死亡那样。RTS游戏中加入了这一元素让游戏精彩(恐怖)程度更上一层。感谢Westwood的Walter以及其他想到了这一创意的人。

 

计算机AI

正如很多玩家所知,计算机控制的“人工智能(Artificial Intelligence)”(AI)通常在战略上很弱,所以人类玩家经常可以AI玩家的程序漏洞,因此可以轻松获胜。为了保证可玩性,AI玩家的队伍通常会在队伍数量、位置上有优势,又或者是通过其它“不对称规则”来给人类玩家足够的挑战。

大部分Warcraft的任务中,计算机敌人通常一开始就会拥有整个城市以及军队。此外,Warcraft还为AI制定了其它不平等的规则,如同作弊一样。

我们制定的不公平规则之一就是:AI玩家每次采矿后金矿数量减少地更少,所以很少会有矿井被采空的情况发生。人类玩家在采矿时会从矿井移除100个矿石单位到市政大厅,但AI玩家同样采一次100单位的矿石,矿井只会减少8个单位的矿石。

这种不对称规则有两方面的好处:

1.防止人类玩家使用“龟缩战术”(不停地堆积防御性建筑,直到变得无懈可击的时候才进行攻击。),因为计算机能够近乎无休止地采矿并且发展军队,于是玩家不得不使用高级战术来战胜计算机AI。

2.当玩家战胜了一个计算机玩家的时候,相当于得到了一个可以使用金矿作为奖励,相比于在有限的资源中磨出胜利,这样的游戏节奏变得更快、更有趣。

大多数玩家都意识到了另一个更加违反公平竞争原则的规则:计算机AI在作弊,因为战争迷雾对它们无效;AI知道玩家每时每刻究竟在做什么。在实战中这是个非常大的优势,可惜计算机没有那么聪明,也无法充分利用这一优势。

有趣的是,在StarCraft流行的那段时间里(自发布以来14年多的岁月),一直有一群AI程序员视图制作无作弊AI的挑战。在BWAPI库的帮助下,这些程序员可以编辑代码直接注入到StarCraft的引擎中去,并且和AI一决胜负。虽然BWAPI AI已经很厉害了,但StarCraft高手仍然可以轻松战胜它们。

 

和真人对战

作为战略游戏资深玩家,我很清楚那个时代计算机AI的局限性。在和众多AI对战的经历中,鲜有败绩,即使在面对Eastern Front(Chris Crawford开发的东部战线)中俄罗斯的疯狂进攻,也从未有面带惧色。

我玩过的这些游戏都非常有趣而且令人兴奋,但从不令人恐惧;这在Warcraft多人对战中就不一样了!

我需要战胜的是一名人类玩家——我所面对的不仅是技巧和战略,还有敌人快速的控制。因为战争迷雾的存在,双方都不知道对手的动作,因此更加令人振奋。我在职业生涯中从未对某款游戏感到如此激动,但是第一次玩Warcraft的时候却不一样,不到迷雾揭开之时都是胜负难知。

我的血液在沸腾,肾上腺素在飙升,只为了更快地伐木、采矿、建造农场和兵营,当然还包括组织战力、探索地形以及——最重要的——在Bob的军队成型前将他击溃!相信Bob也是一样。

我们并没有在游戏开始前对引擎功能进行测试,因为脑海中只有火热的决胜之心,相信Bob也想夸耀自己才是第一场Warcraft多人对战的胜利者吧!除此之外,我们还经常一起在Blizzard玩Doom,在一场激烈的游戏后,Bob怒气冲冲地说不再跟我玩了,因为我总是用火箭炮秒杀他。当然,我知道他一直都在找机会报仇。

在对战中,我们加倍努力地建造单位并派遣到战场上,在找到他的基地并进攻的时候,我甚至感到胜券在握了。Bob的战略杂乱无章,我觉得能够轻易将其击溃,但是稳重起见,我还是开始更疯狂地建造单位,并且在战场上击杀他的部队。

然后……游戏崩溃了:

Patrick Wyatt:魔兽争霸的制作过程(3)

坏消息——DOS4GW告诉我Warcraft崩溃了

这是程序员间的常识——任何一款程序在第一次运行时成功的概率接近于0,游戏半途崩溃不足为奇。游戏的画面在不停地从屏幕上方向下滚动,伴随着DOS4W“crash screen”的字样,这对Windows之前的游戏开发者来说在熟悉不过了。现在我们能得到更详细的Windows错误提示框,玩家可以反馈游戏崩溃记录,当然也有不少玩家会遇到“蓝屏死机”状态,和老式错误提示非常相似。

在崩溃后,我几乎从椅子上跳了起来,直接冲向Bob的办公室,叫嚷着“That was awesooooommmme!”。立刻就得到了回应“… and I was kicking your ass!”我竟然听到Bob说他差点就彻底摧毁我了。

几分钟后我们才从混乱中缓过神来——我们的游戏bug不仅在于崩溃,而且还有个“同步bug”,也就是说游戏状态不完全同步:两台机器上显示着不同的战斗,虽然初始状态相同,但渐渐地就进入了两个完全不同的世界。

没有网络编程经验的人可能会认为,两个Warcraft客户端可以在游戏过程中来回发送/接收整个游戏状态;但实际上,每台计算机仅仅会发送每个单位的位置和状态。对于只有几个板块位置的慢节奏游戏,如国际象棋或者跳棋,这种想法可能还算合理,但对于Warcraft这样每个动作涉及到超过600个单位的游戏来说,不可能通过网络传输所有的状态。

我们预计会有不少玩家使用2400波特的调制解调器,每秒只能传输几百个字符的信息,没有使用过调制解调器的年轻玩家应该花点时间去学学这方面的技术。记住,我们现在讨论的是Amazon、Google、Netflix出现前的“黑暗世纪”。

因为有之前将Battle Chess从“DOS”移植到Windows上的经验,我非常熟悉多人游戏通过调制解调器通信的方式,调制解调器有限的带宽是不可能完整地传输整个游戏状态的,所以我的解决方案是仅仅发送每个玩家的命令,而每个玩家(的机器)同时执行这些命令。

我相信这个解决方案没有问题,因为计算机非常擅长执行命令。不幸的是,编程的人类却无法准确地告诉计算机应该怎样做,这就是出现bug的主要原因。虽然我们指望两台计算机做完全一样的事情,但因为bug而不一致,这就是问题所在。

之所以会出现游戏不同步的bug,是因为在模拟游戏中,两台计算机面对同一个问题却给出了不同的答案,随之时间的推移,差异越来越大。正如《Back to the Future》这部穿越电影所描述的,穿越者在过去所做的小变化会导致完全不同的未来,Warcraft的差异也是如此。在我的计算机上,我的Elvish archer(精灵弓箭手)发现了对手的Orcish peon(兽族苦工),但对手的计算机却没有注意到我的进攻,继续伐木或者采矿,由于没有错误纠正程序来处理这些分歧,于是两台机器上的差异越来越大,以至于完全不同。

所以我们的第一场战斗只能算是平局——但对于整个开发团队来说,这是一个伟大的胜利——它还给我们带来很多乐趣!团队其他成员也渐渐地加入了进来,随着游戏/测试人员的增加,更多的bug暴露了出来。虽然游戏经常会遇到崩溃,而且还有更多的问题,但我们知道,这将会是一番大事业!

我们所需要的只是去把游戏做好。

可悲的是,很快我们就发现了更糟糕的问题:虽然同步bug很多,但造成这一现象的原因却也不少。如果这些同步bug处于相同的原因出现我们早就会开始根本问题的修复工作了。但事实证明有很多引发同步bug的原因,每一种都会带来不同类型的同步bug,而且每种bug都需要不同的修复方式。

为什么会出现同步bug?

在开发Warcraft I的时候,我设计了一种最小化数据传输的方法——只发送玩家发送的命令,比如“选择单位5”、“移动到位置650,1224”、“攻击单位53”等等。很多程序员都自主设计过这样的系统,这是“不发送整个游戏状态就同步游戏变化”的一个显而易见的解决方案。

说点不相关的:这段时间有几个专利好像就是冲着这个方法去的。久而久之,我开始认为软件不应该是专利,大部分软件专利并没有什么新意,有经验的程序员都能想到并实现,而根据定义,专利应该是不平凡的。闲话就说到这里。

那个时候,我还没有实现验证两台机器间同步的方法,所以任何会导致计算机做出不同选择的bug都会导致游戏走向分叉——也就是说,他们会变成两个松耦合的世界,虽然仍有交流,但差别会随着时间的推移而加剧。

所以很明显我的下一篇文章会是关于如何发现不同步问题的。

 

打持久战的准备

你们都知道这个故事的结局:Warcraft最终在5个月后发布了,它成为了不朽的传奇。这离不开我们每天长时间的辛苦工作,在解决了很多问题、克服了很多障碍和挑战之后,最终发布了我们所热爱的作品。在未来的几个月里,我将继续带你们探索Warcraft的开发之道。

 

1 收藏 评论

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部