私たちオブシディアン エンターテインメントのオーディオチームが、WwiseとUnrealを使って『アウター・ワールド』のサウンド、ミュージック、そしてボイスオーバーをつくり出した過程を、2回に分けて詳しく説明したいと思います。このワークフローにWwiseは不可欠で、自分たちのクリエイティブな野望を実現するために必要な「柔軟性」と「機能性」を見事に提供してくれました。パート1では、クリーチャー、音楽、VO（ボイスオーバー）、そしてAIダイアログ（チャター）などの実装や、スペーシャリゼーションについて説明します。
クリーチャーたち
アウター・ワールドのいたるところにいるNPCクリーチャーたちは、大きさも様々で、危険生物もいれば優しいキャラもありで、有機体も無機体もいます。私たちが各クリーチャーのオーディオを作成する上で達成しようとしたのは、信ぴょう性と感情性の2つでした。どのクリーチャーも信ぴょう性のある、アウター・ワールドの世界独自の音を出すように、努力しました。多くの場合、この世でない音なのに、なじみのある感じがするものをつくるようにしました。さらに、クリーチャーがプレイヤーの気持ちに作用するような効果があるように心がけました。クリーチャーの存在目的は、プレイヤーを脅かしたり、危機感を感じさせたり、逆に安心感や和みを感じさせることであったりします。どのクリーチャーも共通して周囲の環境のストーリーを伝えることに意義があります。それでは、信ぴょう性のある効果的なクリーチャーオーディオを作成するという目標を目指して私たちがしたことを紹介します。
デザイン前の検討事項
クリーチャーの特徴
クリーチャーのオーディオデザインに取り組むにあたり、まずはそれぞれの生理的な特徴に目を向けました。つまり、各クリーチャーの身体的なつくりと、ボディの構造を考慮しました。そこから発展させて、オーディオソースをキャプチャしたり編集したりするときに何を意識するのか、その方向性を明確にしました。アウター・ワールドでクリーチャーのサウンドセットをつくる上で、その手法の決め手となったポイントを、いくつか紹介します。
マンティサウルスは大型の虫クリーチャーで、このゲームの最も手ごわい敵の一種です。うろこ状の外骨格と恐ろしい大顎があり、細かく神経質な動きをします。このため甲高いクリックのような要素やスタッカートが入ったデザインになりました。
バイペッド（二足歩行）ロボットは、戦車のような大型のメタルボットです。ゆったりした力強い動きで、優しいのか敵視されるのかはプレイヤーが所属する派閥次第となります。重量感のあるつくりから、鉄のように重く合成的な音の要素に決まりました。
スプラットは、トカゲのような小動物で、かわいらしくピクピクとよく動きます。大抵はプレイヤーに優しく接してくれて、時には、まるで道案内をしてくれているようです。こんな性格から、かわいらしく好奇心旺盛の鳴き声の音の要素が求められました。
息づかい
クリーチャーの音声が現実的に感じられるように、もう1つ私たちが工夫したのが、息づかいのリズムです。通常の呼吸時に、たくさんの空気を必要とするような発声の前後は、大きく肺に空気を送り込みますが、息を吸い込むときに空気を「補給」し、息を吐き出すときに「排出」します。この考え方をアタック時などの大きい音声に応用して、可能な限り、大きく吐き出すようなアタックや奮闘の音の前に、吸い込む音をトリガーするようにしました。こうすることで、私たちが日常的になじんでいる、現実的な身体動作をクリーチャーに与えられます。私たちはクリーチャーのニーズや動きに合わせて表現方法を選びましたが、オーディオイベントを複数のPlayアクションや、Blend Containerや、Sequence Containerなどと組み合わせたり、アニメーション内の個別のイベントを活用するのが典型的な手法でした。それでは、実装例をいくつか紹介し、そのあとに詳しく説明します。
イヌ科動物のアタック、「吸入」付き
原始的なアタック、「吸入」付き
動作
動くときは、クリーチャーの呼吸がリズムよく繰り返されることが普通です。これはリズム感と体力を表現するために効果的なので、クリーチャーの動作にもできるだけ取り入れるようにしました。動作と呼吸音を使って自然なリズム感やリアルさをクリーチャーに付与した事例を、もう少し紹介します。
原始的な歩行リズム
ラプティドンの走行リズム
マンティサウルスのアタックのリズム
実装と微調整のながれ
クリーチャーのActor-Mixerをクリーチャーのサウンドタイプ別に分けたおかげで、PriorityやVoice Limitingといった重要なパラメータ設定を非常に細かく制御できました。また、ミキサーごとにPositioning設定を微妙に変えました。例えば、フォーリーサウンドであれば減衰半径を比較的小さくした一方、クリーチャーのコンバット音声やウェポン音はもっと遠くからも聞こえるようにして、コンバット中のプレイヤーに適したフィードバックが聞こえるようにしています。
クリーチャーのウェポンのAttenuation Shareset
クリーチャー音をトリガーするために、様々なサウンドオブジェクトコンテナを使っています。Sequence Containerや、ディレイ時間を設定したBlend Containerや、複数のPlay Actionを設定したイベントなどを使い、音の大きい音声のあとの息の吸い込み音を実装したり、おしゃべりなタイプのクリーチャーでは、音声にリズム感を出すために呼吸を活用したりしています。クリーチャーによって実装の条件が異なるので、複数の切り口からトリガーの仕方や制御方法を設定できるのは助かりました。Wwiseは、こういったことを多くの項目でうまく設定できるツールです。
エミッターパスのオートメーション
アウター・ワールドのクリーチャーは、接近戦や離れた距離からの攻撃など、数種類が可能です。爪で襲ってくるような近距離の攻撃には、下図のようにエミッターのパスのオートメーションをWwiseで描き、ステレオフィールドを横切るような動作にしました。クリーチャーの肢が空を切るアニメーションを追う「殴打」のサウンドオブジェクトのための、シンプルな通過線です。このようにちょっとした編集ができるおかげで、クリーチャーの攻撃に躍動感と現実味を出せます。
独自ツール
私たちの社内開発ツールでも色々とできるので、その一部をうまく使って「Chatter イベント」でクリーチャーオーディオをトリガーさせました。これは、キャラクターがとる特定のAI行動やState（「パーソナルスペース進入」、「調査」、「ターゲット喪失」、「ターゲット再確認」など）に基づいてトリガーされるイベントです。サウンドデザイナーにも役立つ機能で、一定のState（状態）にクリーチャーが出入りしたときに音をトリガーするように設定できるので、たとえStateを出入りするときのサウンドイベントを添付できるような関連アニメーションがなくても大丈夫です。このシステムに組み込まれた「プライオリティ」や「クールダウン」といったプロパティを、イベント別やGroup別に設定できるので、うまく利用すればクリーチャーごとのイベントの流れをコントロールできます。
クリーチャーのChatter イベント
ゲーム中のロボットのChatter イベントの 'Personal Space Enter'
UNREAL ENGINE 4: アニメーション タイムライン イベント
一般的によくあるように、私たちもアニメーションタイムラインを使ってクリーチャーの様々なアクションに対応したオーディオイベントをトリガーしています。アニメーションタイムラインをクリーチャー音の大部分に利用していますが、それ以外にもクリーチャーの「ガヤ」も対象にしていて、遠くにあるクリーチャーの音声が聞こえてきたら、それに近づいている証拠だということを表現しています。距離に応じた処理を施したクリーチャー音声をトリガーさせて、まだ邪魔の入る前の自然環境にいるクリーチャーをシミュレーションして、環境アンビエンスの補強に役立つようにしたのです。
クリーチャーの「ガヤ」イベントをトリガーするのは、コンバットの外野にある待ち受け状態のアニメーションで、遠くの敵クリーチャーの存在を知らせてくれます。プレイヤーは、現在位置についての情報や、周辺のクリーチャーのだいたいの密集度など、役に立つフィードバックを得られるほか、コンテキストに準じた雰囲気がレベルのアンビエンスに追加されます。
Creature Walla（クリーチャーのガヤ）サウンドオブジェクトは、距離のRTPC、Priority、Voice Limiting、Virtual Voice動作などで制御して、ミキシングをしやすくして、ボイス数の増えすぎを防止しています。プライマリークリーチャーたちによってトリガーされるCreature Walla音が、種族につき2セットずつあります。どのサウンドオブジェクトが聞こえてくるのかを細かくコントロールできるように、これらオブジェクトがPhysical Voiceとなる通過口を距離やプライオリティによって定義しました。Wallaオブジェクトが聞こえるのは4000～6000 Wwiseユニット（40m～60m）で、Ambientオブジェクトが聞こえるのは6000～8000 Wwiseユニット（60m～80m）です。4000未満の距離ではワールド内のアイドリング中のクリーチャーたちが明確に見えていて、その時点でプレイヤーに会う可能性の範囲内に入っているので、クリーチャーたちの同期されたアニメーションオーディオが使われます。一方、アイドリング状態のアニメーションのオーディオイベントは順次コードとVirtual Voice動作設定の両方によって、消去されていきます。このようにして、プレイヤーからクリーチャーまでの距離に関わらずサウンドオブジェクト全体の一部だけが聞こえるように制限しています。
これらのイベントに、ProbabilityやDelayを使った複数のPlayアクションを設定して、自然界でクリーチャーたちが呼び合う様子をシミュレーションしました。
私はAbleton Liveに標準装備されているモジュレーションツール（LFO、エンベロープ）を利用して、クリーチャーのデザイン済みボーカルから、新しいアセットをつくり出しました。これらのモジュレータが、ボーカルサンプルのピッチと振幅の両方に、わずかにランダムなモジュレーションを常時適用しました。さらに、プリフェーダーのリバーブとディレイの両方のリターンのトラックと組み合わせると、各クリーチャーの遠距離のボーカルサウンドとして、定型化されたものを効率的に作成できたのです。
Abletonエフェクトチェインの、遠くにいるクリーチャーのガヤ処理
クリーチャーのゲーム内ガヤ
パラメータやミキシング
プレイヤーの気をひくために、クリーチャーオーディオにWwiseの組み込みパラメータを多用しています。プレイヤーに送るオーディオフィードバックが洗練されるだけでなく、状況によってはミックスをもっとはっきりさせるのに役立ちました。
Listener Coneパラメータを使い、プレイヤーの後ろにいるクリーチャーのボリュームと存在感を少しだけ目立たないようにしています。
Azimuthパラメータを使い、プレイヤー視野の直近にいるクリーチャーを強調するとともに、プレイヤーの視野の左はじや右はじにいるクリーチャーには、わずかなリバーブ増強を加えました。
Elevationパラメータを使いプレイヤーのかなり上やかなり下にいるクリーチャーのボリュームと存在感を減衰させるとともに、その深度を深めるためにわずかなリバーブ増強を加えました。
このゲームのほかの多くのサウンドと同様に、クリーチャーもGame-defined設定のリバーブに送って環境内のクリーチャーの位置に深度を付与しています。またGame-definedのセンドをフィルターにかけ、Abbey Roadエフェクトをシミュレーションしています。このモジュレーションの目的は、リバーブのリターンシグナルで過度の周波数の増加を避けて、よりクリーンなウェットとトライのミックスを達成することです。こうすることでクリーチャーオーディオが環境アンビエンスの中で、もっと自然におさまると私たちは考えました。
>音楽
アウター・ワールドにおける音楽の目的は、プレイヤーがハルシオンというコロニーと、その環境内を進むときに、プレイヤーを引き込んで感情を高ぶらせることでした。統一感のある印象に残るスコアであると同時に、不必要に音楽ばかりに注目が当たらないように意識し、背景になじむ最小限のものにしました。ゲームの主要なクエスト領域のほとんどに、独自のExploration（探検）用とCombat（対決）用のミュージックがあり、そのエリアのワールドの編成とサブストーリーを表現するために作曲されています。ゲームにとって探検が非常に重要な部分で、プレイヤーはそれに長い時間をかけるので、そのミュージックトラック自体も長くなり、だいたい5～8分ほどです。
感情を揺り動かすために、音楽をどのように活用したか
- 特に最初の方では瞬間ごとスクリプトをたくさん行い、主要テーマの音楽を全体に散りばめて統一感を出しました
- モジュラーでリアクティブな音楽もあります
- インタラクティブミュージックシステムを事例を通して説明します
- Wwiseでインタラクティブミュージックをどのように整理したかを説明します
Interactive Music Hierarchyの構成
ゲーム全体で、主にSwitchコンテナを1つとState Groupを1つ使い、部分的にStateやRTPCやMusic Trackスイッチを追加しました。このState Groupに合計203のStateがあります。Stateには、以下の2つの音楽カテゴリーがあります。
- デフォルトのマップミュージック、つまりExploration音楽とCombat音楽
- 筋書きのある（Scripted）音楽、つまりナレーションやプレイヤー行動に合わせてデフォルトミュージックをオーバーライドするかもしれない音楽
大きいState Groupを1つと、マスターSwitchを1つで進めることにしたのは、プレイヤーがそのときの音楽から一瞬でほかの音楽ピースに移った場合に対応できるようにしたかったからで、よくできたWwiseのトランジションマネージャ機能を活用して、音楽的におかしくないトランジションを確保するためです。これについては後述します。
Stateについてここで一言。203個ものStateの入ったState Groupは管理が大変で、WwiseのEditor内で探すのも時間がかかります。一貫した分かりやすい命名規則を取り入れることが不可欠でした。Obsidianでは、各レベルにレベルデザイナーが固有の番号を振ってプレフィックスとして設定しています。私たちは、音楽を主にレベルごとにまとめるので（下図もそのとおりです）、レベル別の固有識別番号をState名に入れることで整理しやすくしました。さらにミュージックスイッチに使う予定のないStateをマーカーとして追加し、レベルとレベルの境目が見て分かるようにしました。
インタラクティブミュージックの基本的な流れ
ほとんどの場合、アウター・ワールドの音楽のインタラクティブ性は非常に基本的なもので、主にExploration musicとCombat musicの間のシンプルなトランジションで成立しています。一連の流れは、自由にオーバーライドを設定して、条件がそろえばScripted musicをトリガーできるようになっています。プレイヤーが任意のマップをロードしだすと、そのレベルのExploration musicがロード画面で再生され始め、プレイヤーが待っている間に先に雰囲気を出します。そしてプレイヤーがマップに入ると、次にExploration musicとなり、Combatによって中断されるまで、またはスクリプトでオーバーライドされるまで、続きます。Combatが終了したり、Scripted musicがクリアされたりした時点で、Exploration musicが復帰します。プレイヤーが今のマップを離れると、今の音楽がフェードアウトして、また最初から始まります。基本的なStateの仕組みは、次のような形です。
ミュージックマネージャ
音楽のState間の切り替わりを確実に、そして体系的に管理するためには、プログラミングされたソリューションで対応する必要がありました。Obsidianの優秀なゲームプレイプログラマーの1人、Jerad Dunnが、シンプルかつ高性能なミュージックマネージャシステムを書いてくれ、これがゲームとWwiseの間に入り、以下を実現してくれました。
- すべてのデフォルト音楽を、適切なタイミングでトリガーすること
- 特別なスクリプトで指示するオーバーライドは、そのStateが「永続的に」保存されること
Obsidianでは、何かのゲームStateの現状をsaveファイルに保存して、saveをリロードしたときにそれを取得できるようにすることを、「persistence（永続性）」と呼んでいます。音楽の観点から言うと、デフォルト音楽をオーバーライドした場合に、プレイヤーがゲームをセーブしてあとから再ロードすることを選べば、デフォルトミュージックが必ずオーバーライドされたままになることを意味します。
また、このミュージックマネージャがあると、アウター・ワールドの合計43個のマップに、それぞれのExploration musicとCombat musicのデフォルト版セットを定義できます。どのマップにも、専用のExploration musicとCombat musicが含まれ、それをデータで定義しています。また、条件に基づくオーバーライド設定もマップごとに定義されています。オーバーライドはゲームプレイ中にいつでもトリガーすることができ、デフォルトの流れであるExploration>Combat>Explorationというトランジション動作を、完全にオーバーライドできます。条件に従い特定の音楽がアクティブになれば、たとえプレイヤーがCombatに携わったとしても、Combat musicはトリガーされません。Scripted musicを出るには、さらに別のスクリプトが必要で、いったん出ると、下図のようにミュージックマネージャがExploration musicの再生を再開し、Combat musicをトリガーすることも再び可能になります。
このデータの保存方法を説明します。アウター・ワールドはUnreal 4を使って開発され、私たちは1つのData Assetを使ってExploration musicやCombat musicとしてどの音楽をデフォルトでトリガーするのかを指定しました。また、音楽の条件を設定するのにも、同じData Assetを使いました。こちらが、そのMusic Gameplay Settings Data Assetで、図の下に主な特徴を説明しています。
- A - このマップのデフォルトExploration musicを定義
- B - このマップのデフォルトCombat musicを定義
- C - ここにConditional（条件付き）の音楽を追加できます。ユーザーが定義するアレイで、順番を変えられます。ゲームがロジックフローを、アレイの上から下へ読み込みます。
- D - 条件の内容を定義します。Obsidianではユーザーが定義できるGlobal Variablesという条件があり、例えばクエストのStateをトラッキングしたりするのに使い、そのVariables（変数）は永続的に保存されます。
- E - 条件がそろったときにトリガーする音楽を、ここで定義します
ミュージックシステムがすべてのフレームチェックをチェックして、Data AssetにあるGlobal Variableのどれかがアップデートされていないかを確認します。変化を検知すると、すぐに、Conditional音楽のアレイの中で、最初に条件を満たすConditionalに紐づけられた音楽を、再生します。実際にいつ、その音楽をトリガーするのかは、Wwiseで設定したTransition設定によって決まります。
Scripted Interactive Musicの事例A
ゲームのストーリー展開に合わせて、Conditional音楽で内容をサポートする方法は2種類あります。まず、プレイヤーがゲームのある領域を進むときに、いくつかのイベントを順番に続けることによって、レイヤーを重ねるように新しい音楽をトリガーする方法です。これを行うときは、全体の流れのうち、1つのパートが、音楽的に有機的で、なじんだ形で、次のパートにつながるように、私たちはかなり気を使いました。
ゲームの初期スタートエリアがその代表例で、プレイヤーが自分の未来の宇宙船「アンリライアブル」に遭遇するまでの場面です。この部分のゲームは比較的リニアで、途中の大事なポイントを元に、音楽が変化します。以下がそのポイントの概要です。
A. プレイヤーが惑星エメラルド・ヴェールに不時着して、脱出ポッドから降りるとき（exits pod）
B. プレイヤーがGuard Pelhamと話すとき
C. プレイヤーがイントロの洞窟を出てMarauderたちに出会うとき
D. プレイヤーが初めてアンリライアブル（Unreliable）を目にするとき。
E. 道程のこの時点で、プレイヤーは次のどちらかを選びます
i. アンリライアブル（Unreliable）に乗り込み、探検する
ii. 無視して、エメラルド・ヴェール（Emerald Vale）の探検を開始する
ステップ3までは、全体的にリニアで、プレイヤーがリニアなパスに束縛されているので、音楽のスクリプトもわりと単純明快です。やがてプレイヤーが自由に行動できるようになり、選択が必ずしも予想できないので、少しややこしくなります。このため、私たちは心地よい音楽フローを維持しながらも、プレイヤーの選択にどう対応するかを、決断する必要があります。そこでステップ4のConditional musicの論理フローが少しだけ複雑になり、音楽がプレイヤーに気付かれないように変化するようにしました。
さて、プレイヤーがエメラルド・ヴェールに不時着した瞬間から、プレイヤーが自由にワールドを探検できるポイントまでの、完全な音楽フローと、実際のゲーム中の場面の動画を2本、ご覧ください。
WwiseのMusic Transition
ミュージックトランジションはWwiseのオンラインチュートリアルで説明されている程度で、なにも特別なことはしていません。ただデフォルトのトランジションに関しては、マップからマップで一貫性を確保しやすいようにしつつ、上で説明したようなスクリプト付きシーケンス時には専用のトランジションを別途設定できるように、Interactive Music Hierarchy内の構成を工夫しました。
前述の通り、このゲームではたった1つのSwitchコンテナを使っています。この中に、Virtual Folderを複数設けてゲーム内の音楽を機能別に整理して、例えばExploration、Combat、Scripted、Globalなどにグループ分けしています。
Wwiseではバーチャルフォルダ間のトランジションが可能で、音楽ピースが大量にあってトランジションルールをいちいちカスタムスクリプトで設定したくない場合は、とても便利です。カスタム設定はとても時間がかかるほか、ユーザーエラーが発生しやすくなります。わたしたちはこのトランジション機能を頻繁に使ってバグ件数を減らし、マップからマップへのトランジションの一貫性を保ちました。特にExploration（下図では"Ambient"）からCombat、またCombatからExplorationなどのデフォルトトランジションのために、この方法が特に実用的でした。
カスタムマーカーを取り入れてバラエティ豊かに
私たちが一つ試してみたのは、CombatからExplorationへ繰り返されるトランジションの細分化でした。そのためには、Combatからほかへトランジションするときは、Destination>Sync>Random Custom Cueというトランジション動作を活用しました。
Custom Cueを、Explorationトラックのミュージックセグメントの考え抜かれたポイントに追加して、必ずトランジションが音楽的に聞けるようにしました。音楽をフェードインさせるのではなく、できるだけダウンビートで再開したかのように聞こえるようにしましたが、時々ゲーム内で、動作設定の存在感がある場合がありました。幸いExploration音楽にはネガティブスペースがたっぷりあるので、音楽の開始ポイントを達成するのはさほど難しくなかったです。
それでは、Emerald Valeの場面ののExplorationミュージックにあるCustom Cueの画像とサウンド例を紹介します。
Combat音楽 から Exploration音楽、Transition A |
|
Combat音楽 から Exploration音楽、Transition B |
|
Combat音楽 から Exploration音楽、Transition C |
|
エミッターとアンビエンス
アウター・ワールドをつくるにあたり、最初から、時間とお金をおしまず多数のエミッターを作成して実装するつもりでした。Obsidianでは、プレイヤーがストーリーやキャラクターやワールドにどんどんと引き込まれていくようなゲームをつくるので、私たちはワールドの環境オーディオで、それを強化したく、まるで 本物 のようにしたかったのです。
それでは、"Geothermal Plant"レベルのAk Ambient Objectの事例です。
ワールドのリアル感を実現する上で、「このワールドは実際、どんな風に聞こえるのか？」という疑問がありました。ハルシオンでは、ダンジョンや、民家や、工場などのいたるところに、機械類が散らかっています。機械類が今にも崩壊しそうな感じにしたかったので、機械が非常に効率悪く動いていて、ガラクタの山のような、崩れてしまいそうな音をつくることを目指しました。実現のために三研マイクロフォンのCO-100kで、よく社内の素晴らしい舞台装置ライブラリから探してきたガラクタやら金属製の舞台装置やらを収録しました。このマイクのすごいところは、とても高いサンプルレートでレコーディングできるので、レコーディングのピッチを2、3オクターブ下げないと、高周波ロールオフが分かるくらいにならない、ということです。おかげでリッチで信ぴょう性のあるテキスチャを入手でき、生命とワールド建設のテキスチャを、マシンに与えることができました。
アウター・ワールドに存在する様々なもののうち、どれにオーディオエミッターを付与すべきかの決断は、有機的なプロセスでした。ダンジョンや村を1つロードして、そこを飛び回りながら、どこのディテールを重視すればプレイヤーを引き込むための最大の費用対効果を得られるのかを洗い出しました。結果的に何百、いやシーンによっては何千というエミッターがエリア内各地に配置されました。最大で「最重要」のエミッターを優先するように気を付けたのですが、プレイヤーエクスペリエンスへの付加価値が最も高いエミッターを取り逃す羽目になり、あとから痛い目に会いました。
これだけ多くのエミッターをWwiseで管理するとなると、分かりやすいグループにまとめたいと思いましたが、同時に、通常のエミッターと比較して特別仕様の処理が必要となる「ギリギリのライン」のエミッターがどうしても出てくるので、それに柔軟に対応することも心掛けました。そこで、エミッター用に4つのActor-Mixerを用意しましたが、それが Emitter_Small、Emitter_Medium、Emitter_Large、そしてEmitter_Unique です（あとから思えば、もう1層か2層くらいに小分けしても良かったのかもしれません）。この形式のおかげで、サウンドをつくったら、それを4つのActor-Mixerのどれかに入れるだけで済み、減衰半径やRTPCなどの属性は、その時点でそっくり継承できます。唯一の例外がEmitter_Uniqueに入れたサウンドで、それらには特別または変則的な減衰カーブが必要となりました。このようにしてサウンドデザインの作業やイテレーションを手っ取り早く行いながらWwiseにサウンドを入れていく過程で、どのようなパラメータが設定されているのかを正確に把握することができました。
エミッターには、組込みパラメータのListener-ConeとElevationをうまく使いました。ゲームでは小さな電気スパークのVFXが出てきますが、それのために実装したサウンドが、良い例です。このVFXはとても頻繁に出てきて、ビジュアルとしては結構大きい電気破裂音が求められました。さて、このVFXに紐づけた音は、プレイヤーが何回も繰り返し聞けば、すぐに耳障りになるのが想像できました。そこでかなり強気のRTPCカーブを追加して、音のボリュームとLPFがListener Coneで変動するようにしました。プレイヤーが火花のパルスを直視しているときは、大きく気をひくような音が聞こえますが、このエミッターから顔をそむけた瞬間、ほとんど聞こえなくなるという設定です。「見えなければ、忘れよう」という考え方です。プレイヤーは火花のパルスが聞こえなくても、火花自体が視野に入っていないので気づかず、ミックスに余裕が生まれ、プレイヤーにとって繰り返され過ぎる音を防止できました。
エミッターに、WwiseのOcclusionパラメータを活用しました。というのも、エミッターのAudio Busを複数のサブバスに分けたのです。1つには完全なオクルージョンを設定し、別のものは一部オクルージョン、そしてもう1つはオクルージョンなし、としました。これを使い、音がドアを通して普通に聞こえるのか、それともくぐもった小さい音になるのか、またはエミッターとリスナー（つまりプレイヤー）の間に閉じたドアがあればミュートにするべきなのかを、決めました。
アウター・ワールドの開発で苦労したことの1つは、ゲーム全体でエミッターを、一貫性のあるかたちで、正確に、タイムリーに広めてくれる確かなシステムを設けることでした。レベル内にあるスタティックメッシュを認識して、そのスタティックメッシュに、ゲームオブジェクトにアサインされている特定プロパティ（例えば正しいWwise イベントなど）をもったAk Ambient Soundをスポーンさせるツールを、テクニカルサウンドデザイナーのJerrick Floresが用意してくれました。おかげで、アンビエントエミッターを実に素早く配置することができ、サウンドデザインやミキシング要素のイテレーションにかける時間を増やせました。開発のフォーカスが、マニュアル作業による実装から、プレイヤーエクスペリエンスの試行錯誤へと切り替わりました。
ビフォー
アフター
ビフォー
アフター
このような形でエミッターを作成して実装していくなか、最適化とパフォーマンスの問題が生じました。最初の問題は、登録済みオブジェクト（Registered Objects）の数です。エミッターツールを稼働させるシーンによっては、作成されるエミッターの数が単純に多すぎるという状況がありました。ツール側は、スタティックメッシュがなぜか地中にあったとしても、プレイヤーに決して届かない地上から30メートルも離れた小さな電球であっても、配慮してくれません。そのスタティックメッシュのために適切なエミッターを配置してしまうのです。エミッターをスポーンするこのツールを使ったあと、まず最初に行ったのが、つくられたエミッターをすべて品質確認して、不要なものや、絶対に聞くことのないものを削除することでした。かなり時間がかかることもありましたが、オーディオスレッドを節約できるので、見返りは大きかったです。次に解消が必要だったのはボイスカウント（Number of voices）で、最初は全エミッターがバーチャルボイスに送られていて、確かにフィジカルボイスほどの負荷はなかったのですが、それでも塵も積もれば、というわけで、数百個のエミッターがあると負担が顕著でした。そこで、レベルごとに決めたAk Ambient Soundオブジェクトの規定半径よりも外側にある場合は、その音を間引くことができる機能が欲しいということになり、プログラミング側のサポートをお願いしました。「間引き半径」なるものを使い、もし半径よりも外側にあれば、ボイスをバーチャル化するのではなく停止させました。つまり、あるレベルにエミッターが500もあれば、一度に聞こえるボイスの合計数を最大15～20個のボイスに抑えることができ、例えば10のフィジカルボイスと、490のバーチャルボイスとなってしまうような状況を避けられます。この違いは大きかったです。
ゲームのアンビエンスに関しては、信ぴょう性のある面白くて細部にこだわりのある雰囲気をプレイヤーに届けることと、ゲーム全体に対応できるモジュラー性が大事だと考えました。
ゲームの全エリアが対象になるような範囲を確保するために、Exterior BedsとRoomtonesの2つのカテゴリにゲーム内の領域を分けました。Exterior Bedsは、それぞれアサインしたエリア（Emerald Vale、Roseway、Monarch、Edgewaterなど）に固有ですが、Roomtonesは、ゲームの全エリアに共通して使えます。基本的に、ゲームに存在するすべてのマテリアルタイプと、ルームの大きさの、マトリックスを作成して、それらのエリアのためのベッドを作成しました。結果的に、このようになりました:
1つのRoomtoneに対し、そのルームトーンの種類に応じたリバーブやディレイを設定しました。
おかげで、これらのルームトーンをゲームの全屋内環境で使いつつ、適切なスペーシャリゼーションや部屋の大きさを適宜、表現できました。
また、Jerrickがレベルの全アンビエンスボリュームをスキャンして、どんなアンビエンスイベントかによって、ボリュームに対してアンビエンスのワンショットイベントをアサインするツールを作りました。つまり、特定のルームトーンと必ずペアで再生される一連のイベントをつくったのです。例えば、"amb_roomtone_wood_medium"は、必ず次のようなワンショットイベントを使います: "amb_os_small_wood_creak"、 "amb_os_bathroom_misc"、 "amb_os_small_lightbulb"、 "amb_os_small_buzz"、 "amb_os_small_pipe_pressure"。
これら基本レベルのワンショットを、専用のAk Ambient Soundオブジェクトで補強することもありました。ダンジョンには一連のワンショットが専用にあるので、それらを使い、もっと危険に感じてほしいときなど、具体的なムードを引き出すために使いました。
次に、必ずListener with Automation 3D positionの設定を使うようにして、再生されるステレオフィールドの中の場所に対してランダム化されたパスを1つだけ用意して、使いました。また、Hold Listener Orientationの設定を有効にして、もしワンショットが再生され出したら、プレイヤーが向きを変えてもワンショットが一緒にパンニングするようにしました。こうするとプレイヤーも「地に足のついた」気になりやすく、周りで起こる様々なアクティビティが、実際に起きているように感じやすくなります。
以上が、全体のアンビエンスとワンショットのオーディオの仕組みとなっている基本構成です！これで、私たちはレベルを1つ開いて、「さあ、プレイヤーがここにいるときに、どのような気持ちになってほしいか」と考えることができました。次にその雰囲気を発展させるために、イベントを1つずつ計画していきました。自由に試行錯誤できて、楽しみながら作業を進めることのできる方法でした。ゲームの空間をうめていくのにも、ずいぶん役立ったと思います。
アンビエンスを極めるために最後にやったのが、アンビエンスがドア経由で外部から屋内へ伝播するのをシミュレーションすることでした。私たちの現行システムでは、屋外の空間から屋内の空間に遷移した瞬間に、外部アンビエンスがフェードアウトして屋内ルームトーンがフェードインするので、これができませんでした。いったん屋外がフェードアウトすると屋内に染み込んでくる外部音がなくなり、ドアが開放されているエリアでの没入感は薄れてしまいました。私たちは解決策として、アンビエンス（該当する場合はガヤも）をベークしたものを再生するエミッターを配置しました。この音はドアが閉まると完全にドアで遮られるようにしたので（オクルージョン）、期待通りに屋外音が聞こえなくなります。
VOとChatter（チャター）
アウター・ワールドはRPGのタイトルなのでVOチャター（ボイスオーバーおしゃべり）システムが、このゲームでオーディオ観点から不可欠でした。ゲームに出てくる豊富なキャラクターたちと、彼らの様々なセリフや声優の様々なパフォーマンスがあるので、膨大な数のVOが入っています。アウター・ワールドはチャター（おしゃべり）のVOとその派生したバージョンで、ソースファイルが34,000個以上あります。
これだけのVOを取り扱えるチャターシステムを構築するにあたり、チャターで達成しようとする目的を明確にすることが大事でした。
最終的に、チャターは「ゲームデザインの意図を表現するもの」であるという考えに行きつきました。別の言い方をすると、チャターの主目的は関連するゲームプレイイベントを強化することです。ライターは、チャターのセリフを簡素化して、コンバット中でもすぐに理解できるようにしつつ、セリフの意図が隠されない程度にワールド構築の役目も担えるように、チャター自体をワールドのコンテキストに沿って設定しました。実装面では、プライオリティの高いイベントが、より低いプライオリティの再生中のイベントを中断（または新たにトリガーされたものを停止）できるように、イベント用プライオリティシステムをつくりました。おかげで、チャターは、もっと重要なゲームプレイイベントが発生しない限り、中断されることなく再生されるようになりました。
この考え方は、ゲームの中の仲間の、チャター作成プロセスに大きく影響しました。具体的には、彼らのチャターをもっと生き生きとさせるために、現在のゲームプレイの内容を表現するVOパフォーマンスとして"Out of Combat" 、 "Stealth" 、 "In Combat" を設定しました。このように、チャターの一部のセリフは、再生できるゲームのコンテキストが限定されていて、さらにおもしろいのが、チャターの一部のセリフに、ゲームのコンテキストによって決まるパフォーマンスが数種類、用意されていることです。コンテキストに左右されないようなゲームプレイイベントにアタッチされたイベントに、1つのセリフを使ったとしても、再生される度にコンテキストに対応しているので、キャラクターがワールドの中にいるという気持ちが深まります。例えば、何らかの行動を了解するときに仲間が発する汎用的なセリフも、以下のように反応型のセリフになります。
ワールドを歩き回りながら景色を眺めているときに、仲間のFelixに、少し見渡して来てごらん、と言う場合は？ 「On the move.（移動中だよ。）」
警備付き施設の周りを偵察しているときに、本当は 中に入ってはいけないのに、Felixに、もっと有利な奇襲ポジションに移動するように言う場合は？ 「On the move.」
命中すると顔が溶けてしまうライフルを振り回す警備隊との銃撃戦の真っ最中に、Felixに、避難して隠れるように言う場合は？「ON THE MOVE!!"」
その時の状況に反応できているのは、ゲーム内の プレイヤーのコンテキスト、つまりプレイヤーの現在のStateに基づいて、再生条件をゲーム側に合わせているからです。仲間のイベントを、プレイヤーのコンテキストに従い再生することで、 プレイヤーがゲームプレイとして何をやっている最中なのかを尊重し、プレイヤーの感情をさらに強化します。プレイヤーがステルス状態のときは仲間同士の会話がひそひそ声になり、コンバット以外のときは普通に話し、コンバット中は大声を出し合う様子を、こちらで確認してください。
最後に、コンテキストによって差をさらに強めるために、VOのプロジェクションレベルを、コンテキストに基づいて適切な表現レベルにすることに注力しました。こうしてボーカルを「激しさ」という目盛で整理して、ターゲットまでの距離を用いて、セリフをどれほど大きい音にすべきかを判断しました。特にコンバット状態のように強さ（Intensity）が異なる複数のVOが同時にあるときは、その違いがよく分かります。
Intensity 1(1 ft.) |
|
Intensity 2(2-3 ft.) |
|
Intensity 3(3-5 ft.) |
|
Intensity 3.5(7-10 ft.) |
|
Intensity 4(10-15 ft.) |
|
Intensity 4.5(15 ft.+) |
|
Intensity 5(20 ft.+) |
|
根本的に、アセットの全体的なゲインはあまり変わらないかもしれませんが、激しさを投影するという追加の処理で、イベントやVOが形成され、ゲームデザインの意図が強化されます。そしてすべてを統合して、プレイヤーがゲームプレイのループを突き進んでいくのに合わせて、常にゲームデザインの意図をプレイヤーに聞かせることのできるチャッターとなります。
さて、これだけ多くのVO（繰り返しますが、チャッター用に34,000以上のVOセリフがあり、ダイアログまで合わせると、合計50,000以上！）をどのように実装したかというと、コア部分で、私たちの独自ツールがWwiseやゲームと、 外部ソースを経由して、インターフェースで接続するのです。
ハイレベルで見ると、以下のようにシステムの役割が分かれています。
|
ゲームコード |
Wwise |
|
|
ゲーム側では、VOを再生するときに、以下を行うVOプレイヤーがいます（イメージ図の下に手順を説明）:
1. ゲーム内でイベントが起きたときに...
2. VOプレイヤーを使い...
3. キャラクターや、そのキャラクターが言うセリフなどに基づいて、サウンドイベントのプールを選択し、インスタンスを1つ取得します。
4. 選択したプールから、次に空いているサウンドイベント名を選択します。
a.このサウンドエフェクトは、Wwise External Sourceで、汎用のSound Voiceを再生します。コンテキストに応じて異なる減衰カーブが必要になるので、これに従い、サウンドボイスやサウンドイベントを分けます。
5. サウンドイベント名を、VO Playerにパスします。
6. .wemファイルパスで、適切なAkExternalSourceInfoオブジェクトを作成し（すでに手順の1と2の間でゲームコードで決定済み）、コールバックや、コーデック情報のために用意します。
7. 獲得したサウンドイベントをポストして、新規作成した AkExternalSourceInfoオブジェクトを渡します。
ヘルメット用の、ランタイムのVO処理
私たちはプログラミング担当チームと協力して、プレイヤーが装着中のヘッドギアの種類によって、キャラクターのボイス処理エフェクトをダイナミックに適用するシステムを実現しました。このシステムの目的は、プレイヤーや仲間に適用できる多数の武装コンフィギュレーションを、いつでも、効率的に表現することでした。Unrealで、ボイス処理に関連付けるヘルメットアートのアセットがどれかを、指定できました。これらのヘルメット（そしてマスク）のアセットを、私たちがWwiseで作成したRTPCに紐づけることができるように、ゲームプレイのタグを取り入れたシステムを使いました。結果的に、4種類のRTPCができました: HelmetArmor、 HelmetMask、 HelmetScience、そして None。もしキャラクターが特定タイプのヘルメットを装着中であれば、そのキャラクターは、今つけているヘルメットアセットに対応するRTPC値として、1をWwiseに送ります。このパラメータデータがいったんWwiseに到着すると、パラメータを使ってキャラクターのVOに変化を与えます。
Unrealのデータと、RTPCの定義
WwiseのVoice Actor-Mixer Hierarchyに、親のVoiceミキサーにインサートした組み込みエフェクトがいくつかあります。これらのエフェクトはUnrealで作成して命名してアサインしたパラメータによって、起動されたり変化したりします。私たちはランタイムのVO処理の基盤として機能するEffectシェアセットを、いくつかデザインしました。処理スタイル（Science、Mask、Helmet）はすべて、ベースとなるエフェクトが共通していますが（Parametric EQ、Flanger、Guitar Distortion）、各Effect Sharesetのモジュレーションや組み替えなどにRTPCを使い、足したり引いたりして、エフェクトのフレーバーを数種類、つくり出しています。今回対応した3種類のボイス処理スタイルを、以下に示します。
HelmetArmor: 中型から大型のプラスチックまたは金属製のヘルメット（重度のParametric EQ マッフルエフェクト、中程度のGuitar Distortion、軽い Flanger）
HelmetArmor VO処理を、警備隊に対して
HelmetMask: 小型から中型のプラスチックまたは金属製のマスク（中程度のParametric EQマフラーエフェクト、軽度のGuitar Distortion）
HelmetMask VO処理を、仲間に対して
-HelmetScience: 小型から中型の、布製またはプラスチックのマスク（中程度のParametric EQマフラーエフェクト）
HelmetScience VO処理を、ベンダーに対して
None:処理なし
ボイスActor-Mixerエフェクト
Actor-Mixerパラメータ
RTPCはどれもブーリアン値で、アクターが装備中のヘルメットスタイルに基づいて、1（アクティブ）または0（非アクティブ）を、UnrealがWwiseに送ります。次のRTPCを使って各Effect Sharesetのパラメータのモジュレーションを行い、様々な方法でエフェクトの音を変化させます。処理後のエフェクトを複数組み合わせるために、複数のエフェクトに対して行います。例えばHelmetArmorがアクティブなときは、Guitar DistortionやFlangerのエフェクトを強く出し、HelmetScienceがアクティブなときは、固有のParametric EQカーブだけに頼ります。処理スタイルは、順番に処理が重くなり（Science > Mask > Helmet）、適用するエフェクトのカラーの量も強さも、大きくなります。また、RTPCはミキサーレベルでもEffectをバイパスするのに使い（もし処理タグNoneがアクティブであれば）、フィルターエフェクトを適用したときに、やや失われる全体のゲインを、補充する形で、一定のボリューム自動化を適用するのにも使います。
Effect Sharesetとパラメータ
ランタイムのVO処理をダイナミックに適用するためにつくったシステムは、柔軟でイテレーションが簡単にできるもので、最終的に、今回のサイズやスコープのゲームに適したものでした。このアイディアはまだまだ応用の余地があり、今後のプロジェクトでも実装できます。次回はWwiseのサードパーティエフェクト、例えばMcDSPエフェクトなども取り入れて、さらに広範囲におよぶVO処理スタイルをつくり出したいと思います。
スペーシャリゼーション
アウター・ワールドのオーディオスケープ全体で、大事な修飾要因となったのがスペーシャリゼーションです。これを使えば素晴らしいソニック精度と地理的に正確な情報を提供できると考え、没入感を向上させて、コンバットやストレスの最中に闘いに重要な情報を正確に伝えることを目指して、導入しました。
背景を説明すると、プロジェクトの制約もあり、WwiseのCORE機能の実装について検討する（また最適化する）ことができませんでした。その代わり、Wwise Spatial Audioで提供されるルーム（Room）やポータル（Portal）機能をゲームのいたるところで使い、深く可能性を探ろうと決めていました。
そのためにゲームコードでまず、ホリスティックなクラスを作成し、必要となるすべてのコンポーネントをそこに含めました。UnrealのTriggerVolume を継承するコードクラスを作成し、そこにAkLateReverbComponentと、AkRoomComponentを追加したほか、その他の利用のためのTArrayを追加してアンビエンスやStateの情報を入れることにしました。また、コンストラクターにロジックを少し追加してブラッシュコンポーネントを手に入れ、デフォルトのコリジョンプロパティをいくつか設定しました（これで、Unrealで複雑なボリューム形状を作ることも可能でした）。下図に示すこのクラスは、スペーシャル機能やアンビエンス（リバーブも含む）をコントロールする、何でも入るボリュームとなり、チーム内ではAmbientSpatialVolumeと呼んでいました。
次にゲームワールドにポータルを落とし込みました（まずポータルを追加して、次のステップのルームを描きやすくしました。）
今度は、ルームとなるAmbientSpatialVolumeをエリア全体に追加していき、ゲーム内の全マップにハイフィデリティのルームスケープを作成していきました。
さらに、これらの「ボリューム」をどこに、どのように描くかは私たちが完全にコントロールできたので、ゲーム全体にルームやポータルを実装するのに、工夫できる点を探りました。
例えば、廊下など急な曲がり角や隅がある線形のエリアを、複数のルームに分割して、廊下の一端の曲がり角の直前にポータルを置いてみました。そうすると、ポータルから音が出るという動作となり、音が曲がり角の向こうに「隠れる」ような状態がつくられ、音が角の向こう側の、具体的にどこから発信されるのかを判断するには、プレイヤーはこの角に接近せざるを得なくなりました。こっそり動くプレイヤーが、エリアのサウンドスケープが提供してくれる情報にもっと敏感に反応するのを促すので、通常のこっそりゲームプレイのループ音へ追加できます。
もう一つ、ルームとポータルの使い方にひねりを加えた例として、屋内の吹き抜けとなった縦型の部屋を、複数の階に分けて、各階に新しいルームを設定し、階と階の間の開放部にポータルを追加しました。そうすれば音は、発信元の階に物理的に存在して、プレイヤーの上部から聞こえてくるので、プレイヤーはそれに報復するなどの行動をとるときに、音を視界に入れるために移動できます。
このようなプロセスがすべて完了すると、深く堅牢な「ルームスケープ」がゲーム一体に出来上がりましたが、これから説明する通り、苦い経験がなかったわけではありません。
自動化:
ゲーム全般にAmbientSpatialVolumeとPortalを追加するパイプラインは、手作業でした。実に多くの時間がかかったプロセスで、人的エラーの可能性が非常に高くなります。私たちは、是非ともこれらのプロセスのどの部分でも、時間をかけて自動化することを推奨します。
私たちが開発した自動化プロセスの1つは、ポータルをドアに添付して、互いの動作をリンクさせるためのものです。どのドアにも、ドアを開・閉する動作で、ポータルの閉・開ができるブループリントロジックがついていますが、それにはポータルへのリファレンスを使うので、最初に手でフックアップするしかありませんでした。これがポータルの実装過程でも役立つことに気づいた私たちは、ドアのブループリントのコンストラクションスクリプトに、自動化機能をいくつか追加して、ドアから一定の範囲内にあるポータルをサーチして最も近いポータルが自動的にそのドアにリンクされるようにしました。おかげで、あるエリアに複数のポータルを追加してから、そのブループリントをリコンパイルすれば、そのレベル中の全ドアがそのスクリプトを実行してリンクする最寄りのポータルを探すので、該当する場合は接続されました。
これを自動化することで、あとから変更があって大量のドアやポータルを移動した場合も楽になり、ドアを移動するとコンストラクションスクリプトが移動処理の一貫として実行され、ポータルを移動したときは（またはすべてがフックアップされていることを再確認したいときは）、このブループリントをリコンパイルすればいいだけです。エンジン内で作業をするサウンドデザイナーであれば、このようなマニュアルプロセスこそ、かしこい自動化技術を取り入れることで目まぐるしくスピードアップするので、是非とも確認してみてください。
最適化:
今回、もう一つ学んだ大事なことは、最適化に関してです。私たちが挑んだ精密の度合いで、空間配置をもつ屋内のサウンドスケープをつくることは、CPUへの負荷が大きく、コンソールでWwiseを使ってAudio Thread CPUのデバグをすると、常に100%を超えていたほどでした。このゲームのすべてのオーディオシステムを最適化するのに、何回も何回もサイクルを回し、スペーシャリゼーションに対応できるようにCPUの解放を行いました。次を最適化しました:
- 登録オブジェクト数の削減: 最適化前は、密度の濃いエリアでは、Wwise Profilerを見ると1,000個以上の登録オブジェクトがありました。残念ながらプロジェクトの制約上、Wwiseへのオブジェクト登録を安全に処理するシステムを作成する機会に恵まれませんでした。正式な管理システムの代わりに、ゲーム内でAkComponent（とそれに伴う登録オブジェクト）を取り除いて、一時的な登録オブジェクトしか出さないPostEventAtLocation経由でサウンドを実装できてしまう場所を探し回りました。ワンショットの音では大体うまくいきましたが、ループ音に関しては、PostEventAtLocationは、ループを停止したいときなどに操作できるようなキャッシュできるオブジェクトを提供してくれないので、この手法だとバグが多発しました。結局、この手法をモジュールゲームオブジェクトに多用して、ドア、コンテナ、ワンショットVFXなどを対象に、1,000個以上あったそのような登録オブジェクトを、500個未満まで減らせました。
- バーチャルボイスの制御: 最初は、バーチャルボイスに送り込んでいるボイス総数を考慮することなく、バーチャルボイスを使っていました。必然的にバーチャルボイスの数が増えすぎてCPUがやられてしまい、これはVirtual Voice設定を変えても同じでした。一番問題となったのはAkAmbientSoundたちで、環境に生命感をたくさん与えるために大いに活用したのですが、ゲーム内の密度の濃いエリアでは一度に300個以上がロードされるはめになり、法外な数のバーチャルボイスとなってしまいました。そこでプログラマーたちに協力してもらい「間引きシステム」をゲーム内に投入して、一定の範囲内をプレイヤーが去ってから、そこに再入場したときのAkAmbientSoundのイベント再生を管理しました（一定の範囲とは、そのイベントのオーディオに設定された減衰半径よりも、わずかに長めに設定しました）。この管理システムがイベントを停止すると、そのイベントの使用を完全に消去するので、そのバーチャルボイスが占有していたリソースが再び解放され、AkAmbientSoundに起因する大量のバーチャルボイスの数は30未満に減らせました。
- アクティブボイスの制限: 最後に、最適化前はアクティブボイス数に制限を設けていなかったので、制限を設定したのは一番大きい最適化の1つとなり、CPUへの負担を解いてくれました。制限と言っても、Advanced Settingsタブで数字を1つ入れれば済む話ではなく、WwiseのActor-Mixer Hierarchyで様々なアクターミキサーがすべて、グローバルリミットに準拠できるように、全体の構成を工夫する必要がありました。そこでプロジェクトの再編成を行い、全体を担うProjectアクターミキサーをつくり、これにサウンドインスタンス数の上限を設け、その他のアクターミキサーや、Wwiseワークユニットを、すべてこのProjectアクターミキサーの中に入れ込みました。次にほかのアクターミキサーにも制限を追加して、必要に応じて特定のサウンドオブジェクトにも、制限をかけました。さらに、Playback Priority設定を多用して、すでにある制限を補強することで、プレイヤーへの距離に基づいて特定の音のプライオリティを変えたりしました。最終的に、全体のアクティブボイス数のリミットが50になりました。
最後にはスペーシャリゼーションによってサウンドスケープにかなりの深みがでることが判明し、没入感が強化され、プレイヤーがゲームのエリアからエリアを渡り歩くときに、ゲームプレイにサウンドの要素が追加されました。今回、ディテールに富んだスペーシャルサウンドスケープを開発するという「旅」を通して学んだのは、このような実装を手作業で調整するのに必要な作業量の多さと、可能なことは自動化することの必要性、そしてスペーシャリゼーション機能に対応するために要する最適化の仕事量です。総合的にみて、スペーシャリゼーションはオーディオチーム全員にとって灯台のようであり、この機能を実装して最適化するために全員が個々の努力を重ね、力を合わせたことで、アウター・ワールドのサウンドスケープが生き生きとするシステムができあがりました。
まとめ
私たちはアウター・ワールドで達成した内容を、大変誇りに思っています。多くを学び、途中の失敗も少なくありませんでしたが、今までObsidianでやらなかった方法でWwiseを使う場面もたくさんあり、私たちの作業を推し進めるのに役立ちました。複数のワールドをつくるのはかなり大変で、特にこのゲームではプレイヤーが取ることのできる決断があまりにも多かったのですが、それでもプレイヤーが楽しめる一貫性のあるサウンドスケープをつくり出せたと感じています。
このブログのパート1で、皆さんの役に立つような情報を提供して、私たちがゲームの様々な領域にわたり経験したプロセスについて、少しでも知っていただけたら、幸いです。ここまで読んでくれたことに感謝するとともに、ハルシオンとアウター・ワールドからお届けするパート2も、お楽しみください！
チームメンバー
ハルシオンの誕生まで、私たちオーディオチームは下記の様々な個人やチームに助けられました。オーディオはパズルのなかの1つのピースでしかなく、皆さんのサポートとスキルなくしては、実現できませんでした。
- アウター・ワールドのQA、ナレーティブ、プログラミング、プロダクション、ゲームデザイン、VFX、アニメーションの各チーム
- Noiseworks
コメント