ゲーム制作において、ボイスのミキシング対象となる台詞の行数が何千、何十万におよぶこともあり、これにローカライズ言語の数を掛けると、その取りまとめが非常に難しくなることがあります。
ボイスオーバー(VO)構成をほかのサウンドと同様にActor-Mixer Hierarchyで1対1のイベントとして実装してゆく場合、ダイアログがWwiseプロジェクト内の最大規模の機能に発展することもあり、その他のサウンドを急激に圧迫してしまいます。VO管理が非常に困難となり、途中で方向性が変わったり、ミキシングの新しい決断があった場合は、膨大な手作業が発生しかねません。私たちオーディオ部門の者にとって、時間の余裕など滅多にない贅沢です。
約6,000個のVOアセットを含む、あるUbisoft Wwiseプロジェクトの典型的な1対1のイベント構成
幸い、この問題を軽減する方法がWwiseにあります。強力な機能であるExternal Sources(外部ソース)は、極めて柔軟であると同時に手作業を根本的に減らしてくれます。『スター・ウォーズ 無法者たち』のボイスデザインチームは、Massive EntertainmentのゲームエンジンSnowdropを使い外部ソースを幅広く活用しましたので、この記事でそのメリット・デメリットを探りながら、ゲームの事例をいくつか紹介したいと思います。
External Sources(外部ソース)とは?
外部ソースはActor-Mixer Hierarchy内のほかのサウンドオブジェクトと同じように見えますが、ソースオーディオファイルと1対1の関係にないという点が異なります。オーディオファイルは外部にあるソースであり、ランタイムにゲームエンジンが選択します。
上は標準的なSFXオブジェクトとその参照先のオーディオファイル 下は外部ソースオブジェクトとExternal Sourceプラグイン
イベント自体は通常のSoundBank生成の一環として生成されますが、オーディオファイルは違います。ボイスアセットはその他のコンテンツと同様にオリジナルフォルダ(あるいは全く別の場所)に置くことができますが、SoundBankの生成とは別に変換する必要があります。
これらのアセットは、どの外部ソースイベントと組み合わせても再生できます。つまりあるイベントとイベントが参照するサウンドオブジェクトは、どの台詞にも使うことのできる「テンプレート」として機能し、オーバーライドや交換が自由にできます。
- 外部ソースの設定には何が必要で、どのように使うのかについて説明します。最もシンプルな実装においては、はじめに以下が必要となります:
- Wwise外部ソース一覧ファイルを生成するプロセス。VOの各行のファイルパスを詳細に記述したXMLファイルです。
- XMLに記載のwavファイルをゲームでストリーミングする、wemファイルに変換する生成ステップが必要ですが、これはSoundBank生成の一部として設けることも、コマンドラインを使用した別プロセスとすることもできます。
- ボイスデザイナーがWwiseの外部ソースイベントを、台詞に1行ずつ割り当てる手段。台詞の各行とイベントをマッピングする処理は、テキストデータベースや、よりシンプルにcsvファイルなどで行います。
- 再生するコンテンツと再生するタイミングを選択する、ゲームエンジン側の何らかのVOシステム。これは外部ソースを有効に活用するための前提条件です。具体的にはストーリー場面において、台詞を正しい順番で再生して正しいゲームキャラクターを参照するシステムや、ランダム化に対応したBark(掛け声)システムなどです。
- テキストデータベースで定義した外部ソースイベントを使い、VOの台詞をポストするゲームエンジン側の関数。この関数がVOシステムが選択した台詞を使い、マッピングで定義したイベントを該当wemファイルと再生します。
1対1のイベントと、外部ソースをランタイムに使うシンプルな実装の比較
なお外部ソースはサウンドSFXオブジェクトと共に使うものであり、サウンドボイスオブジェクトを使いません。サウンドボイスオブジェクトはローカライズしたほかの言語のオーディオに対応するためのものであり、外部ソースを使用する場合は、上図フローチャートの「External Source Info」において、ゲームエンジン側のステップとして行います。
最終的には使用するツール、シネマティックス、ゲームプレイシーン、掛け声などをゲームエンジンがどのように処理するのかによって決まります。Massive Entertainmentで採用した方法は、後述します。
メリット
第1のメリットは、構成がシンプルなことです。Actor-Mixer Hierarchyに数10万個にものぼるオブジェクトを入れる代わりに、ニーズの複雑性に応じて数10個ほどに抑えることができます。当然ミキシングが楽になりますが、それ以外にも膨大な手作業を省くことができます。ファイルのインポート処理を支援する機能として、タブ区切りテキストファイルを使ったメディアのインポートなどが確かにありますが、開発サイクルを通じて構造を維持してリファクタリングする手作業は必ず発生します。全体の規模が大きいほど作業量は増え、クリエイティブなタスクに専念する時間が減ります。
外部ソースイベントを台詞の各行に適用する、事前設定の動作テンプレートとして使える(UbisoftのテキストデータベースOasisより)
これは次の要点であるイテレーションに繋がります。軽量な構造により私たちは機敏に動くことができ、クリエイティブな意思決定を加速化できます。1対1のイベントを使う場合は、ランタイムに精密な調整をある程度行うことができますが、完全なつくり直しが必要な大幅な構造変更が発生した時、処理の自動化を助ける独自ツールがない限り、非常に時間がかかります。
設定の継承はWwiseの強力な機能であり、大規模で複雑なしくみを管理するための重要なツールです。1対1のイベントを利用したVO実装のアプローチでは、コンテンツ階層が大きくなり手作業で管理することが難しく、階層の奥深くでオーバーライドを設定するとどこに何があるのかが分からなくなり、すぐに絡まってしまいます。私たちは人間ですから、大量の手作業のあると間違いなくヒューマンエラーが増えます。完璧な人などいませんから、VO構造が大きくなればなるほど、大きな問題に発展しがちです。さらに悪いことに、大規模なActor-Mixer構造では問題が長く表面化しないことがあり、是正が難しくなります。シンプルな構造であればあるほど、問題をはやめに解決できます。
一般的にプロジェクトのミキシングや事前ミキシングのニーズを模索し、VO管理・整理のための最適な方法を検討してゆく過程で、Actor-Mixer構造をはじめからやり直すことがプロジェクトのライフサイクル中に少なくとも2、3回はあるでしょう。身軽な構造とすることでこの作業を大幅に軽減でき、制作過程の比較的遅い段階においても必要に応じて対応できます。
構造を軽くすることで、より定期的かつ正確な「根元と枝」のレビューが可能になり、すべてが適切に配置されていることを確認できます。1つの問題を解決すると、同じ外部ソースオブジェクトを使用するすべての台詞の行のVOの問題も解消されます。『スター・ウォーズ 無法者たち』のボイスのプレミックスを最終確認する際、私はオーディオディレクターSimon Koudriavtsevに引き渡す前に、すべての構造のすべての値をチェックしました。このゲームのVOは85,000行にものぼり、1対1のイベントアプローチではこのようなことはできませんでした。
状況によって同じコンテンツを再利用し、抜本的に異なるミックス動作を適用したいことがあります。例えばマルチプレイヤーゲームやCo-opゲームでは、同じコンテンツをまったく異なる2つの視点から再生する必要があるかもしれません。1対1のイベント方式もダイナミックダイアログ方式も構造を複製することになりますが、構造を追加したり既存の構造をリファクタリングしたりする時や、ゼロからつくり直す時などは、悲惨な目にあうかもしれません。変更点が何もなければ問題ありませんが、何しろゲーム開発をしているわけですからね...!
あなたがプロジェクト構造のコピーを1個以上作成した時点で、あなたのメンテナンス作業をしばらくの間2倍またはそれ以上に増やしたことになります。外部ソースイベントを利用することにより、同じ基本アセットを使いながら、ランタイム状況に応じてイベントを入れ替えることができます。『スター・ウォーズ 無法者たち』では、対応を標準化した「掛け声」にこれを広く利用しました。VOの多目的使用の台詞でゲームプレイのフィードバックの隙間を埋めたり、類似する状況を一緒にまとめて脚本化やレコーディングの時間を短縮したりしました。
外部ソースでは同じコンテンツに異なる動作を設定することが可能 Actor-Mixer Hierarchyで構造をコピペする必要がなくなる
最後になりますが、オーサリングツールでプロジェクトのロードにかかる時間は、中のActor-Mixer構造の大きさにかなり影響を受けます。1対1のイベントアプローチでVOを処理する場合、プロジェクトを開いたりSoundBankを生成したりするたびに長い待ち時間が発生し、オーディオチームの苦労が増大する可能性があります。
デメリット
どのような実装方法にも必ず弱点があり、外部ソース方式は大きなメリットがある一方、デメリットがあることも事実です。最初で最大のデメリットは、プログラマーへの依存度が高いことです。外部ソースはすぐにそのまま使える機能ではなく、新たなシステムを策定して維持する必要があり、オーディオプログラマーのサポートが充分に得られない場合はこの追加作業が大きな負担となるかもしれません。
メンテナンスは検討すべき大切な課題です。外部ソースはVOパイプラインの複雑化を意味し、障害発生点が増えます。つまり前述の、1対1のイベント方式のヒューマンエラー多発の可能性と引き換えに、より多くの構成要素を持つシステムを導入することによる故障発生の機会が増えます。
オーディオ部門において外部ソースが広く使われているわけではないため、VO実装がオーディオチーム全体にとって不透明なしくみとなり、VO分野で人材を増やすためにスタッフの配置変えをする時などは、チームリーダーや部門長が困難に直面するかもしれません。私はこの7年間、外部ソースを複数のプロジェクトで使用してきましたが、VOの場所が分からず混乱したサウンドデザイナーからたびたび問い合わせを受けました。
あなたのプロジェクトにおいて、VOシステムに必要となるダイナミックダイアログの関わる背景情報や、掛け声の動作のためのランダムコンテナなどをWwiseに依存している場合、不利であることは確かです。例えば掛け声システムのニーズに応えるためにダイナミックダイアログ機能を使う場合、ランダム化するための代替を構築し、その他の技術的ソリューションを開発することは、立ち上げコストを増加させます。しかし外部ソースが必要となるほどの大きさや複雑さのプロジェクトは、それだけで高度なソリューションが必要な可能性が高いです。
コンテンツを統合してしまうと、台詞の行ごとの綿密な調整が難しくなります。外部ソースはミドルウェア上でVOアセットを1行ずつ作業する場合より、ランタイムにミキシングする方向で標準化する時に向いています。行ごとに外部ソースイベントを運用することは、特に必要と思われる特定の機能に限定して行う分にはよいのですが、そのユースケースの規模次第で、外部ソースのメリットの大半が打ち消されてしまうかもしれません。
同じ内容についてですが、外部ソースは外部にあるがゆえに、エフェクトをWwiseでレンダリングすることはできません。ランタイムエフェクトの使用がパフォーマンスの低下を招くことは事実ですが、回数が少なければそれほど問題にならず、オフライン処理を考慮して、いつでもミックスやプレミックスのワークフローを調整することができます。同様にWwiseで新しいランタイムエフェクトを設定する場合、Actor-Mixer Hierarchyから直接再生できるコンテンツがあると大変便利です。対処方法は単純で『スター・ウォーズ 無法者たち』においては“FX_Prototypes”というワークユニットにサンプル用の台詞を入れて作業しましたが、事前に知っておくべき不便さです。
最後に、1イベントでVOの台詞1行に対応するという明瞭さがないため、デバッグは確かに複雑になります。これまでサウンドオブジェクトの名前がアセット名を直接反映していたところ、外部ソースのサウンドオブジェクト名とアセット名の2つの情報をWwise Profilerで示さなければなりません。これがどれほど問題となるのかは外部ソースの実装にもよりますが、結局どこかに複雑性は残り、トレードオフの関係にあります。
アプローチの仕方と事例
外部ソースの使い方には主に2つのアプローチがあり、1つは私が「ラインベース」と呼ぶアプローチで、テキストとダイアログのデータベースでライン(行)ごとに細かくイベントを設定します。もう1つのアプローチは「フィーチャー(機能)ベース」と呼んでいるもので、機能レベルにおいてどのイベントが全体的な文脈の中で使われているのかを効率的に管理します。『スター・ウォーズ 無法者たち』ではどちらも使いました。
ランタイムにSnowdropエンジンが外部ソースが使う流れ
スクリプトのあるVO(プレイヤーが主人公をコントロールするオープンゲームプレイのシーン)では、ラインベースのアプローチを採用しました。ボイスデザイナーがゲームのクエストや、その他のストーリーコンテンツに配慮しながらイベントを設定しました。これらのシーンが再生される文脈は1種類しかなく、台詞の各ラインに特定のオーディオ動作を設定するための最も効率的な方法でした。
ラインベースのアプローチではテキストデータベースに、ライン(台詞)ごとの外部ソースイベントを設定 (『スター・ウォーズ 無法者たち』の無線通信の会話より)
FX処理の大半はランタイムにWwiseエフェクトで行うのではなく、ラウドネスやボーカルFXなどをマスタリング過程で行い、アセットにベイクしました。こうして外部ソースを利用するという私たちの戦略のもと、広く標準化に成功ました。しかしすべてをソースVOアセット側で完成できるわけではなく、ランタイムにおいてカスタムイベントで対応した方がよいものもありました。
すでに用意した外部ソースイベント群や、FX処理をベイクする処理によって解決できない問題に遭遇した時は、ボイスデザイナーが新しいイベントをすばやく作成して動作をカスタマイズし、実装、テスト、イテレーションを行いました。こうした対応ができるようにプレミックスやミックスのワークフローが工夫されており、ミックス要件をボイスデザイナーに送ると多くの場合、その日のうちに実施されました。
マスタリングでさまざまなことに対応できる一方、ランタイムに標準化できない場合はカスタムイベントを導入
Barks(コンテンツプールの台詞をランダムに再生する、「掛け声」VOシステム)には機能ベースのアプローチを採用しました。このBarksシステムには「テンプレートオーバーライド」というユニークな機能があり、使用中のコンテンツプールに関して外部ソースイベントのオーバーライドを指定することができ、テキストデータベースで設定した外部ソースイベントをオーバーライドできます。Wwiseのステート値を利用してオーディオ動作を変更することも確かに可能ですが、バスへのルーティングやポジショニングなど、いくつかの重要機能を細かく制御できません。
カットシーンでは品質レベルに応じてラインベースのアプローチを何種類か実装し、興味深いケーススタディとなりました。シングルカメラの視点から見る親密な会話は、ケイとほかのNPCが単一の視点を共有しており標準化することができ、このようなNPCとの一般的なやり取りはシンプルな「ゲームプレイのダイアログ」であり、おおむね画一的なアプローチで対応しました。「ダイアログシーン」(完全なランタイムのカットシーン用)は焦点を絞り込めるように、カメラアングルを反映したさまざまな視野のイベントを取り揃えた一方、手作業でオーサリングされたLCRアセットのある「レンダリング済みシネマティックス」は、すでにミキシングをオフラインで終了しているため、ほぼすべてがひとつのイベントを共有しています。
カットシーンでは機能やゲームプレイの流れに応じて、さまざまなアプローチを採用
外部ソースをWwiseの各種再生コンテナと組み合わせて使うこともできます。中でも最も活躍したのが、音のプロジェクションに使用したスイッチコンテナです。テキストデータベース側の「プロジェクションレベル値」で駆動されるスイッチが、その台詞のプロジェクションレベルに基づき、外部ソースオブジェクトを選択します。こうしてAUXセンドレベルの設定を変え、例えば"Yelled"(怒鳴る)のVO台詞は、"Hushed"(ひそひそ声)の台詞よりも顕著な音響を起動させます。
左はBarkプールの各台詞にプロジェクションレベル値を設定したテキストデータベースであり、これでVOをポストした時のスイッチ値が決まる。中央ではBarkシステムのルールにより外部ソースイベントがオーバーライドされている。右はプロジェクションレベルごとに用意された外部ソースオブジェクトの入ったスイッチコンテナ。
私たちはブレンドコンテナとシーケンスコンテナのどちらも使用しました。仲間のNPCのVOの「3Dから無線への移行」の処理をブレンドコンテナで提供し、3D位置を有してゲーム内リバーブを伴うVOが、プレイヤーが離れ過ぎた時にドライな無線処理のオブジェクトに滑らかにブレンドするようにしました。シーケンスコンテナはケイのコムリンクの無線通信に使ったほか、一部のNPCから時折り聞こえてくる無線コールの一方的な掛け声や、スター・ウォーズの旧3部作で聞かれる懐かしいストームトルーパーのヘルメットのクリック音などにも使いました。
外部ソースはスイッチコンテナなどその他のコンテナタイプとの互換性がある ここではVO台詞の前後のストームトルーパーのヘルメットのクリック音に、スイッチコンテナを使用
ところで、すべてのボイスコンテンツに外部ソースイベントを使用したわけではありません。例えばガヤのコンテンツはほぼすべて、標準的なサウンドSFXオブジェクトとして統合されています。唯一の例外が接近した視点のコンテンツであり、これはVOパイプラインや外部ソースと密接にかかわる脚本や翻訳が必要なためです。コンバットのNPCの動きやその他の非言語的な音声もまた、外部ソースで駆動される字幕システムを必要としないため、標準のサウンドオブジェクトとして実装しました。同様にシネマティックスの説明音声(アクセシビリティ機能の1種)は字幕を必要としない言語コンテンツであるため、シンプルな1対1イベントを活かしています。
『スター・ウォーズ 無法者たち』には外部ソースを使用しないボイスコンテンツもある ガヤのシステムのコンテンツは、主に標準的なサウンドSFXオブジェクトを使用
まとめ
外部ソースの確実なユースケースや、その長所と短所を分析した資料があまりなかったため、私が記事を書くべきだと考えました。Creative Assemblyの一員としてPvEvPタイトル『Hyenas』を制作していた頃、マルチプレイヤーVOの視点に関する増え続ける問題について、友達で元同僚のChris Goldsmithに愚痴をこぼしたていた記憶があります。すると彼は外部ソースの利用を検討したのかと尋ね、そのしくみを説明してくれ(私がそれを理解できたところ)、その可能性に私は目を輝かせました!
外部ソースは直感的にすぐに使える機能ではなく、理解できるまでに時間がかかるかもしれませんが、面倒な手作業を減らしてクリエイティブな検討時間を増やすための非常に有力な手段であると思います。大規模なプロジェクトでは不可欠だと私は思います。
台詞の行数が2万行以上になると予想される場合や、高度に複雑なしくみに直面し、1対1のイベントの課題を軽減する独自ツールがない場合などは、ひとまず外部ソースの活用を検討するとよいでしょう。一方、数千行程度しかない場合や、基本的なVOシステム機能においてWwiseをかなり重視しておりプログラミング人材が不足している場合などは、1対1のイベントアプローチが最善である可能性が高いです。精密な制御やほかへ転用できるスキルを維持しつつ、貴重なオーディオプログラマーの時間をより成果の出る場面にセーブしてください。
ゲーム開発は何事も常にトレードオフであり、無料のものはありません。コードが必要でなければ大量の手作業が発生するでしょうし、その逆も然りです。あなたが気になっていた“Add Source > External Source”オプションの意味がこの記事で分かり、使って効率的に仕事ができるようになり、ボイスデザイナーのクリエイティブな作業時間が増えることを願っています。
コメント