先日、オーディオオーサリングミドルウェア「Wwise」を開発するAudiokinetic社の日本法人Audiokinetic K.K.設立のローンチイベントが東京・赤坂のカナダ大使館で開催され、『METAL GEAR RISING REVENGEANCE』でサウンドを担当した田中(BGM)、中越(SE)が「Wwise」導入の意義についてプレゼンテーションをさせていただきました。

一般の方には馴染みが薄いであろう専門的な内容になりますが、プレゼンテーションに使用させていただいた資料の一部をこちらでご紹介させていただくと共に、サウンドのプログラムを担当した大森より、内容についても少しご説明させていただければと思います。「Wwise」の導入を検討されているゲーム開発者の方々の参考になれば幸いです。

☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆

◎SEに関する内容:
METAL GEAR RISING REVENGEANCE Audiokinetic 「Wwise」事例紹介

◎BGMに関する内容:
METAL GEAR RISING REVENGEANCEにおけるインタラクティブミュージック

◎BGM事例1ビデオ

◎BGM事例2ビデオ 注：ビデオは音楽を聴きやすいよう効果音をオフにしています。

今回サウンドのプログラムを担当しました大森です。プレゼンの後、いくつかご質問をいただきましたので、「Wwise」導入に関して要した期間や工夫した点などを少し補足させていただきたいと思います。

１．組み込みにかかった時間

・２週間程度
・｢Wwise｣はAPIの数がかなり少ない
・分からないところは、取り敢えずサンプルのまま 放り込んでおけば動く

おそらく２週間程度で基本的なサウンドシステムは構築できていたと思います。既存のサウンドシステムと、ある程度の親和性を保つ形で構築を行いました。

また、APIの数はそれほど多くありません。というか、後述しますがプログラマーにできることは、かなり限定されています。

IOやストリーム関係など最終的には手を入れなければいけない箇所はありますが、とりあえずサンプルのまま放っておきました。

２．組み込み当初に困ったこと

・プログラムで出来ることが少ない！

「Wwise」の組み込み当初に一番困ったのが「プログラムから何も出来ない」ということです。プログラムから出来るのは「イベントを実行する」ことだけで、最初はとても窮屈に思いました。(「Wwise」にはパラメタ制御など他にも色々な機能がありますが、メインは「イベント」です)

何せ音量を変えるAPIすらありません。サウンドから「ポーズした時にＢＧＭの音量を下げて欲しい」と言われても「そういうイベントを作ってくれ」としか返せません。

なので、「Wwise」導入当初には「プログラマーは何も出来ない、イベントを組め」ということを繰り返し言っていた記憶があります。

やり方に慣れてしまえば、サウンド側がイベントの中に必要な処理をまとめてくれるようになります。そうなった後は「プログラマーはイベントを呼ぶだけ」でいいので、作業は非常に楽になりました。

３．ＣＰＵ・メモリパフォーマンス

・豪華に使えば当然重くなる
・クォリティとパフォーマンスのバランスをサウンド側で取れる

パフォーマンスに関しては気にされる方が多いと思いますので、実際のゲーム中のシーンでパフォーマンスキャプチャーを行なってみました。比較的厳しいシーンで取っていますので、参考にして頂ければと思います。

キャプチャーはXbox 360で行なってみました。まずはメモリから。

ざっくり足して10MB弱と言った所です。ただし波形データは基本的に含まれていません。このシーンでの波形データ総量を調べた所、12MB弱でした。サウンド全体としては22MB程度使用しています。

「Wwise」のエンジンに割り振っているメモリの量は、サンプルで指定されている量よりも多めにしています。ストリームが常時複数本走っているのと、大量の発音が起こる場所に対処するためです。

このシーンでは処理軽減のため一部のＢＧＭがメモリに乗っています。その割に、波形データは小さくなっていると思います。PS3ではVorbisフォーマットを使用しているため、更に小さくなります。

次に各種パフォーマンスです。

発音数106、実際に信号制御まで行われた音[Number of Voices(Physical)]は48の状態で、CPUが22.86％です。Xbox 360でのキャプチャですので、ハードウェアスレッドのうち１つが23%程度使用されています。全体に対する負荷は4～5%と言った所です。

PS3ではかなりの部分がSPUに回されるため、CPUの負荷はこれよりも大幅に下がります。

また、このグラフを見ると、CPUのピークと発音数のピークがずれていることが分かります。CPUがピークとなっている箇所を見ると「Number of Registered Objects」の数が大幅に下がっているタイミングと一致しています。

これは、シチュエーションの切り替えにより大量のオブジェクト解放処理が走り、CPUの負荷が一瞬増大したことを表しています。

最後にバスの状況です。

アクティブなバスは４つ。エフェクトとして「Meter」「Peak Limiter」「Compressor」「Delay」「RoomVerb」が使用されています。このシーンでは「Delay」と「RoomVerb」はBypassされているためエフェクト計算による負荷[Total Plug-in CPU]は小さくなっています。

メモリやCPUの最終的な使用量に関しては、これらの項目を見ながら決めて行きました。これらのキャプチャーデータは保存しておくことができ、あとで好きなところを見ることができます。

とりあえずキャプチャーしながらテストプレイをしておいて貰えば、後から気になるところを確認できるため、各種のピークを調べるのにとても役に立ちました。各種ログも残りますので、デバッグにも有用です。

導入当初、「Wwise」に関しては不満に思うこともありました。プログラマーに出来ることは少ないし、サウンドの作業は増えるし、処理もそんなに軽いわけではないからです。

最終的には導入して大変助かったと思っています。プログラマーはイベントを呼ぶだけでいいし、コストやパフォーマンスに関しても、サウンドが決められた枠の中で納得の行くように取捨選択できます。

サウンドの作業量は確実に増えますが、自分たちで制御できる領分が増えて、遣り取りも少なくなるので、あまり苦にならなかったんじゃないかなぁ……と思います。

大体こんなところでしょうか。他にも質問などがありましたら、お答えできる範囲でお答えしたいと思います。お気軽にコメントして下さい。ご検証などの参考になれば幸いです。

☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆