【了解、创造、连接：《塞尔达传说：王国之泪》中重构的开发环境和声音制作实例】【CEDEC2024】
2024年8月21日（星期三）至23日（星期五）期间，日本最大的计算机娱乐开发者会议「CEDEC2024（Computer Entertainment Developers Conference 2024）」举行。在第三天的会议上，进行了「《塞尔达传说：王国之泪》中重构的开发环境和音效制作案例」的讲座。
在本次讲座中，任天堂株式会社企划制作部《王国之泪》（以下简称《塞尔达传说：王国之泪》）开发团队的编程负责人冈村祐一郎、音效编程负责人长田润也、游戏工具开发负责人日高祥藏登台演讲。
图中左起：岡村祐一郎、日髙祥蔵、長田潤也
在《王国之泪》中，即使是与前作《塞尔达传说：旷野之息》（以下简称《旷野之息》）外观相同的敌人角色，其背景开发环境也完全不同。在本次讲座中，相关开发者们讲解了《王国之泪》中开发环境的重构过程，以及该开发环境在实际中的应用，特别是从音效团队的视角介绍了应用案例。
开发数据成为资料的「动态规格书」
在《塞尔达传说》系列的过去作品中，游戏开发规模较小，每个敌人角色涉及的开发人员数量也很少。因此，团队成员之间的沟通会更加顺畅，他们每天都会面对面进行交流，在制作的同时集思广益、提出创意并进行制作。
到了《旷野之息》时代，随着游戏机的发展和进化，需要更高级、更复杂的行为表现，技术也更加细分。为了在这种环境下继续制造优质的产品，分工变得更加明确，通过领导者管理团队的垂直结构在现代开发环境中变得更加普遍。
尽管存在这种趋势，任天堂开发团队还是探索了与之不同的方向。团队中的每个人都会思考游戏的设计，并致力于以允许进行反复试错的扁平化方式创建产品。《王国之泪》的目标是「一个扁平化的制作流程，让团队中的每个人都思考游戏、提出自己的创意，并致力于在反复的试错过程中创建优质的产品」。领导者当然依旧是不可或缺的，但冈村祐一郎认为，无论艺术家的工作如何，这种扁平化结构让每个人都能更容易地想出好创意，例如艺术家也能够思考战斗的平衡并添加自己的动作。
这种思维方式在音效团队中也得到了应用。在音效制作中，音效团队不仅仅是根据视觉效果播放声音，还能够积极提出与游戏体验相关的演出建议。
《塞尔达传说》系列实现了许多以「声音」为主题的游戏玩法和机制。音效团队、游戏设计师和艺术家一起协同工作，创造出了各种独特的演出和游戏玩法。
长田润也在讲座上展示了《旷野之息》中哈特诺村的基础昼夜BGM的转换图。 白天⟷夜晚实际上有两种变化模式（反之亦然），并且它们在乐曲的前半部分和后半部分走向了不同的模式。 长田润也同时展示了张《旷野之息》和《王国之泪》普通战斗BGM的转换图，可以看出关键的变化分为几个级别：随机转换、取决于强度的条件转换...（后面的图看不清楚，不过里面有白天和黑夜的描述，不知道是不是城下町BGM）
■じーくどらむす/岩本翔@geekdrums https://x.com/geekdrums/status/1826822683268710780
为了让音效团队能够主动行动，「了解」（「知る」），也就是信息收集非常重要。然而，仅仅通过试玩正在开发中的游戏很难掌握详细的规格细节，有时甚至很难直接联系到负责人。而且规格书等开发资料的信息量过于庞大而又复杂，同时相关资料可能会由于发生错误或规格变更而与实际行为产生不同。
这种「了解」信息的重要性在所有部门中都是共通的。最容易查看的是规格书等文档，但正如前面所提到的，随着开发的进行，规格书的内容可能会与实际游戏内容脱节。特别是在扁平化的开发环境中，由于游戏内容会不断发生变化，这个问题就变得更加突出。
因此，《旷野之息》开发团队采取了一种形式，将规格书中应描述的「概要」和「具体行为和参数」之间，后者应该包含在基于规格书制作的数据和程序中。规格书中不再写具体实施方针，而是通过数据来实现这些方针。
于是规格书的规模缩小了，即使随着开发的进展，概要大纲部分也很少再与游戏内容脱节，从而缓解了规格书与开发之间的差距和隔阂。结果，数据可以实现更多功能，而程序所占的比例却减少了。由此，数据驱动的体系得以逐渐形成（基于数据进行各种判断和决策的体系）。
当规格书的规模缩小后，在「了解」层面的信息源相关作用减弱。而这可以通过数据来进行补充。例如可以通过表格和图表等各种方式可视化数据，或者通过应用程序直接查看数据。
通过这些可视化信息和实际游玩中的体验，可以了解游戏的最新信息。开发团队将此称之为「动态规格书」。然而，这并不是否定传统规格书在思考整理和交流传达中的实用性。只是因为当开发团队需要了解和获取游戏开发中的最新信息时，「动态规格书」的方式更为合适。
那么，这种「动态规格书」方案在《王国之泪》中是如何进行应用的呢？《王国之泪》包含了前所未有的复杂程度，例如「究极手」可以举起和连接各种物体，「余料建造」可以将其它物体附加到武器上用来创造新武器。此外，由于场景结构变得更加立体化，世界变得更庞大，物体的数量也随之增加。
为了适应这种规模，数据驱动和「动态规格书」也得到了扩展。作为其中的一部分，音效团队还利用了独特的自研BGM控制工具「BGMEditor」。
根据游戏情境和内容改变音乐的「互动音乐」现在已经非常普遍，但相关内容的实现还需要进行定义。例如，为了实现昼夜音乐变化的条件，有必要定义一天应该在什么时间开始或结束：何时为昼，何时为夜？
当为每种情况实现音乐的细致变化时，传统上是由音效作曲家绘制图表，并请求程序员实现。然而，通过这款BGMEditor，作曲家绘制的图表可以直接作为音效运行。于是，作曲家可以更轻松地对变化条件创建详细的定义，更方便进行反复试验，从而创建出演出更加自然的作品。
数据驱动技术在在其它领域也取得了进展。在各角色行为规格的实现过程中，为每个阶段都引入可视化编程工具来可视化算法。这样做对于整个团队的好处是，即使不是实现者本人也能更容易地获取信息，并且在其它领域也能进行试验，从而使分工更加容易，团队整体因此受益。
虽然以上介绍了两个工具的例子，但任天堂一直以来都有独特的工具实现形式，而且已经持续了很长时间。与常用的集成游戏引擎不同，任天堂的每个工具并不是在通用框架上实现的，而是独立创建和进行开发，并能够使用不同的编程语言和技术进行调用，这种形式被称为「组件类型」。例如在《旷野之息》中，每个部分就都使用了不同的编程语言和技术进行开发。
在这种形式中，每个工具都被视为一个组件，每个项目都能够选择必要的工具进行开发。虽然组件型工具比集成型工具更传统，但它的优点是高度灵活，能够适应各种各样的游戏设计。每个人的想法都很容易能被提出，因为任何人都可以构思并创造一款工具。而易于引入新技术也具有积累专业知识和提高技能的优势。
例如，在《健身环大冒险》开发过程中创建的日志工具也被用于其它游戏。
这种组件类型与任天堂多种多样的硬件高度兼容，使得在游戏项目中更容易产生独特的工具和想法，并且更容易应用新技术。然而，组件型工具之间的协作性比集成型工具更弱。
为了让一款工具充分发挥作用，可能需要分析来自其它工具的信息。此外，为了从整体上理解游戏，还有必要了解在跨越多个工具中所使用的数据之间的联系。
例如，如果想在音效工具中引入下拉选择功能，也必须单独分析模型数据来显示选项。考虑到时间、精力等开发成本，只能选择文本输入的形式。
此外，游戏的「结构」难以理解也是一个缺点。不同工具创建的数据之间是有联系的，例如角色会保留模型，而这些模型会与演示、关卡等领域相关联。要理解游戏的结构，就必须了解所有这些相关工具。虽然数据驱动技术使得从单个工具中获取信息变得更加容易，但开发团队真正追求的「了解」并没有实现。
在追求扁平化制作的过程中，「了解」变得更加困难，开发团队迎来了规格愈加复杂化的转折点，《王国之泪》开发团队无法再忽视组件类型的问题。
虽然也考虑过基于前作《旷野之息》的开发环境，但由于《旷野之息》优先考虑了实现速度，缺乏可扩展性，对于系统的整理并不充分，很多部分没有组织好。而《王国之泪》中的游戏内容比前作更加复杂，素材量也有所增加。
因此，开发团队这次决定重构开发环境，随后创建了诸如存放在开发人员 PC 工作环境上的数据库工具「LocalDB」、管理数据版本的工具「GlobalDB」以及可视化数据连接的工具「Project Portal」等等。
使用数据库来协作不同工具和个人
创建新开发环境的两个工具
「LocalDB」旨在解决常规环境中工具之间协作性弱的问题。
为了实现新的开发环境，团队首先分析了工具间进行协作的弱点。在尝试读取其它工具的文件时，单独实现这些工作以及进行解析都需要时间，这些都是问题。
因此，团队设想了一种通用解决方案，即准备一个基础数据库作为通用平台，相关工具能够通过数据库访问文件信息。
日高祥藏将其便利性归纳到了三点。
可与任何工具一起使用的访问方法
开发团队采用关系数据库（※），构建了可以使用「SQL」（结构化查询语言）访问的数据库。由于SQL可以在各种程序中使用，因此它建立了所有工具的通用基础。
※关系数据库（Relational database）：以行和列的表格形式存储数据的数据库。可以处理每行、每列的公共数据，并关联多个表进行数据处理。
谁来将数据写入数据库
音效工具的开发者不一定熟悉3D模型工具的格式。因此，数据信息应该由最熟悉该文件的开发者写入数据库。
在这过程中，特定开发人员的工作量确实有所增加，但由于数据库是一个通用平台，即使有多个工具想要处理特定数据（如音效、3D模型等），也无需为每个工具都提供支持，从而减少了整体的负载。
数据库中包含了什么信息
然而，即使对于那些最熟悉文件内容的人来说，也无法预测其它工具在试验过程中会需要什么数据。此外，单独答复每个请求项目将会产生很大的负担，这是不现实的。考虑到响应需求的工作量，理想状态是从一开始就包含尽可能多的数据。
除了数据特别大或者难以处理的情况外，开发团队甚至还对源代码进行了分析和发布。
因此，「LocalDB」采取了加载尽可能多的数据的策略。例如，对于 3D 模型文件，可以处理的项目越多（例如顶点数、骨骼名称和父骨骼名称、材质名称和着色器等），开发人员就越容易进行反复试错。
在思考创意时，开发者们事先并不知道需要修改哪些项目，但如果能够拥有尽可能多的数据，就能迅速应对突发奇想。
因此，需要上传的数据包括构成游戏的各种文件，其中所包含的数据从3D模型、纹理、关卡、事件、角色、特效、动画、参数、背景音乐等构成游戏的文件，到制作这些文件的Maya的.ma、Photoshop的.psd、程序的源代码等各种类型（但像顶点流这样的大数据除外）。
于是数据库的建设得到逐步推进，但此时出现了新的问题：数据库应该存放在哪里？
通常情况下，数据库会存放在服务器上并从个人的 PC 工作环境进行访问。然而，要处理的文件位于个人电脑上，每个人都能根据自己的想法进行开发和修改。
即使要处理的文件相同，但是每个人所做的工作也会有差异，而当这种情况发生时，每个人所做的更改都会在服务器上发生冲突，从而在游戏开发中经常导致诸如「同一个文件有多个版本，但哪个版本是正确的？」等各种问题。
此外，当开发者通过服务器上的通用数据库访问时，可能会在编辑公共数据库时含有尚未更新的文件。
日髙祥蔵说，此时有必要改变思维。开发团队的想法是，如果每个人都需要进行开发，那么为了解决每个开发者都编写程序所造成的信息冲突问题，最好能让每个开发者都拥有自己的数据库，从而让数据库能够本地存放在每个人的 PC 工作环境上。由于是本地数据库，所以称之为「LocalDB」。
虽然是本地数据库，但每个人的数据库都是相互链接的。相关工具也能通过数据库相互通信。例如，如果在 Maya 中编辑角色模型并更改骨骼名称，则使用该骨骼名称的其它工具中的数据也将被重写为新名称。 然后，如果其他开发人员对该文件进行更改并使用版本控制系统，这些更改将反映在本人的文件中。无论谁的版本才是正确的，最新的更改都会反映在每个人身上。这样可以避免混入其他开发者的数据，通过版本更新可以轻松获取最新数据。
但「LocalDB」也有问题。为了减少磁盘容量和数据获取时间，各开发者避免了不必要的文件以提高速度。因此，开发者无法处理不属于本人的文件，因为它们对于其它分工来说不是必需的。
但是这会导致试验过程中无法引用某些需要的数据。为了解决「LocalDB」的问题，开发团队决定在服务器上准备一个全局数据库「GlobalDB」来管理文件版本。
这个「GlobalDB」与「LocalDB」格式相同，包含最新更新数据。如果开发者想使用「LocalDB」中没有的文件信息，可以引用「GlobalDB」并将其写入「LocalDB」，使得仅通过「LocalDB」就能获取所有信息。
前面提到的下拉选择UI，随着集成度的加强，也被引入到了各种工具中。
「GlobalDB」和「LocalDB」解决了工具之间协作性差的问题。
通过增加工具间的协作功能，也解决了「游戏结构难以理解」的问题。由于「LocalDB」包含了所有信息，如果能将其很好地进行可视化，就能更容易理解它的结构。
既然如此，开发团队要做的就是对信息进行适当的裁剪。对用于追踪各文件所引用的文件而言，其规模过于庞大，无法从整体上查看，因此只能部分查看。为此，开发团队考虑了选择数据类型、数据筛选、追踪连接的三步方法。而为此创建的可视化工具即是「ProjectPortal」。
在「ProjectPortal」工具中，首先在「选择类型」阶段以标签形式整理和显示数据。为了进一步缩小搜索范围，接下来就可以通过选择要搜索的数据类型来缩小搜索范围，并按每条数据所附加的名称或标签进行搜索。
例如，如果需要搜索「大师之剑」，那么不仅可以列出大师之剑，还可以列出剑鞘和底座等相关物品；如果需要搜索可以被闪电击中的武器，就可以使用标签「金属制」缩小搜索范围。
至于可以上传到「LocalDB」的文件类型，这些类型越多样化，就越容易容纳每个人的创造力。
对于这些标签，需要准确地附加到庞大的数据上，并且每次规格更改时都需要重新附加。于是开发者希望能够根据各种条件缩小搜索范围，以此来努力营造有利于创造的环境。
包括「前作中的武器」、「宝箱中的武器」、「带有弓箭的敌人」、「遇到敌人的NPC」和「出现在寺庙中的位置」等在内的标签详细且多样，手动标注存在局限性。因此，「Project Portal」允许开发者在进行SQL查询时，以与标签相同的方式处理参与者（游戏中出现的物体对象）的参数。
这些就是开发团队所引入的「Project Portal」中的「查询标签」。「查询标签」是一种临时标签，通过将它们与标签组合，开发者就能够在复杂条件下缩小搜索范围。
组件（Actor）的性质被描述为数据中的参数。例如，如果组件是「可燃」的，则设置参数「burn」；如果组件是「盾牌」，则设置参数「shield」等等。当满足「可燃」或「盾牌」等条件时，根据进行SQL查询时所引用的数据参数，从而出现在「查询标签」的搜索中。
因此开发者就可以将相关参数视为标签，并使用 SQL 对这些数据进行查询。这样就无需手动标记参数中描述的属性，也省去了手动添加标签的工作。
在最后的「追踪连接」过程中，分别为正向追踪和逆向追踪准备了不同的UI。前者可以用一般的树形结构表示，因此采用了树形UI；后者由于树形结构在视觉上显得太过复杂，因此按数据类型汇总并以列表形式显示。
为了更充分地理解游戏结构，开发团队创建了一个函数来查看数据之间的连接（引用关系）。如果想要顺着参考关系箭头向前走（事件→组件→模型设置），可以使用树形结构。但如果与参考关系反方向时（模型设置→组件→事件）也使用树形结构，就会因为出现重复数据显示而带来不便。因此，开发团队设计了一种在反方向参考时显示列表的机制。
对于各种组件、物理设置和 3D 模型等没有直接联系的离散数据，通过结合「LocalDB」表中的各种信息可以跟踪每份数据之间的联系，获取必要的信息，并将其汇总和列出。 例如，原本写在单独文件中的信息，比如宝箱的位置、进入的组件、组件的售价等，现在都被处理成了表格，同时还包含一个能够跳转到相应位置的按钮。 另外，以波克布林而例，如果组件表中包含名称和标签等信息、3D模型表中包含名称和边界等信息、物理设置表中包含质量等信息，则可以使用SQL添加编写名称、生成缩略图、模型边界、质量列表、数据调试按钮等功能，以方便开发者查看相关数据和进行试验。 通常情况下，开发者必须自己参考每条数据并了解其中的联系，但「Project Portal」将其处理为列表，甚至提供了即时参考数据的按钮。 这个机制不仅适用于单个工具，还意图在所有工具中通用，通过在设置文件中编写SQL和列的处理方法，就可以批量生成「资源表」。与手工管理的电子表格工具相比，自动化工具减少了对拼写表述错误的担忧，并且可以随时参考最新状态的游戏结构。
通过「LocalDB」和「Project Portal」实现音效开发工作的创新
在讲座中，长田润也还从音响团队的角度继续介绍了「LocalDB」和「Project Portal」在音效团队中的实际应用案例。
尽管声音团队的工作往往处于开发流程的后期，但长田润也表示，他希望从早期阶段就积极主动地参与制作。为此，准确的信息收集和高效的制作工作流程至关重要。
通过「LocalDB」和「Project Portal」，就可以在播放声音的同时播放动画，还可以直接跳转到编辑动画数据的相关工具。当其他开发者对动画数据进行更改时，相关声音的负责人就会得到通知，提高了工作效率。
如上所述，声音团队使用的内部工具「BGMEditor」是一款数据驱动工具，可以定义每个组件应该发出什么声音、如何发出声音、何时发出声音等条件。它还能定义当物体的移动速度超过一定值时、其与动画结合所发出的声音等等。
这里最重要的是，这些定义仅在声音工具上进行，而不需要更改其它部分的数据。即使在后期处理中，也可以在时间允许的情况下反复调整。
《王国之泪》声源距离与音量衰减（多普勒效应）的模拟（2023年）专利号：JP2023098724A
《王国之泪》声源距离与音量衰减（多普勒效应）的模拟（2023年）专利号：JP2023098724A
使用「BGMEditor」工具可以完成播放组件动画、检查和确认声音等工作。借助「LocalDB」和SQL的帮助，可以通过下拉形式选择想要绑定声音的动画数据，这也有助于提高效率。开发者不仅可以从「LocalDB」中请求动画列表，还可以通过编写SQL，来追踪与该组件绑定的相关动画和声音。
开发者还可以通过参考数据连接，直接从声音工具跳转到管理和编辑动画数据的工具。在动画工具上，通过节点配置使数据更加易于查看，甚至可以通过条件设置将复杂结构的数据进行可视化。
这样的开发环境可以轻松处理后期流程中出现的因内容变更而需要修改和重新审查的问题。反过来，通过从动画数据中追踪声音，就能够搜索需要修改的区域，同时还能够实现一个跟踪负责人、检测内容更改并通知相关负责人的系统。这种即时跳转到每个工具的能力非常方便，而且由于源代码也存储在「LocalDB」中，开发者甚至还可以直接跳转到代码编辑器。
Bilibili @Posyol
接下来，长田润也介绍了在「格鲁德城防卫战」中，事件控制工具「Project Portal」和声音工具「BGMEditor」协作的具体使用案例。由于该事件在故事中也是重要场景，因此作曲家考虑了根据战斗情况变化音乐的专用演出。
通过「Project Portal」可以了解到活动规格的详细信息，开发团队创建了能够在战斗期间按照音乐节奏进行乐曲过渡的演出，并且每次吉波得（ギブド）的巢穴被破坏时都会改变旋律。
《王国之泪》中的武器具有复杂的规格，每次使用「余料建造」附加材料或其它武器时，SE都会发生变化，但「Project Portal」在这里也很有用。
然而，仅通过查看「余料建造」的构建参数，还是很难全面了解项目的构成。但如果使用「Project Portal」中为游戏设计师提供的视图来调整参数，则可以轻松调整规格、更全面地了解项目。 在某些情况下，使用「余料建造」将材料粘合在一起之前和之后的声音都是相同的，但使
「Project Portal」很容易判断这是有意为之还是设置错误。
长田润也高度赞扬了「Project Portal」的有效性，表示它就像一个可以收集高度可靠信息的基础设施，能够让开发者们安心地进行创造。
这种互动式音乐的变化，通过使用「BGMEditor」等工具变得容易实现。更细致地说，演出的时机与音乐相匹配的时刻，或是在游戏结束前音乐停止的时刻等，都可以毫不妥协地创建细节。
为此，作曲家需要在详细了解事件场景的同时创作音乐。除了听取意见外，使用「ProjectPortal」还可以参考BGM所涉及的事件信息，以及相关的组件和效果等数据。作曲者亲自将各种节点配置在事件管理工具中，并进行精心的编辑。例如为了避免在演出中听到多余的声音，而关闭不需要的相关组件等等。
《王国之泪》的特色系统「余料建造」也同样利用了新的开发环境。在本作中，音效被定义为武器本身的个体特征，但音效团队也希望各种音效能够匹配余料建造的构建变化。
由于余料建造的组合过于庞大，音效团队制定了音效变化的规则来做出回应。尽管如此，如果不了解余料建造的整体情况，由于余料建造的参数数据非常复杂，开发者也很难做出相应的调整。
这时，「ProjectPortal」就派上了用场。通过使用资源表功能，将「LocalDB」的数据整合成易于读取的形式，从而可以更轻松地从鸟瞰视图中检查能够执行余料建造的相关组件信息。
这种鸟瞰视图的功能，原本是游戏设计师和艺术家用于参数调整的，但音效开发者也可以利用它来了解相关项目的规格。换句话说，对于后期流程的工作人员来说，这是一种「规格书」信息源。
在音效调试时，也出现过类似的情况。例如，在使用了余料建造能力后，相关武器的音效没有发生变化。如果有资料说明「此处故意使用相同的声音」，那倒也没有问题，但这种资料并不存在。虽然可以通过音效工具参考具体的音效规则，但这并不意味着除了负责人之外的任何人都可以随意使用该工具。
这种情况也可以通过「ProjectPortal」的资源表功能解决。将音效工具的信息整合成易于查看的形式，就可以在调试阶段作为方便进行检查的规格书使用。对于项目负责人来说，也有助于从不同的角度理解相关数据。
于是，对于后期开发流程的工作人员来说，日常使用的工具就可以直接作为规格书使用。尽管数据会随着优化和设置更改而产生变化，但有了符合目的而又易于查看的视图功能，开发者能够更加容易地理解数据、发现错误。
这些经过检查和确认的结果会反馈到工具上，从而进一步提高数据的可靠性。数据驱动工具作为「动态规格书」参考也具备了足够的可靠性。这一机制离不开任天堂自研的「LocalDB」和「ProjectPortal」数据库工具。
「动态规格书」的实绩与通用性
在讲座的最后，冈村祐一郎总结了《王国之泪》的开发环境，通过将「LocalDB」作为基础加入组件型工具的开发流程，解决了工具间协作的问题。
此外，通过在「ProjectPortal」中查看「LocalDB」的数据，开发者还可以把握游戏的整体情况。所有可见范围内的工具和游戏结构都成为了「动态规格书」，可以让开发团队掌握游戏的开发现状。
当开发者利用这种方式所确认的信息进行内容制作时，「动态规格书」能够通过「LocalDB」和「ProjectPortal」的相互连接而并不断发生变化。通过让团队的每个成员都经历这个循环，能够让开整个发团队始终可以把握准确的信息并搭建适当的设计，从而实现更加扁平化的制作体系。
后期开发流程中的音效部分，则需要相关开发者了解庞大的游戏结构。即便如此，如本次介绍的实例一样，音效团队也能够后期开发流程中顺利实现扁平化的制作。
上述的所有《王国之泪》开发环境已经在其它项目中同样得到使用。这意味着它是一个具有高度通用性的开发环境。任天堂相信这个案例可以作为各种开发环境的转折点或者新思路。
游戏开发的理想之一是，参与游戏开发的所有开发者，无论其职业岗位如何，都能够集思广益，从不同的角度提出想法，并充分发挥他们的个人创造力和独创精神，从而使游戏体验变得更好。然而，随着现代游戏开发规模的发展，这些理想变得越来越遥远。可以说，任天堂在《王国之泪》中通过创造各种提高游戏开发效率的工具来追寻着自己的理想。
近年来，随着AAA级游戏等大型游戏的碎片化分工体系的发展，开发者在开发流程的最后阶段很难掌握游戏的整体情况。而这也正是冈村祐一郎的动力：通过开发流程和制作体系的优化、高效率开发工具的协助，能够帮助开发团队在游戏开发中排除万难，做出更好的游戏。
这是个人（4gamer编辑）的猜测：冈村祐一郎之所以在这次演讲中使用「创造」一词而不是「创作」，我认为他的意思可能是因为他正在用日常生活中的创造力进行创造，而不只是把创造作为他工作的一部分。
不同的工作岗位 能够从不同的角度 观察不同的事物 并提出不同的想法。不难想象，如果人们能够以自己独特的视角和创造力参与创造游戏，那么开发现场的士气将会更加高昂。
正如冈村祐一郎本人所指出的：确实，即使在垂直结构的开发体系中，也有领导者能够顺利完成工作。而我们即使利用扁平化开发体系和各种工具来提高开发效率，也不能保证我们能够创造出比依靠垂直结构开发体系进行开发得到更好的东西。然而，《王国之泪》却让他知难而进、大胆地接受了挑战。
《王国之泪》之所以能受到全球各年龄段玩家如此高的评价，大概也正是因为这些努力终成正果。当然，这并不是每个开发团队都能立即模仿的体系。特别是在游戏开发成本日益膨胀的今天，游戏开发规模趋向长期化、复杂化的现实已经迫在眉睫，我觉得追求理想依然是一件很棒的事情。
■「知る・創る・繋ぐ『ゼルダの伝説 ティアーズ オブ ザ キングダム』で再構築した開発環境とサウンド制作事例」セッションレポート［CEDEC 2024］ https://www.4gamer.net/games/578/G057883/20240824011/
■『ゼルダの伝説 ティアキン』サウンドチームに起きた革新。開発データが資料になる“動く仕様書”で実現したフラットな物づくり【CEDEC2024】 https://www.famitsu.com/article/202408/15284 ■サウンド担当者が開発中タイトルの最新仕様を知るには？『ゼルダの伝説 ティアーズ オブ ザ キングダム』の“フラットなモノ作り”を実現した開発環境【CEDEC2024】 https://gamemakers.jp/article/2024_10_04_78954/
■【CEDEC2017】「ゼルダの伝説」で、自由度の高い「オープンエアー」の表現を支えるサウンドhttps://web.archive.org/web/20170902061521/https://game.watch.impress.co.jp/docs/news/1078827.html
■【CEDEC AWARDS 2024 フォトレポート】「桃太郎電鉄」シリーズを手掛けたさくまあきら氏が特別賞を受賞。『ゼルダの伝説 ティアーズ オブ ザ キングダム』ほか4部門の最優秀賞も発表 https://gamemakers.jp/article/2024_08_23_77146/
■開發人員訪談 : 薩爾達傳說 王國之淚｜任天堂 https://www.nintendo.com.hk/interview/totk/04.html
■GDC 2024（物理）『王国之律动：《塞尔达传说：王国之泪》物理与声音的演变 https://www.bilibili.com/read/cv33358973/
■GDC 2024（音效）『王国之律动：《塞尔达传说：王国之泪》物理与声音的演变』 https://www.bilibili.com/read/cv33383817/
■《塞尔达传说：王国之泪》相关发明专利（48份，持续更新） https://www.bilibili.com/read/cv25622313/
