任天堂的开放世界工业化流程——以塞尔达为例

type

status

date

演讲者介绍

首先我们介绍下登台演讲者。

程序员冈村祐一郎担任“BotW”中的系统架构师，负责整体架构设计、制作工具和环境开发等工作，以确保游戏开发的顺畅进行，本次演讲中冈村将从工程师的角度介绍开放世界项目管理运营的方法。

尾山佳之曾参与塞尔达传说系列中许多角色设计，“BotW”中他负责管理角色模型。

冈村先生负责系统和工作流程的设计，而尾山先生则负责管理现场设计师的工作。

在具体内容介绍之前，介绍了一个名为“Zelda Editor”的《塞尔达传说：荒野之息》专用开发工具。

该工具可以编辑管理游戏中的所有数据，是《塞尔达传说：荒野之息》项目的核心开发工具，本次演讲将以这个名为“Zelda Editor”的工具为前提，介绍任天堂的开发流程。

工具的详细介绍，留待以后的文章分析讲解。

堆叠开发VS框架开发

在介绍具体案例之前，先从理念层面上解释一下两种开发思路。

根据冈村先生的说法，游戏制作流程大致可以分为“堆叠开发”和“框架开发”两种，他以五重塔的建筑为例解释了这两种方式。

堆叠开发”是指先把第一层完全做好，然后根据这一层的样式逐层开发的开发模式。（如下图所示）

用便于国人理解的方式来说就是，《原神》先把蒙德做出来，再去做璃月、稻妻这样的形式。

而“框架开发”则是先想象整个塔大致的样子，制订开发指南，然后组建塔的骨架，接着加上墙壁和屋顶，最后完善装饰的开发方式。（如下图所示）

这种开发方式的代表自然是《塞尔达传说：荒野之息》，在同期的其他任天堂演讲中，任天堂员工介绍了在正式开始制作之前，先制作了一个2D版本的原形来测试玩法的可行性，这种先做原形的流程，其实就是框架开发的体现。

这两种开发方式并没有好坏之分，而是要根据开发的游戏类型来选择。那么对于本次的《塞尔达传说：荒野之息》，哪一种方式更为适合呢？

根据曾经参与制作过多款塞尔达作品的尾山先生表示，《风之笛》等游戏基本上都采用了“堆叠开发”。团队会先制作出一个作为模板的关卡，然后再通过调整设计的方式制作出其余的关卡。

比如《塞尔达传说：时之笛》以大型迷宫的设计著称，森林神殿、火之神殿、水之神殿、暗之神殿、魂之神殿等迷宫，都是以一个迷宫模板为基础，不断修改完善，以堆叠开发的形式制作出来。

能这样开发的原因在于，《时之笛》的迷宫有明确的限定区域和阶段，国内游戏人可以理解为《时之笛》的迷宫为必须按照顺序游玩的副本。

但是尾山也表示，在充满各种怪物、素材、地下城等元素相互关联的开放世界《塞尔达传说：荒野之息》中，并不存在明确区分限定区域的关卡或阶段之类的东西。因此，必须一开始就做好整个世界，这就不可避免地导致了采用“框架开发”。

堆叠开发和框架开发的主要区别在于原型制作阶段。

堆叠开发的原型是一个关卡或者一个任务，用于验证游戏的游戏性，而框架开发的原型是整个玩法框架，问题在于如何构建项目路线图。

对于堆叠开发，如果确定整体需要5个阶段，那么每个阶段就会有一个里程碑。

然而，像开发开放世界这样的框架开发并没有一开始就存在这样的里程碑。

因此，《荒野之息》在从框架阶段的原型到素材量产，以及它们的修补完善的过程中逐步设立了里程碑。

具体来说，在原型阶段，素材是没有多余细节描绘的粗糙模型（比如下图最左边的方块野猪）。然后，这些素材会逐渐完善，与最终版本越来越接近。

重要的是，构成玩法的元素从初始阶段就被包含在内，随着开发的进行逐渐被展现出来。在这次演讲中被称为“无缝制作流程”。

框架开发的优势，与混合开发

这里笔者为大家讲解一下，其实从前面的“五重塔”图片对比（一个歪歪扭扭，一个方方正正）就可以看出，任天堂开发团队比较偏好“框架开发”。

这种偏好的一个主要原因是：任天堂在开发《塞尔达传说：风之杖》等游戏采用堆叠开发，就遇到了后期内容不足头重脚轻的烂尾问题，这个问题是任天堂极力要避免的。

当然，服务型的网游（含手游）与买断制的单机游戏不同，堆叠开发与持续运营、不断更新的网游的确比较契合，对此笔者的看法是：整个游戏的底层玩法还是要坚持框架开发，但是在大世界的制作上可以采用堆叠开发，也就是混合开发。

主要分为以下阶段：

①

首先，在正式开发前，就先通过讨论、试做原型等形式决定底层玩法，把游戏框架确定下来。

比如《原神》最开始是计划做类似塞尔达的深度环境互动，但后来点到为止，其实这些底层玩法的设计，如果能在早期就确定是能减少工作量和返工的。

②

其次，确定好框架后，按堆叠开发的形式去做开放世界，然后结合剧情分阶段开放。

比如在《荒野之息》中，存在大量限制玩家行动的“墙壁”，由这些墙壁分割的地区可以采用堆叠开发，并通过更新和大型任务分批次提供给玩家。

这里结合笔者的《论《塞尔达传说：荒野之息》在开放世界限制玩家行动的手段》一文抛砖引玉说明：《荒野之息》中水神兽所在的佐拉地区因持续大雨岩壁湿滑，玩家无法通过攀岩的形式越过山峰，这样就形成了天然的区域界限。

（下图红线为因大雨造成的区域界限）

那么在制作开放世界服务型网游时，可以这样设计：持续大雨的山谷，山谷外是未开发的开放世界，阶段性的世界任务是打败造成持续大雨的BOSS。在山谷外的开放世界做好后开放击败BOSS的任务，BOSS死后雨停，玩家就可以翻越山峰探索外部的开放世界。

以上的设计就不会给人很强的“没做完”感觉，而是通过剧情将因堆叠开发造成的“不完整的开放世界”合理化。

不过，目前国内公司以“堆叠开发”为主的原因在于：部分领导通常希望快速看到成品产出，误以为前期长时间的分析、研究、讨论和试做是“磨洋工”，很难接受“框架开发”理念，但这样也导致很容易出现“返工”。

三个开发阶段

接下来，将根据具体的里程碑来说明冈村先生的《荒野之息》的开发流程。

相比堆叠开发，框架开发一开始就准备好了所有的元素，在此基础上不断去修补完善。

因此里程碑设计了三个阶段，是像赛车比赛一样设定了第一圈、第二圈、第三圈等，也就是本文开头提到的三次迭代。

《荒野之息》将游戏的开发流程分成三个阶段分别进行，为了避免在每个阶段出现不必要的工作，禁止了一些工作内容。

比如，第一阶段中，除了实现游戏的核心乐趣之外的所有工作都是禁止的；第二阶段，只允许制作角色和环境素材，不允许美化和完善。

其流程的代表就是前面图片的这三头猪，第一阶段只准做这种方块猪来验证玩法的可行性，第二阶段做出猪的大致模型，完善其他动物，第三阶段才是对这头猪进行细化调整。

以下将详细说明每一阶段的工作。

耗时最长的第一阶段

第一阶段是最长的一个阶段，《荒野之息》开发的四年来，超过一半的时间都是花在这第一阶段上，耗时一年半时间。

第一阶段注重于游戏的本质，即玩家与海拉尔世界诸多元素（环境、元素、物理、敌人、生物等）互动产生的玩法。

当然，这是对《荒野之息》是这样，其他开放世界游戏不一定是这样，例如《艾尔登法环》则是魂Like的战斗。

因此，为了降低不必要的工作量和提高效率，所有角色等都需要重复使用以前作品的模型或者临时模型。

下图是一张开发示意图，蓝色的“過”代表过去的模型，“仮”代表临时模型，先用这些模型把游戏的玩法、剧情做出来。

成品中的格鲁德公主，在第一阶段使用了以前作品《风之杖》的大小姐模型，其他怪物等也通过不同颜色的哥布林来区分。

总之，从这个阶段开始，就准备好包含制作人员名单的所有游戏内容，便于确认游戏的玩家体验是否良好。在此阶段进行验证，可以尽早地对不合适的方向进行修正。

这里给大家举个例子，《赛博朋克2077》在早期demo演示时有螳螂刀爬墙玩法和地铁系统，但是后来都删掉了，其实就是早期没验证玩法和系统的可能性。

另一方面，在重复利用以往模型资源和使用临时资源的过程中，那些负责制作实际模型的艺术家们在做什么呢？

其实在这一阶段，他们并没有直接参与实际的游戏开发，看起来似乎“什么也没做”。

但笔者重申，他们并不是在摸鱼，其实这一阶段还没有到他们出场进行实际工作的阶段。

实际上，他们在构思游戏的美术风格和游戏氛围，并参加培训学习如何使用新技术辅助开发（作者注：这里应该是指Zelda Editor）。

此外，他们还研究了如何表现出偏卡通的美术风格（作者注：指泷泽智演讲中提到便于“欺骗”玩家的风格）和金属感，并研究了量产资产所需的工作流程，以及种族设定等世界观的内容。

工作流程可见下面的图片，有点儿模糊，笔者尝试分析一下，不一定准确，但总比没有好，大家觉得我说错的也可以留言提出来。

上面从左第一张图片，应该是林克在不同地形下的错误（NG）姿势；中间那张图应该是林克建模的碰撞模型或建模，用于制作不同姿势时的碰撞模型或建模；最右边是符合要求的游戏资源与NG游戏资源的对比；右下则是为了保持风格统一的图标、元素的基础设定。

使用任务管理工具填充框架

在第二阶段中，主要任务是把临时模型素材替换为正式模型。

示意图如下，注意之前的字都变成了“正”。

实际替换后的游戏画面非常接近最终成品，但纹理和NPC动画仍存在一些粗糙之处。如何打磨这些内容变得非常重要，而关键则是任务管理。

下图为演讲时的宣传图，笔者猜测这里可能是视频，展示NPC纹理和动作还没有做好。

任务管理在游戏开发以及项目管理中都非常重要，任务简单地说就是要求完成的工作，通常使用专门的工具进行管理。

具体来说，是发布一系列包含任务内容、需求发起者、开发者和预估工作量等信息的任务。

然而，传统的任务管理工具存在一些“问题任务”的问题，例如任务执行对象不明确、找不到要修正的数据位置、或者任务说明含糊等问题。通常情况下，为避免这些问题的产生，每个发起者都需要注意任务书写格式，或者让项目经理对任务进行审查和盘点。

任天堂采取的解决方案则更为大胆，他们为Zelda Editor添加了专用的任务管理功能，将任务管理工具与开发工具结合在一起。

与通常的任务管理工具不同，这个任务管理工具将所有任务像“便签”一样贴在数据上。例如，如果哥布林模型有问题，就将任务贴在该模型的数据上，写着“请修复模型”。可以将其想象为在游戏内的所有数据上直接贴上“便签”并指示工作的感觉。

下图是任务管理工具的图示，在游戏中场景上做出气泡提示，看内容应该是需求方希望在敌人据点附近加入“蜂巢”的需求。

结果是，开发人员可以直接访问要处理的数据，消除了不确定性，并且任务的颗粒度也更细致。

此外，每个数据中都包含制作者的历史记录，因此也能自动确定下一流程的开发者。这种类似“便签”的任务可以贴在模型、着色器、AI、游戏内场景坐标等所有地方。

使用任务管理工具进行素材批量生产和错误修复

接下来讲讲设计师如何利用这个任务管理工具进行素材量产。

如先前所述，在《荒野之息》开发的早期阶段，游戏内的资源是使用旧作品资源或临时资源。

在这个阶段，设计师为10种武器制作了临时的剑资源，并仅更改颜色以做区分。

然后，然后，他们会将“Sword_1是剑，Sword_2是棍棒，Sword_3是斧头”等任务附加到“请制作士兵的剑模型”的数据上。

这样，使用任务管理工具就可以机械地批量下达任务。同时，通过将任务与数据相关联，通过汇总任务可以实现精确且简便的进度管理。

冈村展示了一张进度管理表格，左侧是各种武器，右侧看不太清，笔者猜测分为这样四栏：

概念图下属的状态和天数，状态都是已确认，天数是0。

模型制作的状态和天数，状态有新任务、制作中和完成，给的排期是4天。

完善细节的状态和天数，状态跟模型一样，排期三天。

最终成品的状态和天数，排期总共是7天。

通过这样的任务管理，项目在不偏离预期太多的时间下完成了，下面是开发日程管理图，横轴为日期，纵轴应该是需要制作的模型数，左侧的纵坐标大幅提升可能是基础泛用模型制作后延伸出的细分模型。

比如先做出单手剑等基础泛用模型，再去做寒冰剑和火焰剑，这样图表上的工作量才会大幅提升。

实际上，通过任务管理工具的数据可以看出，任务数量呈现出一个漂亮的下降曲线，并且从这里也可以对整个项目的进度进行估算。

由于任务与数据相关联，因此不会出现重复任务或模糊任务。

当所有模型都已确定后，游戏正式开始制作模型，前期经过实际制作预估出必要的工作时间，以此推测最终完成所有任务需要的时间。

第二阶段开发了预计1年多一点儿，最终只比计划多15天时间，可以看出“时间管理大师”任天堂的强大。

完善品质和修复BUG的第三阶段

在最后的第三阶段中，所有资源都需要达到成品的质量。

具体来说，主要是为了提升品质寻找并修复BUG，修复也使用了上述的任务管理工具。

比如下图这样，对BUG进行分级，并显示进度。

而且，不仅可以从Zelda Editor中添加BUG报告，还可以在测试玩游戏时，从游戏内添加BUG报告。例如，如果存在比例感不正确的蘑菇，则可以选择该蘑菇并将BUG报告作为便签附在上面。

此外，由于任务管理工具支持游戏运行的脚本引擎，因此可以直接在BUG报告栏中编写脚本，以便立即使用修改后的脚本执行，这样修改BUG和测试可以无缝切换。

另一方面，设计师在第三阶段的目标是尽可能检查资源，并进行美化工作以提高质量。

与第二阶段一样，确认工作也由领导者进行统一下达指令，例如模型或纹理大小等在工作表中进行检查，而其他模型的诸如燃烧、浮力、水流等则在测试机上进行检查。

设计师在任务管理工具中进行模型确认和美化工作，因为访问数据更容易且信息集中在一起，所以效率会大大提高。结果是他们能够将更多精力放在创造性的工作上。

大规模开发也始终将游戏视为一体

以上是实现《塞尔达传说：荒野之息》多样化角色和场景的三个阶段。

其中，第一阶段持续了一年半，而第二和第三阶段则在一年左右。由于任天堂一开始并没有开放世界的技术知识，所以一开始的阶段花费了最长的时间，但是量产阶段的进度则相对比较稳定。

虽然开发流程应该尽可能地与游戏系列风格相匹配（作者注：指系列过去按照堆叠开发），但像本次召集大量员工，基于框架制作独立的编辑器和任务管理工具的开发模式，也是一次非常有趣的尝试。

下图展示的是其中一个模块的开发流程：

由于没有相关新闻没有解释，笔者分析认为这幅图的内容可能是：主角在前期遇见的第一个敌人“波克布林”，其包括“敌人模型”、“敌人AI”的数据，对此进行任务管理和开发。

在“敌人模型”、“敌人AI”的基础上，生成“波克布林”的角色和动作，把它放到demo场景中测试，最终放到游戏里由程序员编写脚本。

结语

本编辑器每5分钟会自动创建一次开发版ROM以进行游戏测试，这表明任天堂非常注重游戏游玩和游戏开发的循环。

尽管开放世界游戏开发并不罕见，任天堂也并非在开放世界开发上积累了很多经验，但这种工业化的开发流程仍有很大的学习空间。