|
摘要：在之前的关于Warcraft开发的文章中，Warcraft之父Partrick Wyatt开启了一个“为什么Blizzard Entertainment成为了世界上最有名、最受欢迎的游戏公司之一”的话题，并从Warcraft和StarCraft开发回忆当初在Blizzard奋斗的过程，一步一步为我们描绘出Blizzard从普通的工作室开始的“征途”。
如果你没有看过之前的文章，可以点击这里： 支持多人游戏1994年6月，也就是在10个月的开发之后，游戏引擎已经基本上支持多人对战了。随着代码集成的进行，我感到越来越兴奋，因为马上就可以使用Warcraft进行多人对战了！虽然我一直忙于游戏核心逻辑的设计、实现（事件循环、单位调度器、路径寻找、战术AI单位、状态栏、游戏内UI、高级网络代码等等），其他程序员已经开始着手多人对战相关功能的开发了。 Jesse McReynolds ，Caltech（加里福利亚理工大学）的毕业生，完成一个低级网络库的开发，可以在局域网络内发送IPX包。这些代码的实现得感谢id software John Carmack（3D游戏之父——约翰·卡马克）刚刚开源的Doom源代码，虽然IPX中间层只有几百行C代码，但它能很完美地跟网卡驱动结合，保证一个游戏客户端发出的信息能够传送到另一个玩家那里。 Bob Fitch，Cal State Fullerton（加州富乐敦州立大学）的硕士，开发了“glue screens”的原始版本，自此玩家已经可以创建或者加入多人游戏。Bob的办公室紧贴着我的，因此我们可以密切地合作，把他开发的“创建/加入游戏”功能融合进我设计的游戏事件循环中也因此变得非常方便。 在合并了这些更改之后，我把游戏客户端重新编译了一遍，并复制到网络共享盘中，Bob也紧接着回到办公室加入游戏。奇迹发生了，没有任何问题！就这样，Warcraft开始支持多人游戏。 在游戏过程中，我感受到前所未有的兴奋，在之前玩过的所有游戏中都没有这样的感觉。如此激动的原因一部分是因为我自己参与了部分代码编写；另两个更重要的原因在于：我是和人类做对手，而不再是计算机AI（Artificial Intelligence，人工智能）；更特别的地方在于，因为“战争迷雾”的存在，我并不知道他在做什么。这甚至给我带来了心理上的恐惧感。 战争迷雾
一个小村庄被战争迷雾所包围着，那里究竟发生了什么？！？ 早期的游戏里，视野外的敌人是隐藏的，这正是“战争迷雾”设计的原型。除非有友方单位探测过，否则地图将会被黑色的图形层覆盖，以此来模拟真实战斗中无法获知敌人的调度和行动。 Empire，Walter Bright（“D语言”之父）大约17年前所开发的游戏，也出于同样的目的使用了战争迷雾。如果地图上的某一块并没有被探索过，那么它将处于烟雾笼罩之下，所以游戏初期的一个重要任务就是去探索（未探索过的）地图。 心理上的恐惧源于我无法得知对手正在做什么，正如历史上很多将军死亡那样。RTS游戏中加入了这一元素让游戏精彩（恐怖）程度更上一层。感谢Westwood的Walter以及其他想到了这一创意的人。 计算机AI正如很多玩家所知，计算机控制的“人工智能（Artificial Intelligence）”（AI）通常在战略上很弱，所以人类玩家经常可以AI玩家的程序漏洞，因此可以轻松获胜。为了保证可玩性，AI玩家的队伍通常会在队伍数量、位置上有优势，又或者是通过其它“不对称规则”来给人类玩家足够的挑战。 大部分Warcraft的任务中，计算机敌人通常一开始就会拥有整个城市以及军队。此外，Warcraft还为AI制定了其它不平等的规则，如同作弊一样。 我们制定的不公平规则之一就是：AI玩家每次采矿后金矿数量减少地更少，所以很少会有矿井被采空的情况发生。人类玩家在采矿时会从矿井移除100个矿石单位到市政大厅，但AI玩家同样采一次100单位的矿石，矿井只会减少8个单位的矿石。 这种不对称规则有两方面的好处：
大多数玩家都意识到了另一个更加违反公平竞争原则的规则：计算机AI在作弊，因为战争迷雾对它们无效；AI知道玩家每时每刻究竟在做什么。在实战中这是个非常大的优势，可惜计算机没有那么聪明，也无法充分利用这一优势。 有趣的是，在StarCraft流行的那段时间里（自发布以来14年多的岁月），一直有一群AI程序员视图制作无作弊AI的挑战。在BWAPI库的帮助下，这些程序员可以编辑代码直接注入到StarCraft的引擎中去，并且和AI一决胜负。虽然BWAPI AI已经很厉害了，但StarCraft高手仍然可以轻松战胜它们。 和真人对战作为战略游戏资深玩家，我很清楚那个时代计算机AI的局限性。在和众多AI对战的经历中，鲜有败绩，即使在面对Eastern Front（Chris Crawford开发的东部战线）中俄罗斯的疯狂进攻，也从未有面带惧色。 我玩过的这些游戏都非常有趣而且令人兴奋，但从不令人恐惧；这在Warcraft多人对战中就不一样了！ 我需要战胜的是一名人类玩家——我所面对的不仅是技巧和战略，还有敌人快速的控制。因为战争迷雾的存在，双方都不知道对手的动作，因此更加令人振奋。我在职业生涯中从未对某款游戏感到如此激动，但是第一次玩Warcraft的时候却不一样，不到迷雾揭开之时都是胜负难知。 我的血液在沸腾，肾上腺素在飙升，只为了更快地伐木、采矿、建造农场和兵营，当然还包括组织战力、探索地形以及——最重要的——在Bob的军队成型前将他击溃！相信Bob也是一样。 我们并没有在游戏开始前对引擎功能进行测试，因为脑海中只有火热的决胜之心，相信Bob也想夸耀自己才是第一场Warcraft多人对战的胜利者吧！除此之外，我们还经常一起在Blizzard玩Doom，在一场激烈的游戏后，Bob怒气冲冲地说不再跟我玩了，因为我总是用火箭炮秒杀他。当然，我知道他一直都在找机会报仇。 在对战中，我们加倍努力地建造单位并派遣到战场上，在找到他的基地并进攻的时候，我甚至感到胜券在握了。Bob的战略杂乱无章，我觉得能够轻易将其击溃，但是稳重起见，我还是开始更疯狂地建造单位，并且在战场上击杀他的部队。 然后……游戏崩溃了：
坏消息——DOS4GW告诉我Warcraft崩溃了 这是程序员间的常识——任何一款程序在第一次运行时成功的概率接近于0，游戏半途崩溃不足为奇。游戏的画面在不停地从屏幕上方向下滚动，伴随着DOS4W“crash screen”的字样，这对Windows之前的游戏开发者来说在熟悉不过了。现在我们能得到更详细的Windows错误提示框，玩家可以反馈游戏崩溃记录，当然也有不少玩家会遇到“蓝屏死机”状态，和老式错误提示非常相似。 在崩溃后，我几乎从椅子上跳了起来，直接冲向Bob的办公室，叫嚷着“That was awesooooommmme!”。立刻就得到了回应“… and I was kicking your ass!”我竟然听到Bob说他差点就彻底摧毁我了。 几分钟后我们才从混乱中缓过神来——我们的游戏bug不仅在于崩溃，而且还有个“同步bug”，也就是说游戏状态不完全同步：两台机器上显示着不同的战斗，虽然初始状态相同，但渐渐地就进入了两个完全不同的世界。 没有网络编程经验的人可能会认为，两个Warcraft客户端可以在游戏过程中来回发送/接收整个游戏状态；但实际上，每台计算机仅仅会发送每个单位的位置和状态。对于只有几个板块位置的慢节奏游戏，如国际象棋或者跳棋，这种想法可能还算合理，但对于Warcraft这样每个动作涉及到超过600个单位的游戏来说，不可能通过网络传输所有的状态。 我们预计会有不少玩家使用2400波特的调制解调器，每秒只能传输几百个字符的信息，没有使用过调制解调器的年轻玩家应该花点时间去学学这方面的技术。记住，我们现在讨论的是Amazon、Google、Netflix出现前的“黑暗世纪”。 因为有之前将Battle Chess从“DOS”移植到Windows上的经验，我非常熟悉多人游戏通过调制解调器通信的方式，调制解调器有限的带宽是不可能完整地传输整个游戏状态的，所以我的解决方案是仅仅发送每个玩家的命令，而每个玩家（的机器）同时执行这些命令。 我相信这个解决方案没有问题，因为计算机非常擅长执行命令。不幸的是，编程的人类却无法准确地告诉计算机应该怎样做，这就是出现bug的主要原因。虽然我们指望两台计算机做完全一样的事情，但因为bug而不一致，这就是问题所在。 之所以会出现游戏不同步的bug，是因为在模拟游戏中，两台计算机面对同一个问题却给出了不同的答案，随之时间的推移，差异越来越大。正如《Back to the Future》这部穿越电影所描述的，穿越者在过去所做的小变化会导致完全不同的未来，Warcraft的差异也是如此。在我的计算机上，我的Elvish archer（精灵弓箭手）发现了对手的Orcish peon（兽族苦工），但对手的计算机却没有注意到我的进攻，继续伐木或者采矿，由于没有错误纠正程序来处理这些分歧，于是两台机器上的差异越来越大，以至于完全不同。 所以我们的第一场战斗只能算是平局——但对于整个开发团队来说，这是一个伟大的胜利——它还给我们带来很多乐趣！团队其他成员也渐渐地加入了进来，随着游戏/测试人员的增加，更多的bug暴露了出来。虽然游戏经常会遇到崩溃，而且还有更多的问题，但我们知道，这将会是一番大事业！ 我们所需要的只是去把游戏做好。 可悲的是，很快我们就发现了更糟糕的问题：虽然同步bug很多，但造成这一现象的原因却也不少。如果这些同步bug处于相同的原因出现我们早就会开始根本问题的修复工作了。但事实证明有很多引发同步bug的原因，每一种都会带来不同类型的同步bug，而且每种bug都需要不同的修复方式。 为什么会出现同步bug？在开发Warcraft I的时候，我设计了一种最小化数据传输的方法——只发送玩家发送的命令，比如“选择单位5”、“移动到位置650,1224”、“攻击单位53”等等。很多程序员都自主设计过这样的系统，这是“不发送整个游戏状态就同步游戏变化”的一个显而易见的解决方案。 说点不相关的：这段时间有几个专利好像就是冲着这个方法去的。久而久之，我开始认为软件不应该是专利，大部分软件专利并没有什么新意，有经验的程序员都能想到并实现，而根据定义，专利应该是不平凡的。闲话就说到这里。 那个时候，我还没有实现验证两台机器间同步的方法，所以任何会导致计算机做出不同选择的bug都会导致游戏走向分叉——也就是说，他们会变成两个松耦合的世界，虽然仍有交流，但差别会随着时间的推移而加剧。 所以很明显我的下一篇文章会是关于如何发现不同步问题的。 打持久战的准备你们都知道这个故事的结局：Warcraft最终在5个月后发布了，它成为了不朽的传奇。这离不开我们每天长时间的辛苦工作，在解决了很多问题、克服了很多障碍和挑战之后，最终发布了我们所热爱的作品。在未来的几个月里，我将继续带你们探索Warcraft的开发之道。 原文链接：Code of Honer StarCraft系列： |
|
|
