「知る・創る・繋ぐ『ゼルダの伝説　ティアーズ オブ ザ キングダム』で再構築した開発環境とサウンド制作事例」セッションレポート［CEDEC 2024］

　開発スタッフの全員がゲームのことを知り，職種に関わらずアイデアを出し合えるフラットなモノ作り。この理想を実現するために，開発環境を再構築するという英断が行われた。開発者向けカンファレンス「CEDEC2024」の最終日，2024年8月23日に「知る・創る・繋ぐ『ゼルダの伝説　ティアーズ オブ ザ キングダム』で再構築した開発環境とサウンド制作事例」と題した講演が行われ，任天堂の取り組みが解説された。


●登壇者
岡村祐一郎氏（任天堂 企画制作部 プログラミングリード）
長田潤也氏（任天堂　企画制作部　サウンドプログラミング担当）
日髙祥蔵氏（任天堂　企画制作部　ゲームツール開発担当）

左から，岡村 祐一郎氏，日髙祥蔵氏，長田潤也氏

フラットなモノ作りを実現するため，開発環境の一新を決断

　かつてのゲーム開発は小規模開発ゆえの軽快なフットワークやコミュニケーションの取りやすさがあったが，近年のゲーム開発は規模が肥大化し，技術の細分化と分業が進行している。
　こうした中でモノ作りをするには，各部署に用意したリーダーがゲームについて考え，部下たちが作業をこなす縦割り方式が考えられる。
　しかし，「ゼルダの伝説　ティアーズ オブ ザ キングダム」（以下，「ティアーズ オブ ザ キングダム」）で志向されたのは「チームの誰もがゲームのことを考えて試行錯誤する，フラットなモノ作り」。アーティストがゲームバランスを考えつつ新技を作るなど，職種に関わらずアイデアを出していくやり方だ。
　もちろんリーダーは存在するものの，一人一人がかつての時代のようにモノ作りをすることで，良いアイデアが生まれやすくなるのではないかと考えたのだという。



　そのためにはいろいろな職種の人が，自分が作っているゲームについて知ることができるのが重要であり，こうなって初めて「創る」ことができる，と岡村氏は語る。詳しくは後述するが，ここで「作る」ではなく，創造性を含んだ「創る」と表現されているのは重要であると感じられる。


　ゲームを知るには開発中のものをプレイしたり，他の開発者に話を聞いたり，仕様書を読んだりといった手段がある。しかし，プレイするだけでは仕様が掴めないことがあるし，ヒアリングするにも担当者の手が空いていない，仕様書を読んでも実装が違っているというケースも起こる。

　フラットなモノ作りではゲームが変化し続けていくため，さらに困難は増すことになるのだ。前作「ゼルダの伝説 ブレス オブ ザ ワイルド」（以下，ブレス オブ ザ ワイルド）では，これまでなら仕様書で解説されていた挙動説明やパラメータといった部分をデータに取り込んだデータドリブンな開発が行われた。
　データから情報を表やグラフ，ビューワーで可視化し，同時にゲームも遊んでいく。両者を併せた「動く仕様書」でゲームについて知り，創ることにつなげていくわけだ。なお，岡村氏曰く「仕様書を書くべきでないと言っているわけではない」とのこと。仕様書は開発者が頭の中身をまとめるのに役立つものであり，ゲームの最新情報を知るのに適さないということなのだそうだ。



　現在の一般的な開発では，コアチームが共通のフレームワークで様々なツールを作る統合型ツール群が用いられているが，「ブレス オブ ザ ワイルド」ではそれぞれのパートで異なる言語・技術を用いたコンポーネント型となっている。
　統合型ツール群よりは古いやり方ではあるものの，多種多様なゲームデザインに対応できる柔軟性の高さがメリットとなる。思いついたら誰でもツールを作れるためアイデアも生まれやすいし，新技術が導入しやすいことでノウハウが蓄積され，スキルアップできるといったメリットもある。
　「リングフィット アドベンチャー」の開発中に作られたロギングツールが他のタイトルにも転用されるといった成果も上がっている。

　その一方，コンポーネント型は，統合型ツール群に比べてツール同士の連携が弱い。あるツールで便利な機能を実装するためには，他のツールの情報を解析する必要が出てくることもある。また，ゲーム全体を知るには，複数のツールにまたがって使われているデータ同士のつながりを理解しなければならない。
　そして「ブレス オブ ザ ワイルド」のツールでは実装速度を優先したため，拡張性に欠けているところもあるという。そして「ティアーズ オブ ザ キングダム」では前作からゲーム内容がさらに複雑化し，物量も増えることになった。
　そこで岡村氏たちは新しい開発環境を作ることを決断。開発者のPCに置かれる「LocalDB」，データのバージョンを管理する「GlobalDB」，データのつながりを可視化する「Project Portal」といったツール類が作られることになった。

データベースを用い，異なるツールや各人の作業を連携させる

　「LocalDB」は，従来環境の課題である，ツール間の連携の弱さを解決するためのもの。全ツールの共通基盤となるデータベースを用意し，ツールはデータベースを通してファイルにアクセスするといった方法が構想された。
　しかし，単にデータベースを用意しただけでは，開発現場に使ってもらえない。そこで，いろいろなプログラムから使えるSQLを採用し，どんなツールからもデータベースにアクセスできるようにした。
　また，データベースへの情報の書き込みについては，ファイルに最も詳しい人が行うようになっている。例えば3Dモデルなら，3Dモデルツールの開発者がデータベースへの登録を行うわけだ。
　特定の開発者の仕事が増えるのは確かだが，データベースが共通基盤となっていることで，3Dモデルを扱いたいツールが複数あってもそれぞれに対してのサポートが必要なくなるため，全体的な負荷は減ることになったという。



　とはいえ，ファイルに最も詳しい人であっても，他のツールからどんな項目が求められるかはなかなか予想が難しい。そして，欲しいと希望が出た項目一つ一つに対して対応を行うのも負担が増えて現実的ではない。
　そこで「LocalDB」では「可能な限りのデータ」を載せるという方針を採った。例えば3Dモデルのファイルであれば，頂点数，ボーンの名前と親ボーン名，マテリアル名とシェーダー……といった具合で，扱える項目が多ければ多いほど開発者は試行錯誤がしやすくなる。
　アイデアを考えるうえでは，どの項目をいじりたくなるかが事前に分からないが，可能な限りのデータが載っているのであれば，急な思いつきにもすぐ対応できる。

　そして，載せるデータは3Dモデル，テクスチャ，レベル，イベント，アクター，エフェクト，アニメ，パラメータ，BGMといったゲームを構成するファイルから，これを制作するMayaの.ma，フォトショップの.psd，プログラムのソースコードまで，あらゆる種類に及んでいるという（ただし，頂点ストリームのような巨大なデータは例外とされている）。


　こうしてデータベースの構築は進んでいったが，データベースをどこに置くべきかという問題が持ち上がった。通常ならばサーバー上に置いて個人のPCからアクセスするところだ。しかし，作業をするファイル自体は個人のPCにあり，各人がそれぞれの構想で開発を進めて変更を加えていく。
　同じファイルであっても各人の作業に応じて違いが出てくるわけで，そうなると各人が思い思いに加えた変更がサーバーで衝突し，「同じファイルが複数あるけれど，誰のバージョンが正しいのか？」という，ゲーム開発ではお馴染みの問題が出てくる。
　ここでは発想の変換が必要だった，と日髙氏は語る。各人が開発を進めるのであれば，データベースも各人ごとにあればいいのではないか……という発想の元，データベースは各人のPCにローカルで置かれることとなった。ローカルなデータベースなので「LocalDB」というわけだ。


　ローカルとはいえ，各人のデータベースは連携している。そして，データベースを通してツール同士も連携している。例えば，キャラクターモデルをMayaで編集してボーン名を変えたら，このボーン名を使っている他のツールのデータも新しい名前に書き換わる。
　そして，他の開発者がファイルに変更を加えた上でバージョン管理システムを使えば，その変更が自分のファイルに反映される。誰のバージョンが正しい，ではなく最新の変更が全員に反映されるというわけだ。
　しかし，このシステムでは，高速化のために不要なファイルを持たないようにしている。そのため，自分の職種に必要ないので所持していないファイルについては扱うことができない。
　とはいえ，そうしたファイルが必要な場合もある。そこで「LocalDB」ではサーバー上にもグローバルなデータベース「GlobalDB」を用意し，ファイルのバージョンを管理することとした。手持ちにないファイルを扱いたい場合も，「GlobalDB」から持ってこられるようになったのだ。



　「LocalDB」と「GlobalDB」でツール間の連携の弱さは解決できた。
　もう一つの課題は「ゲームの構造が分からない」ということ。ゲームは複雑であり，「LocalDB」に記録された情報も多いため，単にこれを見ただけではゲームの構造を理解することにはつながらない。
　それなら情報を上手く切り取ればいいということで，データの種類を選び，絞り込みを行い，データ同士のつながりを辿っていくためのツールが構想された。これがデータのつながりを可視化する「Project Portal」だ。


　「Project Portal」では探したいデータの種類を選んでの絞り込み，名前や各データに付けられたタグでの検索が可能になっている。
　例えば「マスターソード」で検索すると，マスターソードだけでなく，鞘や台座など関連した項目もリストアップできるし，雷が落ちる武器を探したいといった条件で探す場合も「金属製」のタグで絞り込みができる。
　タグについてはいろいろな条件での絞り込みを可能とするため，膨大な数が用意されている。先ほどの「LocalDB」に載せるファイルの種類と同様，多岐にわたるほど，各人のクリエイティビティの発露に対応しやすくなる。

　タグの中には「前作からある武器」「宝箱から出る武器」「弓を持つ敵」「敵と遭遇するNPC」「神殿に出てくる配置物」といったものもあり，「創る」ための環境を整えようとする努力がうかがえる。
　ただし，タグが詳細で多岐にわたっているため，人の手によるタグ付けには限界がある。そこで「Project Portal」では，アクター（ゲーム内に出るオブジェクト）のパラメータもタグと同じように扱えるようになっている。
　アクターの性質はデータ内にパラメータとして記述されている（例えば，燃えるアクターなら，燃えるというパラメータが設定されている）ため，これをタグと見なしてSQLで問い合わせればいい。
　これが「Project Portal」における「クエリタグ」で，タグと組み合わせれば複雑な条件での絞り込みも行える。
　好みの条件のパラメータを参照する，その場限りのタグといったところだろうか。これにより，パラメータに記述される性質については，人力でタグ付けをする必要がなくなったという。


　そして，ゲームの構造を把握するため，データ同士のつながり（参照関係）を見る機能が作られた。参照関係の矢印をイベント→アクター→モデル設定……と順方向に辿っていく場合はツリー形式でいいが，逆方向をツリー形式にすると重複したデータも表示されてしまうといった不都合がある。そこで逆方向の場合はリスト表示とする工夫が施されている。


　アクターと物理設定と3Dモデルといった直接的なつながりのない（離散的な）データの場合，それぞれのデータのつながりを辿り，必要となる情報を取得して一覧にする機能も用意された。
　例えば宝箱の配置情報とそこに入ったアクター，アクターの売値といった本来別々のファイルに書かれた情報を一覧に加工した表にし，その位置へワープするボタンも付けてくれる。
　また，ボコブリンの場合，アクターテーブルには名前とラベル，3Dモデルテーブルには名前とバウンディング，物理設定テーブルには質量が記載されている場合，SQLを使えば名前と生成されたサムネイルとバウンディング，質量の一覧，デバッグ生成用のボタンが並んだ一覧表にしてくれる。
　本来ならそれぞれのデータを参照し，つながりを自分で理解する必要があったが，「Project Portal」は一覧に加工してくれ，即座に参照できるボタンまで用意してくれるというわけだ。
　SQLや加工方法は量産できるようになっており，これは「リソーステーブル」と呼ばれる。もちろんこうした表はスプレッドシートを使って手作業でも作れるが，自動化した方がミスは少なくなる。

「LocalDB」「Project Portal」を使い，サウンド演出を作り込む

　長田氏からは，サウンドチームの視点から「LocalDB」「Project Portal」を活用した事例についても語られた。
　サウンドチームはどうしても作業フローの後工程になりやすいが，早い時期から能動的に制作を進めたいという思いがあるという。「LocalDB」「Project Portal」があれば，アニメを再生しつつ音を鳴らしたり，アニメデータを編集するツールに飛ぶこともできる。
　他の開発者がアニメデータを変更した場合，関連する音の担当者に通知が来る仕組みも用意でき，作業効率が上がったそうだ。


　また，ゲルドの街防衛戦のイベントでは，サウンド演出をより緊密なものにもできたという。ストーリー的にも重要なシーンであるため，戦闘の状況に応じてサウンドが変わる演出を入れたいというアイデアが出た。
　そこで「Project Portal」を使ってイベントの仕様を細かく把握することにより，音楽的なタイミングで戦闘中の曲へ遷移したり，ギブドの巣が破壊される度に曲が変化するというインタラクティブな演出が実現できた。

　本作の武器は「スクラビルド」によって素材や他の武器をくっつけていく度にSEが変化していく複雑な仕様だが，ここでも「Project Portal」が役立っている。
　スクラビルドのパラメータだけを見ても，どんなアイテムがどうくっついていくかの全体像が把握しづらかったものの，「Project Portal」に用意されたゲームデザイナーがパラメータ調整をするためのビューを使えば仕様を理解することができたという。
　時にはスクラビルドで素材をくっつける前と後で音が変わらないということもあったが，「Project Portal」であればあえてそうしているのか，設定ミスであるかが分かりやすかったという。
　長田氏は，「Project Portal」は信頼性の高い情報収集ができるインフラのようなものであり，安心して最後まで作り込むことができた，とその有効性を高く評価した。



　参加する開発者が職種を問わずアイデアを出し，異なる視点からのクリエイティビティでゲームを良いものとしていく……というのはゲーム開発における理想の一つ。こうした理想はプロジェクトが大きくなるほどに遠くなっていく。「ティアーズ オブ ザ キングダム」では様々なツールを作り出すことで理想を追求しているともいえるだろう。

　AAAタイトルなど大規模ゲームで細分化と分業が進む昨今，末端工程の開発者がゲームの全容を把握しづらくなり，モチベーションにも影響しているという指摘がされているが，個人的にはこうした問題にも対応できるツールであると感じられた。

　これは個人的な予想になるが，本講演で岡村氏が「作」るではなく「創」るの字を用いたのは，おそらく仕事としての作業的に作るのではなく，クリエイティビティをもって創るということではないかと思える。
　職種が違えば見えるものも違い，出てくるアイデアも違ってくる。自分の職種ならではの見方や創造性をもってゲーム作りに参加できるのであれば，開発現場の士気が上がるだろうことは想像に難くない。

　岡村氏自身が指摘するように，リーダーを据えた縦割り式でも作業は上手くいくのは確かだ。そして，いろいろなツールを開発する苦労をしても，縦割り式よりも良いものができる保証はないだろう。しかし，「ティアーズ オブ ザ キングダム」では苦労の多い道を選んだ。
　本作に向けて，世界各国様々な年齢層のプレイヤーから高い評価が寄せられたのは，こうした取り組みが実を結んだからではないだろうか。もちろん，あらゆる開発現場が即座に真似できることではないだろうが，納期までに商品を作るという現実がのし掛かる中で，理想を追い求めたのは素晴らしいことであると感じられた。

「ゼルダの伝説　ティアーズ オブ ザ キングダム」公式サイト