我曾就职的初创公司当时名为Silicon & Synapse，之后更名为暴雪，以对应我们暴风雨般猛烈的开发方法——在闲暇时间玩大量游戏，《魔兽争霸》的灵感正是发源于这种活动。
我们玩过（反复重玩）一款名为《Dune 2》（Westwood Studios）的游戏后受到启发而创造了《魔兽争霸》。《Dune 2》是首款现代意义上的即时战略游戏（RTS），拥有横向卷轴 世界地图，即时单位建设和移动，以及独立单位战斗等元素。除了一些比例和图像质量之外，它在设计上与《星际争霸2》等现代即时战略游戏并没有很大区别。
其前作《Dune 1》也采用了一些相同元素，但其半即时单位战争元素则隐藏在了冒险游戏中。《Dune 2》除去了前作中让玩家作为游戏角色之一参与其中的理念，其关注重点是现 代RTS机制：收割庄稼，收集更多资源，建设军队，最后找到并征服敌人。
作为项目唯一的开发者，在初始阶段没有美术团队，我就先截取《Dune 2》的美术资产来用，直到项目进展不得不需要一两名美术人员时。这些美术人员可以一起赶其他临近截止 日期的项目，此时不可以分心，我们一直是时间紧迫。
我最为骄傲的一个功能就是单位选择。与只允许用户一次仅选择一个单位的《Dune 2》不同，我设计的这项功能允许用户一次选择一大遍的战斗单位，很显然这种功能要以加速玩 家的任务调度，极大提升游戏战斗力。
在之后的开发过程中，我们根据团队成员的许多设计主张，决定允许玩家一次只选择4个单位，因为用户需要关注自己的战略部署，而不只是集结一帮人将其全部发往一场混战。我 们在之后的《魔兽争霸2》中将此数目增加到了9个。继承了《Dune 2》的《命令与征服》并没有单位选择数量的上限。但这是另一个题外话了。
除了一次可以控制多个单位之外，这个阶段的《魔兽争霸》完全不像是降级版的《Dune 2》，我甚至开玩笑说，虽然这款游戏脱胎于《Dune 2》，但实际上与其完全不同——我们 的雷达迷你地图位于屏幕左上角，而后者则处于右下角。
在1994年初，我在为该项目获得更多支持方面取得了进展。Ron Millar、Sam Didier、Stu Rose、Bob Fitch、Jesse McReynolds、Mike Morhaime、Mickey Nielsen等人也入伙了 。他们当中多数人是在我们公司在1994年2月被Davidson & Associates收购时参与到这款游戏中。
Ron Millar这位金发壮汉很显然是维京战士的后裔。他最初曾在Virgin Games为Gameboy作品制作美术内容，但杰出的创意和设计感令他在暴雪多个项目中担任设计师，在《魔兽争 霸》中他也担任同样职位。
Sam Didier是一个矮壮的角色，好像是一只缩小成人类比例的熊，其英雄主义的个性和史诗般的绘画作品奠定了暴雪游戏的美术风格，曾经为16位主机游戏绘制美术资产，在会议 期间和其他闲暇时间都可以露几手绘画才能，并因此负责这款游戏的美术设计方向。
Stu Rose原先是插画师，暴雪运用至今的logo就是出自其手——他最初负责绘制游戏的背景贴图美术，但在游戏最终设计时扮演了更重要的角色。Stu十分还是个令人难忘的配音演 员，他的喜剧天份令其成功演绎了受尽压迫和苦役的“人类农民”。
Bob Fitch原先是程序员，在我开始展开《魔兽争霸》时他还是另一款游戏的项目主管。Allen Adham是暴雪总裁，曾向Bob分配了开发一款文字游戏“Games People Play”（包含 填字谜、scramble、bloggle等多项元素）的任务，但Bob对该项目缺乏热情导致数月毫无进展，看到《魔兽争霸》的情况之后，Bob就过来协助我，他对这款游戏的热情推动了这款 游戏的快速进展。
Jesse是加利福尼亚理工学院毕业生，原先是为IPX网络协议创建网络驱动程序，以便游戏能够运行于本地局域网（LAN）。Mike Morhaime是暴雪两名创始人之一，之后接手了更困 难的任务，即编写“混合模式”的调制解调器驱动器。虽然《魔兽争霸》是一款DOS“保护模式”游戏，调制解调器驱动器通常来源于保护模式和实时模式，原因是DOS操作系统及 其运行的80386芯片构造的变化无常，所以我们经常可以发现他坐在办公室盯着满屏诊断数据，因为他得解决与重新进入代码的复杂时间问题。最后的调制解调器代码稳若盘石，很 大程度上要归功于我们当时使用的原始工具组。
Allen Adham希望获得《战锤》的授权，以便通过品牌辨识度而增加游戏销量。《战锤》是《魔兽争霸》美术风格的一个巨大灵感来源，但结合了多项元素，包括开发团队中几乎每 个人都缺乏商业概念，以及捍卫自己的游戏世界的空前热情。我们已经受够了与DC Comics合作开发“Death and Return of Superman”以及“Justice League Task Force”的糟 糕经历，希望自己的新游戏不要重蹈覆辙。
Bob Fitch是项目的第二个程序员，我和他经常复制文件和反复更改代码。我们间歇性地出现一些整合错误，我们修复的漏洞也会再次出现。我们在复制文件时追踪并发现了这一点 ——我们偶然重写了漏洞修复，我们就不得不加快之前是如何修复漏洞的。
EMS解决方案实际上并不管用，实际上还有更好的方法。有家名为Watcom的公司推出了C编译器，其中包含一种允许程序以“保护模式”编写，可以访问线性32位内存的DOS模式“扩 充器”，这是今天的程序员32位（甚至是64位应用）都会用到的工具。虽然它需要两天时间来更新源代码，但DOS模式扩充器真是完美，当我们重返正轨时，就可以获得更多可用内 存了。
在本系列的下一篇文章中，我将分享Stu Rose以及设计绝招，《魔兽争霸》首个多人游戏，几乎扼杀多人模式的漏洞，Bill Roper如何令游戏适用于软盘，Westwood Studio对我们 这款游戏的反应，以及我所能回忆起来的关于这款游戏18年前的开发团队成员的其他趣事等内容。
当我启动《魔兽争霸》项目时，暴雪手头上至少还有四款游戏在做，而当时只有20名员工，大都都忙着赶进度。对美工、程序员和设计师来说，同时做两三个项目算是家常便饭了 ，当然，我们唯一的音乐师/音效师Glenn Stafford什么项目都要参与。
这个刺激源是公司联合创始人兼总裁Allen Adham在我们的头脑风暴活动中萌生的一个想法。他想制作一系列战争电脑游戏，全部放在几乎完全相同的白盒子里出售，大标题就叫“ Warcraft”，至于各款游戏的副标题，就取材于历史事件：罗马帝国、越南战争，等等。
为什么要装在相同的白盒子里？这是因为许多个白盒子堆在货架上会非常抢眼，让玩家在拥挤的零售环境中一眼就看到我们的游戏；类似于SSI的《龙与地下城》的金盒子系列，那 款游戏在80年代大获成功。新玩家会被抢眼的盒子而被吸引到货架前，而喜欢游戏的老玩家也很容易知道在哪里找到它。零售商店：与现在的应用商店和Amazon网上商城相比，真 是老古董了，是吧？！
Ron Millar和Sam Didier是公司的元老级美工，二人对历史模拟的想法非常有兴趣，且都喜欢幻想游戏如《战锤》和《龙与地下城》。看一眼Sam的美术作品就知道他非常迷恋幻想 题材。所以会议快结束时，他们提议，这个系列的第一款游戏应该发生在兽人和人类共存的幻想世界里，他们有更多机会创作新的游戏美术，而不需要遵循历史的传统。于是，二 人的提议被采纳了，成为该系列的第一款游戏：《魔兽争霸：人类与兽人》。
Stu Rose是暴雪的另一名元老级美工。个人认为，他在大部分方面与Ron持相反的观点，他作为设计团队中的一员，经常与Ron意见不合，尽管他们都同意对方的观点是不可反驳的 。
后来，几乎无法判定谁开发了哪个部分，除非让整个团队投票和分析许久以前发生的争论。甚至在那之后，我们也很难确定游戏设计的荣誉应该归功于谁，最终做了最公平的决定 ，最高荣誉归于集体。所以，《魔兽争霸：人类与兽人》的盒子上写的是“游戏设计：暴雪娱乐”。顺便一提，说Moby Games网站上列出的《魔兽争霸1》制作职员表完全是胡扯， 因为他们把Macintosh和1998年版的和1994年的DOS版的混淆了，所以很多人的工作都搞错了。
虽然我自己的记忆也很模糊了，我最近看了一份标着“Chaos Studios”的、日期为1994年的初期设计文件，这意味着它诞生于1994年初，那时现在的暴雪还没改名为“暴雪”。到 1994年2月，我们有了一系列（仍然非常粗糙的）设计文件已经经过若干次迭代，包含了这款游戏的关键概念。
我想你们可能很好奇有什么想法胎死腹中了，比如Mason’s Hall（需要石料）、Dwarven Inn（更需要石料）、Elven Fletcher（升级弓箭手）、Tax House和Ale House。
这些建筑的作用都是次要的，有些可以在其他地方实现。所以，我们把它们的功能添加到已有的建筑中，而不是为一个功能创造专用的建筑，例如，把Dwarven Inn和Elven Fletcher合二为一。
我们放弃Mason’s Hall是因为我们认为使用石料作为第三种资源（除了金矿和木材）太复杂了。我们在《魔兽争霸2》中修改了这个想法，但在实际执行（编程）时又再次放弃它 了。
Ale Stand的目的是增加战士与黄金的生产比率。我不知道通宵加班加点设计的东西怎么会被放弃，但我想一定因为艾泽拉斯大陆存在特殊的法则和魔力，所以我们删除了Ale Stand。
有些复杂度导致无法执行：队形单位都以同样的速度前进，这样走得慢的单位就不会被落下——这就导致编程上的复杂。队形必须能够转向，这样包含走在后面的矛兵和射手的队 形在朝南前进时，如果遇到从东边过来的敌人，才能与之面对面，且射手仍然在矛兵组成的防护墙后面——这就导致UI上的复杂。考虑到完成这个功能所需的时间太长，我们还是 把时间放在完成更多基本的功能上。
把单位从一个任务带到下一个任务，增加了玩法平衡的任务的复杂度。优秀的玩家会让自己的角色在任务中变得更强大，而随着玩家角色力量的增强，任务会越来越容易完成。相 反地，那些水平不高的玩家的角色越来越弱，以至于无法完成后面的任务。这两个问题都可能导致玩家流失——前者是因为游戏缺乏挑战性，后者是因为受挫，毕竟鲜有玩家会为 了游戏后面的任务而返回去重做之前的任务。
我们的竞争者的产品叫作《War Wind》，比《魔兽争霸》晚发布了几年，它允许玩家把单位从一个任务带到下一个任务；这款游戏的设计师允许玩家运送四个单位，但通过保证这 些单位足够强大以影响玩法，解决了玩法平衡问题。
我们还考虑在《魔兽争霸1》中加入英雄单位，他们有自己的名字如Illusion Thief、Barbarian、Huntress和Juggernaut等，有专属技能。最终，我们大大削减了游戏单位列表， 可能是因为设计和动画的时间受限。
这样的差异部分归因于美工们过去的经验，他们做过几款Super Nintendo和Sega Genesis游戏的游戏，那些游戏要求更明快的色调，因为当时的电视显示器在色彩显示方面落后于 PC显示器。在电视上显示的游戏机游戏分辨率更低，色彩经常溢出，只有对比度高的图像才能显示得好看。
好几个月，我是这个项目唯一的全职员工，这大大拖延了开发进度。好在有其他员工帮助我，Ron Millar、Stu Rose等人也参与了项目的设计。几位美工在自己的项目间歇时也抽 时间贡献了一些原画。
那时，我们还在开发16位的主机游戏《The Lost Vikings 2》（游戏邦注：这是一款横版“跑跳”益智游戏，但这个续作叫好不叫座）、《黑色荆棘》（横版“跑跳”游戏，主角 拿枪当武器）、《正义联盟》（《街头霸王》的翻版，以DC漫画世界为背景）和《超人归来》（横版格斗游戏，是DC漫画世界系列的同名游戏）。
使用这个策略的最佳案例大约就是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被它收购了。
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制作的第一款原创游戏，就是这种疯狂制作过程的最佳（有时候是最糟）示范，最终这款游戏成为（至少在当时）经典。
美工Ron Millar为早期的暴雪游戏做了大量构思和设计，他提议，玩家应该建造生产性建筑—-就像《上帝也疯狂》那样，这些建筑会周期性地刷出基本的工人单位，也就是所谓的 （人类）农民和（兽人）奴隶。玩家可以使用这些单位从事采金、伐木和建造，但这些单位无法像战士一样作战。
在我们开始编写代码时，Ron就陪公司总裁Allen Adham一起去参加展销会了（可能是消费类电子产品展销会）。在他们离开期间，发生了一件事，使整个《魔兽争霸》系列的方向 改变了。我把那个事件称作“魔兽设计政变”。
Stu Rose是美工/设计师，是公司的另一位元老（我想是第6号员工）。一天下午他来我办公室，提议了另一条思路。Stu认为Ron所提议的单位生产机制有太多还没解决的执行难题 ，并且与我们在RTS游戏中应该给予玩家的那种控制权不相符。
在这种新RTS类型中，对玩家的要求比其他类型的游戏更高，且玩家的注意力不能长时间只放在一个地方，因为有许多互相冲突的要求：计划建造/升级树、促进经济活动、生产单 位、布置建筑、探索地图、监督作战和微调单个单位珠技能。在RTS中，最有限的资源就是玩家的注意思，用间接单位生成机制会增加认知负担，进而导致注意力失调和游戏难度上 升。
Stu主张我们应该采用上述方法，与其再争论下去，不如现在就做好， 所以在那之后的几天几夜，我匆匆做出执行单位生产所必需的游戏和UI代码。于是，这个设计决定就成为既 定事实了。等到Ron和Allen回来，游戏已经可以在单人模式下玩了，除了敌人电脑AI仍然差好几个月才能完成。
加州理工大学的毕业生Jesse McReynolds已经完成在本地网络中发送IPX包的低级网络库。这些代码是根据《毁灭战士》的源代码（是id software公司的John Carmack公开的）在 编写的。虽然IPX中间层只是几百条C代码语句，但它是连接网卡驱动的代码的一部分，而网卡驱动保证在一个游戏客户端生成的信息被发送到另一个客户端。
Bob Fitch是加州州立大学的硕士，他开发了让玩家能够创建和加入多人游戏的最初的“glue screen”用户界面屏幕。我的办公室就在Bob旁边，非常方便，因为我们要密切合作， 把他的游戏加入或创建逻辑整合到我的游戏事件循环中。
由“D程序语言之父”Walter Bright于约17年以前编写的多人回合制策略游戏《帝国》，也是出于相同的目的而使用了战争迷雾。一旦地图上的区域“被发现”（已探索），之后 就一直保持可见状态，所以，在早期发现足够大的地图区域以提前获知敌人军队活动的警告，是一个重要的考虑；如果不能及时发现敌军来袭，重要的生产单位或经济命脉就会被 敌人破坏。
有趣的是，随着《星际争霸》的持续流行（自发布起超过14年)。一群程序员决定制作一种非作弊的AI。借助名为“BWAPI”的库，这些程序员写出了可以将指令直接注入《星际争 霸》引擎的代码。程序员让他们的AI们互相对抗，看看哪个AI会胜出。虽然这些BWAPI AI玩家很不错，但获胜的那个仍然会被有技术的人类玩家轻松打败。
作为在开发《魔兽争霸》以前已经玩过许多许多策略游戏的人，我很清楚那个时代的电脑AI的缺陷。虽然我与许多电脑AI对抗过，偶尔失败，多数获胜，但我从来没有被AI吓倒过 ，甚至在玩Chris Crawford制作的《Eastern Front》时面临俄国的疯狂进攻时。我用朋友的Atari 800玩那款游戏，一直玩到存有游戏的磁带老得不能读取时。
程序员都知道，写出第一次就能通过的代码几乎是不可能的，所以游戏崩溃了没有什么好大惊小怪的。游戏的图像扭到屏幕上方，被DOS4GW的“崩溃页面”取代了——这是Windows 时代以前的玩家非常熟悉的。现在，我们有更复杂的Windows错误报告对话，玩家可以提交崩溃报告，玩家很少看到的可怕的“死机蓝屏”就非常类似于那时老玩家看到的死机屏幕 。
当两台电脑面对相同的问题却选择了不同的回答时，同步漏洞就产生了；那个差异会越来越大。就像在时间旅行电影《回到未来》：时间旅行者在过去做的小小的改变导致了完全 不同的未来；《魔兽争霸》的显示不同步问题也是这样产生的。在我的电脑上，我的人类射手看到兽人奴隶就攻击，而在你的电脑上，兽人却没有感应到攻击，仍然在砍它的树。 没有发现或改正这些不一致的机制，我们双方的游戏状态很快就会完全不同。
所以说，《魔兽争霸》的第一场比赛是平局，但同时，它又是游戏开发团队的伟大胜利。不久后，办公室里的其他团队的成员也开始玩多人模式，发现它就像“Blue Sky”——《 绝命毒师》里的主人公Walter White所研制的冰毒纯晶体脱氧麻黄碱：一旦玩过一次《魔兽争霸》的多人模式，就会觉得其他游戏都不好玩了。即使游戏还是经常出现漏洞，但我 们知道我们正在做一件大事。
在开发《魔兽争霸》时，我已经设计了一个最小化数据（必须在网络间传输的数据）量的解决方案——只发送各个玩家发起的指令，像“选择单位5”、“移动 到650，1224”和“ 进攻单位53”等。许多程序员都已经独立设计了这个相同的系统；它显然是一个在不发送回合间的整个游戏状态而解决同步电脑问题的方法。
The making of Warcraft part 1
July 25, 2012 by Patrick Wyatt
Back before the dawn of time, which is to say when PC games were written for the DOS operating system, I got to work on a game called Warcraft.
I get to lead a project!
While I had developed several PC games, a couple of Mac games, and seven console titles for the Super Nintendo and Sega Genesis, I was either in a junior role on those projects, or the projects were game “ports” rather than original development work. A game “port” is the process of moving a game from one platform, like the Amiga, and converting the code, design, artwork and other game assets to make them work on another, like the Nintendo.
My role encompassed two jobs: leading the development team as Producer — a game industry term for project manager, designer, evangelist, and cat herder — and writing the majority of the game code as Lead Programmer. This was perhaps less daunting then, when a game project might employ ten or twenty developers, than it is now, with development teams tipping the scales at two-hundred or more developers.
The source of Warcraft
The developers at the startup company I worked for — then named Silicon & Synapse but later renamed Blizzard in a nod towards our tempestuous development methodology — played a great many games during our free time. And from that game-playing came the spark to create Warcraft.
We were inspired to create Warcraft after playing (and replaying and replaying) a game called Dune 2, by Westwood Studios. Dune 2 was arguably the first modern real-time strategy (RTS) game; with a scrolling world map, real-time unit construction and movement, and individual unit combat. It isn’t that much different in design than a modern RTS like Starcraft 2, excepting perhaps a certain scale and graphics quality.
Its predecessor, Dune 1 — a very worthy game itself — shared some of the same elements, but its semi-real-time unit combat was wrapped inside an adventure game. Dune 2 stripped its predecessors’ idea of the player representing a character inside the game-world and focused exclusively on the modern RTS mechanics: harvesting resources, building a base, harvesting more resources, building an army, and finally, finding and conquering the enemy.
Along with the other folks at Blizzard I exhaustively played Dune 2 during lunch breaks and after work, playing each of the three competing races to determine their strengths and weaknesses; and afterward comparing play-styles, strategies and tactics with others in the office.
While the game was great fun, it suffered from several obvious defects that called out (nay, screamed) to be fixed. Most notably, the only way that my friends and I could play the game was against the computer. It was obvious that this gaming style would be ideal as a multiplayer game. Unlike turn-based games, where each player must wait for all pponents to issue unit movement orders, a real-time game would enable all players to give orders simultaneously,
placing a premium on rapid, decisive tactical movements over long, drawn-out strategic planning.
And with that singular goal in mind, development of the game began without any serious effort to plan the game design, evaluate the technical requirements, build the schedule, or budget for the required staff. Not even on a napkin. Back at Blizzard we called this the “business plan du jour”, which was or standard operating methodology.
As the sole developer on the project, and lacking an art team during the initial phase, I screen-captured the artwork of Dune 2 to use until such time as my forward progress warranted an artist or two. The artists were tied up working on any number of other pressing deadlines and didn’t need distractions at this point — we were always pressed for time.
My early programming efforts developing the game engine included creating a tile-based scrolling map renderer, a sprite renderer to draw game units and other bitmaps, a sprite-sequencing engine to animate game units, an event-dispatcher to post mouse and keyboard events, a game-dispatcher to control unit-behavior, and a great deal of user-interface code to control application behavior. With this subset of the project completed in the first few weeks it became possible
to “play” a solo game, though I didn’t implement unit-construction until sometime later; early play required using typed commands to spawn units on screen.
Each day I’d build upon the previous efforts in organic fashion. Without schedule milestones or an external driver for the project, I was in the enviable position of choosing which features to build next, which made me incredibly motivated. I already enjoyed game development, and getting to do this green-field programming was like a drug. Even now, some 22 years after getting into the game industry, I still love the creative aspects of programming.
The first unique feature: multi-unit selection
One feature of which I was particularly proud was unit-selection. Unlike Dune 2, which only allowed the user to select a single unit at a time, and which necessitated frenzied mouse-clicking to initiate joint-unit tactical combat, it was obvious that enabling players to select more than one unit would speed task-force deployment and dramatically improve game combat.
Before I started in the game industry I had worked extensively with several low-end “Computer Assisted Design” (CAD) programs like MacDraw and MacDraft to design wine-cellars for my dad’s wine cellar business, so it seemed natural to use the “click & drag” rectangle-selection metaphor to round up a group of units to command.
I believe that Warcraft was the first game to use this user-interface metaphor. When I first implemented the feature it was possible to select and control large numbers of units at a time; there was no upper limit on the number of units that could be selected.
While selecting and controlling one hundred units at a time demonstrated terrible weaknesses in the simple path-finding algorithm I had implemented, after I got the basic algorithms working I nevertheless spent hours selecting units and dispatching game units to destinations around the map instead of writing more code; it was the coolest feature I had ever created in my programming career up to that time!
Later in the development process, and after many design arguments between team-members, we decided to allow players to select only four units at a time based on the idea that users would be required to pay attention to their tactical deployments rather than simply gathering a mob and sending them into the fray all at once. We later increased this number to nine in Warcraft II. Command and Conquer, the spiritual successor to Dune 2, didn’t have any upper bound on the number of units that could be selected. It’s worth another article to talk about the design ramifications, for sure.
Apart from the ability to control multiple units at one time, at this phase Warcraft resembled nothing so much as a stripped-down version of Dune 2, so much so that I defensively joked that, while Warcraft was certainly inspired by Dune 2, the game was radically different — our radar minimap was in the upper- left corner of the screen, whereas theirs was in the lower-right corner.
The formation of the fellowship
By early 1994, I had made enough progress to warrant additional help on the project. I was joined by Ron Millar, Sam Didier, Stu Rose, Bob Fitch, Jesse McReynolds, Mike Morhaime, Mickey Nielsen, and others. Many of these folks started work on the game after our company was acquired by Davidson & Associates in February 1994.
Ron Millar, who, with his long blond hair and strong build, was obviously the progeny of Viking warriors. He was originally hired on as an artist based on his skill in creating artwork for Gameboy titles at Virgin Games, but his amazing creativity and design sensibilities led to his taking on a design role in many Blizzard projects, and he stepped into a similar role for Warcraft.
Sam Didier, a strong, stocky and stalwart character who resembled nothing so much as a bear scaled down to human proportions, and whose heroic characters and epic drawings are now the definitive art style for Blizzard games, had honed his computer drawing skills on sixteen-bit console titles, but his penchant for drawing fantasy artwork during meetings and at any other spare moment demonstrated his capability to lead the art direction for this new title.
Stu Rose — whose background as an illustrator led to his design of the Blizzard logo still used today — initially contributed to the background tile-map artwork, but he would later take on a critical role in the ultimate design of Warcraft. Stu is quite memorable as a voice actor in the role of Human Peon Peasant, where his rendition of a downtrodden brute-laborer was comedic genius.
Bob Fitch had started work as a programmer and project lead on another title at the same time I started development of Warcraft. Allen Adham, the president of Blizzard, had assigned Bob the task of building a word game called “Games People Play” that would include crossword, scramble, boggle, and other similar diversions. Bob’s notable lack of enthusiasm for the project resulted in his making little progress on the title for many months; with Warcraft showing well
Bob was released to assist me, and his enthusiasm for the game helped move the project forward more rapidly.Jesse, a Caltech graduate, started work on building a network driver for the IPX network protocol so the game could be played on a Local Area Network (LAN).
Mike Morhaime, one of the two co-founders of Blizzard, later took on the significantly more difficult task of writing a “mixed-mode” modem driver. While Warcraft was a DOS “Protected Mode” game, the modem driver could be called from both Protected Mode and Real Mode due to quirks in the DOS operating system and the 80386 chip-architecture it ran on, so he could regularly be found in his office staring at screens full of diagnostic numbers as he worked through the complicated timing issues related to re-entrant code. At the end of the day, the modem code was rock-solid, quite an achievement given the primitive toolset we had at the time.
Allen Adham hoped to obtain a license to the Warhammer universe to try to increase sales by brand recognition. Warhammer was a huge inspiration for the art- style of Warcraft, but a combination of factors, including a lack of traction on business terms and a fervent desire on the part of virtually everyone else on the development team (myself included) to control our own universe nixed any potential for a deal. We had already had terrible experiences working with DC
Comics on “Death and Return of Superman” and “Justice League Task Force”, and wanted no similar issues for our new game.
It’s surprising now to think what might have happened had Blizzard not controlled the intellectual property rights for the Warcraft universe — it’s highly unlikely Blizzard would be such a dominant player in the game industry today.
Years after the launch of Warcraft my dad, upon returning from a trip to Asia, gave me a present of a set of Warhammer miniatures in the form of a skeleton charioteer and horses with the comment:
“I found these cool toys on my trip and they reminded me a lot of your game; you might want to have your legal department contact them because I think they ’re ripping you off.” Hmmm!
Blockers to game development
One interesting facet of the early development process was that, while I was building a game that would be playable using modems or a local area network, the company had no office LAN. Because we developed console titles, which would easily fit on a floppy disk, it wasn’t something that was necessary, though it would certainly have simplified making backups.
So when I started collaborating with other artists and programmers, we used the “sneaker network”, carrying floppy disks back and forth between offices to integrate source code revisions and artwork.
Bob Fitch was the second programmer on the project, and he and I would regularly copy files and code-changes back and forth. Periodically we’d make integration mistakes and a bug we fixed would re-appear. We’d track it down and discover that — during file-copying while integrating changes — we had accidentally overwritten the bug fix, and we’d have to remember how we had fixed it previously.
This happened more than a few times because of the rapidity with which we developed code and our lack of any processes to handle code-integration other than “remembering” which files we had worked on. I was somewhat luckier in this regard in that my computer was the “master” system upon which we performed all the integrations, so my changes were less likely to get lost. These days we use source-control to avoid such stupidities, but back then we didn’t even know what it was!
With more programmers, designers and artists working on the title progress increased substantially, but we also discovered a big blocker to our progress. The game was initially developed in DOS “Real Mode”, which meant that only 640K of memory was available, less about 120K for the operating system. Can you believe how crap computers were back then!?!
As the art team started creating game units, backgrounds and user-interface artwork, we rapidly burned through all of the memory and started looking for alternatives. A first attempt at a solution was to use EMS “paged memory” mapping and store art resources “above” the 640K memory barrier.
Stories programmers tell about EMS memory are like those that old folks tell about walking uphill to school, barefoot, in the snow, both ways, except that EMS stories are even more horrible, and actually true.
In any event the EMS solution quite fortunately didn’t work; it turned out there was a better solution. A company called Watcom released a C compiler which included a DOS-mode “extender” that allowed programs to be written in “Protected Mode” with access to linear 32-bit memory, something every programmer takes for granted today when they write 32-bit (or even 64-bit applications).
While it required a couple of days to update the source code, the DOS-mode extender worked perfectly, and we were back in business, now with access to substantially more memory.
Not the conclusion
In the next article in this series I’ll talk about Stu Rose and the design coup, the first multiplayer game of Warcraft, the bug that nearly killed multiplayer, how Bill Roper made Warcraft awesome, fitting the game onto floppy disks, the Westwood Studio reaction to our game, and other gems I can dredge up from a game that I and the other members of the development team worked on eighteen (!) years ago.
In my previous article about Warcraft I talked about the beginnings of a series that would come to define Blizzard Entertainment and lead it to being one of the best-known and most-loved game companies in the world.
But how did Warcraft go from an idea to a full-fledged game? Let me tell you, it was not a straight-line path from conception to launch. As with many games the design evolved over time, with ideas being argued, tested, argued, changed, argued, retested and some eventually killed.
You probably gathered that there was a lot of arguing along the way, but that’s not always a bad thing. While sometimes they devolved into ad hominem attacks, hard feelings and apologies, the debates ensured that ideas were likely to be well forged.
And even through the disagreements, there was a sense of camaraderie that pervaded our efforts. We worked together, played together, partied together, slept 10 to a hotel room for trade shows together, and in cases even lived together: I shared a house with three other Blizzard-folks which was the first of many similar dorm rooms scattered throughout Orange County, California.
Blizzard was working on at least four other games when I started on the Warcraft project, and as the company numbered only 20 everyone was mega-busy keeping those projects on track. It wasn’t uncommon for artists, programmers and designers to be working on two or sometimes three projects at a time, and of course our sole musician/sound-engineer, Glenn Stafford, worked on everything.
But we regularly found time to meet in large groups to brainstorm and discuss company strategy, so much that we called our efforts the “business plan du jour“.
I already discussed our motivation to create a Real Time Strategy (RTS) game modeled after Dune II in a previous article, but one other key idea propelled us forward.The other impetus for the game started with a proposal that Allen Adham — president and company co-founder — made during one of our brainstorming sessions. He wanted to build a series of war games that would be released in near identical white boxes under the banner “Warcraft”, with subheadings announcing the historical context for each game: The Roman Empire, The Vietnam War, and so forth.
The goal with the identical boxes was to control a large section of shelf-space that would be easy for players to spot in a crowded retail environment, similar to the Gold Box series of Dungeons & Dragons games from SSI, which enjoyed great success during the late 1980′s. New players would be drawn to the section of games by its dominating shelf-presence, and veteran players who enjoyed one game they would know where to find the next. I know; retail: so archaic compared to app stores and Amazon, right?!?
Ron Millar and Sam Didier, two of the early artists to work at the company, weren’t excited about the idea of working on historical simulations, they enjoyed fantasy games like Warhammer and Dungeons & Dragons. One glance at Sam’s artwork is enough to demonstrate his passion for the fantasy milieu. So at a later meeting they proposed the idea that the first game should be set in a high-fantasy world of Orcs and humans, where they’d have more opportunity to create innovative game artwork instead of being required to conform to the tenets of historical accuracy. The idea took hold, with the first game in the series becoming Warcraft: Orcs and Humans.
Initial game design
Many people believe that a game designer is solely responsible for all idea conception and actually “creates the game design”, and this may be true for some development teams. Designers do need to be highly creative and bring to life many of the elements of the game personally.
But equally important is for designers to be receptive to the ideas of others: without some involvement in the game’s design the rest of the team has less motivation to do their best work. And beyond that, it’s never possible to know where the next great design idea is going to come from. It’s critical for designers to listen so that the best ideas of others aren’t stifled.
Our informal design process during the early period of Warcraft’s development worked effectively in that regard. Many brainstorming sessions occurred during hallway meetings, lunches, smoke-breaks, and after late evenings of game playing. Everyone in the company contributed their thoughts. With little formal process and no single design document, the game design evolved with each passing month.
Ron, who had started his career in the game industry as an artist, was at that time our go-to guy for design on Blizzard games. Though he was finishing up the development of Blackthorne, a side-scrolling shooter for Super Nintendo, he devoted time to generating ideas for the game.
Stu Rose was another artist who became one of Blizzard’s early staffers. From a personality standpoint he was the polar opposite of Ron in most respects, and his efforts as part of the design group occasioned conflicts of opinion with Ron, though during the times they did agree they were an unassailable force.
These two ended up as the book-ends for the entire design process, each working independently to develop the world’s culture and plot overview, define the game’s units, specify the play mechanics, envision how magic spells worked, develop the game’s missions, choose place-names, and finalize other minutiae that are nevertheless important to make games comes to life.
At this late date it’s not possible to document who developed exactly which idea without canvassing the entire team and sorting out arguments over events that happened so long ago. Even back then we had difficulties determining how game-design credit should be shared, and ultimately decided the fairest, most egalitarian solution was to credit everyone, and thus the Warcraft: Orcs vs. Humans box credits include “Game design by Blizzard Entertainment”. Incidentally the Moby Games credits for Warcraft 1 are completely borked because they mix the much later Macintosh and 1998 releases of the game with the original 1994 DOS release, so many folks are mis-credited.
While my recollection of the exact timing of events is dim, I’ve recently seen an early design document dated 1994 and labeled “Chaos Studios”, which means it was generated in early 1994 before the company had been renamed Blizzard. By February 1994 we had a set of (still very rough) design documents that had been through several iterations and contained the key concepts for the game.
Admittedly, it would probably have been better to have a design in place before I started programming in September 1993, but with the amount of “substrate” that I needed to build before the actual fun-n-game parts could be developed, the lack of a design wasn’t a show-stopper at that stage, particularly since we already pulled many of the game’s elements from Dune 2.
What got chopped
While it’s still (barely) possible to play Warcraft 1 today, it’s not much fun compared to later RTS games. The difficulty of getting the game running on modern computers leads one to high expectations that are then crushed when viewing a game with a screen resolution of only 320×200 pixels — one twentieth of the resolution of a modern high res monitor — and with user interface and play balance that are markedly inferior to our later efforts.
But by playing Warcraft 1 it is possible to see the ideas that survived through the design winnowing process into the game’s final release. In many ways Warcraft 1 isn’t so much different from later games in the series.
Today gamers are familiar with classic Warcraft units like Barracks, Town Halls, Lumber Mills and Gold Mines, all of which survived into future releases of Warcraft games. Those iconic units persist because their names and functions are easily comprehensible to those of us who live in the real world instead of Azeroth.
But many of the ideas that our early design documents contained didn’t come to fruition. Some of this was related to the brutal timeline — the game had to launch for Christmas, 1994 and we barely made it. Ideas died because better alternatives existed, or didn’t have strong advocates, or were too time- consuming to implement, or would have required too much memory, or weren’t fun.
I thought folks might like to know about ideas that ended up on the cutting room floor, like the Mason’s Hall [required for stone buildings], Dwarven Inn [greater production of stone], Elven Fletcher [upgrades for archers], Tax House and Ale House.
These buildings all served secondary functions, some of which could be combined elsewhere. We instead added their functionality to existing buildings instead of creating buildings solely dedicated to one function, as for example the Dwarven Inn and Elven Fletcher buildings.
The Mason’s Hall was dropped because we considered using stone as a third resource (in addition to gold and lumber) an unnecessary complexity. We revisited the idea again for Warcraft 2, and dropped it again after actually implementing (programming) the idea.
The Ale Stand was designed to increase the rate at which soldiers and gold would be produced. I’m not sure how we can rectify that design idea with the amount of work that actually gets done after a night of heavy drinking in our world, but I imagine there are special rules of magic at work in Azeroth. Or maybe that’s why we cut the Ale Stand.
And NPC races like lizard men, hobgoblins and Halflings were also on the drawing board but were ultimately rejected, almost certainly due to the effort of drawing and animating the figures in DPaint.
Game development is about trade-offs — great games don’t have to do everything, they have to do a limited number of things well.
A design idea much discussed but never implemented was “formations”, where units would stick together on the battlefield. Formations are difficult to implement so the feature was chopped from the spec.
Some of the complexities that prevented implementation: units in formation all move at the same speed so slow units don’t get left behind — this created programming complexity. Formations need the ability to rotate — or “wheel” in military parlance — so that a formation heading north comprised of infantry carrying pikes with archers following behind can turn as a group to face an enemy detachment approaching from the east, with the archers still lined up
behind the protective wall of infantry — this created user interface complexity. Given enough time we could have completed the feature, but we needed the development time for more basic features.
As a stand-in, I did implement “numbered group selection”. A user would select a group of units and press the Ctrl (control) key plus a number key (1-4). Those unit-groupings would be remembered so it would be possible to later re-select those units by pressing the number key (1-4) by itself. But those units would move independently even though selected as a group.
A player-character on the battlefield
Another idea much discussed but never implemented was that of having a unit that represented the player on the game map: an avatar that would progress from mission to mission during the game.
For a game-avatar to represent the player, it should morph from a weak unit into a mighty hero over the course of several missions to create a sense of progression. To do this properly would require that the character would only become more powerful if utilized. An underutilized avatar would remain weak, while an avatar constantly at work on the front lines would become stronger.
Carrying a unit over from one mission to the next adds to the difficulty of play-balancing missions. A great player will graduate a strong avatar from each mission, and that avatar’s strength will make succeeding missions seem easy, while a less-skilled player’s avatar could be so weak as to make winning later missions impossible. These two problems would lead players to drop out of the game — in the first instance for lack of challenge, and in the second due to frustration, as few players want to go backwards and redo previous missions in order to survive a mission later in the game.
A competitor’s product named War Wind released several years after Warcraft allowed units to be carried over from mission to mission; the game’s designers allowed up to four units to be transferred, but finessed the play-balance problem by ensuring that these units weren’t powerful enough to affect gameplay, somewhat the antithesis of what a heroic player-avatar is supposed to represent.
Heroes — in Warcraft 1?!?
We also considered including hero-units in Warcraft 1; they had names like the Illusion Thief, Barbarian, Huntress, and Juggernaut, each with specialized skills. Ultimately we trimmed the list of game units substantially; probably due to design and art-animation time constraints.
As someone with limited involvement in Warcraft III, it was interesting to see the idea of heroes finally implemented in the series, though the design genesis of heroes in Warcraft III comes from a different source — that is, not from ideas re-hashed from Warcraft 1 design documents.
Briefly, Warcraft III started out as a game called Heroes of Warcraft, which departed from the type of traditional RTS we had already launched five times before (W1, W2:ToD, W2:BtDP, SC, SC:BW) and was instead a squad-based tactical combat game set in the Warcraft universe. This game morphed into a more traditional RTS — but retained the element of heroes — after a change of team-leads halfway through the development.
Warcraft’s bright color palette
If you consider the artwork of the Warcraft series, you’ll see that the colors are shockingly loud in comparison to, say, Diablo, where only in a dim room is it truly possible to see the beauty of the art. The bright, cartoony art-style was different from the style of many other PC war games of the era, which hewed to more realistic color palette.
Part of that difference can be explained by the past experiences of our artists, who had worked on several Super Nintendo and Sega Genesis console titles, where games required more dynamic colors since televisions of that era were so much worse at displaying colors than PC monitors. Console games on TVs, which had lower pixel resolution and color bleed, needed high-contrast artwork to show well.Another reason was at the behest of Allen, who charged all the artists with drawing artwork in bright conditions. He’d regularly stalk the halls of Blizzard turning on lights and opening window-blinds.
His view was that most folks play games in bright rooms, so our artists should be authoring our games to play well in that environment. He argued that it’s easy to draw artwork that reads well when viewed in a dark room with no outside light can distract from the monitor. But when computer art is competing with bright lights it’s much more difficult to see. And fluorescent bulbs are the worst form of light available — the cold, flickering glow of their tubes tires the eyes and washes out colors.
So the lights were always on in the art rooms to force artists to compensate for terrible lighting by creating art that accounted for those conditions. These working conditions chafed on some (all?) of the art team, but ultimately led to artwork that stood out compared to products of the day.
Now you know why Warcraft artwork looks like it has been candy-coated!
What about …
In the first article of this series I promised to address a bunch of topics in this article, but I’ve written another long post and didn’t quite make it to those points; I’ll continue to press forward in future articles. But give me a wee bit because I’ve become addicted to DayZ and need more play-time!
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 economicsFor 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 — eleasing 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 onsidered 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 uilding 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 WarcraftIn 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 rogrammers 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!
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, ositional 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 ompete, 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 rogrammers 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 crashedAs 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 hese 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
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!