中小タイトルでもこれだけできる―『ニンジャラ』におけるオーディオミドルウェアWwise(ワイズ)導入事例【Game Business Expo セッションレポート】 | GameBusiness.jp

中小タイトルでもこれだけできる―『ニンジャラ』におけるオーディオミドルウェアWwise(ワイズ)導入事例【Game Business Expo セッションレポート】

『ニンジャラ』のサウンドはどのように「Wwise」を活用しサウンド制作に取り組んだのか……。小規模チームでもリッチなサウンド表現ができるAudiokineticの「Wwise」活用方法とUE4との連携などが明かされたセッション内容をレポートします!

ゲーム開発 サウンド
中小タイトルでもこれだけできる―『ニンジャラ』におけるオーディオミドルウェアWwise(ワイズ)導入事例【Game Business Expo セッションレポート】
  • 中小タイトルでもこれだけできる―『ニンジャラ』におけるオーディオミドルウェアWwise(ワイズ)導入事例【Game Business Expo セッションレポート】

2020年6月15日から30日にかけてGameBusiness.jp編集部が主催した、ゲーム業界関係者向けオンラインイベント「Game Business Expo」。6月26日に開催されたオンラインセッションでは、ガンホー・オンライン・エンターテイメントのサウンドディレクター・尾崎景吾氏によるセッション「UE4×Wwise×Nintendo Switch――『ニンジャラ』サウンド制作事例」も行われました。本稿では、そのレポートをお届けします。

講演の模様(テキストとあわせてご覧ください)


Wwise導入の経緯


まずは、『ニンジャラ』のサウンド制作にAudiokineticが提供するオーディオミドルウェア「Wwise」が採用された経緯が語られました。

Nintendo Switchで配信中の『ニンジャラ』は、シノビの力を引き出す「ニンジャガム」を使ったさまざまなアクションでバトルを繰り広げる基本無料のマルチ対戦アクションゲームです。ビルの壁を駆けのぼったり、敵をあざむくために標識などの無機物に変化(へんげ)したりと、忍者らしいアクションが数多く取り入れられています。

かねてよりさまざまなセミナーやプレゼンでWwiseの名を耳にして興味を持っていたという尾崎氏は、『ニンジャラ』のサウンドで積極的に取り入れたかったインタラクティブミュージックをWwiseが得意としていることを知り、よりこだわった音作りの環境を実現するために導入を決定。オーディオディレクターを務める尾崎氏に加え、サウンドクリエイター2名、プログラマー1名の計4名で少数チームを編成し、一部BGMの制作を外部委託しつつサウンドの制作にあたりました。

Wwiseを採用した開発環境を整えるまで


WwiseEventの非アセット化

開発当初はすべてのWwiseイベントをWwisePickerで登録してAkAudioEventと呼ばれるアセットとして管理していたという尾崎氏。一度登録すればサウンド担当者以外のスタッフもWwiseEventを手軽に扱えるようになるメリットがありますが、今回の4人という少数精鋭では、逆に管理が行き届かなくなるリスクにもつながりかねません。そこで、WwiseEventをアセット化するのはエディター上でマップに配置したAmbientSoundに絞ったとのことです。

アニメーションへの紐づけは、WwiseEvent名を直接入力することで対応。アセット同士の紐づけがなくなるので、Eventの削除やリネームが容易に行えるようになりました。ただ、AkAudioEventを廃止したことで距離減衰の範囲表示ができなくなったため、距離減衰パラメーターが入ったメタデータを同時に書き出すことで対処しました。

サウンドシートの導入でゲームとWwiseの依存関係を解消

開発チームの「WwiseをUnreal Engine 4(以下、UE4)から簡単に切り離せるようにしたい」という要望に応えるため、デリゲートに登録する関数文をひとつのcppファイルにまとめた「サウンドシート」を作成。Post EventなどのAPIコールをゲームに直接組み込まず外部に集約させることで、ゲームとWwiseの依存関係をなくしました。

これにより、どこでどのような処理が行われているかを管理しやすくなり、さらに「サウンドシート」のみの修正はゲームに直接影響をおよぼさないので、気軽に変更や修正できるメリットが生まれました。

ただ、AmbientSound、ReverbVolune、AnimNotifyなどはWwise Unreal インテグレーションのコンテンツを直接使用しているため、プラグインを外す際はコンテンツから都度削除したとのことです。

Stateの活用による柔軟なサウンド運用

Wwiseではゲームプレイ中のさまざまなシーンをパラメーターとして設定して管理できますが、尾崎氏たちがとりわけ重宝したのが、シーン変更に合わせて使用するStateを変える「Game Scene State」だったそうです。

『ニンジャラ』では、バトル開始直前の画面暗転中にバトルで使用されるキャラクターを生成しますが、実装の都合上、そのときのキャラクターたちは宙に浮いているのだそうです。開発時はそれが仇となり、意図しないタイミングでキャラクターの着地SE(効果音)が再生されてしまったとのことですが、バトル開始前と開始後を異なるシーンとして設定し、かつ開始前のみをミュートにすることで解決しました。

負荷を増やさず充実させるリバーブ深度設定法

Wwise Unreal プラグインの標準機能のままでリバーブの深度差を表現するにはセンドレベルが異なる複数のReverbVolumeを用意する必要がありますが、増やせば増やすほどCPUへの負荷も上昇してしまいます。

『ニンジャラ』のバトルは60fpsを死守することが前提として掲げられていたため、高負荷を避けるためマップに配置できるReverbVolumeは「シンプルな形状のものを最大6つまで」と定め、さらに、Volumeを増やさずに深度を表現できる方法を模索して「Sound深度Actor」を生み出したとのことです。

これは自身とプレイヤーキャラクターの距離を計算した値をWwiseに送る機能を持っており、そのパラメーターをReverbVolumeのセンドレベルと紐づけることで、もっとも深くリバーブがかかってほしい地点を設定できました。

セッションでは実演動画も披露され、左右をビルに囲まれた通路の中心にActorを設定することで、その通路にいるときだけ(左右をビルに囲まれているときだけ)キャラクターのボイスにリバーブがかかる様子が確認できました。

Wwiseの最適化とデバッグへの活用事例


土台固めが終わったところで、次にWwiseを最適化するまでの過程やデバッグ環境への活かし方の事例が紹介されました。

レイによる負荷を半分以下に軽減するワンレイ遮蔽

Wwise Unreal インテグレーション標準の遮蔽計算は、エミッターとリスナーの間でレイを飛ばし、遮蔽物にヒットした場合、その周辺の12点に再度レイを飛ばして遮蔽値を割り出す……という処理を0.2秒間隔で行います。

少しでも負荷を軽くするため、尾崎氏らは最初のレイ1本のみで遮蔽値を割り出せないかと模索。レイが遮蔽物にヒットした場合に、「その箇所が遮蔽物の中心からどれくらい離れているか」を遮蔽値として設定することで、レイ1本(ワンレイ)の処理で遮蔽計算を可能にしました。遮蔽物に厚みがなく細長い場合は中心軸を設定し、そこを中心として処理しているとのことです。

ReverbVolumeのカリングによる負荷軽減

WwiseのReverbVolume機能は、キャラクターが設定された箇所に出入りしたかを1フレームごとに判定します。ここも処理を軽くするため、判定の間隔を任意に設定できるように改修。『ニンジャラ』では、0.2秒(12フレーム)間隔に設定されています。

また、サウンドのリバーブ処理や遮蔽処理はサウンドが聞こえているときのみ行えばよいので、リスナーがエミッターの範囲外にあるときや、エミッターでそのとき再生しているSEが何もないときは、チェックや判定そのものを行わないようにし、さらなる負荷軽減を実現しました。

インゲームでのデバッグ表示による効率化

Wwiseのプロファイラーは、使用するゲームオブジェクト名、距離減衰、リスナーからのダイレクトパス、リスナーの位置、リスナーとエミッターの向きなどを取得できますが、デバッグをより円滑に行えるよう、同等の情報をインゲームで表示できるよう改修。ゲーム画面上に表示することで、マップ上のエフェクトや配置オブジェクトなど、実際のプレイ画面との関係性を視認しやすくなりました。

部分的なハードデコードコーデックの採用

音声のコーデックには、Nintendo Switchの機種固有コーデックを採用。固有のものであるだけに、高品質のまま負荷の軽減に貢献します。ただし、同時再生可能なインスタンス数(同時発音数)が少ないというデメリットもあるため、すべてのサウンドには採用せず一部のBGMやキャラクターボイスのみに留めているとのことです。

『ニンジャラ』を象徴するインタラクティブミュージック


『ニンジャラ』のサウンドで特徴的なのが、バトル中のBGMが色とりどりに変化するシステム「シノバズサウンド」です。プレイヤーはバトル前に任意のBGMを設定することができ、バトルが始まってBGMが1コーラスを終えると、その時点で1位のプレイヤーのBGMに変化します。サウンド面からバトルを盛り上げるために考案されたインタラクティブミュージックに関する導入事例を紹介します。

シノバズサウンドの実装まで

当初は「BGMを1コーラス分再生し終えたら、BGMを切り替えるかの判定を行う」ため、「Music ID=BGM A 切り替え判定=True」という2つのステートで管理すればよいと考えた尾崎氏。ところが、プレイヤーが1位でBGMの切り替え判定が一致しない場合、最初に選んだBGMがそのまま続くのではなく、再生が停止されてしまい変更を余儀なくされました。

そこで、現在再生されているBGMを識別するためのStateを「Battle_Music」と「Battle_Music_NowPlaying」、どのプレイヤーが装備しているBGMであるかを識別するためのState Groupとして「Music_Owner」と「Music_Owner_NowPlaying」という、計4種類のStateを実装。さらに、BGMを切り替えてよいかのフラグとしてStateGroup「Music_Transition」、BGMの1コーラスが終わるタイミングをCustomCue「SongEnd」と設定しました。

バトルが始まると、そのとき再生される曲の情報を「Battle_Music_NowPlaying」と「Music_Owner_NowPlaying」で管理しつつ、バトルの展開に応じて「Battle_Music」と「Music_Owner」を1位のプレイヤーのBGM情報にリアルタイムで書き換え。BGMが「SongEnd」に到達した時点で「Music_Owner」と「Music_Owner_NowPlaying」を比較し、両者が同じであれば再生中のBGMをそのまま継続、両者が異なる場合は、「Battle_Music」と「Music_Owner」の情報がコピーされて楽曲が変更される、という実装で解決しました。

尾崎氏は、説明するとまわりくどく感じられるが実際の挙動はシンプルで、すべてWwise上で管理できるのも大きなメリットであると補足しました。

ミュージックコールバック関数を利用したサウンドとグラフィックの連係

バトルが行われるマップでは、サウンドがゲームに影響を与える演出も用意されています。リリース直後の時点では、ミュージックコールバック関数を利用して得られる、再生中のサウンドのビート情報をグラフィック側に渡すことで、マップ上のスピーカーやモニターのアニメーション速度が再生中のサウンドのテンポに合わせたものになり、一体感が演出されています。

さらに、再生中のサウンドのビジュアライザー表示や、サウンドに合わせたパーティクルの発生などができないか検証を続けていると紹介されました。

Wwiseは大きな可能性を秘めている


最後に、尾崎氏らサウンドチームのその他の取り組みと、今取り組んでいる課題が紹介されました。

取り組みとしては、WwiseのSoundbank生成と周波数スペクトラム解析にJenkinsを採用していること、大量に用意する必要があるニンジャガムに関するサウンドの制作・量産の効率化のために、ビジュアルスクリプトのコンストラクタを用いたオリジナルのインストゥルメンタル「GUM SYNTH」を作成したことが挙げられました。

そして課題としては、WwiseEvent名を文字列で検索できる機能の実装、QAチームが問題解決のために活用できるよう、プロファイラーによるキャプチャーログをいかに速やかに取得するかなどが挙げられました。後者に関しては尾崎氏がAudiokineticに相談したところ、海外デベロッパーのQAチームでは、WwiseをインストールしたPCでキャプチャーしている事例があるとのアドバイスを得られたとのことです。

尾崎氏は「Wwiseは、さまざまな機能や可能性を秘めたツールです。私たちも、まだまだ使いこなせているとは言えません。『ニンジャラ』はいわゆるAAA(トリプルエー)タイトルではなく、小中規模の作品ですが、そこでもこれだけのことが実現できるのだということをお伝えできたなら幸いです。本作は今後もアップデートを継続していくので、サウンド面ではどのようなものを追加で実装できるか、どこを改善できるかの検証を続けていきます」と語り、セッションをまとめました。

「Wwise」公式サイトはこちら
《GameBusiness.jp》

関連ニュース

特集

人気ニュースランキングや特集をお届け…メルマガ会員はこちら