ミドルウェアを使うと色んな事ができますが、はじめに最大のメリットを声を大にして言いたい。
サウンド担当者が音の調整をできる!!
お前は一体なにを言っているんだ、とお思いの方もいらっしゃるかと思いますが
割と多くの開発現場では最終的な音の調整をエンジニアがやっているのではないかと思います。
音を鳴らすタイミングや音量、フェードイン、アウトや発音数の制限、ボイスを鳴らす時だけBGMの音量を下げる、などといった細かい調整を、あなたの現場では誰が担当していますか？
サウンド制作は外注だったりして、納品した後の使い方まで面倒を見る事が無い（できない）
その結果、制作者の意図していない演出ができあがったりします。
自分はサウンド制作の現場に居る事が多かったため、何度となくもどかしい思いをしてきましたが
ADX2などのミドルウェアを使う事で、サウンド担当者が音の調整をできるようになるんです！
エンジニアはゲーム作りに集中できる!!
想像してみてください。
-
ミドルウェアを使わない場合
開発も終盤に差し掛かり、クリティカルなバグが見つかってしまいました。今すぐにでも修正しないとリリースに間に合わない！ そんな時、サウンド担当者がやってきて一言
『ここの演出、BGMは３秒掛けてフェードアウト掛けてくださいって言ったじゃないですか！』
「あぁ、それね。やれば５分でできるよ、５分で。でも忙しいから待ってて」
『そう言って２週間経ちますよ！ いつになったらやってもらえるんですか！』
「仕方ないなぁ…今やりますよ。はいできた」
『やればできるじゃないですか！ どれどれ…あ、すんませんやっぱり２秒にしてください』
「また２週間後ね」
その後、修正される事はなく正式リリースへ。 -
ミドルウェアを使う場合
開発も終盤に差し掛かり、クリティカルなバグが見つかってしまいましたが
サウンド担当者は黙々と自分の作業を続け、エンジニアも自分の作業に集中できた結果、バグを撲滅。
また、サウンド演出の分業ができた事でお互いの余計な待ち時間が発生せず、当社比３倍の時間を調整に割く事ができ、豊かなサウンド演出のゲームが出来上がりましたとさ。めでたしめでたし。
イメージできたでしょうか？
実際の現場はこんなに単純ではなく、様々な問題が出てきたりしますが
担当エンジニアは基本的に音の再生リクエストだけをコーディングすればOKです。
（他の音を止める再生リクエスト、とかもデータ側で作れるので再生だけ考えればOK）
音量調整とか圧縮後の音質確認とか、フェードインアウト管理とか、ボイスの管理とか、全部サウンド担当（とミドルウェア）に任せましょう。お互いハッピーになれます。
ADX2でできる事
- Unity、cocos-2dx、ネイティブ環境などで使える
- エンジニアとサウンド担当の仕事が明確に切り分けられる (ワークフロー改善)
- 低負荷（iPhone4sで同時に16音くらい鳴らしてもCPU負荷10%程度）
- 高音質、高圧縮率（例:44.1kHz 16bit 2chのデータの場合、約1/15に）
- Android端末の遅延推測（端末固有の発音遅延を吸収する。音ゲー向け）
- Android端末 低遅延再生（音ゲーのタップ音など、素早い発音が必要な音向け）
- 専用オーサリングツール（１つの組み込みツールで全プラットフォームに対応）
- インゲームプレビュー（実際の端末で鳴らしつつ、リアルタイムに音量調整ができる）
- 各種インタラクティブサウンド
- ランダム再生（足音や攻撃音に効果的）
- 同時発音数制限（大量にコールされやすい攻撃音、アイテム取得音などに効果的）
- ブロック再生（状況に合わせた音や楽曲の遷移が可能）
- ダッキング（ボイスなど聞かせたい音を鳴らす際にBGMの音量を下げたりする機能）
- AISAC（各種パラメーターと連動し変化するシステム）
- コンボシーケンシャル（連続ジャンプ音や攻撃音などを変化させるシステム）
- ゼロレイテンシーストリーミング再生（ストレージからのストリーミング再生）
- などなど
各種機能の詳細は後日、まとめていきます。