2024年8月21日（水）から23日（金）にかけて開催された、日本最大のコンピュータエンターテインメント開発者向けカンファレンス“CEDEC2024（Computer Entertainment Developers Conference 2024）”。その3日目に実施されたセッション、“『ゼルダの伝説 ティアーズ オブ ザ キングダム』（以下、『ティアキン』）で再構築した開発環境とサウンド制作事例”の内容をお伝えする。
広告
本講演では講演者として、任天堂株式会社企画制作部『ティアキン』開発チームの、プログラミングリード・岡村祐一郎氏、サウンドプログラミング担当・長田潤也氏、ゲームツール開発担当・日髙祥蔵氏が登壇した。
『ティアキン』では、前作『ゼルダの伝説 ブレス オブ ザ ワイルド』（以下、『ブレワイ』）と見た目が同じ敵キャラひとつとっても、そのバックグラウンドの開発環境はまったく異なるという。本講演では『ティアキン』で開発環境を再構築した経緯と、その開発環境が実際にどう活用されたか、サウンドチーム視点での活用事例を挙げて解説された。
開発データが資料になる“動く仕様書”
『ゼルダの伝説』シリーズの過去作では、まだ開発は小規模で、ひとつの敵キャラに関わる開発者の人数も少なかった。そのぶん小回りが利き、全員がコミュニケーションをとりやすく、毎日顔を突き合わせてアイデアを出し合いながら制作していたとのこと。
しかし『ブレワイ』の時代になると、ゲーム機の進化とともに高度な挙動が必要となり、技術の細分化も進んだ。結果として分業が進み、近代開発環境ではチームリーダーを通じた縦割り構造が一般的になっている。
しかし『ブレワイ』の時代になると、ゲーム機の進化とともに高度な挙動が必要となり、技術の細分化も進んだ。結果として分業が進み、近代開発環境ではチームリーダーを通じた縦割り構造が一般的になっている。
そのような時流ではあるが、任天堂開発チームは別の方向を模索した。チームのだれであってもゲームのことを考え、試行錯誤できるフラットな物づくりを目指すことに。たとえばアーティストが戦闘バランスを考え、アクションを自分から入れるなど、ひとりひとりからよいアイデアが生まれやすくなる構造だ。
この考えかたはサウンドチームでも同様で、どうしてもほかの工程よりも後の作業になりがちなサウンド制作において、ただ見た目に合わせて音を鳴らすのではなく、遊びの手応えに関わるような演出も積極的に提案していった。
そもそも『ゼルダの伝説』シリーズでは、“音”がテーマとなる遊びやギミックが多く実装されてきた。サウンドチームがゲームデザイナーやアーティストといっしょに物を作っていくスタイルをとってきたことが、さまざまなユニークな演出や遊びにつながったのだ。
そもそも『ゼルダの伝説』シリーズでは、“音”がテーマとなる遊びやギミックが多く実装されてきた。サウンドチームがゲームデザイナーやアーティストといっしょに物を作っていくスタイルをとってきたことが、さまざまなユニークな演出や遊びにつながったのだ。
そうして能動的にサウンドチームが動くために重要なのが“知る”こと、つまり情報収集だった。しかし、開発中のゲームをプレイするだけでは仕様の詳細はなかなかつかめない。直接担当者に声をかけづらい場面もあり、仕様書などの開発資料は情報量が多く複雑、なおかつ資料と実際の挙動が、バグや仕様の変更で異なっている可能性がある。
この“知る”ことの重要性は、全セクションに共通している。もっとも閲覧しやすいのは仕様書などのドキュメントだが、前述のように仕様書の内容は開発の進行とともに、実際のゲーム内容から乖離していく問題を抱えていた。とくにフラットな物づくりの場合、ゲームの内容が細かに変化し続け、この問題がより際立ってくる。
この“知る”ことの重要性は、全セクションに共通している。もっとも閲覧しやすいのは仕様書などのドキュメントだが、前述のように仕様書の内容は開発の進行とともに、実際のゲーム内容から乖離していく問題を抱えていた。とくにフラットな物づくりの場合、ゲームの内容が細かに変化し続け、この問題がより際立ってくる。
そこで『ブレワイ』開発チームは、仕様書に記述すべき“概要”と“具体的な挙動やパラメーター”のうち、後者については仕様書をもとに制作するデータとプログラムのうち、データに内包する形式をとった。仕様書に実装の方針などを書く代わりに、その方針はデータで実装したのだ。
仕様書は縮小し、概要部分は開発が進んでもゲーム内容と乖離することはまずないので、仕様書と開発の乖離も緩和。結果、データでできることが増えてプログラムの割合が減った。こうしてデータドリブン（データにもとづいてさまざまな判断や決定をすること）の体制が整っていく。
仕様書は縮小し、概要部分は開発が進んでもゲーム内容と乖離することはまずないので、仕様書と開発の乖離も緩和。結果、データでできることが増えてプログラムの割合が減った。こうしてデータドリブン（データにもとづいてさまざまな判断や決定をすること）の体制が整っていく。
結果として仕様書は縮小し、“知る”ための情報源としては心もとなくなったが、それを補うためにもデータが活用できる。表やグラフといったさまざまな見せかたでデータを可視化したり、アプリケーションで直接データを見られるようにしたりすればいいわけだ。
これらの可視化情報と、ゲームを触ることによるフィーリングから、ゲームの最新情報を知ることができる。これを開発チームでは“動く仕様書”と呼んだ。ただし、これは従来の仕様書の思考整理や伝達における有用性を否定する考えかたではない。あくまで、開発中のゲームの最新情報を知るためには適さなかったということだ。
これらの可視化情報と、ゲームを触ることによるフィーリングから、ゲームの最新情報を知ることができる。これを開発チームでは“動く仕様書”と呼んだ。ただし、これは従来の仕様書の思考整理や伝達における有用性を否定する考えかたではない。あくまで、開発中のゲームの最新情報を知るためには適さなかったということだ。
では、この流れは『ティアキン』ではどうなったのか。あらゆるオブジェクトを持ち上げたりつなげたりできる“ウルトラハンド”や、武器に別のオブジェクトをくっつけて新たな武器を生み出す“スクラビルド”など、『ティアキン』ではこれまでにないレベルの複雑な仕様が入ったうえ、フィールドが立体的な構造になったことで世界が広がり、単純に物量が増加した。
その規模に合わせてデータドリブン、動く仕様書も拡大。その一環として、サウンドチームでも独自のBGM制御ツール“BGMEditor”を活用した。
その規模に合わせてデータドリブン、動く仕様書も拡大。その一環として、サウンドチームでも独自のBGM制御ツール“BGMEditor”を活用した。
ゲームの状況やプレイ内容に合わせて音楽を変化させる“インタラクティブミュージック”はいまや一般的だが、その実行には定義付けをする必要がある。たとえば昼と夜で音楽が変わるという条件のために、何時までを昼にするかといった定義付けだ。
細かな状況ごとの音楽の変化を実現する場合、従来はサウンドコンポーザーが図を書き、プログラマーに依頼する形をとっていた。しかし、このBGMEditorにより、コンポーザーが思い描く図がそのままサウンドとして稼働するような仕様が実現。コンポーザー自身による自然な演出となる細かな定義付けや、試行錯誤も容易になった。
細かな状況ごとの音楽の変化を実現する場合、従来はサウンドコンポーザーが図を書き、プログラマーに依頼する形をとっていた。しかし、このBGMEditorにより、コンポーザーが思い描く図がそのままサウンドとして稼働するような仕様が実現。コンポーザー自身による自然な演出となる細かな定義付けや、試行錯誤も容易になった。
データドリブンは他分野でも進み、各キャラクターの挙動の仕様実装においても、フェーズごとにビジュアルプログラミングツールを導入することでアルゴリズムを可視化。実装した本人以外でも情報を得やすく、他分野の部分でも試行錯誤でき、分業がしやすくなるといったチームトータルのメリットが得られた。
ツールの2例が解説されたが、任天堂には以前から続いているツールの実装形態があるという。よく使われる統合型ゲームエンジンのように、共通フレームワーク上に各ツールを実装する形ではなく、それぞれのツールが独立して作られており、言語や採用技術も異なるという形式で“コンポーネント型”と称している。
この形式ではプロジェクトごとに、ツールのひとつひとつをコンポーネントと捉え、必要なツールを選択していく。
この形式ではプロジェクトごとに、ツールのひとつひとつをコンポーネントと捉え、必要なツールを選択していく。
コンポーネント型は任天堂の多種多様なハードへの対応力に優れ、そもそもゲームプロジェクト内で独自のツールやアイデアが生まれやすく、新技術などへの挑戦もしやすい。反面、ツール間の連携が弱くなるデメリットもある。たとえばサウンドツールでプルダウン形式の選択機能を導入したくなっても、選択肢を出すには別途モデルデータを解析しなくてはならず、手間を考えるとテキスト入力式に甘んじるしかない。
また、ゲームの“構造”がわかりづらいという点もデメリットだ。異なるツールで作られたデータ間にはつながりがあり、たとえばキャラクターはモデルを保持しており、デモやレベルの分野にもつながっている。構造を知るには、このすべての関連ツールを読み解かなくてはならない。データドリブンでツール単体それぞれからの情報は得やすくなったが、開発チームが本当に目指した“知る”は実現できていないのだ。
フラットな物づくりを目指す過程で“知る”ことが難しくなり、仕様の複雑化という転機を迎え、『ティアキン』開発チームはコンポーネント型の課題を無視できなくなった。
前作の開発環境をベースにすることも考えられたが、前作では実装速度を優先したため、拡張性に欠け、整理されていない部分も多かった。そこで今作では、開発環境を再構築する決断がくだされた。
前作の開発環境をベースにすることも考えられたが、前作では実装速度を優先したため、拡張性に欠け、整理されていない部分も多かった。そこで今作では、開発環境を再構築する決断がくだされた。
新開発環境を実現したふたつのツール
再構築の課題解決のため、まずはツール間の連携の弱さを分析。ほかのツールのファイルを読み込もうとすると個別に実装する手間がかかり、解析にも時間がかかることが問題だった。
そこで共通して使える解決方法として、共通基盤となるデータベースを用意し、ツールがデータベースを通してファイルの情報にアクセスする方式を考案。その利便性を、3つのポイントに絞って突き詰めていった。
そこで共通して使える解決方法として、共通基盤となるデータベースを用意し、ツールがデータベースを通してファイルの情報にアクセスする方式を考案。その利便性を、3つのポイントに絞って突き詰めていった。
どのツールでも使えるアクセス方法
リレーショナルデータベース（※）を採用し、“SQL（Structured Query Language）”というデータベース管理用言語でアクセスできるデータベースを構築。SQLはさまざまなプログラムから使用できるため、全ツールの共通基盤の土台が出来上がった。
※リレーショナルデータベース：行と列による、表の形でデータが収録されているデータベース。各行、各列の共通データや、複数の表を関連付けしてデータ処理が可能。だれがデータベースに書き込むか
たとえばサウンドツールの開発者が、モデルツールのフォーマットに詳しいとは限らない。そこで自然な形として、各ツールのファイルに詳しい担当者が書き込むルールを設けた。作業が増えているように見えるが、ほかのツールに対して個別にサポートする必要がなくなるため、トータルで見ると全体の負荷が下がる。
データベースに何を載せるか
ファイルに詳しい人物でも、ほかのツールがそのファイルに対して、試行錯誤のうえでどんなデータを欲しがるかまでは予想できない。要求に応える手間を考えると、最初からあるだけのデータが入っているのが理想だ。データサイズが極端に大きいもの、扱いがあまりに難しいものは除き、ソースコードすら解析して載せた。
また、共通データベースにはサーバー上に置いて各開発者がアクセスする場合、編集中であったりすると、最新ではないファイルが存在してしまう可能性がある。各開発者が書き込みを行うことで情報が衝突するという問題を解決するために、“開発者ごとにデータベースを持つ”という発想が採用された。これを開発チームでは“LocalDB”と称した。
また、共通データベースにはサーバー上に置いて各開発者がアクセスする場合、編集中であったりすると、最新ではないファイルが存在してしまう可能性がある。各開発者が書き込みを行うことで情報が衝突するという問題を解決するために、“開発者ごとにデータベースを持つ”という発想が採用された。これを開発チームでは“LocalDB”と称した。
ほかの開発者のデータが混じることはこれで避けられ、バージョン更新をかけることで手軽に最新データも習得できる利便性が生まれたが、LocalDBには問題もあった。ディスク容量やデータの取得にかかる時間を減らすため、各開発者は不要なファイルを持たないようにしており、試行錯誤する際に参照できないデータが出てきてしまったのだ。
そこでLocalDBを補うために、改めてサーバー上にもデータベースを用意。こちらはLocalDBと同じフォーマットで、最新の更新データが書き込まれている。この“GlobalDB”はLocalDBにファイルがない場合に参照でき、LocalDBに必要なファイルを書き込んでくれるので、LocalDBだけですべての情報が取得できるようになった。先述したプルダウン形式の選択UIについても連携が強化したことで、さまざまなツールに導入された。
そこでLocalDBを補うために、改めてサーバー上にもデータベースを用意。こちらはLocalDBと同じフォーマットで、最新の更新データが書き込まれている。この“GlobalDB”はLocalDBにファイルがない場合に参照でき、LocalDBに必要なファイルを書き込んでくれるので、LocalDBだけですべての情報が取得できるようになった。先述したプルダウン形式の選択UIについても連携が強化したことで、さまざまなツールに導入された。
こうしてツール間の連携機能が増えたことで、“ゲームの構造がわからない”という課題についても解決が進んだ。LocalDBには全情報が入っているため、これをうまく可視化すれば構造が理解できるようになる。
とはいえ、各ファイルから参照しているファイルのつながりをたどると、その規模はあまりに広大だ。全体から見ることができない以上、部分を切り取って見るしかない。切り取る方法として考えられたステップは、データの種類を選び、絞り込み、そしてつながりをたどるという3段階で考えられた。そのために作成された可視化ツールが“ProjectPortal”だ。
とはいえ、各ファイルから参照しているファイルのつながりをたどると、その規模はあまりに広大だ。全体から見ることができない以上、部分を切り取って見るしかない。切り取る方法として考えられたステップは、データの種類を選び、絞り込み、そしてつながりをたどるという3段階で考えられた。そのために作成された可視化ツールが“ProjectPortal”だ。
こちらのツールでは、まず“種類を選ぶ”段階でタブ形式でデータを整理して表示。つぎの絞り込みのためには名前での検索のほか、条件をタグで検索できるようになっている。たとえば、ゲーム内で雷が落ちる対象のデータを探したいなら“金属製”のタグで絞り込めばいいわけだ。
このタグについては、膨大なデータに対して正確に付けなくてはならず、さらに仕様変更のたびに付け直しが必要になる。そこでタグについては、SQLで問い合わせたときにデータ内のパラメーターを参照して“燃える”や“盾”といった条件を満たす場合、タグのように作用して検索に出る“クエリタグ”の仕様を導入。人力でタグを付ける手間を省いた。
最後の“つながりをたどる”過程については、順方向にたどる場合と、結果から逆方向にたどる場合で別のUIを用意。前者は一般的な木構造で表せるのでツリー形式のUIにし、後者についてはツリー形式では見た目が複雑になるため、データの種類ごとに集計してリストで表示することにした。
さらに複数のアクターからつながりがある3Dモデルや物理設定といった、離散的なデータを集計するための仕様も考案された。LocalDBのテーブルにある各種情報を、テーブルを結合する機能を用いてひとまとめにして習得。このままだと見やすい形式ではないため、名前からサムネイルの追加、カラム名の表示、データに採用するボタンの追加で試行錯誤をしやすくするなどの工夫がされた。
この仕組みはツールごとに個別ではなく、全ツール共通して使用可能にしたいという意図もあり、設定ファイルにSQLとカラムの加工方法を書くだけで量産できる“リソーステーブル”として完成した。手作業のスプレッドシートでの管理と比べて表記ミスなどの心配も減り、いつでも最新の状態でゲームの構造を参照できるようになった。
この仕組みはツールごとに個別ではなく、全ツール共通して使用可能にしたいという意図もあり、設定ファイルにSQLとカラムの加工方法を書くだけで量産できる“リソーステーブル”として完成した。手作業のスプレッドシートでの管理と比べて表記ミスなどの心配も減り、いつでも最新の状態でゲームの構造を参照できるようになった。
2大ツールによるサウンド作業の革新
講演では引き続き、実際にLocalDBとProjectPortalがどのように活用されたのか、サウンドチームでの事例が紹介された。
サウンドセクションの作業は開発工程上、どうしても後工程になりがち。だがサウンドスタッフとしては、ほかのセクションのように能動的に制作を行いたい。そのためには正確な情報収集と、効率よく制作できるワークフローが必須となる。
サウンドセクションの作業は開発工程上、どうしても後工程になりがち。だがサウンドスタッフとしては、ほかのセクションのように能動的に制作を行いたい。そのためには正確な情報収集と、効率よく制作できるワークフローが必須となる。
サウンドチームで使用している内製ツール“BGMEditor”は前述の通り、各キャラクターがどんな音をどんな風に鳴らすか、いつ鳴らすのかといった定義付けができる、データドリブンに対応したツールだ。移動速度が一定以上になる、アニメーションに連動させて音を鳴らすといった定義付けが可能というわけだ。
ここで重要なのが、この定義はサウンドツール上でのみ定義されるものなので、ほかのセクションのデータを変更しなくてもいいという点。後工程になっても、時間の許す限り調整をくり返すことができる。
ここで重要なのが、この定義はサウンドツール上でのみ定義されるものなので、ほかのセクションのデータを変更しなくてもいいという点。後工程になっても、時間の許す限り調整をくり返すことができる。
キャラクターのアニメを再生して音を確認するといった作業も、このツール上で完結できる。サウンドにひもづけしたいアニメデータは、LocalDBとSQLのおかげでプルダウン形式で選択できるのも効率化に役立っている。アニメリストをLocalDBにリクエストしてリストアップできるだけでなく、SQLを書くだけで、そのアクターにどんなアニメやサウンドがひもづいているかもたどることが可能だ。
データのつながりを参照し、サウンドツールから直接アニメデータを管理編集するツールにジャンプすることも可能。アニメツール上ではノードの配置によってデータが見やすくなっており、条件付けをして複雑に整理されているデータも可視化されている。
後工程で生じる、変更が入ったことで見直しが必要になってしまう問題についても、この開発環境なら対応しやすい。逆にアニメのデータからサウンドをたどることで修正箇所が検索できるほか、担当者をたどって関係担当者に変更を感知して通知するシステムも実装できた。各ツールにこうして即座にジャンプできる機能は非常に便利で、ソースコードもLocalDBに記録されているため、コードエディターにさえジャンプできる。
使用の具体例として、“ゲルドの街防衛戦”でのイベント制御ツールとサウンドツールを連携させた作業の事例が紹介された。同イベントはストーリー的にも重要なシーンとなるため、コンポーザーは戦闘の状況に応じて音楽が変化する専用演出を考えていた。
このようなインタラクティブなBGMの変化は、BGMEditorを利用することで気軽に実装できるようになった。さらに細かに、演技のタイミングと音楽を合わせる瞬間や、ゲームオーバーになる直前の音楽のストップタイミングなども妥協なく作り込める。
そのためには、イベントシーンを細かく把握しながら作曲する必要がある。ヒアリングに加え、ProjectPortalを使えばBGMを参照するイベントの情報や、そこに関連したアクターやエフェクトのデータも参照可能。演出的に余計な音は聴かせたくないところで画面外のキャラの音を消すなど、コンポーザー自身の手でさまざまなノードがイベント管理ツールに配置され、こだわり抜いた編集が続けられた。
そのためには、イベントシーンを細かく把握しながら作曲する必要がある。ヒアリングに加え、ProjectPortalを使えばBGMを参照するイベントの情報や、そこに関連したアクターやエフェクトのデータも参照可能。演出的に余計な音は聴かせたくないところで画面外のキャラの音を消すなど、コンポーザー自身の手でさまざまなノードがイベント管理ツールに配置され、こだわり抜いた編集が続けられた。
『ティアキン』の特徴的なシステムである“スクラビルド”についても、新開発環境が活用されたという。本作では武器そのものに個性として効果音を定義付けていたが、スクラビルドによる変化に合わせ、サウンドチームとしても音を変えたいと考えた。
スクラビルドの組み合わせがあまりに膨大だったため、サウンドチームは音の変化にルールを設けて対応。とはいえ、ルールを設けてもスクラビルドで何ができるかの全体像を把握していないと調整は難しい。スクラビルドのパラメーターデータは非常に複雑だった。
スクラビルドの組み合わせがあまりに膨大だったため、サウンドチームは音の変化にルールを設けて対応。とはいえ、ルールを設けてもスクラビルドで何ができるかの全体像を把握していないと調整は難しい。スクラビルドのパラメーターデータは非常に複雑だった。
そこで出番となったのがProjectPortalだ。LocalDBのデータをリソーステーブル機能を使って見やすく成型することで、スクラビルドが可能なアクターの情報を俯瞰して確認しやすくなった。
この機能での俯瞰は、もとはゲームデザイナーやアーティストがパラメーター調整を詰めるために使っていたものだったが、サウンドスタッフからは仕様を把握するために活用できた。つまり、後工程のスタッフにとってこれは“仕様書”ともいえる情報源だったわけだ。
この機能での俯瞰は、もとはゲームデザイナーやアーティストがパラメーター調整を詰めるために使っていたものだったが、サウンドスタッフからは仕様を把握するために活用できた。つまり、後工程のスタッフにとってこれは“仕様書”ともいえる情報源だったわけだ。
サウンドデバック時にも、同じような状況はあった。スクラビルドをしても武器の効果音が変わらないという事例だ。あえて共通の音にしているという資料があれば困らないところだが、そういったものは存在しないとのこと。サウンドツールを見れば具体的な音のルールが参照できるが、担当者以外がツールを自在に扱えるわけではない。
この事態も、ProjectPortalでリソーステーブルを利用。サウンドツールの情報を見やすくすれば、デバックの段階で確認しやすい仕様書代わりになる。担当者から見ても、データを異なる視点から把握するのに役立つ。
この事態も、ProjectPortalでリソーステーブルを利用。サウンドツールの情報を見やすくすれば、デバックの段階で確認しやすい仕様書代わりになる。担当者から見ても、データを異なる視点から把握するのに役立つ。
このように後工程のスタッフにとっては、日ごろ使用しているツールがそのまま仕様書の代わりとして機能したといえる。ブラッシュアップや設定変更でデータは変わっていくが、目的に応じた見やすいビュー機能があることで、データの把握や間違いの発見も格段にしやすくなった。
こうした確認の結果がツール上にフィードバックされ、データの信頼性はより高まっていく。データドリブンツールは、信頼できる“動く仕様書”として参照できる機能を得た。この仕組みには、LocalDBとProjectPortalが欠かせなかったのは言うまでもない。
こうした確認の結果がツール上にフィードバックされ、データの信頼性はより高まっていく。データドリブンツールは、信頼できる“動く仕様書”として参照できる機能を得た。この仕組みには、LocalDBとProjectPortalが欠かせなかったのは言うまでもない。
“動く仕様書”の実績と汎用性
講演の最後には、総括として『ティアキン』の開発環境ではコンポーネント型のツールフローにLocalDBという基盤が加わったことで、ツール間の連携の課題を解決したことが改めて示された。
さらにLocalDBのデータをProjectPortalで見ることで、ゲームの全体像も把握できる。その見える範囲のツールとゲーム構造すべてが“動く仕様書”となり、ゲームの現状を把握できたわけだ。
こうして確認できた情報を使ってコンテンツを作るにあたり、動く仕様書はLocalDBとProjectPortalを通じてつながり、形を変えていく。このサイクルをチームのひとりひとりが回すことで、つねに正確な情報を把握しながら適切な設計ができ、さらにフラットな物づくりにもつながっていく。
後工程になるサウンドセクションは膨大なゲーム構造を“知る”必要がある。それでも今回紹介された実例のように、後工程でもフラットな物づくりを実現できた。
後工程になるサウンドセクションは膨大なゲーム構造を“知る”必要がある。それでも今回紹介された実例のように、後工程でもフラットな物づくりを実現できた。
なお、この開発環境はすでにほかのプロジェクトでも使われているという。つまり、汎用性の高い環境でもあるということだ。この事例はさまざまな開発環境において、何らかの新たな転機やアイデアにもなり得ると思われる。
