サウンド担当者が開発中タイトルの最新仕様を知るには？『ゼルダの伝説 ティアーズ オブ ザ キングダム』の“フラットなモノ作り”を実現した開発環境【CEDEC2024】

講演に登壇したのは『ゼルダの伝説 ティアーズ オブ ザ キングダム（以降、TotKと表記）』開発チームでリードプログラマーを務めた岡村 祐一郎氏、同リードサウンドプログラマーの長田 潤也氏、そしてゲームツールの開発を担当した日髙 祥蔵氏です。

最初に紹介されたのは前作『ゼルダの伝説 ブレス オブ ザ ワイルド（以降、BotWと表記）』と新作『TotK』に登場する魔物キャラクター「ボコブリン」を比較した映像。

一見すると同じ魔物ですが、実は『BotW』から『TotK』で開発環境を再構築する判断が下されていたため、バックグラウンドには大きな違いがあるとのこと。セッション内では、開発環境の再構築に至った経緯と新たな環境の仕組みや運用が解説されました。

「ゼルダの伝説」シリーズの開発環境の変遷

ゲームキューブ版『ゼルダの伝説 トワイライトプリンセス』では少人数のメンバーが顔を合わせてコミュニケーションしながら小回りの利く開発を行っていましたが、近年は規模が拡大したことで敵キャラクターにも高度な挙動が実装され、関わる人数が増加したと岡村氏。技術の細分化が進み、従来は一人で取り組んでいた役割も分業制へと変化しました。

ゲーム機の性能が進化したことで開発環境にも変化が現れた

多人数での開発環境では、各セクションごとにリーダーを決め、リーダーが作業の割り振りを行う縦割りの開発フローが考えられます。しかし、『TotK』開発チームでは、ひとりひとりがゲームのことを考えられる環境が良いアイデアが生まれるきっかけになると信じて、「フラットなモノ作り」が目指されました。

ひとりひとりが自由にアイデアを考えて実践できる環境を目指した

サウンドプログラマーの長田氏も「後工程になりがちなサウンドも、『こういう音を鳴らしてほしい』という発注に合わせて音を作るのではなく、遊びの手ごたえに関わる演出も積極的に提案する」と補足。シリーズでは楽器を使った音がテーマの遊びも多く、サウンドチームが起点となってゲームデザイナーやアーティストと共に遊びを作っていくことがユニークさに繋がっていると分析しました。

サウンドチームが能動的に開発的に関わっていくためには、ゲーム内容についての“情報収集”が重要であると長田氏。しかし、開発中のゲームをただ遊ぶだけでは細かな仕様を把握しきれず、ヒアリングをするにも担当者を探し出して適切なタイミングを選ばなければなりません。

資料も情報量が多く複雑で、実際の挙動と異なる点が見つかってもプログラムのバグなのか仕様変更がされたのかが判断できず、仕様把握への課題となっていることが指摘されました。

岡村氏も情報収集はセクションに関わらずポイントになると強調し、「ゲームを知る」ことで初めて「創る」ことができると述べました。

ゲームを知るための手がかりとしては仕様書やドキュメントがイメージされますが、これらの資料は開発序盤こそゲーム内容と一致していますが、フラットなモノ作りでアイデアを盛りこんでいく過程での変更が反映されないことが多く、結果的に仕様書ではゲームの最新の情報を知ることが難しくなります。

前作『BotW』の開発では、仕様書に実装方針を書いていくのではなく、データで実装してしまう仕組みに変更。これによってデータの担う役割が広がるため、プログラムの割合が減少。仕様書に記載するのは実装の方針や概念の説明となるため、開発中に内容がほぼ変化せず、仕様書とゲームの乖離が少なくなります。これはいわゆる「データドリブン」になっている状態です。

「知る」情報源としての仕様書は減りましたが、その分データの部分を表やグラフ、時には専用のアプリケーションで可視化することで「知る」に繋げています。こうしたデータの情報に、実際のゲームの手触りから伝わる情報が加わったものを「動く仕様書」と称して、情報源として活用しました。

仕様書そのものは考えを整理するために効果的。仕様書が不要なのではなく、あくまで最新の情報を知るのに適さないという考え

「動く仕様書」化を推し進めた前作『BotW』を経て、最新作『TotK』ではウルトラハンドやスクラビルドというこれまでにない複雑な仕様が登場し、フィールドも立体的になることによって物量も増加。そこで、開発では動く仕様書、つまりデータドリブンを拡大する方針が取られました。

【動く仕様書の実例①】サウンドツールの「BGMEditor」

ゲームの状況によって変化するインタラクティブな音楽演出において、コンポーザーが切り替え表現のために細かな設計図を書いたとしても、プログラマへの依頼段階で上手く伝わらないことが起こりがちだと長田氏は指摘します。そこで、設計したフロー図がそのまま動く仕組みにできるようノードベースの作曲ツール「BGMEditor」を用意。作曲しながらインタラクティブな音楽の設計や試行錯誤を可能にしました。

昼夜で曲が変化するだけでも、どの時間帯を昼と定義するか、どのように変化すれば自然に聞こえるかなどの設定が必要となる。「BGMEditor」では、こうした細かなパラメータもツール上で表現できる

【動く仕様書の実例②】ボコブリンの挙動の仕様書

前作『BotW』の仕様書では、ボコブリンがプレイヤーに発見された時の状態遷移などの具体的なパラメータが文章で書かれていました。製品版ではさらに複雑な制御になっているため、ここでも“乖離”が発生していました。

そこで、本作ではキャラクター挙動をモデル化。挙動制御を「周囲の認識」「行動を決定する」「アクションを計画する」「アクション」「アニメーション制御」の5段階に分け、それぞれのフェーズに適したツールで実装しました。

必要な個所ではビジュアルプログラミングも導入。これらのツールはエンジニアが使用する運用で、アルゴリズムを可視化することで実装者以外のプログラミングが専門ではない人でも情報が分かりやすく、かつ自分で試行錯誤しやすい状態に。実装やデバッグを分業しやすくなるなど、チームトータルでのメリットが生まれたと岡村氏は言います。

ボコブリンがプレイヤーを認識してから行動に移すまでの挙動を5段階に分け、それぞれの段階に適したツールで実装。開発に使用するツールごとにチームを分けられる

一般的な統合型ゲームエンジンは、共通フレームワークの上に複数のツールが実装されており、コアとなるチームが主導することで連携がとりやすい形になっています。これに対して、任天堂では以前から各ツールがそれぞれ独立した「コンポーネント型」を採用しています。

それぞれのツールをコンポーネントとして捉える考え方を採用。ツールごとに使用言語や技術、そして作っているチームも異なるという統合型が登場する以前の形態を現在も使用している

フローの一部を簡略化した制作形態

開発によって必要なツールが異なるため、あるゲームの開発では一部しか使わないこともあれば、追加で独自ツールを組みこむ開発も珍しくないとのこと。こうした柔軟性の高さによって多種多様なゲームデザインに対応できることがコンポーネント型の一番のメリットであり、ハードの種類や仕様、規模によらない開発の実現につながっています。

また、ツールの形態を問わないため、誰でも新たなツールのアイデアを実現できる点、新たな技術にチャレンジしやすく個人のスキルアップや組織として知見を溜めやすい点もメリットに挙げられました。

「CEDEC2020」で発表されたロギングツールは、今では他のタイトルでも使われる汎用ツールに

【コンポーネント型のデメリット①】ツール間の連携が弱い

サウンドツールにおける効果音位置の指定には、スペルミスを防ぎながら入力の手間を省けるプルダウン形式が自然です。しかし、プルダウン項目はボーン名が管理されているモデルツールから取得するため、コンポーネント型ではモデルツールを解析するステップを経由しなければならず、ツールのユーザビリティが下がってしまいます。

こうした「ツール間の連携が弱い」ことはコンポーネント型のデメリットのひとつです。

【コンポーネント型のデメリット②】ゲームの構造が分からない

異なるツールから作られるデータ構造のつながりを把握していなければ、ゲームの全体像が掴めません。しかし、それぞれが独立した状態では、すべてのツールを読み解く必要に迫られてしまいます。データドリブンや「動く仕様書」の拡大を進め、それぞれのデータから情報は得られるようになりましたが、データ構造が複雑化することで本来の「ゲームを知る」ことが実現できない状況になっていました。

前作の開発環境は実装速度優先で制作したため、拡張性に欠く機能整備のされていない環境になってしまっていた。そこで、新たな環境構築を決断

本作ではこうしたコンポーネント型の課題が無視できない状況になり、結果的に開発環境の再構築に踏み切ることになったとのこと。

ここからはゲームツールの開発を担当した日高氏が、前述の「ツール間の連携が弱い」「ゲームの構造が分からない」という2つの課題を解決するための取り組みについて解説しました。

【課題解決策①】ツール間を連携する「ローカルデータベース」

サウンドツールがモデルツールを参照する例のように、複数のツールと複数のファイルがある状況では、他のファイルを読み込む手間と解析を行うための時間がかかります。これを解決するため、すべてのツールで共通して活用できる手段として考案されたのが「共通基盤となるデータベースを通じてアクセスする方式」です。

日高氏によれば、データベースを活用してもらうためには「どのツールでも使えるアクセス方法」と「誰が書きこむか」、そして「データベースに何を載せるか」という3点が重要になるとのこと。「アクセス方法」については、どのツールでも使えるデータベースにするためリレーショナルデータベース（※）を採用し、データベース専用言語のSQLでアクセスする形式に。SQLはさまざまなプログラムで使用できるため、データベースを共通基盤の土台とすることに成功しました。
※　複数のデータベースを表形式で管理し、一意のキーとなるIDで紐づけるデータベース構築方法

「SELECT モデル名 FROM モデルテーブル」というSQLを実行するとモデルテーブルを検索し、モデル名のリストが取得できる

「誰が書き込むか」については、開発者がデータベース書き込み担当までやる方が自然であるとの考えから「ファイルに詳しい人が書き込む」ルールを設定。書き込む手間は増えていますが、データを活用する他チームからの個別の問い合わせに対応する手間がなくなっているので、トータルで見ると全体の負荷が下がる仕組みになっています。

ファイルに詳しい人が書き込む場合も、相手がどんな情報を必要とするかは予想が難しいため「何を載せるか」については「あればあるだけ嬉しい（日高氏）」との考えから可能な限りのデータを載せることに。データサイズが大きく扱いが難しいものを除き、データはそれぞれをテーブルに分けて細かな情報まで載せる運用となりました。

頂点ストリームのようなサイズが大きく扱いが難しいデータは例外としてデータベースから省略

ファイルの種類も「可能な限り」多様に。ゲームを構成する各所パラメータだけでなくDCCツールのファイル、ソースコードもデータベースに載せる

これを「どこに置くか」も重要な問題です。データベースはサーバーに置き、常にアクセスできるイメージがあります。しかし、今回のデータベースの場合、ファイルは編集中の場合や更新していないバージョンを保持している場合など、人によってローカル環境にあるファイルの状態が異なります。各自がそれぞれのタイミングでサーバー上のデータベースに書き込みを行うと情報が衝突してしまいます。

そこで、発想を転換し、各開発者のPCごとにデータベースを置くことで情報が混ざらない環境を実現しました。

ファイルはそれぞれのローカルデータベースに書き込まれるため「ローカルデータベース（以降、LocalDB）」と呼ばれています。LocalDBは、ファイルの更新を検知してデータベースをアップデートします。

Maya上でボーン名称を「Ankle_Left」に変えると、データベースの「name」列に反映される

Mayaではなくメモ帳から名称を一括置換しても同様にデータベースに反映される

他の開発者がLocalDBを更新する場合はバージョン管理ツールを更新します。これによって最新のファイルがダウンロードされ、LocalDBに変更が反映されるようになっています。

担当外の領域のファイルはグローバルデータベースから取得

LocalDBによって情報が手軽に取得できるようにはなりましたが、開発者は担当領域外となる不要なファイルをPC上に持たないようにしています。例えば、サウンドデザイナーはモデルやテクスチャーのデータを、アーティストはサウンドのデータをローカルには持っていません。

このままでは自分のPC上のファイルを扱うLocalDBを完全に活用できないため、この「持っていないファイル」を補う存在として改めてサーバー上に「グローバルデータベース（以降、GlobalDB）」が用意されました。

GlobalDBはLocalDBと同じフォーマットでバージョン管理上の最新情報を保持しており、PC上に持っていないファイルはGlobalDBから情報を取得して書き込む仕組みに。この2つのデータベースによって各ツールがすべての情報を取得できるようになり、ツール間の連携問題が解消されました。

【課題解決策②】ゲームの全体像を分かりやすくする「ProjectPortal」

単体のツールから最新の情報が得られるようにはなったものの、依然ゲームの全体像は掴めない状態です。日高氏は、すべての情報が入っているLocalDBを上手く活用することでデータの繋がり、つまりはゲームの構造が分かるようになるのではと考えました。

しかし、LocalDB内には、3Dモデルのテクスチャやアニメーション、そのテクスチャを参照するアクター、そのアクターを参照するイベントなど無数の繋がりがあるため一気にすべてのデータは見られません。

すべてのデータを一度に見ることができないのならば、切り取って見るしかないと日高氏。「見たいデータの種類を選ぶ」、そこから「必要なデータを絞り込む」、最後に「そのデータが参照されている繋がりを辿る」という3つのステップを踏むことで必要な部分を切り取り、可視化することにしました。この可視化ツールは、すべての入り口になるという意味から「ProjectPortal」と名づけられました。

ProjectPortalでデータの種類を選ぶ、絞り込む

ProjectPortalは初期状態では何も表示されていません。データの種類を選ぶとタブが追加され、データの一覧が表示されます。例えば、ProjectPortalでマスターソードのデータを探したい場合には「マスターソード」とテキストで検索します。雷が落ちる武器を探したい場合には「金属製」のタグ絞り込みが可能になっています。

タブは複数表示できる。この画面では、モデル、イベント、レベルなどのタブを表示し、ソースコードのタブをアクティブにしている

アクターひとつ例に取っても2万件以上のデータが存在する。アクターから落雷の条件である「金属製」のタグで検索し、76件のデータに絞り込んでいる

この検索を正確なものにするためには膨大なタグをすべてのデータに正しく設定しなければなりませんが、開発途中での変更に応じて付けなおしが発生する可能性もあり、人力での対応には限界があります。

しかし、タグを改めて見てみると「燃える」タグが付いているならアクターのパラメータで燃えるものと設定されており、「盾」タグならアイテムパラメータに盾と設定されているため、実は“データを見れば分かる”ものと言えます。そこでLocalDBに対してSQLで問い合わせて条件に一致するアクターにタグが付いていることにする「クエリタグ」という機能が実装されました。

これによってデータベースを見れば分かる要素は人力でのタグ付けが不要になる。クエリタグはタグと同じ振る舞いをするため、タグと組み合わせた複雑な条件絞り込みが可能に

ProjectPortalで「繋がりを辿る」

作中での会話イベントシーンは、イベントが参加するアクターを参照し、アクターが表示を決めるモデル設定を参照しているという参照関係があります。この参照関係をより引いた視点で見ると、1つのデータが他の多くのデータからも参照されていることが分かります。

この時、繋がりの辿り方には「イベントからアクター、アクターからモデル設定→3Dモデル」という順方向の辿り方と、この反対となる逆方向の2種類が存在します。ProjectPortalでは順方向の辿り方に一般的なツリー形式のUIを採用しており、イベントにどんなアクターが登場してアクターの設定はどうなっているか、などとツリーを展開してどこまでも辿れるようになっています。

しかし、逆方向の辿り方はツリー形式で表示すると、アクターを調べたいときに間接的に参照しているモデル設定のツリーも展開しなければならないため手間がかかります。また、ツリー構造の根本部分で参照しているアクターは展開したツリーの先で重複して表示されるため、そのイベントがどれくらい参照されているデータなのかが直感的に分かりにくいです。

3つのアクターが設定されているイベントの例。3Dモデルからこのイベントの情報を見たい場合、3つのアクターのツリーの配下に同じイベントが表示されてしまう

そこで、データの種類ごとに集計してリストで表示する形式を採用。そのデータを変更するとどういった箇所に影響が出るのか分かるようになりました。

例として、ボコブリンについて集計したリストが紹介された。間接的に参照するアクターやイベントがリスト表示される

2種類の辿り方でUIを使い分けることで繋がりを見つけやすい表示を実現しています。

ProjectPortalで離散的なデータを集計するには

「ProjectPortal」には「アクターごとのバウンディングサイズや質量を表形式で観たい」といった場合に役立つ、離散的なデータを集計する機能も実装。LocalDBのさまざまなテーブルに格納されている各種設定は、SQL標準のテーブルを結合する機能によってひとまとめにして取得できます。この取得データは人が見やすい形式ではないため、最後に加工して情報を分かりやすくする機能も用意しました。

SQLによって複数のデータベースのデータを結合。ボコブリンのバウンディングサイズと質量を項目に持つデータを作成した

データのままでは見づらいので、サムネイル画像や表示名を設定し、データに作用するボタンを追加

この「情報を集計して見せる仕組み」を個別に実装しなくても使えるようにするべく、設定ファイルにSQLとカラムの加工方法を書くだけで量産できる仕組みを作りました。開発チームではこれを「リソーステーブル」と呼んでいます。

リソーステーブルの例：宝箱の中身の集計データ

レベルエディタで設定した宝箱の配置情報や、中身のアクターの情報、値段設定など別のファイルに書かれた情報を見やすく集計。宝箱の該当位置へワープする便利機能も実装されています。人の手で再現すると非常に大変な作業となる表ですが、データベースとSQLを活用することで「いつでもゲームの最新の情報が知れる」仕組みを実現しており、課題だった「ゲームの構造が分からない」問題を解消することに成功しました。

ここからはLocalDBとProjectPortalが実際の開発現場でどのように使われたのか、サウンドチームの視点からの具体的な活用方法が長田氏によって紹介されました。

サウンドはどうしても後工程になりがちなセクションですが、長田氏は「遊びができあがってから音をつけるのではなく、他のセクションと同じように能動的に制作を進めたい」というサウンドチームの方針を述べ、そのためには正確な情報収集と効率的なワークフローが重要になると指摘しました。

『TotK』のサウンド制作ではデータドリブンで実装できる内製ツールを活用しており、ツール内で「どのキャラクターが、どの音を、どのパラメータで、どの位置から」鳴らすかを定義できます。他にも「一定速度以上になった時に鳴らす」「キャラクターのアニメーションに連動して鳴らす」というサウンドが鳴る条件の定義も可能になっています。

ここでのポイントは、サウンドツール上で「どのアニメーションにどのサウンドを紐づけるか」という情報が定義されているので、サウンドの再生タイミングやパラメータ調整をする際に他セクションのデータを変更しなくても良い“サウンドツールで完結したワークフロー”になっている点です。これによって後工程でも時間が許す限り調整ができ、キャラクターアニメーションを再生しながら試しに音を鳴らしてみる作業もツール上で完結します。

LocalDBが他チームが行った変更を漏れなく通知

サウンドを紐づけたいアニメーションはプルダウンで選択可能で、ここにLocalDBの仕組みが活用されています。

サウンドツールからアニメーションデータを参照したい場合、「音をつけようとしているキャラクターだけのアニメーションリスト」が求められます。このリストアップはLocalDBにSQLを書くだけで可能となっています。

データの繋がりを辿ることで、サウンドツールからアニメーションデータを管理編集するツールにジャンプすることも簡単

ジャンプしたアニメツール上で、ノードの配置やアニメーションブレンドのような複雑な制御をしている条件式を確認でき、適切なサウンドを実装できるように

サウンドツールだけで完結するワークフローはサウンドスタッフのみで作りこめる反面、サウンドの完成後にアニメーション側で変更があるとまた音を見直す必要が生じてしまいます。こうした問題にもデータ間の繋がり情報を利用することで対応しています。

サウンドからアニメーションのデータを辿った例とは逆の順序で、アニメーション側からも紐づいているサウンドデータを辿れるので、アニメーションの変更があった場合に繋がりのあるサウンド、さらにその担当者と辿って変更通知を送る仕組みも構築。変更を見逃すことがない開発環境になっています。

「うっかり変更の連絡が漏れる」というミスをシステムで防止

サウンドデータから参照元を「逆引き」して作りこみ

サウンドを鳴らす手段はサウンドツールで完結するフローだけでなく、「キャラクター挙動のエディター上」や「イベント制御のツール上に置いたサウンド再生のノード」、「プログラム上のハードコーティングで呼び出す」といった場合も考えられます。

このような外部からのサウンド呼び出しでも、サウンドデータから各種ツールへ直接ジャンプが可能です。

LocalDBにはプログラムのソースコードも収集されているので、Visual Studioのようなビジュアルスクリプティングが可能なコードエディタにも逆引きジャンプできる

【サウンドからの逆引き事例①】ゲルド防衛戦の妥協のない作りこみ

『TotK』のゲーム進行上で重要なシーン「ゲルドの街防衛戦」イベントで、「状況の変化に応じてBGMも変化させていく」という特別な演出が盛りこまれています。

セッションではこの戦いを動画で紹介。会話シーンから曲が開始し、カメラカットやキャラの演技に合わせる。そして音楽的なタイミングで戦闘中の曲に遷移していることを確認

インタラクティブなBGMの変化はBGMEditorによって手軽に実装可能になっており、パラメータの条件判定をしながら曲の切り替えタイミングの調整やフェード時間など、細かな要素をコンポーザーの手元で納得いくまで作りこめる環境が整えられています。

しかし、任意のタイミングで音楽が変わるだけでは演出として完成とは言えません。長田氏いわくサウンドチームは「演技に合わせて曲が切り替わる瞬間やゲームオーバーで曲が止まるタイミングと“間”など、細部まで妥協なく作りこみたい」という意欲を持っているとのこと。

これを実現するために、サウンドチームが担当のゲームデザイナーへヒアリングするだけでなく、ProjectPortalの機能を活用し、「イベントシーンのアクターやエフェクトがどのように作られているか」を把握できるようになっています。

イベント情報の把握に際しては直接イベント制御ツールを開いて閲覧する手段がスムーズな場合もある。この例では、ゲームオーバー時に専用の演出が入ることが確認できた

イベントの細かな挙動がイベントツール上で実装されているので、そこに直接サウンド制御するノードを置いてサウンド演出も同時にコントロールすることも可能です。前述の戦闘イベントシーンでは、当初は画面外で動いているキャラクターの音が鳴ってしまっていたため、余分な音を鳴らさないよう「画面外の音を止める」という機能を持ったノードを置いて制御しているとのこと。

イベントツールは本来ゲームデザイナーがシーンを作りこむためのツールではありますが、サウンド演出を納得いくまで作りこむためにコンポーザーが直接編集して作りこむことも珍しくなかったそうです。派手なバトルシーン以外でもシンプルな会話イベント中にさりげなく曲が変化していく演出など、演出の作りこみに大きな効果を発揮しました。

【サウンドからの逆引き事例②】「動く仕様書」にも後に活用した「スクラビルド」と武器サウンド

武器とさまざまなものを組み合わせられる『TotK』の特徴的な能力「スクラビルド」

武器のサウンドは振った時のSEが重要で、同じ武器を敵やNPCも使うため「武器自体に個性を持たせるもの」と定義して作られています。そして今作ではスクラビルドによって武器の性能や見た目が変化するため、サウンドスタッフとしてもその変化に応じて武器サウンドも変えていきたいというアイデアに。

スクラビルドで作られる豊富な武器バリエーションに対応するため、サウンドでは「見た目が大きくなると低い音になる」「鋭利なものなら金属質な音になる」など、一定のルールを設けた音作りに取り掛かることになりました。

しかし、ルールを設けても「どんなものがスクラビルドできるのか」「武器にどんなくっつき方をするのか」といった全体像が把握できなければ細かな調整はできません。スクラビルド専用のパラメータは複雑で、サウンドスタッフが知りたい以外の情報も含まれていて読み解きづらい状態になってしまっていました。

そこで情報を取得するために活用されたのがProjectPortalです。LocalDBの格納データをリソーステーブルで見やすく整理し、スクラビルドできるアクターの情報を俯瞰して確認しやすくすることで全体像の把握に役立てました。

これは「ゲームデザイナーやアーティストがパラメータ調整を詰めていくために使っていたもの」を、サウンドデザイナーが「仕様を把握するための資料」として活用した、つまり開発のためのデータが後工程のスタッフにとって仕様書ともいえる情報源になっていた事例です。

【サウンドからイベントの逆引き事例③】デバッグ時に「武器をスクラビルドしたのに音が変わっていない」挙動を確認

サウンドに関連するバグを発見するのは、担当者以外には難しい作業です。こうしたケースでもProjectPortalを活用し、リソーステーブル機能でサウンドツールの情報を見やすくすることでデバッグ時の確認に役立てました。

担当者自身も異なる見え方の情報になることで設定ミスの発見などに役立っていたとのこと

開発中はブラッシュアップや設定ミスの発見によってデータが変わることもありますが、見やすいビューがあれば間違いに気付きやすく、修正がフィードバックされることでデータの正確性も上がります。このサイクルによって「データドリブンで効率よくゲームを作るためのツール」が「信頼できる仕様書」つまりは動く仕様書として参照できる環境が構築されました。

長田氏は「信頼性の高い情報収集のためのインフラがあったことで安心して最後までデータを作りこむことができた」と振り返った

動く仕様書からゲームの今を知ることができ、知った情報からコンテンツが創られ、そのデータがLocalDBやProjectPortalで繋がることで、また動く仕様書の内容が最新へと変化していく。このサイクルをチームのひとりひとりが回すことで常に正確な情報を把握しながらの適切な設計が可能になり、これがひいては「フラットなモノ作りに繋がっていく」と岡村氏はセッション全体を振り返ってコメント。

この図すべてとゲームから得られる情報が「動く仕様書」になっている

サウンドの事例が取り上げられたのは、後工程になりがちで膨大な前の工程を知る必要があるセクションでもフラットなモノ作りに繋げられたことを紹介するため

岡村氏はこうした開発環境が任天堂の他タイトルのプロジェクトでも活用されていることに触れ、「ある程度は汎用性が高い環境と言えるのでは」との考えを示し、本内容が皆さんの開発の助けになればとのコメントで講演を結びました。

ハル飯田

大阪生まれ大阪育ちのフリーライター。イベントやeスポーツシーンを取材したり懐ゲー回顧記事をコソコソ作ったり、時には大会にキャスターとして出演したりと、ゲーム周りで幅広く活動中。
ゲームとスポーツ観戦を趣味に、日々ゲームをクリアしては「このゲームの何が自分に刺さったんだろう」と考察してはニヤニヤしている。