ゲームよりな演出、音楽よりな演出
プログラムで直接オーディオファイルを扱っていた
今のようにゲームエンジンがなかった時代、
wavファイルを直接プログラムで扱うことで音を鳴らすことができました。
実際には、wavファイルはメモリも多く、そのまま扱うには大きすぎるので、ADPCMや
ゲーム機によっては、独自の波形再生コーデック（エンコードとデコード＝音声の圧縮と解凍）を持っていて、
非常に軽量に再生が可能でゲームのメインのCPUの負荷を下げることができていました。
昨今のゲーム機では、特別な再生音源などがありません。
このため、負荷のかからないコーデックが常に求められています。
・・・ なお、もっと昔はMMLとかで楽器のデジタルシンセサイザーと同じ内蔵音源を直接鳴らすコマンドを送って音を鳴らしていた時代もありました。
ゲームエンジンでのオーディオは扱いやすい
ゲームエンジンがでてきてゲームのオーディオはとても扱いやすくなりました。
直接wavやmp3素材を扱うことができるので、ある意味なんでもできてしまいます。
スクリプトやBPなどでサウンドとプログラムの間の処理を書くことができます。
ゲーム内の変数へのアクセスなど自由に設計ができます。
しかし、
大量の音が扱われるようになると、それらの更新状況、使用状況、音の差し替えや修正作業が難しくなります。
自由に配置できてしまうため、どこのスクリプトで使われたかなどの把握が難しい面があります。
特に多人数で扱うようになると、
気がつかないうちに複製されていたり、参照が消えてしまったりなど、問題が発生した時の追求が難しくなります。
・・・ それを踏まえても試行錯誤をする上では、直接素材を扱える点はとても魅力的です。
ゲーム上でサウンドをコントロールするということを学ぶのに丁度良い環境です。
どのようなものか掴むのにゲームエンジン上での試行錯誤はとても大切です。
音が多くなった時の管理
ゲームが出来上がってくると、音も増えていきます。
音が多くなる＝ファイル数が多くなる
これは、ゲームエンジンのエディタに特に負荷をかけ始めます。
オーディオの圧縮／解凍といっても長さに応じてそれ相応の時間がかかります。
完成間近になればなるほど、アセット数、リソース数が様々な作業を苦しめ始めます。（回避策はいろいろありますが）
サウンドの場合、ゲームエンジンのエディタでの再生前に必要です。
つまり、初回起動時や実行時などはとても時間がかかります。
もしアセットの差し替えが行われた場合など、バージョン管理ツールから拾ってきたら、
その都度発生することになります。（たとえその音を鳴らさないとしても）
サウンドとは関係ない作業のマシンであっても負荷を増加させます。
さらに、リリース用のビルドのタイミングでも、機種によっては再度処理が入り、ビルド時間が長くなります。
長い波形があれば、それだけ時間がかかります。
サウンドはBGMや収録したボイスなど合計すると数時間にも及ぶデータになる場合があります。
たとえ、数倍、数十倍の速度でエンコードできたとしても、それ相応の時間がかかってしまうのです。
ADX2を使えば この時間を0にすることができます。（あらかじめエンコード済みデータを用意しておくことができる）
すべてをゲームエンジンの統合エディターで行いたい気持ちはすごくあります。
ですが、実際は、使い慣れたDCCツールなどで3Dのモデルやモーションなどは作ることになります。
画像ファイルなども同様です。
同じようにオーディオも考えられます。
ADX2を使えばこれらの作業はサウンドのツール上で行うため、ゲーム制作時の負担を軽減することができます。
素材作成ツールが別ツールの利点
ADX2の場合、CRI Atom Craftという別ツールでゲーム実機でも軽量に再生できるよう
コンパクト＆パッキングしたデータを扱うのでゲームエンジン上でも負担が軽減されます。
大量のボイスを扱うなどの場合は、ミドルウェアを使うと改善される面があります。
いや、むしろ本格的にサウンドをつぎ込むのであればミドルウェアは必須と考えられます。
別ツールでの管理というのは、一見余計な手間を挟むように見えるのですが、
ゲームでよくある演出である、音量調整、音色のランダマイズ、さらにはダッキング処理や、インタラクティブな音楽や効果音のデザインができます。
GUIやプレビュー機能もあるのでゲームを動かさずとも動作を確認することができます。
エフェクト、音量や音の調整といった音に関するところに特化して、
エフェクトのかかり具合など、ゲームエンジン内でも調整は可能ですが、CRI Atom Craftを使うことで例えばDAWのミキサーのような形で変更ができます。
サウンドだけで扱いたい素材（リソース、アセット）
オーディオだけのリソース（アセット）管理になるので、ゲームエンジン側に余分な複製が作られないのも良い点です。
3Dで例えると
作成中はテクスチャや形状データなど編集しやすい形の付属データがあるかと思いますが、
FBXのような標準フォーマットにすることで、やりとりが簡易になるのに似ています。
インタラクティブミュージックでも効果絶大
オーディオ担当の人にも扱いやすく、
音の断片素材などを多く扱うインタラクティブミュージックなどのデータ管理に向いています。
ADX2ではインタラクティブミュージックは「ブロック再生」や「セレクタによるトラック遷移」、「シームレス連結再生」など便利な機能が最初から用意されています。
ゲームエンジンのオーディオはいらない？
いいえ。ゲームエンジン上ではさまざまな試行錯誤ができますが、そのゲームとの連結部分などは無駄にはなりません。
ゲームエンジンではすぐに誰でもどこまでも触れるというとても大きなメリットがあります。
音楽をゲームの状況に応じて変更したり、
足音を状況によって鳴らし分けたり、
モーションからの揺れボーンによるフォーリー音の再生トリガーなど、
さまざまなミドルウェアだけでは解決できない部分を補うことができます。
もちろん、ミドルウェアと組み合わせるとよりパワーアップします。
ゲームよりな演出、音楽よりな演出
ゲームならではのお決まりの演出、音楽側の調整はミドルウェアで、
それを超えるゲーム固有の演出、ゲーム側での調整はゲームエンジン上で行うのが良いでしょう。
