Rovioで私たちがF2P（Free-to-Play、無料プレイ）モバイルゲーム向けオーディオ開発でどのようにWwiseやその他のツールを使い、どのような戦略でワークフローや生産性を改善しているのかを、この記事で明らかにしたいと思います。

はじめに 

モバイルゲーム向けオーディオはパソコンやゲームコンソール向けのオーディオ開発の縮小版だと考える人もいるかもしれませんが、実際にはモバイルゲームオーディオなりのとてもユニークな性質や難しさがあります。私は大手モバイルデベロッパのサウンドデザイナーとしての経験からF2Pモデルは特にそうだと感じていて、このモデルではゲームがどちらかというと継続的な サービス として開発され、単発的な 製品 として扱われません。

ゲームをライブサービスとして開発する上で最もよくある課題は、数年におよぶ製品のライフタイムを通して常に更新しながら継続的に開発して維持するというしくみです。安定したインフラと拡張可能なツールが必要であり、そのためにはある程度の先見性と準備が求められます。この点、モバイルゲームと一部のマルチプレイヤーデスクトップゲームには共通点があります。

大きな会社のモバイルゲーム開発で特によくあるもう1つの特徴は、同時進行プロジェクトや重複する開発サイクルが多いことです。通常PCやコンソール向けの開発はプロジェクト自体の規模が大きく、開発サイクルも長いため、 一般的に 1つのプロジェクトだけの作業が積極的にすすめられます。一方モバイルゲームはその逆で、短期開発の小さなプロジェクトが複数あります。

この場合、オーディオチームはさまざまな技術的ニーズや芸術的要件のある複数の進捗状況の異なるプロジェクトに携わり、広く浅く仕事をします。同時にこのチームは展開中の製品の常時アップデートを維持する責任もあります。さらにF2Pゲームはイテレーションやテストベースですすめられる傾向があり、パフォーマンスが悪いなどのさまざまな理由でいつキャンセルされるか分からず、新しいプロトタイプもキノコのようにどんどん出てきます。このようなチームにはさまざまな課題に対処するための洗練されて効率的なワークフローが必要だということは、想像に難くありません。このような課題を Rovio がどのように解消したのかを技術的な観点から説明し、 Wwise やその他のツールの活用方法について『 アングリーバード 』最新版などの最近のプロジェクトを事例として取りあげながら、ご紹介したいと思います。

テンプレートの国のアリス 

複数のプロジェクトを取り扱う時に最も役立つのが標準化されたツールであり、ワークフローや改善点をプロジェクト間で引き継ぐことができます。学習の相乗効果が生まれ、以前に同じシステムを使用して学習した内容の上にナレッジを構築することが可能です。またプロジェクトを数年間維持することを考慮し、ツールがスケーラブルで将来性があり、使いやすいことも不可欠です。

ゲームオーディオデザイナーの道具箱の中心的なツールとなるのがミドルウェアやその他の実装プラットフォーム（例えばネイティブまたは独自ゲームエンジンツール）だと言えるのかもしれません。インテグレーション前のアセットの準備方法、再生システムや動作の構築方法、技術的な制約事項など、作業の基盤がこれで決まります。複数のプロジェクトで同じ実装ツールを利用することで、ダイナミックミキシング、アセットパッケージ（サウンドバンク）、テンプレート、プリセットといった同じアプローチを採用することができます。

しばらく前から頼りにしているミドルウェアのWwiseですが、どの新しいプロジェクトにおいても使用できる（ほぼ）空っぽのWwiseテンプレートプロジェクトをレポジトリで保管しています。テンプレートプロジェクトには初期設定の作業を簡略化するための具体的な設定、例えば汎用的なミキサー階層、デバグコンテナやイベント、Actor-Mixerやコンテナプリセットのひな型、いくつかの共通ゲームシンク、サイドチェインRTPC、コンバージョン設定、シェアセットなどが入っています。自分の典型的なニーズにカスタマイズされたテンプレートプロジェクトであるため、恰好のスタート地点となりゼロからはじめる場合と比べて時間がかかりません。具体的なプロジェクトに合わせるために多少のカスタマイズはよく必要となりますが、実はこれは悪いことではなく、自分たちの方式を疑問視しながら改善する機会となり、同時に数歩すすんだところから作業を開始できます。このプロジェクトは直近のプロジェクトで実施した最新の改善点を組み込むために常に更新して維持管理しているため、次のプロジェクトでも自分たちの実装アプローチの最新版が反映されたかたちでスタートすることができます。

Wwiseのテンプレートプロジェクト

過去には前のWwiseプロジェクトを使い、そこから次のプロジェクトのテンプレートをつくり上げようとしたこともありましたが、これは面倒でエラーが起きやすいやり方だと感じました。また新鮮なアプローチで臨んで新しいことを試すことの弊害となり、慣れた仕事の仕方に落ち着いてしまいます。 

まとめてラッピング 

標準ミドルウェアがあるとすばらしいのですが、現実的に不可能なこともあります。どのプロジェクトも要件や相互関係が異なり、気づけば違うツール一式を使っているというケースもあります。別のミドルウェア（あるいはミドルウェアなし？）や、全く違うエンジンや、単に別のツールを使った過去のプロジェクトを維持する場合など… 

このようなシナリオに対応するために私たちの武器庫には AudioWrapper というUnity向けのカスタムツールがあります。元々は私の以前の同僚Filip Conicがゲームエンジンとオーディオミドルウェアの間のラッパークラスとして設計したものです。AudioWrapperを使うことでミドルウェア固有のインテグレーションだけに頼ることなく、オーディオコードをミドルウェアと独立させることができ、オーディオコーディングの流れをどのプロジェクトでも同じようにすることができます。このようなラッパーがあることで、使用ツールに影響されない共通のインターフェースで仕事ができます。オーディオ担当者だけでなくそのサードパーティAPIに不慣れなほかのデベロッパも、複数のプロジェクトに参加しやすくなります。

AudioWrapperの使用例

AudioWrapperのもう1つの重要な役割は、オーディオインテグレーションの考え方をより高いレベルで標準化することです。どのゲームもセットアップが異なりますが、ゲームのエンティティやロジックの構築方法に関わらずGUIに基づくインテグレーションツールを使用する場合よりも、コードを通してサウンドインテグレーションを行った方がメソッドを標準化できます。これはどのプロジェクトでもサウンドやミュージックのトリガー方法、ロード・アンロード、イベントの扱い方など、似た実装ワークフローを使用するための私たちの選択です。

ラッパーを使う場合は開発途中にミドルウェアを簡単に交換することができるのも特典の1つです。手はじめにすばやく簡単にイテレーションできるネイティブツールでプロトパイプの作業をすすめ、プロジェクトの勢いが増してきた時にWwiseのようなミドルウェアに切り替えて便利な機能や高度な機能を利用するというのはよくあるシナリオです。メインのツールを変えてもシンタックスは同じであり、オーディオ関連のコード全体をわずかな変更だけでそのまま使うことができます。 

一旦クールダウンしましょう 

このラッパー式アプローチはツールをもう1つ開発して管理するという負荷はありますが、私たちの場合はメリットの方がコストより確実に大きいです。自分たちのニーズに合わせてミドルウェアの機能の上にビルドすることも、これがある分だけ楽になります。

『 ダークファイヤーヒーローズ 』はキャラクターやアクションが大量にあり、多くのボイスが同時再生されるモバイルRPGです。モバイルゲームならではの気軽さから、プレイヤーに音をオンにしてもらうこと自体が難しいです。だからこそ混みあったサウンドを減らして聞き心地をよくすることがとても重要でした。また、レイヤーが常に視覚的な情報に注目していなくても楽しめるゲームにするために、最も重要な情報がいつも露出されるようにしたいと考えました。Wwiseのボイスリミット設定やダイナミックミキシング設定もかなり便利ですが、制御範囲をひと回り増やすためにAudioWrapperを拡張して機能をいくつか追加し、それを使いWwiseイベントをラッピングしようと思いました。最初はタイムウィンドウ（調整可）内の後続イベントの数を調整するスロットルのような機能を提供する、イベントのクールダウンシステムでした。それがいったん使えるようになれば、プロバビリティやディレイなどのさらなる追加コントロールを付加することは簡単でした。これらの追加コントロールポイントを使い、イベント（マクロ）とイベントアクションやボイス（ミクロ）の両方のレベルで設定を微調整することが可能となり、ミックスをクリアにするための柔軟性が飛躍的に高まりました。

『ダークファイヤーヒーローズ』のAudioEventスクリプタブルオブジェクトの例

元同僚のMikko Kolehmainenは『 アングリーバードアドベンチャー 』（英語名：Angry Birds Journey）で、『 ダークファイヤーヒーローズ 』のクールダウンシステムを基に Audio Event Presets と私たちが呼ぶものをつくりました。この改定版ではミドルウェアイベントをラッピングするのではなく、それまでと同じような設定（クールダウン、ディレイ、プロバビリティ、その他も可能）のイベントハンドル（文字列）を指定し、一致するイベントはそれらの設定に従います。このシステムの方が維持管理や一括変更がとても楽になります。さらにこれらのデータはすべてXMLファイルに保存され、パフォーマンス改善のために事前にロードされるというメリットまであります（旧バージョンはデータをランタイムにフェッチしました）。一方、厳密で一貫性のある命名規則への準拠が求められますが、安定した質の高い命名規則に反対するような人はいないはずです（少数派の口うるさい人を除き）。良質な色分け規則に次ぐよさがあります。

『アングリーバードアドベンチャー』のAudio Event Preset設定

Mix It in the Fix 

イベントやボイスリミットは、明瞭なミックスに至るまでのメダルの片側でしかありません。メダルの裏側にあるのがダイナミックミキシングで、予測しづらい継続的なボイスの流れにプライオリティ付けをし、可能な限り分かりやすく気持ちよく聞こえるクリアなサウンドに変えるツールであると私は考えています。その意味で良質のミックスはゲームイベントやその結果のサウンドにダイナミックに反応することができる、良質のミキサー階層からスタートします。

私たちはプライオリティに基づいてミキサー構造を構築します。 サウンドタイプ （アンビエンス、ミュージック、ゲームプレイなど）に従うバスだけを使うのではなく、サウンドの プライオリティ を追う構造を使用します。プライオリティ分けするためにバックグラウンド（BG）、ミッドグラウンド（MG）、フォアグラウンド（FG）といった単純なカテゴリを使います。プライオリティが異なるグループ同士は、ステート、オートダッキング、サイドチェインで駆動するダイナミックコントロールとしてのRTPC経由などで互いに影響します。

ミキサー構造の例

例えばシューターゲームにおけるプライオリティレベルは、武器が高、敵の動きが中、プレイヤー動作が低となるかもしれません。このアプローチでは汎用的なミキサー構造やバス名を維持することが可能であるため、前述のミキサーテンプレートが利用しやすいです。個々のプロジェクトのカスタムバスはありますが、メインバス同士の接続が同じであるため、それなりに聞けるサウンドミックスを最初から確保するために非常に便利です。ほとんどの場合、ほんの少しのカスタマイズが必要なだけです。

ダークファイヤーヒーローズのミキシングプライオリティの例

It’s Alive 

F2Pモバイルゲームの仕事はリリースした時点で終わりではありません。逆にはじまったばかりとも言えます。モバイルゲームの「リリース」とはグローバルローンチのことを指すことが多く、これは終点ではなくゲームのライブサービスの出発点です。そもそもゲームはしばらく前からソフトローンチ状態にあるはずです。

このようなマルチリリースモデルはオーディオデベロッパにとって、コンテンツや機能の全体像が分割して制作され、マイルストーンごとに徐々に展開されていくことを意味します。ソフトローンチは一部のリージョンでゲームが限定的にリリースされる時であり、プレミアゲームのアルファ版に該当するかもしれません。グローバルローンチ前には継続的な更新やイテレーションが行われ、ゲームのベータ版に近づきます。オーディオの作業はこの時期に徐々に本格化するか、より一般的なのは、リリース日付近に大きなスプリントでこなされます。目標はこの日までにゴールドを獲得することですが、実際には一部の機能がこの時点でベータで出荷されることがあります。ゲームのリリーススケジュールの次の段階であるライブサービスがあるからこそ、これが可能なのです。

ライブオペレーション中にゲームが定期的なアップデート（通常は1～2か月ごと）で磨き上げられ、改善、修正、拡張されます。オーディオチームにとって、時間制限のために基準に達していなかったコンテンツに磨きをかけて修正するチャンスです。ほかにもアップデートのたびに新しいメカニズム、新しいキャラクター、新しいチャプター、新しいミュージックトラックなど、新機能やコンテンツが追加されます。

これはもう1度サウンドを見直して不完全な部分を改善する絶好のチャンスです。ライブサービスゲームの大きな利点は、このような初期のアップデートでプレイヤーのフィードバックに簡単に反応して必要な変更を行えることです。ゲームがリリースされた後の初期のアップデートではオーディオチームもかなり忙しく、それ以降のアップデートは作業量が少しずつ減り、落ち着いてゆく様子が想像できます。これらのアップデートはゲームの中心的なテーマを掘り下げ、芸術的な観点で枠組みを広げるチャンスでもあります。最初の数回のアップデートでシステムや構造のスケーラビリティが試されるため、自分のワークフローを見直して将来の改善メモを作成するよいタイミングとも言えます。

ライブオペレーションモデルにはさまざまなメリットがありますが、オーディオチームはコンテンツを毎月納品する覚悟が必要で、しかも対応すべきゲームは単数ではなく複数です。新しいゲームのための作業もあります。

継続的なアップデートに落ち着いて臨むためには、よい計画としっかりとしたコミュニケーションが鍵です。まず最初にこれからのコンテンツの規模を把握し、リソースを適切に配分することが重要です。予定されるマイルストーンすべてのタイムラインを把握することが大事です。すべてのオーディオに関するニーズをプロデューサーたちから迅速に収集し、オーディオ側の要件を伝えるべきです。

制作の骨子を確立させた後は、問題や衝突を起こさずにゲームをアップデートするためのツールや規則です。Wwise内で階層、サウンドバンクの構造、テンプレート、命名規則（いつもながら）などを、拡張性を意識しながら構築することになるかもしれません。WwiseのWork Unit をここで活用してコンテンツを隔離させることは賢い方法です。プロジェクトに新しく参加する人たちも問題なくプロジェクトに馴染め、すでにあるコンテンツとの一貫性を保つかたちで新しいアセットを実装できるような明確で容易なワークフローとするべきです。

次の重要な作業はコンテンツをさまざまな段階でテストすることです。まず最初にゲームエンジン内でテストします。すべての新しいコンテンツが機能してエラーがないことを確認し（ゲームのほかの部分を誤って破壊させないことを確認することはもっと重要ですが）、いよいよデバイスでビルドをテストします。私たちはデバイス上でテストする前に、ビルド自体をテストしてローレベルの問題がないかどうかを確認するようにしています。これはバージョン管理ツールでオーディオ作業を別のブランチに置くことで可能です。ビルドがエラーフリーであることを証明できた場合は、オーディオチームやQAチームのメンバーがデバイス上でテストすることができます。機能についてクリエイティブディレクターの意見や感想を聞くのに適したタイミングでもあります（コンテンツを実装する前にすでにゲームプレイの動画キャプチャを使用して行っていると思いますが、実際のゲームプレイエクスペリエンスに代わるものはありません）。

以上の手順を踏むことで、ライブオペレーションのアップデート時に問題に直面する可能性が劇的に減ります。いずれにしても、安全のために機能完成の日付よりも前にオーディオ開発の締め切り日を設定することで（少なくとも1週間前）、新たな問題に対処する余裕を確保することができます（問題はいつか必ず起きます）。 

最適な制限 

ゲームオーディオはこれまでに古き良き時代の多々の技術的制約を乗り越えてきましたが、モバイルゲームはこの領域でまだ成長の余地があります。低機能な端末に対応するための限られたメモリやCPU予算や、パッケージサイズの制限など、課題はまだ残っています。そこで私たちが採用してきた最適化戦略について、ここで言及することも重要であると思います。

旧世代のモバイルゲームでは音楽をモノラルに落としたり、22.1 kHzのようにサンプルレートを半分にしたり、最低品質のコンバージョン設定を採用したり、オーディオマニアの私には言うのも恥ずかしい極端な手段も含め、さまざまな激しい方法を使った記憶があります。今はそこまで厳しくする必要がなく嬉しいです。Rovioではできるだけクリエイティブなアイデアを技術的な枠組みで抑え込まないようにしています。少なくとも最初は自由な発想からスタートさせ、後から現実的なメモリや処理能力の制約に合わせて調整を行います。例えば『 ダークファイヤーヒーローズ 』ではゲームのオリジナルミュージックが100分以上にもおよび、キャラクターや呪文の種類が大量にありました。 

『ダークファイヤーヒーローズ』のサウンドトラック

1番分かりやすい戦略は保守的なコンバージョン設定です。絞るところは絞り、緩めるところは緩めるのがコツです。あるサウンドに適用するコンバージョン設定を決める際、私はまず以下のようなことを自問自答します： 

• このサウンドが再生される頻度は？ 
• サウンドの長さは？ 
• プレイヤーエクスペリエンスにおけるこのサウンドの重要性は？ 
• サウンドのスペクトルの性質や、空間的な性質は？ 

これらの質問に答えていくことで品質とパフォーマンスのちょうどよいバランスを見つけることができます。頻繁に再生されるサウンドである場合はCPUへの負荷が大きくなるため、すばやくロードできると有利です。一方で常にプレイヤーが耳にするサウンドである場合は、ある程度の音質が求められます。滅多に再生されないサウンドは一瞬だけのディテールであるため、低品質でも許容されることが多いです。しかしやはりゲームプレイのエクスペリエンスにおいて重要な意味を持つサウンドである場合、ありがたみを感じる特別なものが必要です。例えばすべてのディテールが伝わるように、ステレオのままにして完全なサンプルレートを維持させるかもしれません。

ゲームによってプライオリティもゴールも異なり、質問への回答が変わりますが、必ず正しい方向へと導いてくれるはずです。私たちは典型的なゲームを基に、一般的なコンバージョンシナリオを網羅したプリセットを私たちのWwiseテンプレートにいくつか入れました。こうすることでパフォーマンス面のよいスタート地点を簡単に設定することができ、サンプルレートや圧縮品質などのパラメータは必要に応じて微調整できます。Wwiseでビットレートを切り捨てることができなため（サンプルレートを下げることはできますが）、私たちはファイルのエクスポートを48 kHz、16 bits（場合によっては24）とすることが多いです。

最適化の別の方法は、同時に発生するボイスや処理の量を制御することです。プライオリティやボイスリミットの設定は適切に整えてあり、先ほど説明したイベントクールダウンシステムも大きな助けとなります。それ以外にプロパティ継承を最大限に活かし、Actor-Mixerやプロパティの重複使用を抑えるようなアクターミキサー階層の設定が大切です。マスターミキサー階層においても同じです。例えば『 ダークファイヤーヒーローズ 』ではActor-Mixer階層全体をタイムストレッチプラグインを中心に構築し、プラグインインスタンスがすべてのボイスで重複されないようにしました。プロジェクト構造が少しややこしくなりましたが、パフォーマンスは非常によくなりました。 

『ダークファイヤーヒーローズ』のActor-Mixer階層

ほかにも、頻繁に使用するRTPCを修正してベジェ曲線ではなくリニアカーブだけになるようにする、といった小技もあります。しかし最も費用対効果が大きいのは、アセットやWwiseプロジェクトを最初から拡張可能な設計とすることだと思います。複数の目的で使用できる共有可能なアセットを作成することも含みますが、そもそもアセットの作成を抑えるべき部分を知ることが大事です。例えば『 ダークファイヤーヒーローズ 』ではエネミータイプ別にカスタムボイスを追加しましたが、エネミーのバリエーションでは行いませんでした（火のゴブリンと氷のゴブリンは同じボイスを使っています）。一方、アタックサウンドとヒットサウンドは共有グループしか使っていません。このようにしてエネミータイプごとにカスタマイズされた感じをつくり出し、それでもメモリ予算内に収めています。納品するコンテンツ数を制限することは、今後のアップデートのコンテンツ需要に対応するためにもよい戦略でした。

最後に忘れてはならないのがサウンドバンクのセットアップで、これがうまく設定されているとミュージックやアンビエンスなどの大きいファイルに特に有利です。私たちは通常、メタやコアのゲームプレイ要素、キャラクター、UIなどが入ったいくつかのサウンドバンクをコアパッケージとして整え、これを初期インストール時にダウンロードさせます。その後、新しいミュージックやアンビエンスのある新チャプターなどのコンテンツを別のサウンドバンクに入れ、ダウンロードパッケージとして提供します。これで1時間以上の固有のミュージックコンテンツを確保できます。ゲーム中のミュージックやアンビエンスのバリエーションはレイヤーやセグメントを活用したアプローチで実現しています。私たちのミュージックやアンビエンスは大半が複数のレイヤーやセグメントで構成され、これらをランダムに使用することで繰り返しを少なくしています。特に『 アングリーバードアドベンチャー 』のアンビエンスは非常にダイナミックな方式で設定されていて、リバーブセンド、LFO、エンベロープ、フィルターなどのランダム設定された数多くのパラメータを採用し、常に変化し続ける感覚をつくり上げています。アンビエンスはRTPCで相互に作用するレイヤーもあり、ダイナミックな環境が創出されます。どのゲームプレイミュージックトラックもイントロが4バージョンあり、プレイヤーは新しいレベルに入るたびに違う印象を受け、ミュージックトラックの開始地点はAまたはB、再生されるレイヤーは3つのうちの1つとなるため、バラエティが非常に豊富です。 

『アングリーバードアドベンチャー』：氷の洞窟チャプターのアンビエンスをWwiseよりエクスポート

『アングリーバードアドベンチャー』：氷の洞窟チャプターのミュージック

『アングリーバードアドベンチャー』のゲームプレイミュージックの設定

まとめ 

モバイルゲームはPCやコンソールゲームの弟分とみなされることもあります。とはいえモバイルゲームのオーディオは深く入り組んだものにすることもできれば、シンプルでかわいらしいものにもできます。モバイルゲームゆえの制約や課題があるのは確かです。ただし致命的な制約があるとすれば、それはプラットフォームではなくゲームそのものに起因することが多いです。デザイナーの創造力を広げてくれるゲームこそ想像力を引き出すサウンドを生み出し、特徴のないプロジェクトは芸術的にもつまらない窮地に追いつめられます。それ以外の制約事項は考え方やツール次第で解消できてしまう、単なる問題点です。