给大伟哥“马上去做”打补丁：任天堂的工业化开发流程

这几天和朋友复盘大伟哥演讲的干货，聊到一个关于大伟哥“马上去做”的执行逻辑 Bug。

声明一下，这并非吹毛求疵，而是在一线实操中发现，大伟哥的理论虽然在宏观上极其正确，但在微观执行上却存在一个“定义模糊”的坑。

问题的核心在于：

• • “马上去做”的颗粒度到底该如何拆解？
• • 是指拿到灵感就直接进入开发堆人力？
• • 还是必须先在战略层面上把大方向“跑通”？

如果执行的起点错了，那“马上”往往意味着“最快速度掉坑”。

回看米哈游，他们的Project SH也曾走过“吃一堑长一智”的弯路：立项初期的战略模糊，却匹配了庞大的研发资源，最终导致耗时两年的攻坚战因逻辑无法跑通而折戟。

所幸蔡浩宇展现了极强的战略定力，敢于“壮士断腕”及时止损。虽然付出了两年的研发成本，但相比那些在沉没成本中反复拉锯、动辄蹉跎数载的其他厂商，这份果决已是难能可贵。

比如这些年暴死的那些大制作游戏，基本都是很快就进入实质开发阶段阶段，团队在核心玩法尚未通过 MVP 验证时，就急于开启流水线铺设美术资源。

结果往往是：代码堆成山了，美术风格还没定调；系统架构成型了，却发现玩家根本不买账。这种“勤奋”本质上是用战术上的勤劳掩盖战略上的懒惰。

已停运的网易《射雕》简直就是“没想清楚就马上去做”的教科书式代价。

“马上去做”中的战略懒惰

有一些“马上去做”是用战术上的勤劳掩盖战略上的懒惰。

从大的方向上看，网易《射雕》是一个典型案例。

临上线前大改系统、2.0版本近乎自杀式地推翻美术风格——这种级别的动荡，本质上就是立项时的底层逻辑“脑死亡”。

在大厂的工业化管线下，当几百号人、数亿资金“马上去做”时，如果领航员没想清楚终点在哪，这种执行力就会变成一种灾难。

这种立项时的模糊，最终会在游戏上线时酿成恶果。

这种现象并非《射雕》孤例，而是许多大厂“S级”项目的系统性顽疾。

这里从微观角度，分享一个典型的项目夭折案例：

在某头部大厂的一个自研项目中，立项初期的顶层设计始终处于动态摇摆中。由于产品定义缺乏定力，文案与美术部门在各自的垂直赛道上，基于初始版本的模糊诉求开启了高强度的并行开发。

这种“盲目加速”在首个关键里程碑暴露了致命问题：由于缺乏跨职能协同，叙事内容与视觉表现发生了严重的架构脱节。

面对巨大的资产合入风险，若要强行对齐，意味着其中一方长达数月的交付物将彻底沦为沉没成本。在考核压力与部门壁垒的博弈下，项目陷入了组织内耗。

结果项目在混乱的管理中停止开发。

不止是国内游戏公司，国外也有类似的情况，比如《真三国无双8》、《光环：无限》都是想做开放世界但没想好的典型，它们的商业表现在系列中也属于垫底级别。

反观成熟的游戏企业如任天堂，在“马上去做”之上，增加了很多细节。

“想了一年” VS “马上去做”

任天堂的研发哲学则是彻底的“玩法驱动”。在正式立项并进入工业化管线之前，他们通常会设置一段极长的“核心原型验证期”。

以《塞尔达传说：众神的三角力量2》为例，其背后的《社长谈》揭示了一个极具启发的细节：在正式开发启动前，核心团队曾经历过一段长达一年的“停滞期”，专门用于打磨核心创意。

访谈内容节选如下：四方宏昌：只剩下毛利先生、另一个程序员和我。3DS主机当时还没有面世，我们想为NDS之后的掌机做一款《塞尔达传说》，于是便用一年的时间做了很多设想。

岩田聪：就你们三个人，想了一年？这很难吧？

四方宏昌：是的。我们每天都很痛苦，一直在想要做什么。

青沼英二：我多说一句，这不代表那一年就荒废了。正是在试验阶段，我们想出了让林克变成一张画的独特玩法。

四方宏昌：是的。

青沼英二：光是想出这个主意就费了不少时间。

岩田聪：确实很艰难。

而笔者翻译整理的《任天堂的开放世界工业化流程——以塞尔达为例》一文中，也提到类似的思路。

任天堂版的“马上去做”

任天堂在正式制作《塞尔达传说：荒野之息》前，先制作了一个2D版本的原形来测试玩法的可行性。

2D版玩法可行性通过后，也没有马上堆叠游戏资产，而是采用框架开发的模式去多次迭代。

任天堂系统架构师冈村祐一郎提到，游戏制作流程大致可以分为“堆叠开发”和“框架开发”两种，他以五重塔的建筑为例解释了这两种方式。

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

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

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

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

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

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

能这样开发的原因在于，《时之笛》的迷宫有明确的限定区域和阶段，必须按照顺序游玩。

但是尾山也表示，在充满各种怪物、素材、地下城等元素相互关联的开放世界《塞尔达传说：荒野之息》中，并不存在明确区分限定区域的关卡或阶段之类的东西。

因此，必须一开始就做好整个世界，这就不可避免地导致了采用“框架开发”。

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

有所为，有所不为

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

比如，第一阶段中，除了实现游戏的核心乐趣之外的所有工作都是禁止的；

第二阶段，只允许制作角色和环境素材，不允许美化和完善。

第三阶段才开始美化和完善。

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

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

验证玩法的第一阶段

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

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

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

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

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

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

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

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

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

实际上，他们在构思游戏的美术风格和游戏氛围，并参加培训学习如何使用新技术辅助开发。

此外，他们还研究了如何表现出偏卡通的美术风格和金属感，并研究了量产资产所需的工作流程，以及种族设定等世界观的内容。

工作流程可见下面的图片。

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

填充资产的第二阶段

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

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

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

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

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

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

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

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

结果是，开发人员可以直接访问要处理的数据，消除了不确定性，并且任务的颗粒度也更细致。此外，每个数据中都包含制作者的历史记录，因此也能自动确定下一流程的开发者。这种类似“便签”的任务可以贴在模型、着色器、AI、游戏内场景坐标等所有地方。

任务管理工具进行素材批量生产

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

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

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

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

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

冈村展示了一张进度管理表格，左侧是各种武器，分为这样四栏：

• • 概念图下属的状态和天数，状态都是已确认，天数是0。
• • 模型制作的状态和天数，状态有新任务、制作中和完成，给的排期是4天。
• • 完善细节的状态和天数，状态跟模型一样，排期三天。
• • 最终成品的状态和天数，排期总共是7天。

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

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

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

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

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

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

完善打磨的第三阶段

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

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

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

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

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

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

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

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

始终将游戏视为一体

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

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

真正的“马上去做”，不应该是盲目的“马上开工”，而应该是“马上思考并验证试错”。

对于一个游戏项目来说，最危险的 Bug 就是把“执行力”等同于“生产力”。在《原神》或《崩铁》这种级别的产品逻辑里，大伟哥口中的“做”，背后必然隐藏着极其缜密的预研逻辑。

如果普通开发者只看到“快”而没看到“准”，很容易就会在错误的航道上全速冲刺，最后在资源耗尽的那一刻，才发现自己造了一艘永远无法离岸的巨轮。

所以，给大伟哥的理论打个补丁：在“马上去做”之前，必须先“马上想清”那个决定生死的一线逻辑。 如果还没想清楚该去哪，那么停下来思考，或许才是最高效的执行。