《塞尔达传说王国之泪》打造「可动的规格书」重构开发环境

让开发团队全员都深入了解游戏整体，并不论担任职务都可以提出点子的平行制作手法。为了实现这种理想，所以下定决心重新建构游戏的开发环境。在日本游戏开发者会议「CEDEC2024」最后一天，有一场以「了解、创作、连结在《萨尔达传说王国之泪》中重新建构的开发环境与音效制作案例」为题的讲座，在其中解说了任天堂开发团队实际制作的案例。

登台主讲

冈村佑一郎（任天堂企画制作部首席程式设计师）

长田润也（任天堂企画制作部音效程式设计负责人）

日高祥藏（任天堂企画制作部游戏制作工具开发负责人）

照片自左起为冈村佑一良、日高祥藏、长田润也

为了实现平行式创作手法，决定完全翻新开发环境

过去在开发游戏时，因为开发规模都比较小，所以进行决策时的节奏轻快，在沟通交流方面比很顺畅，但近年来因为游戏开发规模不断在膨胀的关系，技术的分枝数量增加，开发时的分工合作也变得更细腻。

想要在这种环境下创作游戏，通常就会采用让各个部门的领袖人物下去思考游戏制作方针，再分配工作给各个部下的所谓由上至下的创作手法。

只不过在《萨尔达传说王国之泪》（以下简称为《王国之泪》）的开发工作当中，却是以「团队所有人都可以构思游戏开发方向并不断尝试的平行式创作手法」为目标。可能会看到美术设计师在考虑到游戏平衡的前提下去设计新招式这种情况发生，是一种不论担任什么职务都可以尽情提出自己创意点子的制作手法。

虽然团队当中当然还是会有领袖人物存在，但开发团队是认为，能够让每一个人都像过去那个时代一样亲自参与创作过程，应该是更容易激出发优秀的点子才对。

为了达成这个理想，重点就是必须要让担任各种不同职务的成员，都能够清楚了解到自己正在制作一款什么样的游戏，冈村佑一良表示在达到这个前提之后，才能够去「创作」。虽然后面还会再次提到，但大家可以注意在这边主讲者并不是用「制作」，而是包含了创造性在内的「创作」字眼，可以从中感受到其重点所在。

想要了解游戏，可以游玩正在开发中的版本，请教其他的开发者，又或者是阅读规格书等等不同的手段存在。只不过光是游玩，常常会没有办法完全把握规格，而想要找人请教，又必须要该部份的负责人刚好有空才可以，就算是去阅读规格书，也会碰上加入游戏时采用的规格其实并不一样的案例。

想要实现平行式创作手法，由于游戏在开发过程中会不断变化的关系，所以让实现的难度也随之提升。在前作《萨尔达传说旷野之息》（以下简称为《旷野之息》）当中，是采用将游戏各方面的动作方法和数值等，原本会以规格书说明的部份转化为资料，以资料驱动式手法进行开发。

将从资料中读取到的情报，制作出表格、圆饼图或者是投影片等视觉化资料，并且同时去游玩游戏。透过这种兼并两者方式的「可动规格书」下去了解游戏，然后再连结到创作行动上。另外冈村佑一郎特别强调「这并不是指不应该要去制作出规格书」，是表示规格书虽然可以用来整理游戏开发者脑海当中的想法，但是并不适合用来了解关于游戏的最新情报。

在现在一般的游戏开发过程当中，通常是由核心团队利用共通的框架去制作出各种不同开发工具，打造出整合型开发工具让大家使用，但是在《旷野之息》当中，其实是采用每一个不同的部份，全都使用不一样的程式语言和技术去制作的综合组成方式。

虽然这是一种比起整合型开发工具来说，较为古老的开发手法，但同时也有柔软性更高，更容易去应对各式各样不同游戏设计的长处。因为只要有构想，不管是谁都可以下去制作开发工具，所以更容易激发出全新的点子，也比较容易采用全新技术来累积不同的经验，促进开发团队成员的技能成长，其实有相当多不同的长处。

比如说在开发《健身环大冒险》时制作出来的记录用工具，就有转用到其他游戏开发工作的成果。

但是另一方面，综合组成方式与整合型开发工具相比之下，各个开发工具之间的连结力较弱。有时候想要在某个开发工具里加入一个方便使用的功能，就必须要去解析另一个不同开发工具的情报才行。而且为了要了解游戏整体的架构，就必须要同时使用复数不同开发工具，并且去理解各个资料之间的连结才可以。

而且《旷野之息》的开发工具，因为将加入速度摆在第一优先的关系，有些工具其实没有什么扩充的空间可言。再加上《王国之泪》的游戏内容与前作相比之下更加复杂，内容量自然也变得更为庞大。

于是包含冈村佑一郎在内的开发团队成员，就决定要从头打造一个全新的开发环境。开始制作设置在各个开发者电脑里的「本地资料库（LocalDB）」、用来管理资料版本的「公用资料库（GlobalDB）」，以及让各资料之间连结视觉化的「专案入口（Project Portal ）」等等开发工具程式。

使用资料库来连结不同的开发工具以及每个人的作业进度

「本地资料库」是为了解决旧有开发环境的问题之一，也就是各开发工具之间连结力较弱这个问题的工具。基本构想是先准备作为所有开发工具共用基础来使用的资料库，让开发工具透过资料库去读取各种档案。只不过单纯只是准备一个资料库，开发第一线人员也不会去使用。于是就采用了能够利用在各种不同程式上面的SQL 工具，让不管是使用什么开发工具，都可以直接读取到资料库里面的档案。

另外关于要在资料库里写入各种情报的时候，基本上是让有最了解该档案的人会下去执行这个动作。比如说如果是游戏的3D 模型，那就是由3D 模型工具的开发者下去将资料登录到资料库里面。

虽然这样的确会增加特定开发者的工作量，但是因为资料库成为可以共用的基础部份，所以即使会有复数开发工具都需要使用到3D 模型，也就不用再分开来一一去应对，因此反而能够降低整体的负担。

只不过话虽如此，但即使是对该项档案最了解的人，实际上也很难去预测其他不同开发工具，会需要哪一些项目的资料。而且如果采用有人提出需求，就一一去对应该项目的方式，那反而又会增加负担，并不现实。

于是就决定在制作「本地资料库」的时候，采用加入「尽可能多种不同的资料」这种方针。举例来说像是3D 模型的档案，就会记载包含顶点数量、骨架的名称以及原型骨架、材质名称和使用着色器……等等，资料库里面记载的项目越多，就越方便其他开发者尝试各种不同的方案。

虽然在构思不同点子的时候，很难事前去预测会让人想要对哪些项目动手调整，但只要事先记载好尽可能多样化的资料，那就能够立刻对应突如其来的发想。

而且会记载在资料库里面的资料，包含3D 模式、材质、关卡、事件、演员、特效、动画、数值以及背景音乐等等构成游戏的档案，还有用来制作这些档案的Maya 的.ma 档案、 Photoshop 的.psd 档案，以及各项程式的源代码等等，有各种不同种类的资料，可说是包罗万象（只不过像是顶点串流（Vertex stream）之类巨大的资料就会被视为例外）。

不过就在这样建构资料库的过程当中，有人提出了「那资料库应该要设置在哪里」这个问题。一般来说通常会把资料库设置在伺服器上面，让每人个使用自己的电脑去读取资料库。只不过在开发过程中进行各种作业需要使用的档案，基本上是放在每个人自己的电脑里面，而且还会因为开发游戏时出现的不同构想持续加入变动。

这也就是说就算是同一份档案，也会因为每一个人作业进度不同而产生差异，这样子自然就会让每个人依照自己想法加入的变更，与伺服器上的档案版本发生冲突，产生「同一份档案却有复数不同版本，那到底是谁的版本才正确？」，这个在游戏开发过程中大家都很熟悉的问题。

于是日高祥藏就表示，这时候就必须要换一个想法。既然每一个人在开发过程中都需要进行不同的作业，那么就让每一个人都有专属于自己的资料库不就好了吗……在这个想法当作前提之下，最后就采用了在每一个人的电脑里面，都设置一个存在于本地的资料库这种做法。而因为是存在本地的资料库，所以就命名为「本地资料库」。

但虽然说是存在本地，可是每一个人的资料库都还是有互相连结。而且各种开发工具，也会透过资料库互相连结。比如说有人使用Maya 编辑某个角色模型并且更改了骨架的名称，那有用到这个骨架名称的其他工具，也会更新资料将这个全新的名称覆写上去。

而且其他开发者只要有变更档案内容，并且使用版本管理系统的话，这些变更也会反应到自己的档案里面。这样就不用去判断到底谁的版本才正确，而是最新的变更会持续反应到所有人持有的档案当中。

只不过在这个系统里，为了要提升反应速度，所以刻意排除了不需要的档案。所以因为对自己担任职务没有必要性，因此没有存在本地资料库里的档案，就没有办法下去更改。

然而就算是这样说，有时也是会需要用到这些档案，于是就决定要在「本地资料库」的系统中，准备一个设置在伺服器上面的共用型资料库，也就是「公用资料库」来管理各种不同档案的版本资料。所以在想要使用自己手头上没有的档案时，就可以连进「公用资料库」里面去读取这些档案。

以「本地资料库」和「公用资料库」，解决了开发工具之间连结力较弱的问题。

那现在就要开始处理另外一个问题，也就是「无法理解游戏构造」。因为游戏十分复杂，会记录在「本地资料库」里的情报量十分庞大的关系，很难只看这些情报就去了解到整体游戏的构造。

但既然如此就应该要去适当处理分类这些情报，所以就开始构想出一个可以选择资料的种类，并且尽可能缩限要读取的情报范围，让使用者可以去追查资料与资料之间关联的开发工具，而这就是让资料关联视觉化的「专案入口」。

在「专案入口」可以筛选想要寻找的资料种类，并且靠资料名称以及加在各个资料上的标签来进行搜寻。

比如说以「大师之剑（マスターソード）」当关键字进行搜寻，除了大师之剑本身以外，还会看到剑鞘以及台座等关联项目也列在搜寻结果的清单里，如果是想要找会被雷噼到的武器，那就可以使用「金属制」这个标签来筛选要搜寻的范围。

而且因为标签本身也可以加入各式各样的条件来进行筛选，所以就准备了相当庞大数量的标签。就和前面提到的「本地资料库」里要刊载的档案种类一样，加入的标签数量越多，就越能够灵活对应每个人发挥出来的创意构想。

在加入的标签当中，还有「前作就存在的武器」、「会从宝箱掉出来的武器」、「拿弓箭的敌人」、「会遇见敌人的NPC 角色」以及「会出现在神殿的设置物件」等等，可以看出开发团队为了要打造一个让人可以进行「创作」的环境，付出了多少努力。

只不过正因为标签十分详细而且又多样化，所以要靠人手去加入标签就有极限存在。于是在「专案入口」这个开发工具当中，就会把演员（在这里指会出现在游戏中的物件）的数值也全部都当作是标签来处理。

由于演员的性质会在资料内以数值化的方式来记载（比如说像是可以燃烧的演员，就会设定一个可以燃烧的数值），所以只要将这些数值当作标签对SQL 送出请求就好。

这个在「专案入口」的设定中被称为「请求标签」，和一般的标签一起搭配运用，就可以使用十分复杂的条件来进行筛选。

应该可以说是参考自己想要使用的条件数值，直接去产生一个可以在当下使用的标签吧。也因为有这个设计，所以关于会使用数值来记载的性质，就不需要以人力来主动去加上标签了。

然后为了要把握游戏的构造，还制作出可以直接看到资料之间连结（参考关系）的功能。参考关系的箭头在依照事件→演员→模型设定……这样顺向来表现时，直接使用一般的树状图就可以，但是要显示出逆向树状图的时候，就会发生可能会显示出重复资料的问题，于是就采用在显示逆向关系的时候，改用清单方式的手法。

而就演员和物理设定以及3D 模型这种没有直接关联（离散程度较高）的资料来说，则是提供了可以查询各自资料的连结，取得必要情报后显示成一览表的功能。

比如说宝箱的配置情报，与放在里面的演员，还有演员的卖价，这些原本应该是写在不同档案里面的情报，就会加工为一览表，并且加上可以直接跳到情报所在位置的按钮。

另外就波克布林（ボコブリン）来说，在演员表格里面会有名称和内容标签，而在3D 模型表格里会有名称和边界框架，在物理设定表格里则是会记载质量，在这种情况下只要使用SQL 就可以制造出将名称、产生出的缩图与边界框架、质量一览表，以及除错产生用的按钮都一字排开的一览表。

本来应该要自己去参考每一个不同的资料，从中去理解资料之间的连结，但是透过「专案入口」就可以加工成一览表，提供让人可以马上就参考所有关联资料的按钮。

这样子就可以量产出SQL 或者是加工方法，于是就把这个功能称为「资源表格」。当然像这类试算表也可以直接用人手制作，但是自动化生产一定比较少会出现失误。

利用「本地资料库」和「专案入口」，制作音效演出细节

接下来登台的长田润也，则是以音效团队的角度，举出实例来解说活用「本地资料库」和「专案入口」的范例。

由于音效团队工作性质之故，通常都是在游戏开发后期才开始动工，但团队一直都有希望可以在早期就开始主动参与游戏制作的想法。只要有「本地资料库」和「专案入口」这两个开发工具，就可以在播放动画片段的同时加入音效，又或者是介接到用来编辑动画资料的开发工具上。

而且还有加入在其他开发者变更动画资料的时候，就会自动通知关联音效制作者的设计，让整体作业效率有明显提升。

而且在格鲁德小镇（ゲルドの街）防卫战这个游戏事件中，还能够让音效演出变得更加紧密。由于这在游戏故事上也是一个十分重要的场面，所以就有人提出希望可以加入依照战斗当下状况，让音效出现变化的演出这种提案。

于是就在利用「专案入口」仔细把握这个事件的规格之后，成功加入了在适当的时机去切换战斗背景音乐，以及每一次破坏吉波得（ギブド）巢穴时乐曲都会发生变化等等，更具有互动性的演出手法。

而在本作中玩家使用的武器，可以透过「余料建造（スクラビルド）」黏贴上不同素材甚至是其他的武器，每次黏贴后音效都会出现变化，设计可说是十分复杂，而在这方面「专案入口」也是帮上很大的忙。

虽然只调查余料建造的数值，也很难去了解比如说是用什么方式黏贴上哪一种道具，也就是整体产生了什么样的变化，但只要利用在「专案入口」当中，为了方便游戏设计师调整数值而加入的预览，就可以完全理解当下使用的武器规格。

虽然说有的时候，在使用余料建造黏贴上素材前后，音效也不会出现变化，但只要透过「专案入口」调查，就可以马上了解到这是刻意为之的设定，还是单纯设定时出现失误。

长田润也表示，「专案入口」可以说是一个可信度极高的情报收集基础建设工具，让团队能够放心打造游戏细节到最后一刻，给这项开发工具相当高的评价。

让参与开发的所有开发者，不论其职务都可以提出点子，透过从不同视角出发的创意发想让游戏变得更加完善……这应该是游戏开发工作的理想状态之一。然而当专案规模越变越庞大，距离这种理想也就越来越远。可以说在《王国之泪》的开发工作当中，就是透过打造出各种不同的开发工具，尽最大努力去维持这种理想的状态。

在近年来所谓3A 大作当道，因为大规模游戏作品成为主流，让开发工作越来越高度分工的时代里，负责游戏末端工程的开发者，真的是很难去把握游戏的全貌，实际上也有人指出这种状况，甚至会影响到开发者投入开发游戏的动力，本次讲座中讲解的这些工具，从笔者个人角度来看，也明确感受到是一种能够去解决这种问题的手法。

虽然这只是笔者个人的感想，但是冈村佑一郎在这场讲座当中，会特别强调「创作」这个用字，而不是单纯使用「制作」，应该就是想要强调大家不应该只把游戏开发当作一种工作，只是机械性地去投入制作，而是要在其中加入创意发想去完成一场创作才对。

从不同职务角度出发能看到的事情不同，所以能够催生出的点子也不一样。如果能够透过自己本身职务特有的观点和创造性，去参与游戏开发工作的话，想当然是一定可以大幅提升开发第一线人员的士气才对吧。

正如同冈村佑一郎本人指出的一样，就算是采用让领导人物决定一切的由上至下方式，还是可以顺利完成游戏开发。而且即使费尽苦心开发出一大堆开发工具，也不能保证一定可以完成比由上至下方式还要出色的游戏。只不过《王国之泪》即使是如此，依然选择了这条要克服许多难关的道路。

本作之所以能够在全世界各个国家，让各个不同年龄层的玩家都给予极高评价，应该就是因为费的这些苦功，的确有开花结果获得成效的关系才对吧。当然这绝对不是一种能够马上就让所有游戏开发现场模仿的手法，但是就在必须要在截止期限之前完成游戏的现实考验当中，还能够坚持要去追求理想，的确是件让人感觉到十分精彩感动的事情。