Wwiseヘルプ

従来のSoundBankロード方式はEventデータ、構造データ、メディアが混在するSoundBankを使いました。これらSoundBankのコンテンツ（中身）をそのまま、特定のタイミングでゲームにロードしたりアンロードしたりして、イベントデータや関連するメディアが、トリガーされた時に再生できるように準備しておきます。

従来からあるこの方式で、2つのSoundBankを作成して、プレイヤーがゲーム中にレベル1からレベル2に移る時に、それぞれのSoundBankをプラットフォームメモリに対してロード（Load）したりアンロード（Unload）したりする様子を、下図に示します。

ここでは、SoundBankにある全てのデータやメディアを、一度にメモリにロードするので、必要な時に備えてどのデータやメディアも再生できる状態になるだけでなく、ゲームプレイ中に実行するディスクシークが非常に少ないため、他のディスク負荷の高いタスクを行うディスクスペースを確保できます。

この方式の主な欠点は、SoundBankがロードされている状態では、これらのSoundBankが終始、かなりのメモリスペースをとるため、規模が大きく洗練されたゲームの場合は、柔軟に対応しづらくなることです。また、この方式では、SoundBankの中のメディアファイルのうち、既にメモリにロードされているものがあるかを確認しないまま、コンテンツ（中身）を全てロードします。つまり1つのメディアファイルが、メモリに何回もロードされてしまう可能性があります。しかし、欠点があるものの、この従来の方式はピンボールゲームのように、常に全てのデータやメディアを使用可能な状態にしなくてはならない場合には、適しています。

LoadBank()メカニズムの欠点を一部、解消するために、バンクをロードせずに、AkBankContent_All()を使って、SoundBankをプリペア（Prepare / 用意）できます。この方式ではSoundBankにすべてのコンテンツタイプ（Event、構造データ、メディアファイル）が入っていても、メディアファイルをそのままロードするのではなく、すべてのメディアをPrepareEvent()メカニズムを使用してメモリにロードします。このメカニズムでメディアをロードする時、Wwiseはまず、各メディアファイルが既にメモリに存在するかどうかを調べてから、ロードします。メモリに同じメディアファイルがロードされることを防ぎ、メモリ使用率を最小限に抑えます。

この方式を使うとメモリを節約できるほか、ディスクアクセスが必ず順番に行われます。PrepareEvent()を使ってイベントを1つずつプリペア（用意）すると、ランダムなディスクシークが発生する可能性が高くなりますが、これを回避できます。

「バンクの準備（全コンテンツ）」のメカニズムを使って、プラットフォームメモリにメタデータやコンテンツをロードする様子を、下図に示します。

SoundBankに、Vorbisエンコード、またはWEM Opusエンコードのメディアをロードするときに、 Preparation typeを Preparation_LoadAndDecodeにし、メディアファイルを圧縮なしのPCM ファイルにデコードすることが可能です。その結果SoundBankのサイズが大きくなりますが、イベントがメディアをコールした時に解凍せずにすぐに利用できます。

PrepareEvent() 方式は、必要な時だけメディアをロードするダイナミックな方式です。この方式を使うにはAction EventのメタデータをSoundBankに入れ、関連メディアファイルをファイルシステムからアクセスできる状態にする必要があります。対応する構造メタデータはイベントと同じSoundBankに入れるか、別のSoundBankに入れます。この方式では、Action Eventのメタデータが入ったSoundBankは、LoadBank()（バンクをロード）を使って、メモリにロードされ維持されます。Action Eventはゲームに呼び出される前にサウンドエンジンで「準備」します。Eventを準備することでファイルシステムにあるすべての関連メディアファイルがロードされ、関連する構造メタデータがすでにロードされていない場合は、これもSoundBankからロードされます。Action Eventが不要になると、「準備を解除」すれば対応メディアファイルがメモリからパージされます。メモリ使用率を最小限に抑え、メモリ内でメディアファイルが重複するのを防ぐために、Wwiseはメディアファイルをロードする前に、必ずチェックを行い、そのメディアファイルがまだメモリに入っていないことを確認します。

	注釈
	事前にプリペア（用意）できるのは、Action Eventだけです。PrepareEvent()（プリペアイベント）方式は、ダイアログイベントに使えません。

イベントを事前にプリペア（用意）することで、必要なメディアファイルだけがメモリにロードされる様子を、下図に示します。

メタデータ（構造と呼ぶこともある）がイベントと同じバンクに格納されていない場合に、他のSoundBankに保存された対応データを見つける手段が必要となります。探せるように、Wwiseは、他のSoundBankに保存されている関連コンテンツのレファレンス（参照情報）を入れます。他のSoundBankを参照するには、名前またはIDを使います。サウンドエンジンでSoundBank名を使用する場合は、Project SettingsダイアログのSoundBanksタブでUse SoundBank Namesオプションを選択する必要があります。IDを使う場合は、この選択を外します。詳しくは「SoundBanksタブ」を参照。

SoundBankが参照するメディアは、ディスク上にファイルとして保存するか、その他の方法でローレベルIOが扱える状態（File Package内など）でなければなりません。

この方式は全般的にメモリ使用が非常に効率的ですが、ディスクシークが増えるため、すでにディスクからストリーミングしているファイル数が多い状況には向かない可能性があります。また、ゲームで複数のStateやSwitchを使う場合は、不要なメディアファイルもメモリにロードされる可能性もあります。例えば、ゲーム中の観衆（Crowd）の声として、観衆の満足度やエネルギーレベルに合わせて複数のサウンドがあるとしても、ゲームの特定ゾーンで、「Angry（憤慨）」Switchに該当するサウンドだけが使われるのであれば、他のサウンドをメモリにロードしても意味がありません。このような問題を避けるため、ステートやスイッチも「準備」する段階を設ければ、プリペアされたステートやスイッチに関連するメディアファイルだけをロードできます。

Switchだけを事前にプリペア（用意）して、メモリにロードされるメディアの数をさらに抑えた例を、下図に示します。

ゲームシンクを事前にプリペア（用意）することでメモリ使用を最適化できますが、同時に、メモリにメディアをロードする速さが遅くなるので、注意が必要です。プリペアされたゲームシンクに該当するサウンドを探すため、サウンドエンジンがディスクの中をシークする必要があるので、読み込み時間が長くなります。

この第2の方式では、必要なオーディオファイルだけをダイナミックにロードするので、多数のサウンドが存在する巨大なゾーンやレベルなどの状況や、メモリにイベントデータ、構造データ、メディアを保存するスペースが非常に限られた状況でも、柔軟に対処できます。

ご覧の通り、どの方式にも長所と短所があります。ゲームのさまざまなシナリオ、要件、制限などに基づいて、最適な方式をお選びください。1つの方式を選んだにしろ、いくつかを組み合わせたにしろ、戦略が決まれば、SoundBankに中身を入れて調整を開始できます。

	注釈
	ここで紹介した、LoadBank、AkBankContent_All、PrepareEvent、PrepareGameSyncs、AkBankContent_StructureOnly の各種機能は、Wwise APIを通して使用できます。バンクのロードや、イベントやゲームシンクの準備については、Wwise SDKの、Integrating Banks のセクションを参照してください。

SoundBank管理に利用できる様々な方式の詳細については「SoundBank管理の戦略」を参照してください。