はじめに
本文書は、Unityでサウンドまわりを実装する際に各種(ADX2, Wwise, FMOD)を採用するさいに検討したい事と、実装する際に懸念すべき事についての私見です。定性的な部分が多いので定量的な情報をお持ちであればご指摘いただけると幸いです。というか情報がもっとほしい。
結論
はじめに結論をのべておくと、「ほとんどの場合Unityならサウンドエンジンいらない」そして「ある程度したい演出があって楽にやりたいならADX2」「WWiseはつかうならちゃんと使いこなさないと損」「FMODは使うと楽しいけど情報はすくない」「どれを使うにしても発音数をなにも考えずに増やしてはだめ」となります。ある程度使ったことのある人には何をいまさら?というのことをこれから長々と書きます。
環境
- MacBook Air (11-inch, Early 2015) OSX 10.12.6
- Unity 2017.3.f3
- ADX2 Unity Plugin/AssetStore 2.24.00
- Wwise 2017.2.0.6500
- FMOD 1.10.02
各エンジンの特徴
世の中にはUnity公式ノンリニアオーディオデモというすごくかっこいいデモがあります。ただ、これの実装はそこそこ大変です。さらにUnity上でオーサリングして調整するとなるとかなり大変そうです。これを各サウンドエンジンで実装することで各エンジンの特徴を再確認しました。
※ページビュー乞食
- ADX2でオーサリング
- ADX2で組み込み
- Wwiseでオーサリング1
- Wwiseでオーサリング2
- Wwiseで組み込み
- FMODでオーサリング
- FMODで組み込み
ざっくり表にすると
項目 | オーサリング負荷 | 組み込み負荷 |
---|---|---|
Unity | X | X |
ADX2 | ◯ | ◯ |
Wwise | △ | ◯ |
FMOD | ◎ | ○ |
※便宜上、Unityでもの状態を一番つらい、にしてます。
という感じでした。正直Wwiseのオーサリング負荷はXにしてもいいくらいにつらいものでした。大規模になってくると段々つらさが均されていくのですが、このデモ程度の規模だとちょっとのことのためにメンドくさい部分を直に触ることになるためです。また、オーサリング負荷がADX<FMODなのはUXがわかりやすくてなんとなーくやっても上手くいくからです。実装負荷は正直どれもおなじくらいです。用意されてるコンポーネントもどれも一緒な感じですし。
2020/10/12:お値段の話
聞きかじったお値段の話を書いておきます。
インディーだとだいたいどれもタダです。
商用の方は予算3億、売上5億くらいで考えてみます。
(夢があるような内容な絶妙なライン..モバイル売切だと夢ありすぎて非現実的..)
項目 | インディー環境 | 商用価格 |
---|---|---|
Unity | - | (追加費用なし) |
ADX2でSteam | LEなら0,AssetStore版なら$100 | 5億円*0.7(Steam税引)/1.1(税引)*0.0095(ADX料)≒300万円≒$28,000 |
ADX2でiOS/Android売切 | LEなら0,AssetStore版なら$100 | 75万円、あるいは売上*ストア税*0.04の大きい方 例)5億*0.7(ストア税)/1.1(消費税別)*0.04=1272万≒ $121,000 |
ADX2でiOS/Android アイテム課金 | LEなら0,AssetStore版なら$100 | 販売価格-ストア手数料の0.95% x 販売本数、上限25円/本。基本無料・アイテム課金ゲームは月0~80万円の売上連動型 |
ADX2でF2P | LEなら0,AssetStore版なら$100 | 販売価格-ストア手数料の0.95% x 販売本数、上限25円/本。基本無料・アイテム課金ゲームは月0~80万円の売上連動型 |
Wwise | $150K規模まで0 | $900(+ロイヤリティ)~ 21,000(ロイヤリティなし) |
FMOD | $500k規模まで0 | $5,000~15,000 |
ちなみにお値段は公式サイトからの引用です。
以下にもうすこし詳しい内容を書いておきます。
素Unity
長所
- 中身はFMOD
- AudioSource, AudioClipなどのわかりやすいAPI
- Unity標準装備のプロファイラで最適化できる
- AssetBundleとも親和性高い
- 音数がふえたら優先度順に消す、くらいはやってくれる
短所
- 細かな発音制御しようとするとスクリプト書く必要がある
- Wavをバージョン管理に含むとプロジェクトが肥大化するのでサブモジュールにしたり、AssetBundle化したりと苦労が多い
ADX2
長所
- だいたいなんでもできる
- 日本のゲーム業界のシェアが高い
- 独自コーデックの圧縮率高い
- Androidの低遅延再生に優れる(標準40msecに対して15msecくらい)
- プロファイラーもつかいやすい
- パッキングシステムも用意されてる
短所
- 商用でもUnity用に添付されてるサンプルなどは乏しい
- パッキング用のサンプルはとくに乏しい
- StreamingAssets前提
- 機能制限版ではMac用エディタがない=>2021年現在、追加されたそうです。
Wwise
長所
- 大体なんでもできる
- 世界標準なので漁るといろんなプラグインとかある
- GDCとかで最先端情報を探るとWwiseが前提
- VR用ソリューションへの対応も早かった
- 使用者の目的にあわせたレイアウトプリセットが多い
- 公式チュートリアルがめちゃくちゃ詳しい
短所
- 日本語情報が少ない
- 使用目的ごとにレイアウトプリセットを切替えてもなお溢れ出るオーサリングツールの情報量
- ほかドライバにくらべて常駐メモリ量がやや多い
FMOD
長所
- オーサリングツールのUXわかりやすい
- 世界的にはそこそこ採用されてる
- 発音制御、3Dサウンド、ランダム再生、インタラクティブ...だいたいのことはできる
短所
- マイナー
- 日本語情報はめちゃくちゃ少ない
- 最近までモバイル用がなかったりとやっぱり足が遅い
補足
作業負荷だけでなくエンジニア的にはマシンリソース負荷もきになるところなのでその辺補足しておきます。本当の最適化は各エンジン添付のプロファイラーでおこなうべきですが、公平になるようにUnityプロファイラーから見えるところで比較します。
なお比較は各サウンドエンジンの組み込みで作成したもので、コーデック:ADX2=独自コーデック、FMOD&Wwise=ogg、再生方式いずれもStreamで作成してあります。
ざっくりプロファイラーでみると
Audioプロファイラーでみるとこうなります。
全部いっしょ。しってた。
それぞれ独自のPluginで走ってるので当然UnityProfilerからは確認できません。
CPU
もちろんこの程度のデモでは1%たりともCPUをつかわないので比較はあまり意味がありません。
※正直オーディオバッファのfillって1frameないに3frame分つめるくらいで動作しないとプチプチいう世界なので、まともなサウンドエンジンを普通に動かしてるかぎりあんまり負荷ってあがらないんですよね。
ADX2
基本はCriAtom.Initializer、Cri.Listener、Cri.Updateがはしる。追加で音源数が増えるとSourceの処理がはいります。
Wwise
おなじように音源数によって処理が増えます。
FMOD
どれ?
基本的にはどれも音源数によって増える。ということは実は数百〜数千規模になるならあらかじめ刈り取ってあげたほうがいいという中身であろうと思われる。当たり前。
メモリ
概要
ざっくりみるとADX2とFMODが10MBに対して、Wwiseが30MB近いように見える。やっぱり若干おおい。
ちなみにWwiseのテクスチャがおおいのは標準プラグイン画面のアイコン
はずすの面倒だったんですごめんなさい。そのへんを差し引いてもWwiseは10MB程度は多めに食うようです。
詳細
ADX
よくみると結構興味深いです。CriExPlayerが結構多めに食っています。CriAtomPlayerEx=CriAtomSouce.player=音源にかかわるので音源をprefabなどに埋め込んでリクエストとして利用するとこのResourceがおおくなり、またそのGCによって処理が低下することが予測されます。可能ならAudioSourceを使い回すような作りにしていたほうが良い事がわかります。当たり前ですね。
Wwise
そりゃプロファイラ上でメモリ負荷が高くなるよ、という状態です。
Windows用とMac用の便利機能やエディタ用のオブジェクトがたくさんいます。このあたりはReleaseビルドなら消えるので先ほどの数字より若干マシになるはずです。
また、音源用オブジェクトサイズは15kB程度とそこまで大きくなく、Callbakなどのマネージャーが大部分をしめています。これがWwiseをいれると大した事やってないのに多くメモリを食われる理由のようです。もう少し大規模なプロジェクトであればこのあたりの割合が下がるため採用してもよい、という判断になります。
FMOD
こんどはまともに見るものがありました。イベントのキャッシュは発音イベントのキャッシュで、一回しかリクエストしていないからか、対して大きくありません。Assetモニタではそのかわり250kBとドカッと確保しています。ADX2が細かく確保している分をひとまとまりで確保している感触です。細かいところがみたい。。
要するにどのエンジンでも、音源を何も考えずにふやすとGCでメモリと処理負荷を食われていきそうなのがわかります。
まとめ
デモの完成度などからも、Unity単体でだって色々なことができることはわかります。しかしその実装・調整負荷を下げるためにはサウンドエンジンを採用するという判断が有効です。
その際にADX2は独自コーデックや低遅延といったニッチなニーズに応えてくれ、プロジェクトの規模によってもスケールしやすいため、とりあえずコレと選んでしまってもよいサウンドエンジンです。
Wwiseを採用する場合はコンポーザーとエンジニアががっつり腰をすえてやらないと、コンポーザーの負荷が高く、またマシンリソース的にももったいない結果になっていしまいます。
FMODはUnity環境において正直まだおすすめしにくい状態ですが、UXのわかりやすさからインタラクティブミュージックのモック作成などにはアリです。
参考
- Unity Audio Overview
- ADX 助け合い所
- CRIWARE Portal
- ADX2 ライセンス料
- Wwise トレーニング
- Wwise ライセンス料
- FMOD Unity Integration
- FMOD ライセンシング
日本のモバイルやインディーでもかっこいいサウンド演出が増えていけばいいですね。