科技: 人物 企业 技术 IT业 TMT
科普: 自然 科学 科幻 宇宙 科学家
通信: 历史 技术 手机 词典 3G馆
索引: 分类 推荐 专题 热点 排行榜
互联网: 广告 营销 政务 游戏 google
新媒体: 社交 博客 学者 人物 传播学
新思想: 网站 新书 新知 新词 思想家
图书馆: 文化 商业 管理 经济 期刊
网络文化: 社会 红人 黑客 治理 亚文化
创业百科: VC 词典 指南 案例 创业史
前沿科技: 清洁 绿色 纳米 生物 环保
知识产权: 盗版 共享 学人 法规 著作
用户名: 密码: 注册 忘记密码?
    创建新词条
科技百科
  • 人气指数: 5686 次
  • 编辑次数: 1 次 历史版本
  • 更新时间: 2013-01-20
土土
土土
发短消息
相关词条
Naughty Dog发展历程
Naughty Dog发展历程
《古墓丽影》系列发展史
《古墓丽影》系列发展史
《Drag Racing》发展历程
《Drag Racing》发展历程
魔兽世界60年代点点滴滴
魔兽世界60年代点点滴滴
《魔兽争霸》多人模式诞生过程
《魔兽争霸》多人模式诞生过程
《仙剑奇侠传》系列回顾
《仙剑奇侠传》系列回顾
口袋妖怪15年画面进化史
口袋妖怪15年画面进化史
魔兽争霸历史版本全回顾
魔兽争霸历史版本全回顾
《Pocket Planes》开发始末
《Pocket Planes》开发始末
街头霸王25周年收藏版
街头霸王25周年收藏版
推荐词条
希拉里二度竞选
希拉里二度竞选
《互联网百科系列》
《互联网百科系列》
《黑客百科》
《黑客百科》
《网络舆情百科》
《网络舆情百科》
《网络治理百科》
《网络治理百科》
《硅谷百科》
《硅谷百科》
2017年特斯拉
2017年特斯拉
MIT黑客全纪录
MIT黑客全纪录
桑达尔·皮查伊
桑达尔·皮查伊
阿里双十一成交额
阿里双十一成交额
最新词条

热门标签

微博侠 数字营销2011年度总结 政务微博元年 2011微博十大事件 美国十大创业孵化器 盘点美国导师型创业孵化器 盘点导师型创业孵化器 TechStars 智能电视大战前夜 竞争型国企 公益型国企 2011央视经济年度人物 Rhianna Pratchett 莱恩娜·普莱契 Zynga与Facebook关系 Zynga盈利危机 2010年手机社交游戏行业分析报告 游戏奖励 主流手机游戏公司运营表现 主流手机游戏公司运营对比数据 创建游戏原型 正反馈现象 易用性设计增强游戏体验 易用性设计 《The Sims Social》社交亮 心理生理学与游戏 Kixeye Storm8 Storm8公司 女性玩家营销策略 休闲游戏的创新性 游戏运营的数据分析 社交游戏分析学常见术语 游戏运营数据解析 iPad风行美国校园 iPad终结传统教科书 游戏平衡性 成长类型及情感元素 鸿蒙国际 云骗钱 2011年政务微博报告 《2011年政务微博报告》 方正产业图谱 方正改制考 通信企业属公益型国企 善用玩家作弊行为 手机游戏传播 每用户平均收入 ARPU值 ARPU 游戏授权三面观 游戏设计所运用的化学原理 iOS应用人性化界面设计原则 硬核游戏 硬核社交游戏 生物测量法研究玩家 全球移动用户 用户研究三部曲 Tagged转型故事 Tagged Instagram火爆的3大原因 全球第四大社交网络Badoo Badoo 2011年最迅猛的20大创业公司 病毒式传播功能支持的游戏设计 病毒式传播功能 美国社交游戏虚拟商品收益 Flipboard改变阅读 盘点10大最难iPhone游戏 移动应用设计7大主流趋势 成功的设计文件十个要点 游戏设计文件 应用内置付费功能 内置付费功能 IAP功能 IAP IAP模式 游戏易用性测试 生理心理游戏评估 游戏化游戏 全美社交游戏规模 美国社交游戏市场 全球平板电脑出货量 Facebook虚拟商品收益 Facebook全球广告营收 Facebook广告营收 失败游戏设计的数宗罪名 休闲游戏设计要点 玩游戏可提高认知能力 玩游戏与认知能力 全球游戏广告 独立开发者提高工作效率的100个要点 Facebook亚洲用户 免费游戏的10种创收模式 人类大脑可下载 2012年最值得期待的20位硅谷企业家 做空中概股的幕后黑手 做空中概股幕后黑手 苹果2013营收 Playfish社交游戏架构

《魔兽争霸》多人模式诞生过程 发表评论(0) 编辑词条

目录

《魔兽争霸》多人模式诞生过程编辑本段回目录

作者:Patrick Wyatt(ArenaNet联合创始人、前暴雪成员)

《魔兽争霸》的第一个多人模式获得了压倒性的成功,但同时也打了个平局,甚至是失败了。怎么可能?这当然是有多方面的原因的,包括游戏AI、经济困难、战争迷雾等等。如果你有时间,不妨继续阅读本文。

自1993年11月起,经过六个月的开发,《魔兽争霸:人类与兽人》,即后来的《魔兽争霸》系统的第一款产品,最终变成一款完整的游戏,而不是扩展技术的演示样本。

warcraft(from juegosabiertos)

warcraft(from juegosabiertos)

数个月以来,只有我一个人专门做这个项目的工作,所以开发进展很慢。幸运的是,Ron Millar和Stu Rose等同事抽空帮我完成了项目的设计工作。其他几位美工也在赶其他项目的空档时帮我绘制原型插图。

团队成员这么少,是因为开发《魔兽》是公司自己筹资的。公司支持项目的资金来自为Interplay和Sunsoft公司等开发游戏所获得的收益。公司自己的财力并不强。

那时我们正在开发4款16位的主机游戏:《失落的维京人2》(这款横版“跑跳”益智游戏的续作叫好不叫座)、《黑色荆棘》(也是一款横版“跑跳”游戏,主角拿着散弹枪到处射)、《正义联盟》(翻版《街头霸王》发生在DC漫画世界)和《超人:死里逢生》(根据DC出版社的同名漫画改编的横版格斗游戏)。

公司靠开发这些游戏和从事其他零碎工作,才有能力支付初期的开发费用。

warcraft header(from gamasutra)

warcraft header(from gamasutra)

游戏开发的经济之争

在游戏行业的历史上,有相当长一段时间,独立开发游戏的工作室并不归零售游戏的发行商所有,通常是与发行公司签约项目。发行商会“提前”支付项目的开发费用。除了资助开发,发行商还负责广告宣传、市场营销、零售推广、客户服务等工作。

回顾90年代,那时的发行公司比现在的要多。但随着游戏开发,特别是游戏发行的成本提高,大量发行公司因为破产和收购而与其他公司合并。今天,说到零售游戏发行公司,你可能只会想到动视暴雪、EA或育碧,而不是20年前无数的中小规模的公司。

无论是在什么行业,合约的条款总是对有钱的一方更有利。另一条黄金定律是:“有钱人说了算”。理论上,这些协议是合理的,所以当游戏卖得好时,游戏开发商也赚得多。在唱片和电影行业,发行商占据绝大部分的利润,而开发商得到的钱只够维持到签另一份合约——如果他们运气够好的话。

我刚才提到发行商的“提前”支付,其实更准确地说,应该是“提前支付版税”,也就是开发者先拿游戏的销售额抵压开发成本。这听起来不错:开发游戏,卖一份赚一份。但事实上,绝大多数的游戏赚不到足够的钱偿还(支付)开发费用。因为开发工作室通常必须放弃自己的游戏及其续作的版权,所以这些合约更像是项目雇用合同。

为了争取更有利的商业条款,开发工作室经常采用的策略是,自行筹资开发游戏原型,然后用原型“左右”发行商的合同条款。开发商自行筹资开发游戏的时间越长,最终的合同条款就对它越有利。

成功执行这个策略的典范大概是Valve Software。Gabe Newell拿自己为微软工作挣的钱开发《半条命》,所以在游戏的发行日程上获得很大的主导权——这款游戏的发行商Sierra Entertainment计划只要游戏达到季度收益目标就可以发行了,不管有多匆忙,但开发商坚持游戏的品质达到要求才能发行。更重要的是,Gabe的资金使Valve获得了《半条命》的在线推广权,适逢数字下载正在成为出售游戏的可行策略,所以最终促成该工作室的巨大成功。

自行筹资开发原型的弊端是,开发商要自己承担没有与发行商签约的项目的风险,这往往导致工作室的倒闭。

我供职的公司——当时名叫Silicon & Synapse,自行筹资开发《魔兽》和另一款叫作《游戏人间》的游戏,后者包含填字和拼字游戏的元素,在机场的书商里可以找到类似的游戏,滞留的旅客会拿它们打发时间。

通过开发这两款针对完全不同的受众的游戏,公司老板希望能够拓宽收效渠道,稳固经济实力,而不是拿公司的未来当硬核游戏市场的赌注。

当然,开发多种游戏类型也有风险,因为如果产品没有满足各类受众的喜好,公司的品牌形象就会受损。今天,暴雪品牌的一个大优势是,玩家闭着眼睛也会买它的产品,因为他们相信这家公司的实力和信誉。如果一家公司既发行低成本的休闲游戏,又开发高投入的AAA游戏,它是很难建立这样的行业威信的。就像Sierra Entertainment,多次挣扎着寻找受众,现在终于崩溃了。

无论如何,开发《游戏人间》是一个错误,因为开发休闲娱乐产品使公司的首席程序员很泄气,所以这个项目最终夭折了。或者,它也可能不是一个错误,因为《魔兽》和《游戏人间》的组合使Davidson & Associates公司看到了希望,当时它是世界上第二大教育软件公司,后来它收购了我们的公司Silicon & Synapse。

我们的新东家

Davidson & Associates是由Jan Davidson创立的公司,后来她的丈夫Bob也加入公司。这家公司从事多种教育软件开发,让它成功的游戏是《数字射击》。在这款游戏中,玩家正确回答数学问题后就可以爆破小行星,避免飞船撞毁。这款游戏巧妙地将教育与娱乐相结合,发行之后使公司获奖无数。

作为一款教育游戏,《数字射击》如果运用得当,可能有些价值,但我经常看到的却是玩家以非常愚蠢的方式玩它。我中学时,新闻班的同学会在计算机房给校报写文章,当时机房是与矫正教育班的同学合用的,我和新闻班的同学很惊恐地发现,12年级的矫正教育班同学居然用计算器玩《数字射击》!

当小行星出现“3+5”或“2*3”的算式时,这些学生会快速地将算式输入计算器,得到结果后再输入电脑,这样就摧毁那些小行星了。确实,他们是在学习——考虑到他们比上课的老师更聪明,但我不敢肯定这就是充分利用时间的最好方式,如果他们立即进入职场的话。

在良好的管理和上进的领导下,Davidson & Associates终于将业务扩展到游戏制造(制作和包装零售盒)、游戏经销(将盒子卖给零售商和经销商)和学校的学习教材经销。

他们看到进军娱乐产业的机遇,但早期从事娱乐游戏开发的经验使他们相信,与其让那些懂早期教育却不了解宝剑和魔法的员工开发游戏,不如收购一家有经验的游戏开发工作室。

所以,阻碍《魔兽》开发的难题因为公司被收购而一下子解决了。有了新东家的慷慨解囊,Silicon & Synapse(收购后更名为暴雪)终于能够专注于自己的游戏,不必迁就其他游戏发行商的最低营利条款。即使在被收购以前,他们就非常努力——在1993年就制作出两款最受欢迎的游戏,因此荣获“年度最佳任天堂游戏开发商”的称号,但没有得到任何版税。

收购得到的大量资金,和新员工的雇佣,使之前的员工能够将全部精力放在《魔兽》的开发上,因此项目的进展快了很多。

设计“过程”

暴雪早年设计和制作游戏的方法实在很难形容为“有组织的”。那是一个混乱的过程,正式的设计会议很少,往往是在走廊和餐桌上临时展开讨论。

在游戏中,有些特点出自设计文件,而有些是程序员一时兴起添加的。有些美术设计是计划、安排和执行过的,但有些则是美工半夜的突发奇想和心血来潮。有些元素是即兴设计的;《魔兽》的故事和传说直到发布前的最后几个月才编写出来。

开发过程虽然不可预料,但结果很惊人。因为我们的团队是由电脑游戏迷组成的,所以游戏在开发的过程中始终遵循他们想制作一款玩家想玩、再玩、不停玩的游戏的设想。《魔兽》,我们的第一款IBM PC原创游戏就是那个过程最好(有时候是最坏的)的证明,最终成为游戏的典范之作(至少在当时是这样)。

《魔兽争霸》的单位生成系统是如何设计出来的

正如生物学家所说的,进化过程有一个错误的开端,在那里,进化树将所有分枝都抹掉了。我们的开发过程也是如此。因为我们没有一个衡量的标准,所以我们只能不断做实验,再剔除不可行的东西。我得说,这是一个慎重的、有意识的过程,但在许多情况下,是由于意外、争论和个性冲突导致的。

我记得有一件事,就是开发游戏单位生成系统的时候。在开发早期,单位是通过输入到控制器的“欺骗”命令召唤出来的,因为当时没有其他用户界面可用。当我们考虑怎么生成单位时,大家的想法各不相同。

Ron Millar是一位做过不少设计,负责早期的暴雪游戏设计的美工。他建议,玩家可以建造农舍——就像在游戏《上帝也疯狂》中那样,这些农舍可以定期地刷出基本的生产单位,也就是(人类)农奴和(兽人)奴隶。玩家可以用这些单位采金、伐木和建造,但他们的战斗力不如战士。

玩家可以直接将那些没有被占用的“奴隶”放到军营中训练,在这个过程中,奴隶会暂时从在地图上消失,但之后会变成训练有术的战士。其他训练区域可以用来制造更先进的军事单位,如投石车和术士。

想法没有完全实现,这是我们的设计过程中的一个常见缺陷:设计过程的最终结果没有规范成执行文件。想法反复提出来,但往往没有得到充分考虑就被驳回了,这是不正规的设计团队(大部分公司)在开始执行(编写程序)前常犯的错误。

在我们开始编写代码以前,Ron陪公司总裁Allen Adham去参加交易展了。在他们离开期间,发生了一件事。这件事为整个《魔兽》系列确定了方向,我称它为“魔兽设计的政变”。

Stu Rose是另一位设计师/美工元老(我想是第六位加入公司的员工)。一天下午他走进我的办公室提出了另一种方案。Stu认为Ron提出的单位生成机制有太多没有解决的执行难题,并且违背了即时策略游戏(RTS)应该给予玩家控制权的原则。

在RTS游戏中,游戏对玩家的要求比其他类型的游戏要高,玩家要顾全大局,不能在一个方面投入过多关注而忽略了其他竞争要求:计划培养/升级技能、组织经济活动、生产单位、安置建筑物、探索地图、监督战斗情况和微观管理独立单位的技能。玩家的注意力是最有限的资源,所以间接的单位生成机制会增加玩家的认知压力,导致玩家无法分配注意力,进而提升游戏的难度。

为了生产“兽人步兵”这种基本的战斗单位,玩家必须给闲置的或者手头工作不重要的农奴进行军事训练(Stu的观点),这就增加了游戏的难度。

我认同他的提议,因为我也有相同的考虑(尽管没有那么周全),并且不觉得单位生成是必须大改特改的地方。《魔兽》的设计借鉴了《沙丘魔堡II》,后者的单位生成机制相当简单:只要按下用户界面上中的工厂面板上的一个按钮,过了一会儿单位就生产出来了。这种机制并不新鲜——是模仿了更早以前的游戏,但就是管用。

Stu认为我们应该采用这种方案,不要再争论了,就这么办。所以之后的几天几夜,我匆匆忙忙地写出执行单位生成的用户界面的代码。设计决定就这样生米煮成熟饭了。当Ron和Allen回来时,游戏已经能够在单人模式下玩了,可惜仍然需要好几个月才能开发出敌人/电脑AI。

此时,《魔兽》已经是一款真正的游戏了,并且操作很简单,更重要的是,很有趣。于是我们无怨无悔了。

《魔兽争霸》的第一个多人模式

1994年6月,也就是开发游戏的第10个月,多人模式的游戏引擎接近完工。在我整合第一个多人模式的代码时,我的兴致越来越高涨。在我忙着构建游戏的核心逻辑(游戏邦注:事件循环、单位分配、导航、战术单位AI、状态栏、游戏内用户界面、高级网络代码)的同时,其他程序员也在做其他与多人模式相关的组件。

加州理工大学的毕业生Jesse McReynolds已经完成将IPX数据包发送给本地网络的低级网络库的代码。这份代码借鉴了《雷神之锤》的源代码(由id software公司的John Carmack开启)。虽然IPX界面层只有几百条C语言代码,但它是接入网卡驱动的代码的组成部分,那些代码负责将一名玩家的游戏产生的信息发送给另一名玩家。

加州大学的硕士Bob Fitch开发了最初的“粘合界面”,玩家就是通过它产生并加入多人模式的。我的办公室就在Bob的旁边,这样真是方便,因为我们要密切合作,将他的游戏加入或生成逻辑整合到我的事件循环中。

将这些变化整合好这后,我又编辑了游戏客户端,再将它复制到网络驱动器中,而这时Bob就跑回他的办公室加入游戏。就在这个小小的奇迹中,我们写的代码成功了,我们终于可以玩上真正的第一个多人模式下的《魔兽争霸》了。

开始游戏时,我甚至觉得比玩任何游戏都更加激动兴奋。部分是因为知道这份代码有我的一份心血,但更多的是因为多人游戏的两个特点:对抗人类玩家而不是电脑AI,因为战争迷雾而不知道人类对手的行动。

战争迷雾

从早期的游戏中借鉴的一个创意是,让敌对玩家看不到己方的单位。也就是,用一块黑色的图形覆盖地图的隐藏区域上,除非自己或同盟玩家探索了该区域。这么设计的目的是,模似真实战役中己方无法得知敌方的计划和军队活动。

伟大的Walter Bright(“D”语言的创造者)于大约17年前编写了《帝国》,这是一款多人回合制策略游戏,也是出于相同的目的而使用了战争迷雾。一旦地图上的一片区域“被发现”,玩家就能看到这片区域的样子,所以玩家游戏时有一个关键的战略考虑,那就是尽快探索足够范围的地图,以便提早收到敌军的行动警报,这样才能避免让敌人抓住破坏重要建筑或经济活动的机会。

Warcraft-fog-of-war(from gamasutra)

Warcraft-fog-of-war(from gamasutra)

在历史上,有许多将领死于对敌人的无知导致的心理恐慌,将这种元素添加到RTS中,是增加玩家的兴奋感(和恐惧感)的好办法。在此要向Walter和参与制作《沙丘魔堡II》的Westwood公司的员工们致敬!

电脑AI

许多玩家都知道,在策略游戏中,电脑控制的“人工智能”(AI)玩家通常是很弱的。人类玩家往往能发现一些电脑AI保护不了的资源,然后利用这些资源毫不费力地就击败AI。所以为了给玩家一个实力相当的对手,电脑AI玩家通常具有军队人数大、地理位置好或“不对称法则”偏袒的优势。

在大部分《魔兽》的任务中,游戏一开始就给敌对电脑玩家完全的城市和军队。另外,《魔兽》包含几条不对称法则,使AI玩家更容易与人类玩家竞争,不过,大多数玩家可能会说这些法则是赤裸裸的欺骗。

我们帮助电脑AI的一条法则是,减少金矿被采集走的数量,以免AI玩家的金矿资源枯竭。当人类玩家的矿工采矿时,每次将100单位的矿运回玩家的城镇,矿就这样渐渐地采完了。而当AI控制的矿工采矿时,每次只能运走80单位的矿,但补充到AI国库中的矿却是100单位。

这条不对称法测其实使游戏更有趣了,这体现在两个方面:第一,防止人类玩家变成“龟”,也就是建成坚不可摧的防御工程,然后利用更高级的战术打败电脑AI。玩家必然会用“龟”术对抗电脑AI,因为他们的金矿资源的耗竭时间比电脑敌人的早了非常多。

第二,当人类玩家最终占领电脑对手的营地时,玩家仍然有一些金矿可采,这让游戏进行得更快更有趣。毕竟玩家也不希望好不容易占了一个地盘,资源却那么少。

此外,大多数玩家都意识到游戏对公平竞争精神更严重的破坏:电脑AI欺骗了玩家是因为它可以看穿战争迷雾;AI一直都很清楚玩家在做什么。事实上,这不是让电脑占了大便宜,只不过是防止电脑显得太愚蠢。

有趣的是,随着《星际争霸》的持久风行(自从发行已经超过14年了,并且仍然有很多玩家),有些AI程序员决定挑战更高级的AI——构建不欺骗的AI。在名为BWAPI的开源工具的帮助下,这些程序员编写了可以往《魔兽》引擎中直接输入指令的代码。程序员让自己的AI们互相竞争,决出赢家。虽然这些BWAPI AI玩家表现不错,但即使是当中最优秀的一个,也会被熟练的人类对手轻易打败。

对抗人类玩家

作为一个开发《魔兽》之前就已经玩过诸多策略游戏的玩家来说,我充分认识到电脑AI的局限性。虽然我与许多电脑AI游戏较量过——大多胜利,偶有失手,但我从来没有被AI的智商吓到。甚至当我用朋友的Atari 800游戏机玩Chris Crawford制作的《苏德战线》时,面对苏军的强大攻势,我也没有惊慌过。那款游戏我一直玩到存那款游戏的磁带不能读取为止。

这些有游戏是有趣的、令人兴奋的,基本上有挑战性的,但并不可怕。但是,当我玩第一款多人游戏《魔兽》时,我怕了。

知道我面对的是一个有能力的人类玩家——不止是在技巧和策略上,还有指挥的速度,而且因为战争迷雾而看不到他的行动,这都使我在游戏中感到振奋和恐惧。在我的生涯早期,我从来没有对一款游戏感到如此兴奋,直到我第一次玩《魔兽》,无法预料自己会输会赢。

我兴奋极了,努力地采矿、伐木、建农场和兵营,建设防御工程、探索地图,还有最重要的——打败Bob的军队。

这不是为了验证引擎性能而进行的游戏测试;我知道他也一样渴望宣布自己是第一款多人游戏《魔兽》的赢家。另外,我们在暴雪里一起玩《毁灭战士》时,我已经赢过几次了。经过异常激烈的游戏后,Bob很生气,因为我老是用火箭筒杀掉他,所以他发誓再也不跟我玩了。我知道他还想着报仇呢。

当我们的军队狭路相逢时,我们更加努力生产军队,然后把他们投入战场。当我发现他的营地,我就进攻,我感到胜算更大了。Bob的战术太没组织了,看来我能击溃他的军队,但我不想给他留下任何反击的机会,所以我继续发动疯狂的进攻,杀他的人烧他的房子,一个都不能少。

然后……崩溃了?

Dos4GW-crash(from gamasutra)

Dos4GW-crash(from gamasutra)

所有程序员都知道,新代码第一次运行就成功的可能几乎为零。所以游戏崩溃了就没什么奇怪了。游戏的图象缩到屏幕的上方去了,画面显示了一段DOS4GW的“屏幕崩溃”的文本,这对Windows游戏时代以前的玩家来说再熟悉不过了。现在我们有了更复杂得多的Windows报错对话框,让玩家可以提交错误报告,不过,玩家偶尔会看到死机的可怕蓝屏,与老式操作系统非常相似。

崩溃之后,我从椅子上跳起来,冲进Bob的办公室,大叫:“我赢了!”Bob立即回应我:“我揍死你!”所以我很惊讶地听到Bob的反驳:不是我打败他,而是他打败我了。

我们费了好几分钟才让我们紧崩的神经恢复正常,但我们立即意识到不仅是我们遇到了崩溃漏洞,而且游戏状态的同步性也有问题,我称之为“同步漏洞”:两台电脑显示的战斗情况完全不同,即使一开始是一样的,但越发展越不同。

那些没有写过网络代码的人可能会说,这两个《魔兽》客户端在游戏时,会在每个回合里将整个游戏状态反复发送。也就是,在每一个回合中,电脑会发送所有游戏单位的位置和活动。在慢节奏的游戏,如国际象棋或西洋跳棋,只有几个棋盘位置,这是完全可能的。但对于《魔兽》这种游戏,同时有600个单位在活动,不可能通过网络发送这么大的信息量。

我们估计许多玩家会用200波特率的猫(调制解调器)玩《魔兽》,它每秒只能发送几百个字符。从来没有使用过猫的年轻玩家应该花点时间读读技术书。当时,我们可是处于黑暗时代啊,虽然比石器时代先进,但也才刚刚脱离飞鸽狼烟的时代。那时候可没有亚马逊、谷歌和Netflix。

我曾将《国际象棋》从DOS“移植”到Windows上,所以我熟悉多人游戏如何通猫传输信息。我知道因为猫的可用带宽有限,所以不可能将整个游戏状态通过网络发送,所以我的解决方案是只发送玩家的指令,而双方玩家同时执行这些指令。

我知道这个方法是可行的,因为电脑最擅长的就是如实执行收到的指令。不幸的是,编写程序的我们却不善于告诉电脑到底要做什么事。这就是漏洞产生的主要原因。当两台电脑本应该做相同的事时,因为漏洞而产生差异,这就是问题。

如果两台各自执行游戏的电脑选择不同的答案来解决相同的问题,并且差异越来越大时,同步漏洞就产生了。就像一部时间旅行的电影《回到未来》,时间旅行者在过去做的小变化导致了完全不同的未来;所以两台电脑上《魔兽》的分离也是类似的原因。在我的电脑上,我的精灵射手会看到你的兽人奴隶并进攻,然而在你的电脑上,兽人奴隶并没有受到攻击还是返回仓库。因为没有发现或更正这些差异的机制,所以两台电脑显示的游戏情况很快就完全不同了。

所以,两位玩家在第一个多人模式的《魔兽》中打了个平手。但同时,它却是游戏团队的重大胜利。在办公室里的其他成员之后玩了多人模式,很快发现它像Blue Sky,也就是Walter White在电脑《绝命毒师》中制作的纯冰毒。一旦人们玩过多人模式的《魔兽》,其他游戏都是浮云了。即使游戏经常崩溃,我们也知道我们做了一件了不起的事。

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

悲剧的是,我们很快发现了一个更糟的问题:我们不仅是遇上无数同步漏洞,而且导致这些同步漏洞的原因五花八门。如果所有同步漏洞是出于相同的原因,那么我们只要努力修复那个根本原因就行了。但是,问题的类型那么多,且各自产生不同类型的同步漏洞,因此,每个漏洞都要有自己的修复方案。

为什么产生同步漏洞?

当开发《魔兽》时,我已经设计了一个最小化必须通过网络传输的数据量的方案,也就是只发送各个玩家发出的指令,如“选中单位5”、“移动到650,1224”或“进攻单位53”。许多程序员也各自设计了相同的系统;毕竟对于同步两台电脑,而不在每个游戏回合之间发送整个游戏状态,这是一个显而易见的解决办法。

现在,大概有数种专利软件宣称解决了这个问题。久而久之,我渐渐觉得软件不应该取得专利权;一般水平的程序员都能想出大多数软件的编写想法,并且专利的定义要求专利应该不太显而易见。

我还没执行能验证两台电脑的同步性的机制,所以任何导致电脑做出不同选择的代码漏洞都会而导致游戏走向“分叉”——也就是,将游戏分裂成两个松散联系的世界,虽然保持交流,但分裂的速度随着时间而加快。

为了发行游戏,制作一个检测去同步性问题的系统显然是我的下一个任务。

结尾

你知道这个故事的结局:《魔兽》“最终”在仅仅五个月后发布了。它看起来就是一件不朽的作品,因为我们在它上面花了那么多时间、攻克了那么多随障碍、战胜了那么多挑战,才做出了这么一款我们深爱的游戏。在以后的文章里,我将继续讲述这些经历,但是回忆太多了,我不可能把所有思绪都塞进这篇已经冗长的文章里了!(本文为游戏邦/gamerboom.com编译,拒绝任何不保留版权的转载,如需转载请联系:游戏邦

The Making of Warcraft’s Multiplayer

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 ’90s, 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. 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 20 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 is 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 & 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, “hardcore” 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 of 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 triple-A+ 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.

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 12th graders played Math Blaster using calculators.

As asteroids containing expressions like “3 + 5″ and “2 x 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 workforce.

With good stewardship and aggressive leadership Davidson & Associates expanded into game manufacturing (creating and 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 and 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 composed 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 a 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 farmhouses, 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 number six, 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 then-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 a 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 10 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, pathfinding, 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 to Quake, which had been recently 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

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 that make it easier for the AI player to compete, though most players would perhaps call these rules outright cheating.

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 removes eight 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.

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 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.

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:gamasutra)


→如果您认为本词条还有待完善,请 编辑词条

词条内容仅供参考,如果您需要解决具体问题
(尤其在法律、医学等领域),建议您咨询相关领域专业人士。
0

标签: 《魔兽争霸》多人模式诞生过程

收藏到: Favorites  

同义词: 暂无同义词

关于本词条的评论 (共0条)发表评论>>

对词条发表评论

评论长度最大为200个字符。