『 It Takes Two 』のサウンドの裏側 ― Hazelightオーディオチームに聞く ―

ゲームオーディオ / インタラクティブオーディオ

Hazelight Studiosの『It Takes Two』は、スプリットスクリーンで構成されるアクションアドベンチャーのプラットフォーマーCo-opゲームです。コンテンツの膨大なバリエーションと、独特で遊び心あふれるアニメーションスタイルが、ほかのアクションアドベンチャーゲームと明らかに違います。このようなゲームでサウンドスケープを開発するにあたって、一番の課題は、スプリットスクリーンと、そのオーディオへの影響でした。

Hazelight Studioの仲間たちが、 『It Takes Two』のオーディオを開発するにあたって遭遇した難題やチャンスについて、質問に答えてくれました。オーディオチームのリードサウンドデザイナーのPhilip Eriksson、テクニカルサウンドデザイナーのJoakim Enigk Sjöberg、オーディオプログラマーのGöran Kristiansson、そしてシニアサウンドデザイナーのAnne-Sophie Mongeauが、スプリットスクリーンの扱い方や、ミックス、サウンドデザイン、パフォーマンス、そしてミュージックへの対応を教えてくれました。彼らがどのようにして、高品質のオーディオエクスペリエンスを実現し、このゲームカテゴリーのオーディオに新たな基準をもたらしたのか、その技術的ソリューションについて聞きました。

It_Takes_Two

スプリットスクリーン

『It Takes Two』 の左右のスプリットスクリーンに対応するのに使った技術的ソリューションについて、簡単に教えてください。

PHILIP: 縦に割れたスプリットスクリーン表示に対応するために、サウンドミックスも二つに分けました。スピーカーは左、センター、右を全サウンドのベースとして使い、常にフロントをリアよりも優先させました。画面左半分に属する音は左とセンターの間でパンニングして、右スピーカーに少しだけ染み込みます。この技はプレイヤーの動作、アビリティ音、そしてボイスにまで使っています。アンビエンスは4チャンネルなので、リアスピーカーでも再生します。キャラクター同士が別々の場所でゲーミング中に、異なるアンビエント音を聞くような場合は、右キャラクターのアンビエンスを、左、フロント、リアのスピーカーで弱くし、その逆も同様にすることで、画面の空間に合った、すっきりとしたエクスペリエンスをつくりました。

Panning_ambiences
図1: アンビエンスのパンニング

スプリットスクリーンは、真ん中の分割以外では、対応を変えましたか?例えば、一方のプレイヤー側が大きくなるときとか、上下に分割されたときとか、ゲームがフルスクリーンになるときなどは?

JOAKIM: 圧倒的に多いのが、2人のプレイヤーが均等に縦に分けられた画面を持つシナリオで、私たちも技術的に一番努力しました。もう1つ、ゲーム全体を通してよくあるのが、1つのフルスクリーン画面を2人で共有するというシナリオです。そういったシーンでは、すでに確立された空間的な配置の枠組みを完璧に覆さないようにすることが大切でした。視界の角度が変わりますが、オーディオ動作のルールはわずかに違うだけで、できればプレイヤーに気づかれないようにします。フルスクリーン部分では主に、画面中央に対する音源の位置をトラッキングし、中央から横方向に平面的に適宜パンニングさせる、という方式をとりました。そうすることで画面スペースを管理するための全体的な考え方と整合性をとることができ、フルスクリーンのゲームプレイは本質的にカオス状態で激しいのですが、状況をはっきりとさせてくれます。

GÖRAN: このカオス状態に秩序をもたらす技術的なソリューションの1つが、私たちのフィルタプラグインです。チャンネルごとのbiquadフィルタで、ボリュームフェーダやフィルタ用のQ値があるフィルタプラグインです。このプラグインを使って各チャンネルを確実に制御できるようにし、プレイヤーが死んだりリスポーンしたりするときに利用しました。ミックスの半分をローパスフィルタでスウィープしたり、プレイヤー同士に明確な差をつけることで、かっこいいエフェクトをつくり出しました。ゲームプレイの制約(例えば長期間続く低ヘルス)のため、ミックスのローパスとなる半分に同様のエフェクトを適用しなかったのは、あまり長く適用すると聞こえが悪くなるからです。だから、劇的で短い、死やリスポーンの瞬間だけに使ったのです。Wwiseの既存コードベースのおかげで、プラグインの機能を実装するのは簡単でした。

スペーシャリゼーション(3D)を完全に適用したサウンドは、どうしましたか?ワールド内にスペーシャルサウンドが各所に配置され、プレイヤー達が音源に対して、それぞれ違う場所で立っているとき、どうやって混乱を回避しましたか? 

PHILIP: 2D音より、解決するのが少し難しかったです。ゲームのサウンドを作成する過程で問題自体は早期に認識していましたが、修正できたのは、かなりあとになってからでした。問題となった簡単な例を1つあげると、1人のプレイヤーが音源のとても近い場所に立っているのにカメラは別の方向を向いていて、もう1人のプレイヤーが音源から遠くにいるのに、音源に面と向かっているときです。この場合、合算したミックスを聞くとフロントとリアの両方のスピーカーから音が出て、結果として(必要以上に)とても幅が広くて大きい音として認識されました。これはイメージを壊してしまう、と思いました。ゲームをこのまま出荷するわけにはいかない、と感じました。私たちは、パンニングやミキシングの絶対的ルールの1つとして、音源が視界にあるプレイヤーの方を優先しましたが、ここではルールに合わず、なんとかする必要がありました。

JOAKIM: ここでの問題は、私たちの具体的なリスナーセットアップに基づいて発生していて、大きなペインポイントが2つありました。1つは、スペーシャルサウンドの配置自体です。スペーシャル音源に一番近いプレイヤーの方が、一番大きい出力をミックスすることが多かったので、そのプレイヤーの視界の方が、スピーカー配置に対する影響が大きくなります。そのプレイヤーの視界は必ずしも我々デザイナー側が、その瞬間に注目してほしいと思っているところを見ていませんが、その出力を制御するツールが、まだありませんでした。

2つ目の問題は、リスナー向けにWwiseがチャンネルを統合するときの本質的な方法にありました。スペーシャルサウンドの出力をリスナーが2人とも積極的にミックスしたときの結果は、信号の量の倍になり、同じ音を1人のプレイヤーだけが聞いた時と比べて、出力ボリュームが増大してしまいました。最終的な結果を予測するのは非常に難しく、各チャンネルの信号量は、音源に対する両方のプレイヤーの関係の組み合わせで変わります。

スペーシャリゼーションされたエミッターの振幅に関する問題は、ゲームに音を実装しだした時点で明らかでした。対策としてまず、非常にシンプルなRTPCを設定し、上位のActor-Mixerでメイクアップゲインにバインドしました。空間化された音を再生するエミッターごとにリスナーの接近度をトラッキングし、2人とも範囲内に入ったときに、このRTPCを継続的に更新してプレイヤーの距離に基づいてボリュームを下げ、ダブルチャンネルによる追加の音量を抑えました。当然、これは美しくない修正方法でした。また、2人のリスナーで合算される信号量を厳密に予測することは不可能なので、振幅をフラットにすることに関して、この実装の効果は全体的にイマイチでした。

この2つの問題で、ゲームのスペーシャルミックスを制御する方法はない、ということになりました。そこで、Wwiseの下位レベルを開いてみて、『 It Takes Two 』用に自分たちで、スペーシャリゼーションされた音源の扱い方を書こう、ということになりました。

One_sound_sourcec

two_listeners_routing
図2、3: 音源は1つ、ルーティングするリスナーは2つ

GÖRAN: Wwiseのシステムに自分たちのルールを書き込む前に、まずWwiseのルールを知る必要がありました。何があるのかを1つずつ確認しながら、どれを変え、どこで変えるのかを考えました。

先ほど言った通り、これに取り掛かったのは遅い段階だったので、プロジェクトをスケジュール通りに進めながら、必要な結果を得るにはどうすれば良いかを考えました。私たちのデザイン要件をまとめると、信号の二重化を排除し、信号を視界の方向に基づいて固定することがゴールであったので、私たち独自のSpatial Panningシステムをつくりました。

さて、これを念頭に私たちは、減衰の範囲内の全てのリスナーと、各エミッターに対するリスナーの方向が必要でした。信号の変化は、主に距離に基づいて平滑化することに決めました。なお、信号の方向性の平滑化の速さは、間接的にゲームプレイで制御し、理由は、多くの場合に回転の変化が比較的制御され、スムーズだったからです。パフォーマンスへの打撃を抑え、もちろん必要なデータフォーマットで取得するために、わりと長いパンくずの跡をWwiseシステムに残して、求める結果とパフォーマンスを得る必要がありました。

Spatial Panning のソリューションは、役立った反面、新たな問題につながったことはありましたか?もしあれば、その内容と、回避するために何をしたかを教えてください。

PHILIP: あえて聞こうと思えば、私たちの修正部分が聞き取れると、100%確信していますが、つくり出した問題よりも多くを解消してくれました。このソリューションは、リアスピーカーからフロントスピーカーに動かしたりするので、その遷移がスムーズに行われるように、lerpを作成する必要がありました。そうすると、プレイヤーがキャラクターを素早く極端に動かしたときに、私たちが設定したlerpでは、たとえ全シナリオに対応できるように細かく調整済みだとしても、遅いと感じてしまうリスクがあります。ただ、プレイヤーは自分で、1つの音源だけを聞くことはできないので、ゲームのフルミックスの中から、問題点を1つだけ特定するのはとても難しいはずです。 

JOAKIM: Spatial Panning機能は、私たちが『 It Takes Two 』で見た具体的な問題に対処するために、一からつくったものです。このプロジェクトの最終的な結果を得るために用いた数々のメソッドは、Spatial Panningも含めてどれも、アクション系スプリットスクリーンのあらゆるゲームにぴったりフィットするように設計したのではなく、私たちのゲーム『 It Takes Two 』の枠内で機能するように、具体的に設定されています。例えば、このゲームプレイは極めて線形なので、プレイヤーは常に前に進み、遭遇するスペーシャルサウンドは、その旅を可能にする世界の中に存在するものとして設計されています。このようなゲームの観点では良く機能するソリューションですが、もっとオープンなワールドのゲームや、2人のプレイヤーの視界がさらに非同期のゲームでは、簡単に転用できないと思われます。今後の取り組みでSpatial Panningの考え方が出発点となるかもしれませんが、新しいゲームでは2つの半分を合体させて1つの全体的な真実への見通しを構成するときに、何を求めているのかの再確認が必要になります。

GÖRAN: ゲームのリリース期間は新しいコンソールのリリース中だったので、新しいコンソールの問題や機能と関係してWwiseのバージョンを結構頻繁にアップデートすることになり、その分、Spatial Panningなどの自分たちの機能がうまく動くように維持するだけでも時間がかかりました。サードパーティソフトを使うときによくあることで、驚きはしませんでしたが、既存のソフトを変えるときには、その過程をできるだけ助けてくれるようなツールをつくる(または既存ツールを使う)ことを頭に入れておくようにして、コードベースに、自分が加えた変更をはっきりと印しておくことが大事です。そうすれば、バージョンを移行するときのオーバーヘッドを減らせます。

ミックス

『 It Takes Two 』のミックスはすごくよくて、スプリットスクリーンなのに、常にクリーンでクリアに聞こえます。このゲームのミキシングのアプローチを教えてください。どのようなビジョンを抱き、どうやって実践しましたか?

PHILIP: おもしろくて変化の激しいミックスをつくりたいと思い、新しくて引き込まれるようなことに常にフォーカスしました。ゲームはかなりリニアなので、もっとオープンワールド的なゲームよりも実施するのが楽でした。プレイヤーが部屋から部屋へ移動するときや、メインパスを通るときは、次に起きる面白いサウンドやイベントが必ず注目されるようにしました。ほとんどのとき、ミックスの決定で達成でき、プレイヤーにどの音が聞こえて、どの音が聞こえないのかを慎重に選びました。オーディオチームのスポッティングセッションで私たちはこれを意識的に、サウンドエフェクトをつくるところから、ファイナルミックスの作成に至るまで一貫して行いました。1つ面白いのは、デザインで意図したとおりにゲームが動くことを確認するために、ミキシング中に2人のプレイヤーを確保したことです。おかげでミキシングプロセスがグッと面白くなり、おまけに、常にもう一組の耳が同室にいて、ミキシングの判断を話し合える相手がいるのは、とても助かりました。

ANNE-SOPHIE: ミックスを決めていく上で、スプリットスクリーンの影響は大きかったです。例えば、常に2つの画面を別々に分けようと画面の分割に対抗するのではなく、分割を受け入れてストーリーを伝えるために音を使い、ゲームプレイで今、起きている一番大事な要素を(どの画面にあっても)強化して、ミックスを通して強調しました。大事な要素を1つに絞ることで、何に注目してほしいのかをプレイヤーに伝えます。壮大なシーンや、コンバット場面、忙しいシーケンスなどでは、これが特に重要です。何を通すか、そして何を落とすか、という観点でときにはかなり思い切った判断をしましたが、最終的には明快で一貫性のあるミックスとして功を奏しました。

再生のセットアップによって、ミックスを変えることを検討しましたか?例えば、ヘッドフォンミックスをプレイヤーによって変えるとか、プレイヤーがcouch co-opモードでプレイしているときと、ネットワークを介して別々にプレイしているときで、ミックスを変えるとか。

PHILIP: それは、オーディオ制作の最初に考えたことで、アイディアもいくつか持っていました。その1つは、自分がプレイしていない方のキャラクターの動作音と声を、小さくすることでした。また、ほかのプレイヤーに聞こえるワールドサウンドをミュートする、というアイディアもありました。プレイヤーエクスペリエンスを想像してみると、このようなアイディアは役に立たないと気づきました。ゲームの画面表示はゲームのプレイ方法に関わらず常に同じなので、音も、同じように扱うのが論理的だと感じました。また、様々な種類のミックスを維持するとなると、私たちの作業量も増えます。そこで、2人のプレイヤーが同じサウンドスケープ内でシーンを共有したときに、そのエクスペリエンスの音が良く聞こえることを目標としました。特に 『 It Takes Two 』 は、どのようなプレイの仕方でも、絶対にシェアして楽しむべきゲームだと思います。

HDR

『 It Takes Two 』 でWwise HDRをつかいましたか?スプリットスクリーンに一番うまく対応して、ニーズに最も合った戦略は、何でしたか?

PHILIP: Wwise HDRを、使いました。ミックスをクリーンにして、聞こえない音をカットすることでゲームを最適化するためのツールとしてもHDRを使いたかったので、簡単に採用を決めました。EA DICEでHDRを使ったタイトルもあり、Wwise HDRと仲良くできるまで、少しテストをしました。ヒントやコツをいくつか:

  • サウンドは、ノーマライズします。
  • 各カテゴリの音に使う、 ボイスボリューム 値の基準をつくるか、自分のミックスのどの音が一番大事なのかを選びます(必ずしも一番大きい音でなく、一番面白い音にしても良い)。
  • できるだけ ボイスボリューム 値を静的にし、距離による減衰だけは例外とします。例えばランダムなLFO RTPCを ボイスボリューム 値に適用してしまうと、時間が経つにつれ、この音がほかの音をダッキングする(またはダッキングされる)度合いが変わってしまい、それは望ましくないかもしれないので、避けてください。
  • メイクアップゲインを、全ての変動ボリュームや、一般的なミキシングで、使います。
  • 同じサウンドエフェクトに、複数のレイヤを使う場合は、各ボイスの ボイスボリューム 値が異なることがあり、一緒に再生されるはずのレイヤがダッキングされる可能性があるので、注意してください。一つのやり方として、一緒に再生したいレイヤは、同じ ボイスボリューム 値を設定し、これらのレイヤ間のパンニングは、メイクアップゲインでミックスします。
  • ボイスボリューム があなたのHDRウィンドウ範囲の下限よりも低く設定されていると、 virtual voice 動作でこの設定を選択していれば、この音はおそらくカリングされてしまうので注意してください。これをあえて利用してもいいですが、知っておく必要があります。

もう一つ面白いことに気づいたのですが、リスナーが2人いるので、同時にHDRインスタンスが2つあります。もし1人のリスナーが、例えばボイスボリュームの大きい音の隣に立っていて、もう1人が減衰の範囲外にいたとすると、合計したHDRダッキングは、リスナーが2人とも音源の近くにいるときよりも小さくなります。これは正しい動作かもしれないですが、好ましくないかもしれません。

HDR_visualization_using_voice_monitor
図4: Voice Monitorを使ってHDRを可視化

RVB/Worldizing

『 It Takes Two 』 のサウンドのリバーブや、ワールド全体が、とてもリアルで没入感あふれています。どのようなリバーブを使ったのか、そして、ここまで信ぴょう性のある環境をつくるのにどのようなソリューションを開発したのか、教えてください。

PHILIP: 『 It Takes Two 』 のオーディオの方向性の主要な柱となったのは、プレイヤーにとって没入感のあるエクスペリエンスをつくり、音に反応する親近感の持てるワールドにすることでした。クリエイティブな環境として掃除機のホース部やガラス瓶などをつくり出したかったのと、万華鏡のようなワールドレベルで使う、変なリバーブエフェクトもデザインしたかったのです。Wwiseの RoomVerb プラグインを使おうとしましたが、それでは不十分に感じ、もっとクリエイティブになれるように、コンボリューションリバーブだけを使うことにしました。私たちは鞭や花火を使って、様々な環境でかなりのインパルスレスポンスを録音して、水中や、想像上の場所のために、手の込んだ設計を施したインパルスをつくりました。

これらのコンボリューションリバーブに加え、‘Environment Type’ システムも作成し、デザインした様々なリフレクションテイルを再生できるようにしました。これらのテイルは主に爆発や武器に使いましたが、ほかの音でも、その規模や、音の大きさを伝えるために長いテイルのメリットがあれば、使いました。実は、小部屋と大部屋用に一つずつ、ベイクしたフットステップのテイルを用意しました。

さらにリアルなワールドを作成するために、キャラクターから反射面までの距離を測るのにレイキャストを使い、サーフェスタイプも使ったランタイムディレイシステムを構築しました。とても穏やかでバリエーションのある反射が、ほかの静的なリバーブやベイクされた反射に追加され、ワールドが微妙な変化に素早く対応できるようになりました。

convolution_reverb_level_specific_impulse_response_settings
図5: Convolution Reverbで、このレベル専用のインパルスレスポンスを設定

JOAKIM: 再生中のサウンドの環境エフェクトをシミュレーションするためのシステムを設計するときは、スペクトラムを、事前に定めた決定的なものになるように設計するのか、あるいはランタイムに発生する、もっとダイナミックで瞬間的な結果を目指して設計するのかを、考えてみることが大事です。その間のスウィートスポットとなるような、技術的にもクリエイティブにも、リソースや理想に合った中間地点を探ってください。 『 It Takes Two 』 の環境システムの基盤を示す例として、コンボリューションを通して実装したリバーブがあります。ランタイムに、これらのバスにダイナミックに信号を送り込みますが、エフェクトユニット自体の特性は、特定の種類の環境を表現できるように事前に注意深く設計されています。ワールドを動き回るプレイヤーの位置をモニタリングしたり、これに基づいてリバーブバスへのルーティングを管理したりする以外には、リバーブ自体のサウンドは非常に決定的です。

一方、厚く信頼できるリバーブのベッドができると、そこからアーリーリフレクションの物理的な現象を表現することができ、ゲーム中に収集されるあらゆる種類のデータで駆動するリアルタイム計算によってプログラミングした可変ディレイラインを使い、例えば壁までの距離や、プレイヤー周りにあるマテリアルや、周囲のオブジェクトとの関係などを取り込めます。

システムが事前に決定されていても、ゲーム実行中に構築される結果を使っても、本来のメリットやデメリットが継承されますが、これらを組み合わせることで、デジタルワールドが本物に感じられるような結果を作成できます。

GÖRAN: 残念ながらWwiseのディレイプラグインに足りないのが、可変ディレイタイム、つまりランタイムにディレイタイムの変更をRTPCでサポートすることです。私たちのアーリーリフレクションシステムには、必須の機能でした。

当初、プロトタイプにはPure Dataを使いました。さらにPure Dataパッチから、今は廃止されたHeavyコンパイラを使ったWwiseプラグインもつくり、全てをエンジンで試せるようにしました。ここで注意したいのは全プラットフォームに対応していないことと、そのままでは、今となっては使えないかもしれないということです。

最初はテープディレイを使おうとしましたが、ディレイタイムを更新するときにピッチチェンジが発生してしまいました。可変ディレイタイムのディレイラインも、試してみたのですが、ディレイタイムを更新するときにクリックなどのノイズが発生してしまいました。それでも可能性を披露し、自分たちでWwiseプラグインをつくり続けるには充分な結果が出ました。

最終的に、フラクショナルディレイラインにバイキュービック補間を使い、ディレイタイムを変えたときに発生することのあるノイズを平滑化しました。

Haze_delay_wwise_plugin
図6: Hazelight独自Wwiseプラグイン‘Haze Delay’は、ディレイタイムの変化を平滑化するための、フラクショナルディレイライン

スプリットスクリーンなので、それなりの数のコンボリューションリバーブのインスタンスを同時に処理することもありますし、ディレイについても同じです。これらのシステムのせいで、パフォーマンス問題はありましたか?あれば、どう対処しましたか?

PHILIP: 2人のキャラクターが別々のアンビエントゾーンにいる可能性はかなり高く、最悪の場合、2つのアンビエントゾーンの間のフェードゾーン入っていれば、キャラクターサウンドだけが同時に4つのコンボリューションリバーブにミックスされてしまいます。また、ほかのアンビエントゾーンに配置された音も、そのゾーンのリバーブにミックスできるようになっているので、同時に多くのリバーブインスタンスが発生することもあります。ランタイムディレイシステムでは、もう少し簡単になります。ディレイがキャラクター周りだけに集中するので、同時に可能なディレイインスタンスは、キャラクター1人に2個ずつ、合わせて4つだけになります。

JOAKIM: 『 It Takes Two 』 ではリバーブバスが、ワールド内の区分けされた空間(‘Ambient Zones’)にあり、リバーブバスは、自分のエリアにプレイヤーが入ってきたときに初めて仕事をするために目を覚まします。同様に、そのエリアからプレイヤーがいなくなれば、そこに関連するリバーブがカリングされ、バスは再び休眠状態に戻ります。ゲームプレイ中にプレイヤは常にリバーブインスタンスの横で移動し続け、リバーブインスタンスは互いにクロスフェードし合いながらプレイヤーを次の環境にスムーズに送り込み、そのあと、プレイヤーから入力信号を受信しなくなればスリープに入ります。このシステムは2人のプレイヤーが全く異なる場所にいる可能性にも対応でき、できるだけ密に編まれていますが、それでもプレイヤーや、ワールド内からくるほかの音の位置によっては、同時に7つか8つの固有のコンボリューションリバーブバスがアクティブ状態になることも、珍しくありません。開発期間中に、Audiokineticもコンボリューションリバーブのエフェクトのパフォーマンス最適化をリリースしましたが、とても感謝しています!

GÖRAN: 処理負荷を削減するために全体を通して行い、リバーブにかなり影響を与えたのが、処理されるアクティブなオブジェクト数を制限することで、アクティブでないと判断したものはカリングしました。例えば、音を再生していなかったり、範囲外にあったりるするものです。

また、必要なときだけ、データを更新するようにしました。例えばディレイシステムで非同期のレイキャストを使いましたが、充分な数のデータが変更されたときだけ、ディレイプラグインを更新しました。できる限り可変ディレイラインの変更を減らしましたが、全ての変更を現在フレームに入れることができないという犠牲が伴いました。

パフォーマンス

リバーブとは別に、スプリットスクリーンのゲームなので、常に同じゲームの2つのインスタンスが基本的に並行して稼働していることになります。これは、パフォーマンス的に大きな問題を引き起こしましたか?何を一番心配し、どうやって解決しましたか?

PHILIP: その点はもちろん、オーディオ制作中は常に頭のどこかにあったことで、それで良かったと思います。素晴らしいサウンドのゲームを作成したのに、制作工程の最終段階で、せっかく時間をかけて作成した美しい音を、最適化によって排除されてしまうのは、悲しいです。最初の頃からデータをモニタリングし、正常な範囲内に常にあることを確認しました。効率よく、必要なレイヤだけをサウンドデザインで活用するようにして、充分に検討した上でのミキシング判断や、HDRを用いて、不要な音を削除(またはカリング)しました。これは、クリエイティブな面で私たちの妨害にはなりませんでしたが、良い音と同時に最適化を狙うために、デザインテクニックを調節することが必要なときもありました。WwiseのHDR、再生制限、バーチャルボイス動作、再生プライオリティなどWwiseに組み込まれた全ての最適化システムを、私たち独自の最適化システムと組み合わせて、使いました。

JOAKIM: どのようなゲームでも、複数の音を同時に再生するという基本的な動作が、ほぼ確実にCPUを一番消費し、スプリットスクリーンのゲームである 『 It Takes Two 』 も、もちろん例外ではありません。規制するにはボイス制限やバス制限が基本ですが、HDRも忘れてはならず、ミックスをクリーンでダイナミックにしてくれるだけでなく、ゲームプレイのときに、重要でない音は、既定のボリュームスレッショルドを下回った場合にカリングすることで、そのような音に対処するプレッシャーを和らげてくれます。

『 It Takes Two 』 は5つの異なるプラットフォーム向けにリリースされましたが、それぞれ異なるニーズや、要件や、長所短所があります。私たちの方針は、一番の悪者を適宜特定し、それが全てのコンソールの条件下で確実に動くようにすることで、プラットフォーム別にWwiseの階層の設定を行うことはしませんでした。全てのデバイスでうまくいくようなスウィートスポットを見つけるために、かなりの時間をかけて悩んだ例として、ディスクからストリーミングするサウンドの典型例を分類することで、これは私たちのゲームではパフォーマンスに直接の影響があることが判明しました。パズルのピースを全て揃えるのと同じで、オーディオフレームにプロセッサがかける時間や、RAMで待機する圧縮されていないPCMデータの量や、ハードドライブが対処するストリームの数などのバランスを探りました。

Wwiseにある機能がProfilerだけだったとしても、私だったら使います。

GÖRAN: 誤解のないように言いますが、ゲームのインスタンスが2つあるのではなく、視点が2つあり、聴覚的なエクスペリエンスとしては、常にリスナーが2つ以上あります。つまり、オーディオソースは1つだけですが、信号は2つのリスナーに対してミキシングされます。

Joakimが言った通り、一番の懸念は同時再生中の音の数、そして個々の音の複雑性でした。複数のRTPCやリバーブやポジションを、フレーム毎に更新しなくてはならないものもあり、各オブジェクトの異なる要件を分別するために、多数の設定や、使いやすいショートカットを設けて、スムーズな開発プロセスを実現しました。例えば Fire-Forget 音は、その音の間だけ存在し、別の音を再生する必要があるまで、無効になります。ほとんどサウンドオブジェクトを無効にできるタイミングを把握するために、減衰半径を使いこなし、リスナーが動く速度に合わせてパディングも多少追加し、聴覚エクスペリエンスを維持しています。

サウンドデザイン

『 It Takes Two 』 の特徴は、ゲームプレイのバリエーションが豊富なことですが、作成したオーディオコンテンツも膨大なはずです。どうやってこなしたのですか?外注しましたか?

PHILIP: Red Pipe Studiosと協業し、シネマティックスの全てのサウンドとミキシングを納品してもらいました。音楽に関しては、コンポーザーとしてKristofer Engが、社内コンポーザーのGustaf Grefbergとタグを組んでくれました。ゲーム内のボイスオーバーのレコーディングや、初期の編集作業は、SIDEがほぼ全てを担当してくれました。さらに、Red PipeがFoley Walkersと緊密に連携し、シネマティックス用のフォーリーを提供してくれ、私もTon & Vision (Patrik Strömdahl) と共に広範囲におよぶフォーリーレコーディングセッションを行いました。

正直言って、 『 It Takes Two 』 のオーディオ制作に時間を充分に取れたことはなく、「最初のトライが唯一のトライ」と冗談で言っていましたが、実際それに近い状況でした。ほとんどの場合、あとから戻って磨きをかける時間があるのか、確信をもてることがなく、良い音をつくるチャンスは一回しかありませんでした。でも、これも健全なことだと思っていて、極端に言えば、とても洗練された音がファーストレベルだけにあるよりは、ゲームの最後まで音があった方がいいわけです。

このようなアプローチの仕方でしたが、最初から品質の目標を高く設定して、スタジオマネージャーの言葉を借りれば私たちは「品質基準を非常に高く設定して、そこにボルトで締め付け、何が起きようとそこから動かさなかった」のです。私たちが目指したのはスプリットスクリーンのゲームとして今までにない最高の音を達成することで、与えられた時間は短かったですが、最後まで、その目標を変えませんでした。

最後の方に少しだけ、戻っていくつかの音を追加したり拡張したり、多少の磨きをかけたりする時間を取ることができ、私たちはゲームが手元から奪い取られるまで、一生懸命に、できる限り素晴らしい音にするために作業を続けて、それはそのまま消費者の元へと出荷されました。

ANNE-SOPHIE: Philipの、プロジェクト全体を見渡した巧みな計画がなければ、ゲーム全体でこれほど質の高いコンテンツを制作することは不可能でした。サウンドデザインの制作から実装にいたるまで、そして技術的なシステム開発や、イテレーションや、カットシーンのオーディオ外注についても、同じです。基本的に各レベルと、そのサブレベルに対して、具体的な期間を設定しておき、磨きをかけてミキシングするための時間の余裕も考慮しました。設定された時間が切れたら、そのまま次に移るようにしました。極端に厳しいスケジュールだったので、最初のイテレーションで、そのままリリースできる状態にまとめるつもりで進め、サウンドデザインの品質だけでなく、ミックスも同じで、常に全員がミックスに対する責任を負い、ゲームに何か新たなものを加えるときは、必ずその品質がほかの品質と一致することを確認しました。最後に、とにかく全員が最もクリエイティブな姿を前面に出し、できる限り創造力を駆使して、たくさんのオブジェクトやキャラクターに命を吹き込んでいきました!コンテンツの多様性で全体的に苦労しましたが、このプロジェクトで絶対に一番楽しかったことの1つでした。 

音楽

Musicレベルはゲームの最終レベルで、とても魅力的な音です。歌のアビリティをどうやって解決しましたか?ビートマッチで、音楽がゲームプレイを駆動する部分はありますか?

JOAKIM: Musicレベルでは、何らかのかたちで、バックグランドミュージックによって制御されるゲームプレイ要素が、結構あります。まず最も重要で目立つのが、メイの 歌のアビリティ で、このレベルのパズルを解いて先に進むのに使います。プレイヤーがこのアビリティを起動すると、メイは現在再生中の音楽に合わせて歌い始め、テンポもキーもシンクします。ボーカリストに、MIDIトラックをテンプレートに使いながら音楽のメロディを歌ってもらうことで、これを実現しました。その後、MIDIデータを解析して、マーカーとしてソースファイルに埋め込み、あとからゲームエンジンが読み込んでシステムに通知できるようにしました。

ゲームプレイを、オーディオスレッドで発生しているイベントにシンクさせようとするときに、 『 It Takes Two 』 は、ローカルで2人が同じデバイスでプレイして1つのWwiseインスタンスを共有する状況以外にも、ネットワークを介してオンラインで接続している可能性も考慮する必要があります。そのような場合は、ゲームのインスタンスが2つ、別々に存在し、それに伴いWwiseのインスタンスも2つ別々にあります。ゲームプレイの状況は、2つのゲームインスタンスの間で常に伝えられますが、Wwiseのインスタンスは、お互いの存在を知ることもなく、単純にローカルで発生しているサウンドを再生し、反応します。オーディオスレッドはその性質上、一定の速度で進みますが、メインスレッドの1つのフレームを計算するのに何ミリ秒かかかり、両者の間で、音の開始や停止に時間差が生じるかもしれません。ほとんどのゲームプレイにおいて、これは些細なことで、どちらのプレイヤーにも自分の「本当の」状況が見えて聞こえるので問題ありませんが、もし一方のオーディオスレッドでイベントが発生してから、それをきっかけに別のイベントが、両側で起きるような場面では、このタイミングが重要な要素になります。

Musicレベルでこの事実と直面した私たちは、戦力をほかに向けるべきだと判断しました。とはいえ、タイミングが致命的でないイベントを自由にトリガーするためにミュージックコールバックを多用していて、例えばバックグランドエフェクトや、ほかの映像的な「装飾」に利用しています。こういったものは、いつ起きても自由なので、音楽的に起きていることに、ビジュアルをシンクせます。

2人とも音楽を再生してワールドに影響を与えることを楽しめ、相手のゲームインスタンスで何ミリ秒か前に起きたダウンビートが原因で、イベントがトリガーされて、それで自分が殺された、などと文句が出ることはありません。

Wwise

Wwiseがオーディオエンジンとして特に役立った例を一つと、逆に役立たなかった例と、その迂回策や修正内容を、教えてくれますか?

PHILIP: 『 It Takes Two 』 は私が初めてWwiseでつくったゲームでした。Wwiseのすごいところの1つは、ソ連時代の自動車ラーダのようで、これは非常にポジティブなことです。どこまでも行ってくれます!もちろんWwiseで技術的な問題もありましたが、それでもいつも仕事を進めることができ、完全に行き詰ることはありませんでした。もう一つ良かったのは、私以外はチーム内でAnne-SophieやJoakimがWwiseをよく知っていて、オーディオチームのほかのメンバーに教えて、指導してくれたことです。また、使い始めるのは結構簡単で、Wwiseを学ぶのに大きい山を超える必要はなく、はやく取り掛かることができました。

Wwiseは世界中の多くのオーディオチームが使っていて、それは基本的に良いことですが、だからこそWwiseは一つのチームだけに、あるいは一つのゲームだけにぴったりと合うような、特定の動作がありません。もちろん私たちの場合はほとんど、それはスプリットスクリーンに対応することでした。1つ、分かりやすい例は、Balance-Fade (2D) の音をセンターチャンネルに送ることでした。音を2つに分割できるように、センターチャンネルを多用するつもりでしたが、センターを分割してステレオ性能を維持したかったのです。WwiseではBalance-Fadeとセンターの%センドを使うことに対応していないので、迂回策としてたくさんのAUXバスを代わりに作成し、センターチャンネルに信号を送りました。

Aux_busses
図7: ワークアラウンドとしてセンターチャンネルに送るAUXバスを作成

JOAKIM: Wwiseは安定したマシンで、常にそうです。つまり、予期せぬことをWwiseが行ったり、やってほしいことをしてくれなかったりしても、一貫しているのです!枠組みとして当然、最新のサウンドエンジンとして期待される基本的な機能がたくさん詰め込まれていますが、Wwiseを使ってファンタジーサウンドに根差したエクスペリエンスに取り組んでみようと真剣に考えているスタジオのために、Wwiseが何か、そして何でないか、自分の考えを説明したいと思います。あなたのサウンドニーズに全て応えてくれる最終的なソリューションとして、提供されていません。

そのようなサードパーティツールは、存在しません。あらゆるゲームプレイ条件や機能のための既成のソリューションは、同梱されていません。

何かというと、驚異的な出発点を提供してくれます。Wwiseという「ボックス」を開けば、すぐに始められ、毎回使え、そこから自分の驚異的なマシンを構築することも可能です。ボックスの中に組み込まれているパーツだけに興味があるような人は、いずれ、がっかりします。逆に、それらパーツを使って何がつくれるのかに興味を持っているのであれば、可能性は無限です。

私たちにとって、自分たちのニーズに合うようにWwise機能を拡張するためにとった一番大きな一歩は、複数のリスナーによって取り扱うスペーシャリゼーションされた信号の、組み合わせ方でした。Wwiseのリスナー2つの設定を使った初期の結果は、満足いく結果ではなく、実はワールドの没入感を阻害しました。初期のテストや作業の多くは不足が多く、私たちが求めている項目を全て満たすような1つのソリューションは、Wwiseにないように感じました。

幸運にもWwiseのアーキテクチャは、ユーザーがエンジンの奥深くまで入り込む心の準備ができていれば、ユーザーがカスタマイズできるように設計されています。このようにして、その時点で、下位システムに根本的な変更を加え、私たちの具体的なニーズに合わせてカスタム化したのです。その結果がSpatial Panningで、WwiseにHazelightの手が加わり、求めていた色が生まれたのです。

GÖRAN: これは、私にとってオーディオプログラマーとして初めてのプロジェクトで、私は制作のあとの方で加わったので、まずWwise用の自動化ツールの改善と構築は、優先した仕事の1つでした。そこでWAAPIが大いに助けとなり、好きなプログラミングランゲージを使い、Wwiseのオーサリング機能を活用できるようになっています。残念ながらWAAPIの機能は完璧ではありませんが、一般的な使用方法はほとんど全て入っていて、Audiokineticは常に更新や改善を行っています。

制作を始めたときは、UnrealにEvent-Based Packagingと呼ばれるコンセプトがありませんでしたが、初期のころに自分たちで独自のバージョンをスタートさせました。私たちは、イベントベースのバンク生成の、カスタム化されたインテグレーションを持っていますが、.bnkや .wemファイルを生成するのにWwiseが提供する生成機能を使っています。反復作業で無駄にした時間を取り返すために一番重視していた決定性と高性能のどちらも備わっているので、よく使いました。 

Wwiseをスプリットスクリーンのゲームに使うほかのスタジオに、どういったアドバイスを送りますか?

PHILIP: パンニングやミキシングの扱い方を決めて、そのルールを守るようにしてください。スプリットスクリーンのゲームのためにオーディオをつくるなら、妥協が必要です。適切なサウンドを優先して、大半の音が、最終的にうまく聞こえるようなルールをつくることです。取捨選択するのは難しいかもしれませんが、プレイヤーにとってクリアで楽しいエクスペリエンスにするには、止むをえません。

JOAKIM: できるだけ早い段階で、あなたのゲームのビジュアルフレームを見て、サウンドデザイナーとしてどの要素が重要なのかを決断してください。アンカーポイントとなるような基準点を見つけ、そのフレーム内に音を配置するときに空間的な一貫性を得るためのソースとします。Wwise内でもアセット作成のソースでも、このようなルールや上下関係を確立するのが早ければ早いほど、これからスプリットスクリーンのオーディオゆえに出てくる変数のリストが大きくなったときに、管理しやすくなります。最後に、できるときは、リスクを取ってください!スプリットスクリーンのオーディオはまだ、私たちの分野では、ほぼ未開拓の領域で、ほかのゲームタイプでは見られない、音で語る新しいストーリーの可能性は大きいです。

GÖRAN: オーディオプログラマーとしてWwiseソースコード無しではどうなったか分からないので、まずコードベースを知るようにして、Hazelightではよく言っているように、めちゃくちゃになってしまうのを恐れないでください。

ANNE-SOPHIE: 私も、Philipが言うパンニングやミキシングのルールを立てて守るというのは、同感です。最終的に音をどのように空間化するかが、スプリットスクリーンゲームの音を決めることになり、このビジョンや、枠組みを、できるだけ早く、そして一貫したかたちで、ルールに仕立てることは、頭痛の原因や混乱を大分解消してくれます。 『 It Takes Two 』 の場合、ミキシングルールとしてうまくいった例の1つは、完全に空間化された音源を目指そうとせず、画面のスペースを、サウンドスケープの大部分の「枠」として使うことです。音が明快になり、スプリットスクリーンゆえの混乱を最小限に抑え、プレイヤーやカメラアングルとの位置関係から、最終的に音がどの位置で再生されるのかを、改善してくれました。画面のスペースを「枠」として使うと言っているのは、あえて多くの音を空間化せず2Dに残したということで、これらは映画などのリニアのメディアでやるように、レフト・センター・ライトのスピーカーで再生し、できるだけ正確で詳細に映像と合うようにしました。もちろん、それで意味の通じる音だけで、例えばキャラクター自身から出てくる音(フォーリー、キャラクターの運転する車両、プレイヤーのアビリティ)や、常にフレームに見えているソースからくる音(短いワンショット音など)からくる音です。つまり全体的にリニアなスプリットスクリーンのゲームであれば、決定論的なサウンドデザインやミキシングアプローチを、完全なスペーシャリゼーションよりも検討してみることを、是非お勧めします。

結局のところ、Hazelightのオーディオチームが課題を乗り越えることができたのは、チーム内のクリエイティブ陣営とテクニカル陣営との間の継続的な協力体制のおかげです。サウンドデザイナーやコンポーザーたち、テクニカルサウンドデザイナー1名、そしてオーディオプログラマー1名のこのチームで、それぞれが専門の技量と長所で貢献し、互いの知識に頼りながら、中断されない協調的な体制をつくり上げ、品質基準をさらに上へ押し上げることができました。継続的な生産性を明瞭で妥協しないビジョンで前に進め、安定したカスタム化可能なツールを使い、これまでにない最高の音のスプリットスクリーンゲームを作成したいという意気込みがあったからこそ、 『 It Takes Two 』 のオーディオエクスペリエンスが成功したのです。

Hazelight

Hazelight

Hazelightは、スウェーデンの映画監督でもある、受賞に輝いたゲーム『Brothers - A Tale of Two Sons』のクリエイターが設立。スタジオ初の公式タイトルとなった『A Way Out』は2018年にリリースされ、Co-opだけの初めてのサードパーソンアクションアドベンチャーゲームとなる。同スタジオチームは真新しいタイプのゲームを求め続け、その好例が2021年3月リリースの『 It Takes Two 』である。Co-op型アクションアドベンチャーのプラットフォーマーゲームである『 It Takes Two 』では、Hazelightの豊かで魅惑的なCo-op体験をつくり出す力が、さらに強化されている。今のHazelight Audio Teamは『It Takes Two』制作中に結成され、Hazelightが世に出すイノベーティブな世界やゲームプレイの仕組みに負けることのない、最高品質のオーディオエクスペリエンスをゲーム全体で提供する。

コメント

Replyを残す

メールアドレスが公開されることはありません。

ほかの記事

ボイスチャットでゲームのソーシャル面を強化 : Wwise GME!

8.1.2020 - 作者 サイモン・アシュビー(Simon Ashby)

PixelSoundというオーディオのおもちゃ

13.10.2021 - 作者 ピーター・ドレッシャー、別名 pdx(Peter "pdx" Drescher)

ライブゲームの反復的なリリースの管理

『Dead by Daylight』は定期的にライブアップデートされる"活きた"ゲームで、制作スケジュールがタイトです。将来の新機能を予測しながら事前に対応しつつ、未公表の情報がWwise...

29.6.2022 - 作者 ビアトリクス・マーシュ(BEATRIX MOERSCH)

「No」を言う方法

19.9.2023 - 作者 ゴードン・マクグラデリー

『ウェイワード ストランド』のボイスオーバーのパイプライン パート3

『ウェイワード ストランド』のボイスオーバー作業についての連載の最終回です。第1回はこちら、第2回はこちらをご覧ください。...

17.10.2023 - 作者 メイズ・ワーリン

1人称視点のホラーゲームを単独で開発する

経歴 アレッサンドロ・グッツォと申します。私は1人称視点のホラーゲーム『The Land of Pain』と『The Alien...

14.11.2023 - 作者 アレッサンドロ・グッツォ

ほかの記事

ボイスチャットでゲームのソーシャル面を強化 : Wwise GME!

PixelSoundというオーディオのおもちゃ

ライブゲームの反復的なリリースの管理

『Dead by Daylight』は定期的にライブアップデートされる"活きた"ゲームで、制作スケジュールがタイトです。将来の新機能を予測しながら事前に対応しつつ、未公表の情報がWwise...