游戏邦在:
杂志专栏:
gamerboom.com订阅到鲜果订阅到抓虾google reader订阅到有道订阅到QQ邮箱订阅到帮看

Patrick Wyatt分享《魔兽争霸》制作过程(3)

发布时间:2013-11-06 09:09:52 Tags:,,,

作者:Patrick Wyatt

你可以说第一款多人游戏《魔兽争霸》是成功的,也是失败的,或者是平局。怎么可能?好吧,这里面是有故事的。这个故事包含设计和制作游戏AI、游戏商业的经济、设计战争迷雾,等等。如果你的空闲时间很多,就继续往下读吧!(请点击此处阅读本文第1第2部分

从1993年9月起,《魔兽争霸:人类与兽人》最终成为该系列的第一款游戏,而不是一个拓展技术DEMO。

好几个月,我是这个项目唯一的全职员工,这大大拖延了开发进度。好在有其他员工帮助我,Ron Millar、Stu Rose等人也参与了项目的设计。几位美工在自己的项目间歇时也抽时间贡献了一些原画。

《魔兽争霸》项目组的成员极其少,因为这次是的资金由公司拿自己帮发行商Interplay和SunSoft等制作游戏获得的收益凑成的。公司的财源不广。

那时,我们还在开发16位的主机游戏《The Lost Vikings 2》(游戏邦注:这是一款横版“跑跳”益智游戏,但这个续作叫好不叫座)、《黑色荆棘》(横版“跑跳”游戏,主角拿枪当武器)、《正义联盟》(《街头霸王》的翻版,以DC漫画世界为背景)和《超人归来》(横版格斗游戏,是DC漫画世界系列的同名游戏)。

正是靠开发这些游戏和外包其他零活挣的钱,我们公司得负担初期开发的成本。

warcraft(from actiontrip.com)

warcraft(from actiontrip.com)

游戏开发的经济

在游戏行业的历史上,独立游戏开发工作室——也就是不属于零售游戏发行公司的工作室,通常靠与发行公司签约获得项目的资金。发行商会“提前”出钱支持项目的开发。除了资助开发,发行商还负责做广告、市场营销、生产、零售分销、客户服务,等等。

在90年代早期,那时的零售游戏发行商比现在更多,但随着游戏开发和发行的成本上涨,游戏行业开始大规模重组,导致许多公司破产或被收购,所以当说到今天的零售游戏发行商,你可能只会想起动视暴雪、EA或育碧,而不是无数存在于20年前的中等规模的公司。

与所有行业一样,合同条款主要是由出钱的一方规定的。这是另一条黄金法则:“有钱就是老大”。虽然理论上说,根据协议游戏卖得好的话,游戏开发者获得的收益也多,但与唱片和电影行业一样,绝大部分收益还是归发行商所有,而开发者得到的钱只顾支撑到签下一纸合同——如果他们走运的话。

我所谓的发行商的“提前”支付,更准确地说应该是“预付版税”:发行商给开发者提供的偿还性贷款,开发者之后用游戏的销售额偿还。听起来不错:开发游戏,卖一份赚一份。但事实上,绝大部分游戏的收益不足以扣除(支付)预付版税。因为开发工作室往往必须放弃游戏及其续作的版权,这些合同通常只是虚假的承包协议。

为了争取有利的合同条款,开发工作室的常用策略是,自己出资制作游戏原型,然后拿原型和发行商谈交易。开发者能够支撑游戏开发的时间越长,最终的合同条款就对开发者越有利。

使用这个策略的最佳案例大约就是Valve Software;联合创始人Gabe Newell用他在微软工作时获得的收入资助《半条命》的开发,因此很大程度上控制了游戏的发布时间安排—-只有在游戏达到高品质时才可以发布,而不是像Sierra Entertainment(该游戏的发行商)所期望的那样匆匆忙忙做出一款能达到一季度收益目标的产品。更重要的是,Gabe提供的必要资金为Valve争取到《半条命》的在线销售权;那时候数字下载正在成为游戏销售的可行策略,并且最终缔造了该工作室后来的巨大成功。

自行出资制作原型的缺陷在于,开发者要冒着发行商可能不签项目的风险。这通常导致工作室的倒闭。

我工作过的公司——当时名叫Silicon and Synapse,也是自行出资开发《魔兽争霸》和另一个叫作《Games People Play》的项目(它包含在机场书店里经常可以找到的填写益智游戏、串串字等供滞留旅客消遣的文字游戏)。

通过开发这款受众非常不同的游戏,公司老板希望挖通多条收益渠道,使公司的财政更加稳定,而不必把公司的整个前景押在核心娱乐市场上(也就是硬核市场)。

当然,把筹码分别压在多个类型的游戏上也是有风险的,因为公司品牌可能因制作达不到受众期待的产品而被削弱。今天,暴雪品牌的一大优势就是,它的玩家会闭着眼睛购买它的游戏,因为他们信任这家公司的实力和信誉。如果公司同时发布低成本的休闲游戏和高预算的AAA游戏,那么这种信誉就很难建立了,就像Sierra Entertainment一样,它经过几次开发受众无果后终于破产了。

无论如何,制作《Games People Play》最终被证明是失策,因为开发休闲娱乐产品令程序员们斗志全无,所以这个项目始终没有进度,后来就被取消了。或者也许它也不算是错误,因为《魔兽争霸》和《Games People Play》的组合打动了当时世界上第二大教育软件公司Davidson & Associates,所以Silicon & Synapse被它收购了。

D&A Logo(from merchantcircle.com)

D&A Logo(from merchantcircle.com)

我们的新老板

Davidson & Associates,是由Jan Davidson创立的,后来她的丈夫Bob也加入。这是一家从事教育软件开发的公司,《Math Blaster》是其成功的奠基之作。在这款游戏中,玩家通过回答数学问题来炸毁小行星,以免自己的飞船被撞坏。《Math Blaster》是寓教于乐的典范,它为该公司赢得了不少荣誉。

另外,作为一款教育游戏,《Math Blaster》如果使用得当确实有一些价值,但我经常看到它被误用。我上中学时,给我们的校报写文章的记者班的同学和矫正教育班的同学共用一个电脑房,我和我的记者小伙伴们惊恐地发现,十二年级的矫正教育班的同学居然用计算器玩《Math Blaster》!当小行星显示数学算式“3 + 5”和“2 * 3”时,这些学生会飞快地把算式输入计算器,然后把计算器输出的答案打出来,使飞船击毁这些小行星。确实,他们正在学习,毕竟他们比他们的老师更聪明,但考虑到他们马上就要工作了,我不敢说他们充分利用了课堂时间。

在上进的领导层的良好管理下,Davidson & Associates的业务拓展到游戏制造(制作和包装零售游戏)、游戏销售(把游戏分配给零售商和中间商)和面向学校的教材销售。他们看到进入娱乐行业的机遇,但他们自己制作娱乐产品的早期经验告诉他们,收购一个有经验的游戏开发工作室来继续开发他们的游戏更合理,因为他们自己的员工对早教的了解远多于刀剑和魔法。

所以,阻碍《魔兽争霸》开发团队成长的资金流问题一下子就因公司被收购而解决了;有了新东家的雄厚财力的支持,Silicon & Synapse(游戏邦注:被收购后更名为“暴雪”)得以专注于自己的项目开发而不是跟其他游戏发行商争抢那一点儿利润。新东家其实也很边缘,甚至在1993年制作了两款广受欢迎的游戏,为该公司赢利了“年度Nintendo游戏开发者”的荣誉,他们并不收取任何版税。

暴雪用“卖身”得到的钱雇用了新员工,使老员工得以抽身去开发《魔兽争霸》,所以项目的效率大大提高了。

设计“过程”

在暴雪的发展早期,设计和制作游戏的过程非常混乱,虽然也有正规的设计会议,但更经常地是在走廊聊天或吃饭时即兴创作。

有些特征来自设计文件,有些是程序员一时兴趣添加的。有些游戏美术是计划好的,根据日程表有条理地执行的,有些则是美工半夜灵感突发或只是想尝试不同的东西。其他元素也同样即兴添加;《魔兽争霸》的故事和设定直到发布的前几个月才整合到一起。

虽然这个过程难以捉摸,但结果却相当惊人。因为我们的团队是由电脑游戏狂人组成的,我们的游戏随着开发越来越完善,最终成为玩家想一直玩下去的杰作。《魔兽争霸》,我们为IBM PC制作的第一款原创游戏,就是这种疯狂制作过程的最佳(有时候是最糟)示范,最终这款游戏成为(至少在当时)经典。

单位生产系统

生物学家知道进化过程有不成功的开始,进化树的所有分支都被消除了,我们的开发工作也是如此。因为我们没有可测量的标准,所以我们只是实验和剔除不管用的东西。我想过,这是一个慎重的、有意识的过程,但许多时候源于意外、争论和个人冲突。

我记忆犹新的一件事是关于游戏的单位生产系统。在开发早期,单位出现全靠输入主机的“欺骗”指令,因为没有其他UI机制能建造它们。当我们思考用什么方法生成单位时,我们冒出了各种想法。

美工Ron Millar为早期的暴雪游戏做了大量构思和设计,他提议,玩家应该建造生产性建筑—-就像《上帝也疯狂》那样,这些建筑会周期性地刷出基本的工人单位,也就是所谓的(人类)农民和(兽人)奴隶。玩家可以使用这些单位从事采金、伐木和建造,但这些单位无法像战士一样作战。

这些“农奴”除非已经在劳作,否则玩家可以把它们放进兵营中训练,这时它们会从地图上消失一会儿,直到它们成为合格的战士。其他训练区域将用于生产更多先进的军事单位如投石车和术士等。

这个想法没有完全“充实”,这是我们的设计过程的普遍缺陷:设计过程的最终结果很不正规,没有文明规定想法应该如何执行。所以这个想法并没有得到充分的讨论和编写执行代码,就被不正式的设计团队(公司的大部分人)驳回了。

在我们开始编写代码时,Ron就陪公司总裁Allen Adham一起去参加展销会了(可能是消费类电子产品展销会)。在他们离开期间,发生了一件事,使整个《魔兽争霸》系列的方向改变了。我把那个事件称作“魔兽设计政变”。

Stu Rose是美工/设计师,是公司的另一位元老(我想是第6号员工)。一天下午他来我办公室,提议了另一条思路。Stu认为Ron所提议的单位生产机制有太多还没解决的执行难题,并且与我们在RTS游戏中应该给予玩家的那种控制权不相符。

在这种新RTS类型中,对玩家的要求比其他类型的游戏更高,且玩家的注意力不能长时间只放在一个地方,因为有许多互相冲突的要求:计划建造/升级树、促进经济活动、生产单位、布置建筑、探索地图、监督作战和微调单个单位珠技能。在RTS中,最有限的资源就是玩家的注意思,用间接单位生成机制会增加认知负担,进而导致注意力失调和游戏难度上升。

为了生产基本的战斗单位“野猪兽”,必须把闲置的农民或从事低优先级任务的农民送去训练,这就增加了游戏的不必要的(在Stu看来)复杂度。

我赞同他的意见,因为我也有相同的担忧(尽管没有那么清楚的思路),而且我认为单位生产不是我们必须大胆修改的地方。《魔兽争霸》的灵感来源,《沙丘魔堡2》有更加简单的单位生成机制:只要点击生产建筑的UI面板上的一个按钮,单位就会马上刷出来。这其实也不是什么创新的做法——也是从更早的游戏那里复制过来的,但就是管用。

Stu主张我们应该采用上述方法,与其再争论下去,不如现在就做好, 所以在那之后的几天几夜,我匆匆做出执行单位生产所必需的游戏和UI代码。于是,这个设计决定就成为既定事实了。等到Ron和Allen回来,游戏已经可以在单人模式下玩了,除了敌人电脑AI仍然差好几个月才能完成。

这时的《魔兽争霸》是一款玩起来非常容易的游戏,更重要的是,好玩。我们成功了。

第一款多人游戏

1994年6月,也就是开发了十个月后,多人模式的游戏引擎已经接近完工。当我整合代码时,我的心情一直很激烈,因为它将成为《魔兽争霸》的第一款多人游戏。在我一直忙着编写核心游戏罗辑(事件循环、单位分配器、寻径、战斗单位AI、状态栏、游戏内UI、高级网络代码)的时候,其他程序员已经在做多人游戏必须的相关组件了。

加州理工大学的毕业生Jesse McReynolds已经完成在本地网络中发送IPX包的低级网络库。这些代码是根据《毁灭战士》的源代码(是id software公司的John Carmack公开的)在编写的。虽然IPX中间层只是几百条C代码语句,但它是连接网卡驱动的代码的一部分,而网卡驱动保证在一个游戏客户端生成的信息被发送到另一个客户端。

Bob Fitch是加州州立大学的硕士,他开发了让玩家能够创建和加入多人游戏的最初的“glue screen”用户界面屏幕。我的办公室就在Bob旁边,非常方便,因为我们要密切合作,把他的游戏加入或创建逻辑整合到我的游戏事件循环中。

整合完修改后,我编辑了游戏客户端,复制了一份到网络共享盘,Bob则返回他的办公室加入游戏。真是奇迹,我们的代码管用了,我们可以开始玩《魔兽争霸》的第一款多人游戏了。

我们开始玩游戏了,我比玩任何其他游戏都兴奋。部分是因为我参与了代码编写,但更重要的是另外两个原因:我将与人类对手而非电脑AI对抗,以及因为战争迷雾,我将不知道对手的动向。

战争迷雾

借鉴早期游戏的另一个想法是隐藏敌人单位。在游戏地图上,隐藏区域将被黑色覆盖,除非有友方单位探索了该区域;这个所谓的“战争迷雾”就是为了真实战争中存在的模仿信息不完整的情况—-不知道敌人的战术和军队活动。

由“D程序语言之父”Walter Bright于约17年以前编写的多人回合制策略游戏《帝国》,也是出于相同的目的而使用了战争迷雾。一旦地图上的区域“被发现”(已探索),之后就一直保持可见状态,所以,在早期发现足够大的地图区域以提前获知敌人军队活动的警告,是一个重要的考虑;如果不能及时发现敌军来袭,重要的生产单位或经济命脉就会被敌人破坏。

在历史上,不知道敌人在做什么的心理恐惧是许多将领失败的根源,把这个元素添加到RTS中,是提高游戏趣味(兴奋和恐惧)的好办法。向Walter和制作了《沙丘魔堡》的Westwood开发者们致敬!

电脑AI

正如许多玩家所知的,在策略游戏中,电脑控制的AI玩家通常是很弱的。人类玩家往往发现和利用程序未能阻止的电脑AI的缺陷,不费力地就击败AI,所以为了与真人玩家势均力敌,电脑AI玩家通常依靠军队数量上的优势、位置优势或“不对称原则”。

在《魔兽争霸》的大部分任务中,敌人电脑玩家在与人类玩家对抗时,一开始就有完整的城市和军队。另外,《魔兽争霸》使用了若干不对称原则,使AI玩家更有竞争优势,尽管这些原则可能会被大部分玩家称为“作弊”。

我们用来帮助电脑AI的一条原则是,减少从金矿堆中移走的金子的数值,以防止金矿被开采完。当人类玩家的农民采集金矿时,每次将100单位的矿石运回玩家的城镇,最终金矿会被采光。然而,当AI控制的农民采矿时,一次只能从金矿中运走8单位的金子,但放进AI仓库的金子数量仍然是100。

事实上,不对称原则使游戏更好玩了,这体现在两个方面:第一,防止人类玩家使用“乌龟”战术,也就是建造一个打不到的防御工事,使用他们更高超的策略技巧来制服电脑AI。乌龟战术是对抗电脑AI的致命策略,因为人类玩家的金矿采集完的时间会比电脑的早得多。

第二,当人类玩家最终摧毁电脑对手的基地时,仍然会剩下一些金矿供玩家继续开采,这就使游戏得以运行得更快,比靠资源受限获得胜利来得有趣。

大部分玩家都意识到电脑AI在另一点上更加严重地违背了公平竞争的精神:电脑AI可以看穿战争迷雾;玩家的一举一动都落在AI眼底。事实上,这对电脑来说并不是什么大优势,只是避免AI显得太过愚蠢。

有趣的是,随着《星际争霸》的持续流行(自发布起超过14年)。一群程序员决定制作一种非作弊的AI。借助名为“BWAPI”的库,这些程序员写出了可以将指令直接注入《星际争霸》引擎的代码。程序员让他们的AI们互相对抗,看看哪个AI会胜出。虽然这些BWAPI AI玩家很不错,但获胜的那个仍然会被有技术的人类玩家轻松打败。

Starcraft(from hiveworkshop.com)

Starcraft(from hiveworkshop.com)

对抗人类玩家

作为在开发《魔兽争霸》以前已经玩过许多许多策略游戏的人,我很清楚那个时代的电脑AI的缺陷。虽然我与许多电脑AI对抗过,偶尔失败,多数获胜,但我从来没有被AI吓倒过,甚至在玩Chris Crawford制作的《Eastern Front》时面临俄国的疯狂进攻时。我用朋友的Atari 800玩那款游戏,一直玩到存有游戏的磁带老得不能读取时。

游戏有趣,令人兴奋,大部分时候也有挑战性,但并不可怕。直到我第一次玩多人模式的《魔兽争霸》,我才改变看法。

知道我正在与正常的人类玩家竞争,对方不只是懂技巧和策略,而且控制的速度快,再加上战争迷雾使我看不到他的行动,让我既兴奋又害怕。在我的整个游戏生涯中,单人游戏从来没有让我像玩《魔兽争霸》的多人模式这样兴奋过,因为在后者中,我不可能知道我的一举一动是让我走向胜利还是失败。

我热血沸腾,我竭尽全力采集金子和木材、建造农场和兵营、增强进攻能力、探索地图——以及最重要的,粉碎Bob的军队的进攻,否则他就会消灭我的军队。

这不是为了验证引擎的功能性而做的测试;我知道他也很渴望成为第一个在《魔兽争霸》的第一款多人游戏中获胜的人。另外,我们在暴雪一起玩《毁灭战士》时,我已经有一些荣耀了,因为我一直用火箭筒打死他,让他非常生气,以至于发誓再也不跟我一起玩了。我知道他想一雪前耻。

当我们两军交战时,我们再加倍生产单位,把它们丢进战场。当我发现他的营地时,我就进攻,我感觉有希望获胜。Bob的打法似乎杂乱无章,似乎我有办法粉碎他们的军事力量,但我想把事情做得完美无缺,所以我继续疯狂地进攻任何被我遇到的他的单位和建筑。

然后……崩溃了。

程序员都知道,写出第一次就能通过的代码几乎是不可能的,所以游戏崩溃了没有什么好大惊小怪的。游戏的图像扭到屏幕上方,被DOS4GW的“崩溃页面”取代了——这是Windows时代以前的玩家非常熟悉的。现在,我们有更复杂的Windows错误报告对话,玩家可以提交崩溃报告,玩家很少看到的可怕的“死机蓝屏”就非常类似于那时老玩家看到的死机屏幕。

崩溃之后,我从座位上跳起来,冲到Bob的办公室,大叫“太牛了!”却马上听到:“干掉你了!”我为他的反驳回答感到吃惊:他居然消灭了我?

我们花了几分钟才让紧绷的神经回复正常,但我们很快意识到我们不仅遇到了漏洞,还有游戏状态不同步的问题,我称之为“同步漏洞”:两台显示的战斗完全不同,虽然它们一开始时是一样的,但慢慢分裂为两个完全不同的状态。

不曾编写过网络代码的人可能会认为,当游戏运行时,两个游戏客户端会在发送各个回合中的整个游戏的状态。也就是,各个回合电脑会发送所有游戏单位的位置和活动。对于只有几个面板位置的慢节奏的游戏,如国际象棋或西洋棋,这当然是可能的,但对于像《魔兽争霸》这样具有同时活动的600个单位的游戏,通过网络发送所有信息是不可能的。

我们想到许多玩家会用2400波特率的“猫”玩《魔兽争霸》,它的传输速度是每秒几百个字符。从来没有用过“猫”的年轻玩家应该好好了解一下这种技术,它比狼烟先进,但没有太多。记住,这是亚马逊、谷歌和Netflix诞生以前——我们在说的黑暗时代。

以前曾参与过把《战棋》从DOS移植到Windows,所以我很熟悉多人游戏如何用“猫”通讯。我知道,因为“猫”的有限带宽,发送整个游戏状态是不可能的,所以我的解决办法是只发送玩家的指令,并让双方玩家同时执行那些指令。

我知道这个解决方案是可行的,因为电脑最擅长准确地执行人类告诉它们的任务。不幸的是,编程的我们人类自己却并不擅长告诉电脑到底怎么做才是对的,这就是漏洞产生的根源。当两台电脑应该做相同的事情时,漏洞会导致两台电脑显示不同的状态。

当两台电脑面对相同的问题却选择了不同的回答时,同步漏洞就产生了;那个差异会越来越大。就像在时间旅行电影《回到未来》:时间旅行者在过去做的小小的改变导致了完全不同的未来;《魔兽争霸》的显示不同步问题也是这样产生的。在我的电脑上,我的人类射手看到兽人奴隶就攻击,而在你的电脑上,兽人却没有感应到攻击,仍然在砍它的树。没有发现或改正这些不一致的机制,我们双方的游戏状态很快就会完全不同。

所以说,《魔兽争霸》的第一场比赛是平局,但同时,它又是游戏开发团队的伟大胜利。不久后,办公室里的其他团队的成员也开始玩多人模式,发现它就像“Blue Sky”——《绝命毒师》里的主人公Walter White所研制的冰毒纯晶体脱氧麻黄碱:一旦玩过一次《魔兽争霸》的多人模式,就会觉得其他游戏都不好玩了。即使游戏还是经常出现漏洞,但我们知道我们正在做一件大事。

我们要做的只是把游戏完成。

悲剧的是,我们很快发现一个更严重的问题:不仅同步漏洞很多,而且导致这些同步漏洞的原因也各不相同。如果所有的同步漏洞都是因为类似的原因,那么我们就可以努力解决掉这唯一的根源就好了。但结果是问题的类型这么多,每一个都引起不同类型的同步漏洞,所以挨个解决是不可避免了。

为什么出现同步漏洞

在开发《魔兽争霸》时,我已经设计了一个最小化数据(必须在网络间传输的数据)量的解决方案——只发送各个玩家发起的指令,像“选择单位5”、“移动 到650,1224”和“进攻单位53”等。许多程序员都已经独立设计了这个相同的系统;它显然是一个在不发送回合间的整个游戏状态而解决同步电脑问题的方法。

另外:现在这个方法可能有几个专利要声明。我一直觉得软件不应该申请专利;软件中大部分想法是一般程度的程序员就能想到的,专利的定义要求专利品必须非明显。废话。

我还没有执行过能验证两台电脑之间的同步性的机制,所以游戏代码中任何引起电脑做出不同选择的漏洞都会导致游戏走向“分裂”——也就是,变成两个松散成对的时空,虽然还在继续交流信息,但分裂的速度会越来越快。

制作能够检测不同步问题的系统,显然是发布这款游戏以前的下一个任务。

你知道这个故事的结局:《魔兽争霸》最终在五个月后完工了。它对我们来说就是一个永垂不朽的产品,因为我们花了这么多时间、遇到了这么多障碍、克服了这么多挑战,才做出我们这么热爱的东西。在接下来的文章中,我将继续叙述这个故事,但那时候发生的事太多了,所以我不可能在这篇已经很久的文章中把所有回忆都回顾一遍!(本文为游戏邦/gamerboom.com编译,拒绝任何不保留版权的转载,如需转载请联系:游戏邦

The making of Warcraft part 3

by Patrick Wyatt

The first-ever multiplayer game of Warcraft was a crushing victory, an abject defeat, and a tie, all at once. Wait, how is that possible? Well, therein lies a tale. This tale grew organically during the writing to include game AI, the economics of the game business, fog of war and more. Read on if you have lots of free time!

After six months of development that started in September 1993, Warcraft: Orcs vs. Humans, the first product in what would eventually become the Warcraft series, was finally turning into a game instead of an extended tech-demo.

For several months I was the only full-time employee on the project, which limited the rate of development. I was fortunate to be assisted by other staff members, including Ron Millar, Stu Rose, and others, who did design work on the project. And several artists contributed prototype artwork when they found time in between milestones on other projects.

The team was thinly staffed because the development of Warcraft was self-funded by the company from revenues received for developing titles for game publishers like Interplay and SunSoft, and the company coffers were not deep.

At that time we were developing four 16-bit console titles: The Lost Vikings 2 (the sequel to our critically-acclaimed but low-selling, side-scrolling “run-and-jump” puzzle game), Blackthorne (a side-scrolling “run-and-jump” game where the lead character gets busy with a shotgun), Justice League Task Force (a Street Fighter clone set in the DC Comics universe), and Death and Return of Superman (a side-scrolling beat-em-up based on the DC universe comic series of the same name).

With the money received for developing these games and other odd jobs the company was able to pay initial development costs.

Game development economics
For most of the history of the game industry, independent game development studios — which is to say studios that weren’t owned by a retail game publishing company — usually funded their projects by signing contracts with those publishing companies. Publishers would “advance” money for the development of the project. In addition to advances for development, publishers were responsible for publicity, marketing, manufacturing, retail distribution, customer support and so forth.

Back in the early 90′s there were many more retail game-publishers than exist today, but the increasing cost of game development and especially of game publishing led to massive industry consolidation due to bankruptcies and acquisitions, so when you think of a retail game publisher today you’ll probably think of Activision-Blizzard, EA or Ubisoft instead of the myriad mid-sized companies that existed twenty years ago.

As in all industries, the terms of contracts are drawn up to be heavily in the favor of the people with the money. This is the other golden rule: “he who has the money makes the rules”. While in theory these agreements are structured so that the game developer is rewarded when a game sells well, as in the record and movie industries publishers capture the vast majority of profits, with developers receiving enough money to survive to sign another agreement — if they’re lucky.

When I mentioned “advances” paid by the publisher, the more correct term is “advances against royalties”, where the developer if effectively receiving a forgivable loan to be repaid from royalties for game sales. It sounds great: develop a game, get paid for each copy sold. But the mechanics work out such that the vast majority of game titles never earn enough money to recoup (pay for) the advances. Since development studios often had to give up the rights to their title and sequels, these agreements are often thinly disguised work-for-hire agreements.

To aim for better deal terms, a common strategy employed by development studios was to self-fund an initial game prototype, then use the prototype to “pitch” a development deal to publishers. The longer a developer was able to self-fund game creation the better the eventual contract terms.

Perhaps the best example of this strategy is Valve Software, where Gabe Newell used the wealth he earned at Microsoft to fund the development of Half Life and thereby gain a measure of control over the launch schedule for the game — releasing the game only when it was a high-quality product instead of rushing it out the door to meet quarterly revenue goals as Sierra Entertainment (the game’s publisher) desired. More importantly, Gabe’s financial wherewithal enabled Valve to obtain ownership of the online distribution rights for Half Life just as digital downloads were becoming a viable strategy for selling games, and led to that studio’s later — vast — successes.

The downside to self-funding a prototype is the risk that the developer takes in the event that the game project is not signed by a publisher — oftentimes resulting in the death of the studio.

The company I worked for — at that time named Silicon and Synapse — was self-funding Warcraft, along with another project called Games People Play, which would include crossword puzzles, boggle and similar games found on the shelves at airport bookstores to entertain stranded travelers.

By developing two games that targeted radically different audiences the company owners hoped to create multiple sources of revenue that would be more economically stable compared to betting all the company’s prospects on the core entertainment market (that is, “hard core” gamers like you ‘n me).

Of course spreading bets across diverse game genres also has risks, inasmuch as a company brand can be diluted by creating products that don’t meet the desires its audiences. One of the great strengths of the Blizzard brand today is that users will buy its games sight-unseen because they believe in the company’s vision and reputation. That reputation would have been more difficult to establish had the company released both lower-budget casual titles and high-budget AAA+ games, as did Sierra Entertainment, which is now out of business after repeated struggles to find an audience.

In any event, creating Games People Play turned out to be a misstep because developing a casual entertainment product was so demoralizing for the lead programmer that the project never matured and was later canceled. Or perhaps it wasn’t a mistake, because the combination of Warcraft and Games People Play convinced Davidson & Associates, at that time the second largest educational software company in the world, to purchase Silicon & Synapse.

Our new overlords

Davidson & Associates, started by Jan Davidson and later joined by her husband Bob, was a diversified educational software company whose growth was predicated on the success of a title named Math Blaster, in which a player answers math problems to blow up incoming asteroids before they destroy the player’s ship. It was a clever conjunction of education and entertainment, and the company reaped massive rewards from its release.

Aside: As an educational title Math Blaster may have had some value when used properly, but I had occasion to see it used in folly. My high school journalism class would write articles for our school newspaper in a computer room shared with the remedial education class; my fellow journalism students and I watched in horror as remedial twelfth graders played Math Blaster using calculators. As asteroids containing expressions like “3 + 5″ and “2 * 3″ approached those students would rapidly punch the equations into calculators then enter the results to destroy those asteroids. Arguably they were learning something, considering they outsmarted their teachers, but I’m not sure it was the best use of their time given their rapidly approaching entry into the work-force.

With good stewardship and aggressive leadership Davidson & Associates expanded into game manufacturing (creating & packing the retail box), game distribution (shipping boxes to retailers and intermediate distributors), and direct-to-school learning-materials distribution. They saw an opportunity to expand into the entertainment business, but their early efforts at creating entertainment titles internally convinced them that it would make better sense to purchase an experienced game development studio rather than continuing to develop their own games with a staff more knowledgeable about early learning than swords & sorcery.

And so at a stroke the cash-flow problems that prevented the growth of the Warcraft development team were solved by the company’s acquisition; with the deep pockets of Davidson backing the effort it was now possible for Silicon & Synapse (renamed Blizzard in the aftermath of the sale) to focus on its own titles instead of pursuing marginally-profitable deals with other game publishers. And they were very marginal — even creating two top-rated games in 1993, which led to the company being named “Nintendo Developer of the Year”, the company didn’t receive any royalties.

With a stack of cash from the acquisition to hire new employees and enable existing staff to jump on board the project, the development of Warcraft accelerated dramatically.

The design “process”

The approach to designing and building games at Blizzard during its early years could best be described as “organic”. It was a chaotic process that occurred during formal design meetings but more frequently during impromptu hallway gatherings or over meals.

Some features came from design documents, whereas others were added by individual programmers at whim. Some game art was planned, scheduled and executed methodically, whereas other work was created late at night because an artist had a great idea or simply wanted to try something different. Other elements were similarly ad-libbed; the story and lore for Warcraft came together only in the last several months prior to launch.

While the process was unpredictable, the results were spectacular. Because the team was comprised of computer game fanatics, our games evolved over the course of their development to become something that gamers would want to play and play and play. And Warcraft, our first original game for the IBM PC, exemplified the best (and sometimes the worst) of that process, ultimately resulting in a game that — at least for its day — was exemplary.

How the Warcraft unit-creation system came about

As biologists know the process of evolution has false starts where entire branches of the evolutionary tree are wiped out, and so it was with our development efforts. Because we didn’t have spec to measure against, we instead experimented and culled the things that didn’t work. I’d like to say that this was a measured, conscious process in each case, but many times it arose from accidents, arguments, and personality conflicts.

One event I remember in particular was related to the creation of game units. During the early phase of development, units were conjured into existence using “cheat” commands typed into the console because there was no other user-interface mechanism to build them. As we considered how best to create units, various ideas were proposed.

Ron Millar, an artist who did much of the ideation and design for early Blizzard games proposed that players would build farm-houses, and — as in the game Populous — those farms would periodically spawn basic worker units, known as (Human) peasants and (Orc) peons. The player would be able to use those units directly for gold-mining, lumber-harvesting and building-construction, but they wouldn’t be much good as fighters.

Those “peons” not otherwise occupied could be directed by the player to attend military training in barracks, where they’d disappear from the map for a while and eventually emerge as skilled combatants. Other training areas would be used for the creation of more advanced military units like catapult teams and wizards.

The idea was not fully “fleshed out”, which was one of the common flaws of our design process: the end result of the design process lacked the formality to document how an idea should be implemented. So the idea was kicked around and argued back and forth through the informal design team (that is, most of the company) before we started coding (programming) the implementation.

Before we started working on the code Ron left to attend a trade show (probably Winter CES — the Consumer Electronics Show), along with Allen Adham, the company’s president. And during their absence an event occurred which set the direction for the entire Warcraft series, an event that I call the “Warcraft design coup”.

Stu Rose, another early artist/designer to join the company (employee #6, I believe), came late one afternoon to my office to make a case for a different approach. Stu felt that the unit creation mechanism Ron proposed had too many as-yet-unsolved implementation complexities, and moreover that it was antithetical to the type of control we should be giving players in a Real-Time Strategy (RTS) game.

In this new RTS genre the demands on players were much greater than in other genres and players’ attention could not be focused in one place for long because of the many competing demands: plan the build/upgrade tree, drive economic activity, create units, place buildings, scout the map, oversee combat and micromanage individual unit skills. In an RTS the most limited resource is player attention so adding to the cognitive burden with an indirect unit creation mechanism would add to the attention deficit and increase the game’s difficulty.

To build “grunts”, the basic fighting unit, it would be necessary to corral idle peasants or those working on lower priority tasks to give them training, unnecessarily (in Stu’s view) adding to the game’s difficulty.

I was a ready audience for his proposal as I had similar (though less well thought out) concerns and didn’t feel that unit creation was an area where we needed to make bold changes. Dune II, the game from which the design of Warcraft was derived, had a far simpler mechanism for unit creation: just click a button on the user-interface panel of a factory building and the unit would pop out a short time later. It wasn’t novel — the idea was copied from even earlier games — but it just worked.

Stu argued that we should take this approach, and in lieu of more debate just get it done now, so over the next couple of days and late nights I banged out the game and user-interface code necessary to implement unit creation, and the design decision became fait accompli. By the time Ron and Allen returned the game was marginally playable in single-player mode, excepting that the enemy-computer AI was still months away from being developed.

Warcraft was now an actual game that was simple to play and — more importantly — fun. We never looked back.

The first multiplayer game of Warcraft
In June 1994, after ten months of development, the game engine was nearly ready for multiplayer. It was with a growing sense of excitement that I integrated the code changes that would make it possible to play the first-ever multiplayer game of Warcraft. While I had been busy building the core game logic (event loop, unit-dispatcher, path-finding, tactical unit-AI, status bar, in-game user-interface, high-level network code) to play, other programmers had been working on related components required to create a multiplayer game.

Jesse McReynolds, a graduate of Caltech, had finished coding a low-level network library to send IPX packets over a local-area network. The code was written based on knowledge gleaned from the source code of Quake Doom, which had been recently was later open-sourced by John Carmack at id software. While the IPX interface layer was only several hundred lines of C code, it was the portion of the code that interfaced with the network-card driver to ensure that messages created on one game client would be sent to the other player.

And Bob Fitch, who was earning his master’s degree from Cal State Fullerton, developed the initial “glue screens” that enabled players to create and join multiplayer games. My office was next to Bob’s, which was mighty convenient since it was necessary for us to collaborate closely to integrate his game join-or-create logic to my game-event loop.

After incorporating the changes I compiled the game client and copied it to a network drive while Bob raced back to his office to join the game. In what was a minor miracle, the code we’d written actually worked and we were able to start playing the very first multiplayer game of Warcraft.

As we started the game I felt a greater sense of excitement than I’d ever known playing any other game. Part of the thrill was in knowing that I had helped to write the code, but even more so were two factors that created a sense of terror: playing against a human opponent instead of a mere computer AI, and more especially, not knowing what he was up to because of the fog of war.

The fog of war

A small village surrounded by the fog of war; what’s out there?!?
One of the ideas drawn from earlier games was that of hiding enemy units from sight of the opposing player. A black graphic overlay hid areas of the game map unless a friendly unit explored the area, which is designed to mimic the imperfect information known by a general about enemy operations and troop movements during real battles.

Empire, a multiplayer turn-based strategy game written almost seventeen years before by the brilliant Walter Bright (creator the “D” programming language), used fog of war for that same purpose. Once an area of the map was “discovered” (uncovered) it would remain visible forever afterwards, so an important consideration when playing was to explore enough of the map early in the game so as to receive advance warning of enemy troop movements before their incursions could cause damage to critical infrastructure or economic capability.

The psychological terror created by not knowing what the enemy is doing has been the demise of many generals throughout history, and adding this element to the RTS genre is a great way to add to the excitement (and fear) level. Thank Walter and the folks at Westwood who created Dune II for their savvy!

Computer AI

As many gamers know, computer-controlled “Artificial Intelligence” (AI) players in strategy games are often weak. It’s common for human players to discover exploits that the computer AI is not programmed to defend against that can be used destroy the AI with little difficulty, so computer AI players usually rely upon a numeric troop advantage, positional advantage, or “asymmetric rules” in order to give players a good challenge.

In most Warcraft missions the enemy computer players are given entire cities and armies to start with when battling human players. Moreover, Warcraft contains several asymmetric rules which make it easier for the AI player to compete, though these rules would perhaps be called outright cheating by most players.

One rule we created to help the computer AI was to reduce the amount of gold removed from gold mines to prevent them from being mined-out. When a human player’s workers emerge from a gold mine those workers remove 100 units of ore from the mine and deliver it back to the player’s town hall on each trip, and eventually the gold mine is exhausted by these mining efforts. However, when an AI-controlled worker makes the same trip, the worker only remove 8 units of ore from the mine, while still delivering 100 units into the AI treasury.

This asymmetric rule actually makes the game more fun in two respects: it prevents humans from “turtling”, which is to say building an unassailable defense and using their superior strategic skills to overcome the computer AI. Turtling is a doomed strategy against computer AIs because the human player’s gold-mines will run dry long before those of the computer.

Secondarily, when the human player eventually does destroy the computer encampment there will still be gold left for the player to harvest, which makes the game run faster and is more fun than grinding out a victory with limited resources.

Most players are aware of a more serious violation of the spirit of fair competition: the computer AI cheats because it can see through the fog of war; the AI knows exactly what the player is doing from moment to moment. In practice this wasn’t a huge advantage for the computer and merely served to prevent it from appearing completely stupid.

Interestingly, with the long popularity of StarCraft (over 14 years since launch and still played), a group of AI programmers has risen to the challenge of building non-cheating AIs. Aided by a library called BWAPI, these programmers write code that can inject commands directly into the StarCraft engine to play the game. Programmers enter their AIs in competitions with each other to determine the victor. While these BWAPI AI players are good, the best of them are handily beaten by skilled human opponents.

Playing against a human

As a person who had played many (many many) strategy games before developing Warcraft, I was well aware of the limitations of computer AIs of that era. While I had battled against many computer AIs, sometimes losing, many times winning, I was never scared by AI intelligence, even when battling the terrible Russian offensive in the game Eastern Front by Chris Crawford, which I played on a friend’s Atari 800 until eventually the audio cassette tape (!) that contained the game was so old it could no longer be read.

These games were fun, exciting, and most certainly challenging, but not scary. But something changed when I played the first multiplayer game of Warcraft.

The knowledge that I was competing against an able human player — not just in terms of skill and strategy, but also in terms of speed of command — but was prevented from seeing his actions by the fog of war was both electrifying and terrifying. In my entire career I have never felt as excited about a single game as I was during that first experience playing Warcraft, where it was impossible to know whether I was winning or losing.

As a massive adrenaline rush spiked in my bloodstream, I did my best to efficiently harvest gold and lumber, build farms and barracks, develop an offensive capability, explore the map, and — most importantly — crush Bob’s armies before he could do the same to mine.

This was no test-game to verify the functionality of the engine; I know he felt the same desire to claim bragging rights over who won the first-ever multiplayer game of Warcraft. Moreover, when we had played Doom together at Blizzard, I had won some renown because, after a particularly fierce game Bob had become so angry at me for killing him so frequently with a rocket launcher that he had vowed never to play me again. I knew he’d be looking for payback.

As our armies met in battle, we redoubled our efforts to build more units and threw them into the fray. Once I discovered his encampment and attacked, I felt more hopeful. Bob’s strategy seemed disorganized and it appeared I would be able to crush his forces, but I wanted to leave nothing to chance so I continued at a frenzied pace, attacking his units and buildings wherever I could find them.

And then … crash:

Bad news bears – DOS4GW lets us know Warcraft crashed
As any programmer knows, the likelihood of new code working properly the first time is close to zero, and so it should be no surprise that the game crashed. The game’s graphics scrolled off the top of the monitor and were replaced with the blocky text of the DOS4GW “crash screen” so familiar to gamers in the era before Windows gaming. Now we have the far more sophisticated Windows Error Reporting dialog which enables the player to submit the crash report, though occasionally players see the dreaded “blue screen of death” which is remarkably similar to those of old.

After the crash I leaped up from my chair and ran into Bob’s office, yelling “That was awesooooommmme!” immediately followed by “… and I was kicking your ass!” So I was surprised to hear Bob’s immediate rebuttal: to the contrary, he had been destroying me.

It took a few minutes for our jangled nerves to return to normal but in short order we determined that not only did we have a crash bug but also a game-state synchronization problem, which I termed a “sync bug”: the two computers were showing entirely different battles that, while they started identically, diverged into two entirely different universes.

Someone who hasn’t worked on programming network code might assume that the two Warcraft game clients would send the entire game state back and forth each turn as the game is played. That is, each turn the computers would send the positions and actions for every game unit. In a slow-paced game with only a few board positions, like Chess or Checkers, this would certainly be possible but in a game like Warcraft, with up to 600 units in action at once, it was impossible to send that volume of information over the network.

We anticipated that many gamers would play Warcraft with 2400 baud modems, which could only transmit a few hundred characters per second. Younger gamers who never used a modem should take the time to read up on the technology, which was little removed from smoke signals, and only slightly more advanced than banging rocks together. Remember, this was before Amazon, Google and Netflix — we’re talking the dark ages, man.

Having previously “ported” Battle Chess from DOS to Windows, I was familiar with how multiplayer games could communicate using modems. I knew that because of the limited bandwidth available via a modem it would have been impossible to send the entire game state over the network, so my solution was to send only each player’s commands and have both players execute those commands simultaneously.

I knew that this solution would work because computers are great at doing exactly what they’re told. Unfortunately it turned out that many times we humans who program them are not so good at telling computers exactly the right thing to do, and that is a major source of bugs. When two computers are supposed to be doing the same thing, but disagree because of a bug, well, that’s a problem.

A sync bug arises when the two computers simulating the game each choose different answers to the same question, and from there diverge further and further over time. As in time-travel movies like Back to the Future, small changes made by the time-traveler while in the past lead to entirely different futures; so it was that games of Warcraft would similarly diverge. On my computer my Elvish Human archer would see your Orcish peon and attack, whereas on your computer the peon would fail to notice the attack and wander off to harvest lumber. With no mechanism to discover or rectify these types of disagreements, our two games would soon be entirely different.

So it was that the first game of Warcraft was a draw, but at the same time it was a giant win for the game team — it was hella fun! Other team members in the office played multiplayer soon afterwards and discovered it was like Blue Sky, the pure crystal meth manufactured by Walter White in Breaking Bad. Once people got a taste for multiplayer Warcraft, nothing else was as good. Even with regular game crashes, we knew we were on to something big.

All we needed to do was get the game done.

Tragically, we soon made an even worse discovery: not only did we have numerous sync bugs, but there were also many different causes for those sync bugs. If all the sync bugs were for similar reasons we could have endeavored to fix the singular root cause. Instead it turned out there were numerous different types of problems, each of which caused a different type of sync bug, and each which therefore necessitated its own fix.

Why do sync bugs happen

When developing Warcraft I had designed a solution to minimize the amount of data that needed to be transmitted over the network by only sending the commands that each player initiated, like “select unit 5″, “move to 650, 1224″, and “attack unit 53″. Many programmers have independently designed this same system; it’s an obvious solution to the problem of trying to synchronize two computers without sending the entire game state between them every single game turn.

Aside: These days there are probably several patents retroactively trying to claim credit for this approach. Over time I’ve come to believe that software should not be patentable; most any idea in software is something that a moderately experienced programmer could invent, and the definition of patents requires that patents be non-obvious. Nuff said.

I hadn’t yet implemented a mechanism to verify synchronization between the two computers, so any bug in the game code that caused those computers to make different choices would cause the game to “bifurcate” – that is, split it into two loosely-coupled universes that would continue to communicate but diverge with increasing rapidity over time.

Creating systems designed to detect de-synchronization issues was clearly the next task on my long list of things to do to ship the game!

In for the long haul

You know the ending to this story: Warcraft eventually shipped only five months later. It seemed an eternity because we worked so many hours each day, encountered so many obstacles, overcame so many challenges, and created something we cared for so passionately. I’ll continue to explore those remaining months in future blog articles, but so much was packed into that time that it’s impossible to squeeze those recollections into this already too long post!(source:codeofhonor)


上一篇:

下一篇: