いくつかのメリットを簡単にご紹介しながら、特に予算枠の大きいゲームでWwiseを採用する利点を、自分の考えとして述べたいと思います。
どのプロジェクトにも共通する、オーディオミドルウェア採用のメリットとは
- プロジェクトの音をより良くできる。
- 効率的にリソースを活用できる。
- プログラミング時間を短縮できる。
ゲームの楽しさの半分は、オーディオからきます。ゲームオーディオとは、単に音をトリガーして鳴らすだけではありません。残念ながらオーディオは範囲が限定されてしまうことが多く、オーディオ実装の作業も、プロジェクトの最終段階に、誰もやりたがらないようなマイナーなタスクとなってしまいます。オーディオのプログラミングは決して楽でなく、それを支援できる担当リソースがいなければ、問題が起きるかもしれません。Wwiseを使うと、上にあげた3つの大きなメリットを何の不自由もなく達成でき、しかも短時間で最適化された状態で使い始めることができます。その結果、オーディオパイプラインの実装が改善され、プロジェクト全体の品質も向上します。
プログラミング時間の削減
Wwiseに独自のインターフェースがあり、サウンドデザイナーはアセットの整理やメカニズムの制作を、ゲームエンジンから完全に独立して進められます。複雑なシステムを構築するのにプログラミングが一切不要でとても速いので、サウンドデザイナーの能力を広げてくれます。具体的には、カスタムスクリプトをビルドする時間や、ゲームプレイのコアに集中したがっているプログラマーと延々とやり取りする時間を、何時間も節約できるのです。プログラマーが普段するような作業を大きく割愛でき、サウンドデザイナーが自分ですべてを処理できるようになります。
1) 基本的なWwiseのインプリメンテーションは、このような感じです:
一番多く書かれるコードのラインが、PostEventというファンクションです。Eventによって引き起こされる動作は様々ですが、このファンクションが、サウンドエンジンの該当Eventと、WwiseがそのEventで行う内容を、コールしてくれます。
2) 2番目に多く使われるファンクションは、SetRTPCValueです。
RTPCもまた、時間を節約してくれる機能で、ダイナミックオーディオに関連する複雑なシステムの基盤となります。
下の例では、Car.Speedという、コードにある実際の値（数値は0から30まで変化）を、私が設定したRTPCのSpeedBisにつなげてあります。
こうすると、Car.Speedが変化するとリアルタイムにソフトウェア側で更新されます。その結果、ゲームでは、車のスピードが速くなるにつれ、その値に合わせて風のアセット音が徐々に大きくなります。次に、音量を、ゲームプレイしながら自分で調節します。時間にして5～10分で完了！
3) プログラマーとのやり取りは、自分で設定したメカニズムに使える値や、先ほどの、EventをコールするPostEventファンクションを入れる場所などを、聞くときだけです。ほんの数分で終わり、スクリプトは一切不要。もしあとで、自分の制作を可能な限り突き詰めていきたいと思うことがあれば、プログラマーにお願いすることが増えるかもしれません。稀なケースですが、それには20～30分ほどかかります。
分かりやすい事例: 車（Car）が環境（Env）に衝突（Impact）するとき（マップにはConcrete、Metal、Rock、Woodの4つのテキスチャがあります）。インパクトポイント（Collision Enter）で、Eventをコールします。まず左のSwitch Containerを経由し、タグに従い、適切なアセットを選択して再生させます。問題はありませんが、Eventのポスト先が、そのスクリプトが付いているGame Objectとなっています。そうすると、車にオーディオ的なスペーシャリゼーションを適用できません。それでも音を3Dにしたいので、インパクトポイントでEventをトリガーする必要があります。
プログラマーの助けを借りてカスタム設定し、コリジョン時点でGame Objectを作成し、そのタグ情報を、すでに自分で設定したメソッドに送り、音を再生するインパクトポイントをobjectHitとします。Wwiseで設定しておいた3Dポジショニング* を、これで実現できました。
時間はかかりますが、それでも20分以内。コードは必要でも、機能を作成する作業でなく、できたものを仕上げるということだったので、私もプログラマーも楽しめました。
4) Wwiseでクリック2回ほどで済むような基本的な機能も、プログラミングするとしたら、何日もかかります。ランダム再生に関連する要素だとか、浮動小数点や整数値をリンクさせるだとか、オーディオアセットを稼働させるための要素などは、かなりの時間を要した作業の一例で、たとえここで努力してもカスタムスクリプトは失敗することがあり、パフォーマンスにも影響します。プログラマーはゲームのコア部分に集中してもらうのが理想的です。Wwiseのようなサウンドエンジンですでに準備されているようなシステムを、わざわざ何時間、何日、あるいは何か月もかけて開発するよりは。
リソース使いの効率化
Wwiseは、Unityセッションや、ビルド状態のゲームにも接続でき、詳細にプロファイリングを行えます。もちろん、再生しながら行ったミキシングや微調整も、即時に適用されます。Unityでもライブミキシングが可能ですが、オーディオに影響する設定値やその他のパラメータはランタイムに変更できません。プロファイラ機能を使えば詳細データが表示され、CPUを最適化して、最終的にメモリ使用を効率化できます。Wwiseは、コードを書かなくても優れたメカニズムと音の良いサウンドシステムを提供してくれるだけでなく、最適化もしやすくしてくれます。
1) メモリを節約するにはオーディオの圧縮が必要です。ターゲットプラットフォーム毎に最適な設定を選択します。
自分のプロジェクトが対応するプラットフォーム別に、圧縮率を変えて設定できます。また、特定のプラットフォームに入れたくないアセットがあれば、それを除外できます。
2) SoundBankは、本当に便利です。すべての作業内容をグループ別に分類してデータを分けることで、オーディオの実装がグッと効率的になります。
具体的には、ゲーム中に、そのときに必要なアセットや、そのマップで必要なアセットを、ロードすることになります。メモリ使用を完璧にできればパフォーマンスが素晴らしくなり、細かいところまでコントロールできます。ランゲージ（言語）のローカリゼーションも、最初から組み込まれている機能の1つです。UnityやUnrealだけでは、言語を切り替える機能がなく、セリフやその他のボイスを置き換えて、適切にローカリゼーションすることもできません。
3) Playback Limit機能はパフォーマンスに大変重要な設定で、間違ったスクリプトで発生してしまうバグや問題から、私たちを救ってくれます。
何らかの理由で、スクリプトがEventを千回トリガーしても、文句を言わなくても大丈夫。ほとんどの問題は自分で解決できるもので、前もってファイルやコンテナが一度に再生できるインスタンスの上限値を設ければいいだけです。プログラマーの時間を節約できるので、プロジェクトのリソースも節約できます。この機能は本当に必要で、なければ痛みを伴うと思います。
サウンドインスタンスの上限に到達した時点で、オーディオをバーチャルボイス状態に送ることができます。とても効率的なリソース運用の方法で、エンジンはオーディオの処理を停止し、ボリュームの計算だけを実行しファイルが再び必要となるまで待機させます。同じように、アセットが、プロジェクトの設定で決めたボリュームスレッショルドよりも低い時も、対応できます（例えば3Dオブジェクトがリスナーから離れ過ぎたり、車のRPMの変化など、バックグランドで常時聞こえるオーディオがあるときなどです）。このとき、ファイルが耳に聞こえないのに処理を続ければ、ハードウェア側のアクティブボイスを不必要に占領してしまいます。それを、バーチャルボイス状態に送り込むわけです。
このように微調整や設定変更を行いWwiseのパフォーマンス設定を最大限に活かせば、メモリと、処理能力を、効率的に使ったり節約したりできます。
サウンドエンジンのないゲームエンジンを使うと、プログラミングに頼らざるを得ません。また、オーディオの実行が上手でなければ、パフォーマンス負荷が非常に高くなることは、周知のとおりです。
もっと良い音を
読者がDAW（デジタルオーディオワークステーション）上で息をのむような素晴らしいオーディオアセットを作成し、最高のサウンドライブラリやレコーディングを有効活用したとしても、アセットを正しく実装できなければ、すべてが無駄になってしまいます。使うツールが優れていれば、自然とプロジェクトの品質が向上するはずです。自分の仕事内容を自分で完璧にコントロールできると、その成果がゲームのパフォーマンスにも反映されます。
プログラマーは、私たちのリクエストすべてに対応してオーディオ的なニーズを満たしてくれるだけの時間が、どうしてもありません。サウンドデザイナーとして、些細なディテールも常にプログラマーに依存するのでは、全体像だけを気にせざるを得なくなり、もっと時間のかかる大事なディテール部分は省かれるかもしれません。例えばUnityは個別アセットのボリューム調整を許容していません。これが問題となるのは、カスタムスクリプトの中に、ユニークなオーディオソースを共有するオーディオファイルのアレイが含まれるときです。いつでも正確性が肝心なので、満足できる仕事をするにはゲームに入れるすべての詳細まで気を配ることが必要で、効率的な設定調整ができなければ、ミックスに悪影響です。これはすべてのことに当てはまり、ピッチやフィルターのように、Unity のミキサーやオーディオソースに適用できるエフェクトも同じです。また、オーディオソースを最小限に抑えて、ファイルの個別コントロールで妥協しないという原則は、誰もが知っていることです。
今回は、読者全員に意味のある内容にしたかったので、全面的にメリットのあることを中心に書きました。これ以外にも、ミドルウェアによってサウンドデザイナーの仕事が楽になることは沢山ありますが、Wwiseがなければ享受できない効果や、時間と努力が必要なものなどもあります。
簡単で速くこなせる仕事は、最終的に、質の良い仕事につながります！
ほかにも沢山の参考文献が！
コメント