このブログ記事はPlariumで最初に公開されました。

モバイルゲームに求められる技術的な要件や見た目の美しさに対する要件は着実に増え続けており、コンソールゲームやPCゲームのレベルに近づきつつあります。サウンドデザインに求められる要件も例外ではありませんが、携帯電話にはデフォルトビルドのサイズ、ボリューム、サウンドの同時再生、CPU負荷などの技術的な制限が数多くあります。サウンドシステムが適切に構築されていない場合、クラッシュが評価アルゴリズムの対象になることもあって、モバイルゲームストアでの評価に悪影響がおよび、プロジェクトの命運を左右することにもなりかねません。こうした問題の原因を特定して、すでに実行段階にあるプロジェクトをやり直すには、開発当初からサウンド制作に向けて計画的なアプローチを取るよりもはるかに多くの費用がかかります。

私はPlariumのオーディオプロデューサーのイリア・ゴゴリエフです。10年以上の間、モバイルゲーム、シネマティクス、テレビ、オンライン広告向けのサウンドデザインに従事しています。オーディオチームと協力して開発に取り組んだPlariumプロジェクトの中でも特に有名なのは、RAID: Shadow LegendsとMech Arenaです。このブログ記事では、プロジェクトにもゲームプレイにも支障が出ない方法で、モバイルゲーム向けのオーディオコンテンツを最適化する方法を紹介したいと思います。社内チームや外注のサウンドデザイナーだけでなく、サウンド制作に自力で取り組むインディーデベロッパにも有益な情報となるでしょう。 

 

モバイルゲームでサウンドの最適化が必要な理由

携帯電話はゲームコンソールではないため、PlayStationやXboxのようにゲームプレイを目的として作られているわけではありません。またデベロッパという立場上、たった1つの特定のモバイルデバイスではなく、幅広いデバイスに対応することが求められます。ゲームが携帯電話向けに最適化されていない場合、それが原因となってプレイ体験がネガティブなものとなり、プレイヤーが離れてしまうという結果を招きます。

プレイヤー離れの原因

• ゲームのロードに時間がかかりすぎる
• ゲームの容量が大きすぎる
• ゲームの動作が遅いまたはクラッシュする
• サウンドと映像が同期していない
• サウンドの音量が小さすぎるまたは大きすぎる（プレイヤーが煩わしく感じて、ゲームプレイに影響を与えます）

おそらく理由はもっとあると思いますが、サウンドを最適化することで最終的な結果が変わる部分に焦点を当てたいと思います。

最適化とは、RAM、ディスク容量、CPU使用率といった利用可能なリソースを一定のバランスに保つことです。

出典：Unity Audio Import Optimisation（著者：ザンダー・ヒューム、職業：サウンドデザイナー）

この図はモバイルゲームを最適化する必要のあるすべての人に関連します。テクニカルアーティストとデベロッパの両方が該当します。

 

課題：ビルドサイズのリミッティング

App StoreやGoogle Playによって設けられているデフォルトビルドのサイズの上限は、モバイルゲーム制作や開発のモデルに大きな影響を与えます。現在のところ、両ストアの上限は200MBです。このブログ記事では、マーケティング担当のジョナサン・フィッシュマンが実施した、App Storeのモバイルアプリのサイズと最適化戦略に関する以下の調査結果を紹介します。

アプリが200MBを超えると、ユーザに送られるアプリサイズに関する警告メッセージが原因で、コンパージョン率が15～25%低下する可能性があります。

それに加えて、プレイヤーが数万から数十万人規模になると、不具合発生率を大幅に下げたいという理由でデベロッパがゲームを最適化してビルドサイズを200MB以下に調整することもあります。

解決策

できるだけ早い段階からゲームリソースのプロファイリングに取り掛かる。ミドルウェアを使用していない場合でも、Unityを使用すればプロファイリングは可能です。リリースする機能の数を事前に把握し、デフォルトビルドのサウンドに必要な容量を予測し、この情報を記録しておきます。

AudiokineticのWwiseプロファイラには、特定の瞬間におけるゲーム内のサウンドに関連するすべてのオブジェクトの階層が表示されます。ここではリソースのボリュームや重みが、ゲームプレイ中のデバイスの機能にどのような影響を与えているかを確認できます（出典：audiokinetic.com）

私たちの経験から言えば、デフォルトビルドの合計サイズの少なくとも10%をオーディオアセットに割り当てる必要があるでしょう。

ファイルの圧縮に関して、これはやや厳しめの要件です。これについては、さらに詳しく考えてみましょう。追加のコンテンツについては、アセットバンドルを通して後からアップロードします。

できるだけ早い段階からオーディオコンテンツ階層の構築に取り掛かる。複数のオーディオコンテンツがある場合には、少ない容量をどのように分けるのかを考えましょう。割合はオーディオのジャンルなどに応じて変わります。アンビエントサウンドが多く必要な場合もあれば、インターフェースサウンド、ミュージック、ボイスなどが多く必要な場合もあります。リソースの整理に取り掛かるのが早いほど、ゲームの開発や新機能のサイズ予測が容易になります。技術的にここまでという線がはっきりしていれば、一定の制約に適応する必要があるため、解決策でクリエイティビティを発揮できます。

課題：リソースの圧縮

以下によってリソースサイズを最適化できます。

• サンプリングレート
• フォーマットと品質

サンプリングレートの歴史については掘り下げませんが、携帯電話がどのようにサンプリングレートを使用して動作するのかについては理解しておく必要があります。情報媒体のサンプリングレートとしてもっとも普及しているタイプは、44,100 Hzと48,000 Hzの2つです。これらは長年にわたって並行して活用されています。

44,100 HzのフォーマットはCDに使用され、48,000 Hzは映画やケーブルテレビに使用されていました。両フォーマットは、デバイスやサービスの発展に大きな影響を与えてきました。MP3プレイヤーの後継デバイスという位置付けでもあったスマートフォンは、長年44,100 Hzで動作していました。iPhone 6Sの発売以降、Netflix、YouTubeなどのストリーミングサービスや大容量のビデオゲームが登場し、携帯電話では48,000 Hzのコンテンツが大勢を占めるようになりました。

携帯電話がネイティブ周波数で動作中に、特定のアプリが別の周波数でファイルを再生するよう強制すると、携帯電話は直ちにファイルの周波数を変換しますが、ユーザが聞いてそれに気づくことはありません。動作周波数が下げられるか上げられるかによって、このプロセスはそれぞれダウンサンプリングまたはアップサンプリングと呼ばれます。アセットの周波数を下げてディスク容量を節約しても、CPUに過剰な負荷がかかっていました。このため、携帯電話のほとんどは現在48,000 Hzに切り替えられています。これにより、ネイティブ周波数で直接動作できるようになりました。

解決策

すべてのコンテンツを48,000 Hzのままにすることが、Google Developersにより推奨されています。圧倒的大多数の携帯電話がこの周波数で動作しているためです。しかし、圧縮が必要になる可能性が高くなるため、これを実現できるのは理想的な場合に限られます。

ディスク容量を節約する目的で、サンプリングレートを利用してアセットを品質に関して圧縮する場合は、24,000 Hzまたは16,000 Hzからはじめるようにしましょう。リソースのアンサンプリングを実行する携帯電話の場合、周波数を2倍または3倍するのが最も簡単な計算式です。極限圧縮の第一候補になるのはボイスオーバーのほかに、ノイズのコンポーネントが音色のコンポーネントに勝っているアンビエントサウンドなどがありますが、圧縮後のサウンドを注意深く聞いてアーティファクトを見つけてください。

これらの解決策を使用せずに済ますことはできるか？

この問いに対する答えは「イエス」であり、ゲームがどのように実行されるのかをよく理解し、別の周波数に変換したり大きなフォーマットを使用してもプロセスに影響がないことをプロファイラで確認できる場合、これらの解決策は不要です。そして、クリエイティブなアイデアは諦めないでください。これらの解決策は、Googleの推奨通りにすべてを圧縮する必要があることを意味しているわけではありません。

オーディオアセットの圧縮でよく使用されるフォーマット

• ADPCMはアセットをリニアに圧縮します。ファイルサイズは3分の1まで小さくなります。解凍プロセスは非常に速く、CPUリソースを使用しません。このフォーマットはUIに最適で、例えばボタンを押した時の応答速度を上げたいといったニーズに対応します。
• Vorbisを使用すると、ファイルの圧縮効果を最大にできますが、解凍で使用されるCPUリソースが多くなります。聞こえてくる圧縮後のサウンドが要求される水準に達しているかを判断するには、注意深くサウンドを聞いて、サウンドの解凍時間を確認する必要があります。この圧縮ツールには品質スケールが用意されていますが、ニュアンスを掴むことが重要です。品質パラメータによって判定されるのは圧縮後のファイルの品質ではなく、圧縮ツールの品質です。例えば、Unityでは品質スケールが1から100の範囲で定義され、Wwiseでは対数式で定義されます。このため、品質が0または–1になる場合があります。 

RAID: Shadow Legendsの最新リリースでボイスオーバーの例をお聞きください。

例：

• 生成ファイル：48 kHz PCM WAV – 1 MB
• サンプリングレートの圧縮ファイル 24 kHz PCM WAV – 500 kB
• ミュージック（再生により確認可能）が追加された高品質圧縮ファイル：OGG Vorbis（~q. 0.4）- 100 kB

前述したGoogle Developersのアドバイスに従わない場合は、ファイルをさらに圧縮する必要が生じる可能性があります。Vorbisで20 kHzまで圧縮することや、圧縮の品質を下げることも可能ですが、まずアーティファクトを確認してからこれを行ってください。次にオーディオコンテンツの優先順位と重要度について考えます。

課題：RAMの優先順位付けシステム

携帯電話には、すべての操作に優先順位を付けるシステムが備わっています。ゲームより重要度が高いと見なされるプロセス用に多くのメモリが予約されています。緊急通知、通話、ヘルスアプリなどが例として挙げられます。さらに、ユーザは同時に複数のアプリケーションを使用するのが当たり前となっています。例えば、Netflixを観ながらファイルをダウンロードし、同時にインスタントメッセンジャーを使用するといったことが起こり得ます。

結論：携帯電話の一定メモリ容量は、ゲームでは絶対に使用できません。

そのため制限への適合が求められます。これを行わない場合、携帯電話は単に優先順位の低いものをすべてクラッシュさせようとします。

ゲームサウンドに使用されるメモリ容量を把握する方法としては、ゲームシーンのすべてのサウンドバンクのサイズを合計します。これがメモリ使用量になります。ゲームシーンに必要なすべてのコンポーネントや特定の機能は残し、必要ないものはすべて厳密に制限します。例えば、メニューのサウンド、シネマティックシーン、メモリからのアンロードが完了している以前のシーンなどです。

このことが重要な理由は次の通りです。

• 必要以上のメモリを使用する = FPSが下がり、ゲームが「スライドショー」になります
• メモリリソースを過剰に使用する（例：サウンドバンクのロードやアンロードを制御しない）= メモリの上限を超えるとクラッシュし、プレイヤーを苛立たせるだけでなく、ゲームの進捗データが失われて、プレイヤー離れを招きます

解決策

対象デバイスを特定し、そこで徹底的にテストする。

できるだけ早くプロファイリングに取り掛かり、ゲームシーンや機能ごとのメモリ使用量を予測します。

小さなサウンドバンクを数多く作成する。1つの大きなサウンドバンクより有用です。最初は管理しづらいと感じるかもしれませんが、時間が経てばこの方法によってゲーム内での不要なリソースの使用を回避できるようになります。

柔軟性に優れたサウンドバンクのトリガーシステムを構築する。メモリにロード、またはメモリからアンロードするサウンドバンクの条件を制御します。これは手動で行うことを推奨します。AudiokineticのWwiseなどのミドルウェアを使用するとよいでしょう。すべてが「内部処理」されることの多いUnity Audioとは異なり、Wwiseではユーザが文字通りすべてのサウンドのロードやゲーム中のサウンドのライルサイクルを制御できます。

ストリーミングを使用する。Spotifyではなく、ディスクベースタイプのリソースパッケージングでは、ファイルをゲーム内でRAMを使用せずに解凍できます。ミュージック、アンビエントサウンド、ボイスオーバーをストリーミングできます。ただし使い過ぎは禁物です。メモリ使用量が減る一方で、CPUに負荷がかかります。

課題：フィジカルボイスの上限数

携帯電話では、サウンドの同時再生ストリームに制限があります。これは「フィジカルボイス」と呼ばれ、非常に厳しく制限されています。「how to get a hold on your voices」の記事では、ボイス数を50～100にすることが推奨されています。私たちのチームの経験からすると、これは非常に楽観的な見積もりです。

私たちは、同時ボイス数のリスクゾーンは20～30の範囲だと考えています。ボイス数が多いと、AndroidとiOSの両方でオーディオがいとも簡単にクラッシュします。

ゲームシーン内にオブジェクトがいくつか登場するマッチ3ゲームを制作するとします。例えば、爆発するパイナップルが登場します。1つのアセットにサウンドを1つ割り当てますが、次のレベルではパイナップルの数が15個になります。このためボリュームやオブジェクト数の制限が必要になります。15個のパイナップルのサウンドがうるさすぎるという事実だけでなく、CPUに負荷もかかります。

解決策

優先順位を設定する。サウンドの重要度の階層を構築する必要があります。ボイスの上限を超えても、決して犠牲にすべきではない最重要サウンドを決定します。逆もまた同様です。優先順位が低く許容限界ゾーンに到達した場合にドロップするアセットを決めます。

例えば、ゲームシーンで爆発するパイナップルの数に関係なく、プレイヤーがこのタイプのボイスを聞くのは3つまでにするといった条件を追加できます。プレイヤーが知る必要があるのは、パイナップルがいくつか爆発したことだけであるため、携帯電話でボリュームや同一プロセス数が過剰にならないようにすることが重要です。

AudiokineticのWwiseプロファイルでは、サウンド階層が「リスナーに向かってすすむ」ライブイベントのキューのように表示されます

ボイスの上限を設定する。上限は、グローバル（特定のプラットフォームが対象）または個々のアセットに対して設定できます。後者の場合は、ゲームエンジンでどのように不要なリソースを取り除くのかを選択します。例えば古いリソースを停止する方法や、再生中のフィジカルボイスが終了するまで新たに再生できないようにする方法があります。

プラットフォームやアセットごとに上限を設定

対象デバイスですべてをテストする。

アナリティクスを分析する。ゲームセッションのログを収集することは極めて重要です。膨大なデータセットがあって、はじめてプロジェクトの問題点と深刻度を把握できます。こうしたログには、メモリ使用量の統計、ファイルのアップロード速度に関するデータ、クラッシュの統計などの情報が含まれます。アナリティクスを使用しない場合でも、ストアが代わりに行います。プレイヤー離れの原因がゲームのクラッシュや低パフォーマンスであるとストアによって判断された場合、それに応じてそのゲームは検索結果の下位に表示されます。

課題：ダイナミックレンジの制限

デスクトップコンピュータ、ゲームコンソール、テレビに比べて、携帯電話のダイナミックレンジは非常に狭い範囲に限られています。これはリスナーに向けて発する最大ボリュームと、最小ボリュームのサウンドの差が小さいことを意味します。ボリュームグラデーションも小さく、粗くなります。

デベロッパは、携帯電話ではすべてのサウンドのボリュームをデスクトップコンピュータやゲームコンソールより若干大きくし、圧縮率を高くする必要があります。

解決策

ミックスレベルについては、ソニー（–18 LUFS）やGoogle Developers（–16 LUFS）の推奨値に従う。これは一般的なアドバイスです。PlayStationやXboxとは異なり、App StoreとGoogle Playにはラウドネス認証がありません。提案されているスダンダードを満たしていなくても、検証に問題はありません。

ヘッドフォン用とスピーカー用の2つのミックスを作成し、動的なステート変更を実装する。Unityでもこれに対応した、Mixer Snapshotという名前のツールが用意されています。Wwiseでは別のステートを作成できます。プレイヤーがスピーカーを使用する場合のステートに対応した別の設定のテンプレートを作成し、プレイヤーがヘッドフォンを着脱した時にステートを変更するトリガーを追加します。

ゲームセッションのミックスを測定することで、推奨されているスタンダードからどの程度離れているかを大まかに把握します。リアルなゲームセッションの動画をできれば30～40分記録し、Youlean Loudness Meterなどの無料のプラグインを使用して測定します。こうすることで、ゲームサウンドのボリュームを把握できます。

 

最後に

これまでに説明した技術上の妨げのせいで、ゲームのクリエイティビティを台無しにしてはなりません。クリエイティブなコンセプトに沿った結果であると確信していれば、スタンダードから逸脱していても受け入れられます。

また、志を同じくする人々のコミュニティでアドバイスを得られることも常に心に留めておいてください。経験を共有し、学び、人脈を作るには、プロフェッショナル集団のコミュニティに参加することが大切です。こうしたグループの1つが、Discordで運営されているウクライナのオーディオデザイナーのコミュニティ、Noise Shelterです。このコミュニティには現在100人を超えるプロフェッショナルたちが集っています。

ほかにもゲームオーディオ：ゲームサウンドへの取り組みに関する広範囲にわたる内容の記事（ウクライナ語のみ）が役に立つかもしれません。この記事は主に初心者と、サウンドデザインの仕事やツールに関心のある方々を対象としています。

コメント欄にご意見やご質問をいただけますと幸いです。プログをお読みいただきありがとうございました。