《刺客信条》等开发者如何解决无处不在的Bug？

人人都知道Bug。有好玩的Bug，有莫名其妙的Bug，有恼人的Bug，也有真正严重的Bug。但它们拦在开发者与玩家之间，一个致命错误，一次崩溃，都是一次重大打击。

玩家对这些问题的感受是非常直接的。Bug会带来恶搞题材，或是玩家的怒火，它们也应该被解决。玩家并不太清楚开发者在这其中的工作。在过去十多年间，开发者与玩家之间的关系越来越紧密。在如今以网络推送更新的时代，“早期体验（Early Access）”这样的形式帮助了独立游戏的发展，玩家进入到游戏开发的过程中来，审视各项更新内容，并提供反馈。

“这是一把双刃剑，对吧。你能够发布你的游戏，玩家能告诉你哪有问题，你可以跟进他们的反馈然后修复这些问题。”《Hohokum》、《Frobisher Says》的开发者瑞奇·哈格特（Ricky Haggett）这么说道。“这很好，但也让人非常有压力。你也会感觉到自己像是暴露在世人面前。”

“这可能是一件很感性的事。”Positech Games的克里夫·哈里斯（Cliff Harris）也同意这种说法，他是Lionhead及Elixir工作室的老员工，曾主导开发《民主制度（Democracy）》、《无厘头太空战争（Gratuitous Space Battles）》系列，以及如今的汽车工厂管理模拟游戏《流水线（Production Line）。

“我认为大家一直有种误解，认为说玩家碰到有Bug会觉得开发者不会关心这种事，毕竟他们已经拿到了买游戏的钱。尤其是Steam有了退款机制，我们只是暂时收到了玩家的付款。我做的游戏中任何的Bug，除了那些良性的之外，对我来说都是灾难。我也知道这一点，我不能假装这不是我干的。你看到那些错误报告都会感觉到血清素水平陡降，甚至一个‘闪退（crash）’的字样都能让你崩溃。”

《机械狂暴》开发者安德鲁·布雷布鲁克（Andrew Braybrook）评价C64 bug


早期游戏机上6502芯片的汇编器非常难用。它无法让你停下来看到到底是哪里出了问题，开发早期也没有调试工具。试想，一个游戏能正常玩上20分钟，然后突然停止运行。这就是1983年9月里《机械狂暴》碰上的事，而此时距离游戏进入拷贝阶段不到一个月。

通常来说如果有Bug出现，意味着有什么地方做的不对，但《机械狂暴（Paradroid）》不太一样，没有任何区域的代码显示导致了这个问题，我花了三天时间检查所有的代码。第三天当回到家，我把范围缩小到碰撞监测系统上。大概晚上7点的时候，我吃完晚饭，忽然意识到了什么。我发现了出错的地方：我在数据表里弄错了一个索引值。

数据表中有24种不同的类，储存所有游戏中角色数值、最高速度、装甲强度、初始能力和武器数据。同时还有另一个数据表存储角色的位置、能量和速度等16个值。如果你把这个有24个值的表索引16个值的表，就会导致有8个值无法读取数据。而问题只发生在处理碰撞监测上，因此当一个角色碰上另一个时，游戏就会停止运行。我走进后院然后大叫，终于找到了问题所在。

所有的开发者对他们的游戏都有着很强的荣誉感，至少也会捍卫他们的作品。因此当Bug从环环相扣的系统中出现时，开发者也很头疼，他们也知道Bug是不可避免的，但直到游戏发售之后，真正严重的错误报告才会出现。

“有时我收到关于游戏缺陷的邮件时，”哈里斯说：“我在我的网站上有提交游戏错误、缺陷的板块，可以让人们报告Bug，虽然他们经常是在讨论区把这些问题提出来。我会收到私信反馈，在Facebook游戏页面收到反馈，在Reddit上回复玩家的反馈，还有在Steam各种板块提交的错误反馈。然后，每次我公布些什么东西，评论里也会有反馈。啊，还有YouTube，每次放个视频都会有人评论说游戏又闪退了。”

有时这些反馈详尽说明了玩家的设备，问题出现的时间点，以及玩家当时的操作。“但我经常收到邮件说，‘你的游戏又崩溃了，快修复’，我甚至都不知道这是什么游戏，只是一则孤零零的信息！你还会碰上某些火气相当大的玩家，他们对解决问题并没有帮助。”

Fireproof的罗伯·陶德（Rob Dodd）对重现Bug有话说


我多年以前负责一款第一人称射击游戏的开发工作，这款游戏的敌人死掉之后会掉落武器。武器会实体化然后掉到地上。然后这里有一个非常罕见的Bug：枪支会直直穿过地板。这很严重，因为游戏有时要求玩家收集特定的枪支。但这个问题的原因很多。只是看着它发生是没有用的，我需要重现这个Bug，所以我设了一段代码，每秒掉落一支枪，速度、角度、高度全部随机，并在同一关卡内各个位置掉落。同时持续追踪，如果十秒内有枪掉到地面以下，它就会报告其确切的参数。

我让这段代码运行了一个晚上，然后第二天早上去看看游戏有没有出问题，但几个小时过去了，系统已经掉落了数千支枪，少量穿过了地面。我改变了初始设置，突然，我就重现了这个bug。修复也很简单，碰撞系统并没有针对旋转掉落的枪支进行完整的设置，只要一行代码限制枪支的旋转即可。

作为一个开发者，很难真的觉得那些愤怒的反馈信息是玩家对游戏热情的表现。但简单地回复一个愤怒的玩家通常会让这些愤怒的玩家迅速变得理性起来。哈里斯看到，正常的用户反馈要是在谷歌或是微软这样的巨头面前都感觉像是石沉大海。而给游戏反馈邮箱发反馈居然有真人回复，都会让人蛮惊讶的。

“我尽量直接回复他们，不管是什么时间，先道歉，再向他们询问更多信息。”哈格特说道：“人们一般都很理性，我们也很庆幸不用和很糟糕的人打交道。而一旦你先道歉，又为人提供帮助，这已经是个很积极的举动，人们也愿意和这样的开发者交流。而我也喜欢和玩我游戏的玩家聊天。”

接下来，开发者需要记录反馈的问题。哈里斯作为独立开发者，会把这些东西记在他的日历上，逐步修复他们。更大一点的团队会使用管理系统，比如Zendesk之类进行修复工作。而专业的系统远比1990年代的管理方式先进了很多。

“有一件事情让我非常震惊，那就是Bug反馈和修复这个事情有多原始。”Looking Glass的编程人员及设计师多利安·哈特（Dorian Hart）这么说道。“当我们做《创世纪：地下世界 2》和《网络奇兵》的时候还没有专门的反馈软件。测试人员和开发者会跟QA的负责人发邮件反馈，记录在一张长长的列表上。随后某天，我们会开一个大会议，QA团队在会上把这些Bug大声念出来。对此负主要责任的人员得举起他们的手，承诺改进。如果这个Bug之前已经出现过，QA团队就会大喊‘骗子’。两个同源的Bug通常也会引来引起争执，而同样的情况还会出现在‘这不是一个Bug’的争执上，或者为谁负责吵起来。”

乔瑞斯·多曼（Joris Dormans）：我们在《未探索地域》里把游戏Boss弄丢了


当我们把《未探索地域（Unexplored）》从Early Access阶段推进到上市发布阶段时，我们在最后的补丁里犯了一个非常低级的错误。简单来说，我们把Boss的数量全设为0了。大概一个星期我们才意识到，我们发布了一个除了最终Boss之外没有任何其他Boss的游戏。Early Access的一名玩家提到了这个问题。我们迅速推送更新解锁了50个新Boss。剩余玩家反响也还好。作为一个独立游戏开发团队，我们能在平台上提供持续的更新实在是件好事。你可以很快地解决这种事。

不过，虽然情况有所缓解，但核心的工作在于找出问题所在。“调试就像是侦探，你得找出线索，问出对的问题，还原犯罪现场。”安德鲁·布雷布鲁克说，“它不能按步就班地来，也不能贪图省事，但它又必须解决。在C64电脑上，所有调试工作必须在游戏发布之前完成。”在那时，代码的量还很少，而随着编程人员倾向于独立工作，代码也变成了他们的东西，他们也知道这些东西如何运作。“这带来了实际的好处，你不再需要从别人的代码里找他的错误。很多bug很快就能找到并修复。”

“几乎所有的问题都取决于我是否能重现这个问题。”哈里斯独立完成了他的游戏引擎，也因此他能处理游戏各方面的问题。“一般来说，我能看到的闪退，我一下子都能修复。”这也是为什么开发者需要玩家提供足够的信息。如果开发者能够重现一个Bug，他们就能知道计算机在什么情况下出现了问题，并找到问题的根源。通常，真正的工作，在于找到引发错误的各种罕见游戏场景和各种参数。

但还是有更棘手的Bug。哈里斯称之为“海森bug（Heisenbugs）”，它们会随着调试的进行消失或者变动，这导致它们很难确认。查尔斯·兰德尔（Charles Randall）是曾在多个游戏团队工作过，包括BioWare埃德蒙顿、育碧蒙特利尔以及Capybara Games。他谈到了“meta-bugs”，它并非由于代码本身形成，而是由编译器导致的bug。

“把责任推到编译器身上就像是游戏中的‘It's Not Lupus（这不是狼疮）’，但如果它真的是个问题，那就很痛苦。在《孤胆枪手 2》中，有个开发者负责音效部分的代码，然后发现特定的游戏音效无法播放。调试时他发现代码并没有执行指定的函数，在大量的工作之后，我们推测这是一个名称重整问题，重新命名函数之后我们才解决了它。到目前为止没出什么问题。”

查尔斯·兰德尔和《刺客信条2》的bug


《刺客信条 2》有一个战斗动作缺失的bug，但我一直没能解决。我找不出什么东西触发了它，它在一年多里一直神出鬼没，我却没能在代码里找到问题，就……只能这样了。我要提醒这不是对的做法。当我发现这个问题时我在播放其他的动作效果，我推测这是一个极罕见的问题，你会看到动作并不同步，不过没有人抱怨过这个问题，那是我猜它应该是被修复了。Bug不见了也算是不错了。

有些时候，反馈里说的其实根本不是问题。“我相信玩家会觉得这是在胡说八道，但很多时候玩家说一个游戏运行不正常，他们只需要升级一下显卡驱动。”哈里斯说：“这听起来真是废话，但启动页闪退这个问题，80%都是因为驱动没升级。”在Steam和PS4上，哈格特收到反馈说游戏莫名在启动时闪退。原因也不明，但重新安装游戏能够有效解决问题。“我们会觉得‘噢，得重新安装，那还是个问题啊’”。

不过修复之后，升级就容易得多了，即便是在主机上，很多东西都自动完成了。一个误解是主机制造商审核内容是为了确认是否有错误。实际上完全不是，这只是为了内容符合平台规范而已。《Loot Rascals》这款游戏就附和规范，但有很多Bug会导致闪退。在PS4上推送补丁，审核一般也只需要花费几天。

有时Bug是无法修复的。这比你想象的要罕见得多，也由于开发者对他们工作的认同感，当这样的东西出现时，这更多是一个基于商业考量的问题。“如果有人说Windows版本的升级让《红衫》无法运行，我就不会再修复了。我会下架它。这很不值得。程序员对Bug很敏感，我们真的比任何人都讨厌Bug，这让我们看到自己的差劲。所以他们不会留着这些Bug，除非这是个商业抉择。程序员总是想着追求完美，不去修复绝不是一个程序员的选择。”

泰迪·迪耶夫（Teddy Dief）谈到《光明旅者》里的漏洞和漏洞利用


我还记得2013年在一次大会上展示《光明旅者（Hyper Light Drifter）》的场景。那真是美妙，展示我们做的游戏，看到很多人沉浸其中。我们在完成预览版之前我整夜睡不着觉。那天，一个傲慢的小鬼到展台上说“我要破了你们这个设计”，然后就开始一遍一遍的操作任务冲向墙壁。我跟他说不行，他坚持认为可以。我们大概拉锯了十来分钟。但他最终没有找到漏洞。两年以后，我和我的设计师博·布莱斯（Beau Blyth）一起看了Awesome Games Done Quick。我们看到玩家利用漏洞跳过了《时之笛》的整个关卡。这是我第一次意识到，如果有人真的破了这套设计，真的是好事吗？

六个月之后，我们正式发布了《光明旅者》，大概两天之后就有速通玩家找到了如何穿越墙壁的方法。他用了一个我们从未想到的手法，故意被陷在水晶里，强行通过墙壁，随后就能自由行动了。我们想修复这个漏洞，我们调整了水晶的位置使其远离关键的墙体。但最终我们还是选择不去彻底修复这个漏洞。好吧，我们也不知道如何在不大改游戏的情况下修复这个问题。因此，我们选择让玩家能够继续利用这个漏洞，而非彻底堵死……只不过我们会让玩家的角色在其后数秒内死亡。这样对防止速通玩家做出太过分的事足够了，也让无意触发这个漏洞的玩家能意识到问题。有时你就是得得罪玩家，还得希望他们原谅你，所以请原谅我。

via：界面