type
status
date
category
summary
language
面向群体
游戏品类
资料类型
平台
tags
password
Sub-项目
作者
文章链接
来源
标签
Parent 项目
发布时间
slug
icon
等你点关注都等得长猫了
欢迎关注“游戏寿司”
本公众号的主旨是发布游戏深度研究和日本游戏市场分析的原创文章，欢迎关注~
微博名称：游戏寿司
微信公众号ID：gamesushi
微信号ID：hebeihang
知乎ID：寿司君
与其他开放世界游戏相比，《荒野之息》的Bug之少令人惊讶。不信？我们看看隔壁的《宝可梦朱紫》的各种哭笑不得Bug。
更不用说曾被给予厚望的《赛博朋克2077》中那个引发玩家热议的黑屏BUG。
那么，为什么《荒野之息》的Bug如此之少？比起笼统的"多年精心开发"或者缥缈的"日本的精益求精匠人精神"，真正的答案藏在2017年8月31日的一次演讲中。
这一天是日本最大的游戏开发者技术交流会CEDEC演讲，任天堂的丸子良太和大礒琢磨发表了题为“《塞尔达传说：荒野之息》的QA：最大化游戏乐趣的工具和Debug的介绍”的演讲。
本文根据IGN的《「ゼルダの伝説 BotW」にバグが少ない理由》和《【CEDEC2017】「ゼルダの伝説」作成を裏から支えたエンジニアたち》的新闻稿进行整理和分析而成，特此鸣谢。
QA专业领域特别感谢QA业内人士逐烟和木菻的指正，谢谢！
（备注：原文的デバッグ本文翻译为调试）
演讲者介绍
首先我们介绍下登台演讲者。
>
丸子良太
在非游戏行业任职后，2009年加入任天堂。负责开发和支持游戏开发工具，包括本地化、序列控制和关卡编辑器。
>
大礒琢磨
早稻田大学毕业后，加入任天堂后参与了内部项目的开发。在《塞尔达传说：荒野之息》担任QA工程师。
开发早期就进行调试
新闻稿中没有记录最开始的演讲者是谁，但根据前后文推理应该是丸子先生。
在进行《荒野之息》的QA工作前，团队认识到品质不仅仅包括没有Bug，还包括游戏的趣味性，这是QA团队的方针。
QA的方针可能是指，如果一个玩法有趣但容易出现Bug，解决方法有①经过调试在保证玩法的前提下解决Bug，或者②干脆删掉玩法，显然《荒野之息》团队选择的是前面这一种。
为了增强趣味性，团队将开发周期定为尽可能多的循环，将提供和维护这种环境作为QA的职责。
这里的循环可能是指下图所示，开发游戏的玩法并确认玩法是否有趣的开发循环。
此外，本作是开放世界游戏，预计是一个需要处理多样且庞大的数据的大型项目。因此，团队需要根据游戏定制开发工具来提高开发效率。
为了实现人员、数据和工具的连接，并使其易于使用，开发人员将编辑数据、工具、需求和操作者的各种数据进行数据库化，数据生成时会录入数据库，之后也会定期录入数据库。
当工作时，如果数据、人员和工具之间没有建立有效连接，那么在寻找这些工作目标时会遇到困难，这将浪费设计师宝贵的创作时间。
为了解决这个问题，团队开发了开发工具"Zelda Editor"（参见《任天堂的开放世界工业化流程——以塞尔达为例》）。通过它，开发人员能够减少寻找工作目标的时间，提高开发效率。
为了全面了解整个游戏并提高品质，团队设计了可以让任何人查询数据库的机制。创建一个可视化的世界图表来显示与场景相关的信息，并设置了场景需求浏览器，通过图表和列表的形式来了解整体工作的进度。
下图是世界图表（左侧）和数据库浏览器（右侧）的介绍，两种方法优势互补。
比如世界图表的优势是：
- 可以知道关于场地的信息
- 把握神庙、资源等元素在地图上的密度和分布总量
- 分享数据的整体和平衡
- 支撑策划想法的论据
这里结合其他演讲进行分析，世界图表可能是指，其他演讲提到的根据测试人员行走轨迹对开放世界进行调整的一种模式。
数据库浏览器的优势则是：
- 适合呈现和地图配置无关的数据
- 数值型的数据
- 以管理项目为目的的数据
- 自动检查处理的任务化
演讲中举了一个具体例子，在世界图表的“Game Over View”中记录了经常出现Bug的位置，可以在这些位置设置自动保存，来防止崩溃对开发的影响。
此外数据库浏览器还设置了数据共享功能。可以分享和重复使用查询。
在这里，不仅可以分享其他人创建的查询，还可以让非程序员也能够在开发中使用，自动将有问题的数据转为需求的功能。通过这些工具的协作，能够更频繁地进行提高游戏趣味性的创作循环。
开发早期就进行调试
然后是大礒先生的演讲。
大礒先生是2010年加入任天堂的QA工程师，而《荒野之息》是他首次参与的《塞尔达传说》系列游戏。
之前，他在《nintendogs + cats》（下图）和《New超级马里奥兄弟U》等游戏中担任开发系统部分和开发环境的程序员。
换句话说，大礒先生并非是专业的QA工程师。
但在《荒野之息》项目中，为了确保这个游戏顺利完成，大礒先生自愿接受了QA工程师这个重担，从开发早期就参与游戏开发。
制作人青沼英二曾提出“重新审视《塞尔达传说》系列中那些理所当然的设定”的开发理念，而大礒先生也是从QA的角度去审视“那些看似理所当然的开发流程”的成员之一。
迄今为止，《塞尔达传说》系列通常是在开发后期时才进行调试。
改变这种方式的契机是在开发早期进行的"游戏趣味性验证阶段"，也就是前文《任天堂的开放世界工业化流程——以塞尔达为例》中的原型阶段，可能包括最初的2D版塞尔达原型（下图）。
也包括下图最左侧的粗模阶段。
当时，整个团队的约80人成员花了两天时间从头玩到尾，验证玩法是否实现了他们的预期。
结果是：尽管预期的玩法得到了实现，但测试工作非常困难。由于测试中发生了各种各样的Bug，游戏短短两天内就崩溃了617次。
据大礒先生说，团队内部甚至形成了"经常保存"的口头禅。
大礒认为：“这样下去不行。”
他意识到，如果像往常一样在后期才进行调试，即使再努力也无法消除bug。因此，他提出了从开发早期就开始调试的建议。
把调试分为两个阶段
但是“开发初期就开始调试”遭到很多人的反对，他们认为如果有时间去调试，不如去推进实际的开发工作。
任天堂内部有员工认为，由于不确定开发过程中的bug是否会留在最终产品中，同时进行开发和调试会浪费时间。
这句话也很有道理，比如《荒野之息》早期计划制作小人国，但最终取消了。
然而，大礒先生坚持认为应该将"早期调试"和"最后阶段调试"分开进行考虑。因为bug并非只影响玩家的游戏体验，还影响了制作团队的开发效率。
不仅测试这样验证玩法趣味性的工作，由于大量bug的存在导致开发效率明显下降，在开发的各个环节中，bug也会对开发产生负面影响。
从早期开始调试的目的不仅仅是为了在成品中消除bug，更重要的是提高开发效率。此外，游戏能以良好状态进入最终阶段调试，可以说一举多得。
在早期调试阶段，团队并不需要修复所有bug，而是重点关注那些对开发造成困扰的bug。
修复困扰程序员的bug，以及其他人希望修复的bug，对于那些由于时间关系或原因不明难以调试的bug暂时搁置；对于当前阶段尚未对开发造成困扰的bug，在开发早期也不予修复。
发现bug后能够轻松报告的机制
那么，为什么《塞尔达传说》系列在过去一直没有采取大礒先生提出的早期调试方法，却几乎没有bug呢？
大礒先生表示，的确有些游戏在最后阶段才需要进行调试。但是，《荒野之息》这样的开放世界游戏，在数据的种类和数量上都是一个比以往作品更加庞大的大规模游戏项目。
在这种拥有庞大数据量的游戏中，连自己的bug都很难发现，这些没发现的bug有时也会给其他工作人员带来麻烦。
正因为如此，大礒先生提出了整个团队应该提高质量管理意识，并设计一旦发现就能够轻松报告bug的机制。
在过去的《塞尔达传说》系列中，Bug主要由测试人员报告，而游戏开发发布"需求"（Task）和"Bug"在不同的工具中进行管理。然而，在像《荒野之息》这样由多个不同地区的团队共同开发体制下，这样分开管理的开发流程并不理想。
（备注：《荒野之息》有任天堂外部团队Monolithsoft参与开发）
为了避免"因为是Bug所以以后再处理"的想法，他们将Bug和需求的管理工具进行整合，并从一开始就报告了所有的Bug并设置了优先级。为了提高Debug的意识，除了引入系统外，还举行了团队全体的说明会。
下图为混合了需求和Bug的Zelda Editor开发工具，这个开发工具在《任天堂的开放世界工业化流程——以塞尔达为例》有介绍，有兴趣可以阅读。
我们看一下这个管理工具呈现的信息：
其中的A级Bug是“木制宝箱燃烧会崩溃”，影响游戏运行的Bug需要尽快修理。而B级Bug是“不知什么时候开始滑翔伞的飞向距离变了”，不影响运行的可以暂缓处理。后面的参数是Bug的提出者和委托者。
为了减少Bug的产生，他们引入了在游戏中检测Bug的机制"ZELDA_ERROR"。开发者在代码中对可预见的问题打了6000多个“埋点”，如果触发问题，那么这个系统可以在发现Bug时轻松地进行报告。
下图是一个"ZELDA_ERROR"的案例，开发人员可以很轻松地提交“砍倒树木但没有树桩模型”的Bug。
由于只需点击"提交"就可以轻松地报告Bug，即使很忙也不会增加工作负担，此外，玩家的坐标、场景切换、事件和迷宫等信息会自动插入报告中，。减少了Bug报告者的工作量。
此外，Bug报告者不需要确认Bug是否已修复，这也是一个重要的因素，这样就避免了"确认Bug是否修复很麻烦，那我不报告了"的情况。
这个设计很人性化，“Bug报告者需要确认Bug是否修复”这个机制看似能督促Bug修复，但也为开发者增加了额外工作量，难以得到开发人员的响应。
不仅如此，QA团队使用热重载来直接修正错误的数据，可以减少程序更新时停止和重新启动所带来的风险，从而减少因此导致的错误或异常。
结语
通过在开发早期排除影响开发的Bug，可以提高开发效率，同时还能以良好的状态开始最终阶段的调试。
下图是《塞尔达传说》系列随开发时间（横轴）和Bug报告数量（纵轴）的对比。
左侧为过去的《塞尔达传说》游戏，可以看出游戏前期完全不进行Debug，临近E3展和最后阶段紧急Debug，而本作全程都在做Debug，曲线相对平滑许多。
而且，Bug的报告者比例中，专职测试人员（红色部分）报告的Bug是最少的，其次是自动测试（AI测试，绿色部分），大部分Bug由开发成员（蓝色部分）报告，而且比例不断增多。
由于QA团队的努力，这让《荒野之息》成为了开放世界游戏工业化的优秀案例。
- 作者:何北航
- 链接:http://gamesushi.cn/article/5e084bee-cef0-4b92-affc-f6e25a229349
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。