はじめに
ゲームサウンド開発において、あまり語られないであろう部分、作ったサウンドを管理する部分について実例を含めて解説します。
ゲームサウンドでは
- 誰が実行時のデータ管理をするのか？
- ゲーム用のデータをいつロードするのか？
- いつ破棄するのか？
という問題があります。
サウンドデザイナーが行うのか？それともプログラマが行うのか？
永遠の課題として残っています。
プロジェクトを進めるうえで、最初に確認しておくべき点であるかと思われますが、
内容はサウンド制作からは遠い話でもあります。
実際のプロジェクトでサウンドデータ管理をいくつか経験しないと語れない面でもあります。
データ管理はなるべくしたくない
データの構成は開発中はたびたび変化します。
アドベンチャーゲームであっても、回想シーンでまた使いたいとか、想定のデータをまたいで開発が進むことも多々あります。そのたびに構成を再構築したり、別バージョンを作るのはスピード感が足りない。
また、別の視点で、
昨今のゲーム、たとえば運営タイトルの場合は、継ぎ足されていったり、DLCの配信単位で扱いたいなどもあります。
ゲームで実際にどのように使われるデータなのか、サウンド制作時に把握するコストが大きい。
→専任の管理者が必要になる場合が多いです。
一方、ゲームジャムや小規模開発では、そもそも、管理しなくても技術で解決できるのでは？
という面もあります。
開発規模や、ゲームのジャンルによっても変化があるかと思います。
以下の３つの方法を試しました
- 【大規模アドベンチャーゲーム向け】サウンドデザイナー側：単純管理、プログラマ負担ゼロにする方法
- 【高速アクション対戦ゲーム向け】プログラマが全部管理する（デザイナ管理０）方法
- 【小規模探索ゲーム向け】再度サウンドデザイナー側：単純管理、プログラマ負担ゼロにする方法
【大規模アドベンチャーゲーム向け】 サウンドデザイナー側：単純管理、プログラマ負担ゼロにする方法
サウンドミドルウェアのADX2の機能を利用して、すべてのデータをゼロレイテンシーストリーム再生することで解決しています。
ストリーム再生の形式であれば、再生時にメディアから直接読み込みつつ再生するので、最小限のメモリ消費で済む想定。
多少実行時負荷・応答性が犠牲になるが、アドベンチャーゲームであればOKと判断。
メリット
- ゲーム開発中、事前ロードを気にせず、どこからでも気軽に再生リクエストができる
- サウンドデータのロード管理がいらない（オーサリングツール上で一元管理）
- データ管理しなくてすむ（サウンドマネージャ初期化時に全データロード）
- 長尺なBGM、多くの多言語ボイスなどでも実行時メモリが少なくてすむ
デメリット
- ストリーム再生のため若干の負荷・遅延
想定外に困ったこと
- データを差し替える時にほぼすべてのデータの更新になる
- パッキングされたデータが大きくなり、一部の更新時のgit差分が増えがちになる（更新が気楽に行えない→まとまった単位での更新になりがち→イテレーションが早く回せない）
- 分割apk、obb時に特殊なビルド処理が必要になった
- ミドルウェアのストリーム再生対応機能とデバイスの保存管理の相性が悪く、Androidでのビルド形式の依存で、複数のビルド対応が迫られた
この方法を採用したゲーム
アルトデウス （VRアドベンチャーゲーム）
サウンドデータ構成
- インタラクティブBGM 66
- 日英ボイス 10646
- 効果音・環境音 1318
- トータルサイズ 320MB
BGMとSEとVOICEという
非常にシンプルな構成
おおむね問題なくサウンド制作が行えました。
デモ版作成のためにサイズ削減版を作成した経緯があり、プロジェクトは多少煩雑になっていますが、ほぼ理想形。
このタイトルで初めてDLC対応のヤマト編も発生したが、サウンドに関しては新たな要素は作らず、ゲーム本体にデータを持つ形で行われた。
ディスクロニア（VRアドベンチャーゲーム）
サウンドデータ構成
- インタラクティブBGM 60
- 日英ボイス 12583
- 効果音・環境音 1410
- トータルサイズ 1GB
アルトデウスとほぼ同じで
BGMとSEとVOICEという構成と
Systemという音を鳴らさない全体コントロール用を分離を試していたが、
管理が煩雑になったため最終的にはSEに機能吸収した。
アルトデウスと比較して、３章構成であったのと、開発期間が異なるためワークユニットごと分けているため、
データが複雑になっていますが、なるべくわかりやすく管理。
初回リリースと、章データのDLC単位でのデータ分割となった。
過去の章のデータを参照する場合も発生したため、章ごとのデータ区分で、追加型でロードされていきます。
実行時のデータとしては起動時にロードを試みて、見つからなければ音が鳴らないという想定。
サウンドデータの章ごとのロード自体を考えから外すことを検討しました。
ありそうな想定のデータはすべてロードを試みる。
もともとボイスなどシナリオのどこで使われるか、有機的に変更が行われるため
あらかじめパッキングできる状況ではなかった。
開発中でもどこからでもよべることが利点という形での実装に至った。
一方で、メモリの最適化などは不能な状態。
初回ロード時間などにも影響を及ぼしている可能性はある。
【高速アクション対戦ゲーム向け】 プログラマが全部管理する（デザイナ管理０）方法
アクションゲームで、最適化が必要なタイトルで、メモリ再生のみにした。
（もはやストリーム再生ですら負荷を懸念するレベルだった）
メモリにロードされるため、
データは、音ごとに個別で管理するような仕組みを採用した。
（１キュー・１キューシート）
ゲーム側では、必要なデータをシーン切り替え時などに事前に読みこみ、不要なデータは一括破棄するような作りにした。
独自の形式で、manifestファイルを定義して、サーバーでの整合性情報なども管理する形で生成している。
複数のキューをまとめての想定もあったが、管理が煩雑になるため断念。
メリット
- プログラム側で管理するため、柔軟なデータ管理が可能となった
- 後からキャラやシーン、DLCアセットが増えたら、その都度必要なデータをロードする形に
- 初期ロード負荷が減る
- サウンドデザイナー側でデータ管理をしなくて済むことになった
デメリット
- プログラマ側の管理負担が増えた（サウンドデータを意識して管理する人が必要となった）
- シーン読み込み時の負荷が増えた（大量にデータを読み込むため、シーン読み込み処理削減が難しい）
- 処理負荷軽減のためストリーム再生をしないためメモリの多く利用するBGMやボイスがロードの負荷に直結
- 読み込み忘れたりすると音が出ないなどの問題がおこる
- プログラム側である程度自動的に必要な情報が得られる仕組みなどで工夫して対応（GSSやcsv、エディター拡張など） バンドル化など必要な処理は、サウンド以外の他のデータでもあるので、サウンドデータも便乗する形。
シーンロードの負荷が目立つため、SEはロードしたまま解放しない形で運用するようにしていたが、ロードチェックの単位が音ごとのため音数に応じて負荷が軽減できない状況は改善できず。
もう少しメモリに余裕があれば、全部読み込んでも良いところ。
（だが、メモリはあれば消費されてしまう運命でもある）
この方法を採用したゲーム
ブレイゼンブレイズ
サウンドデータ構成
- BGM 23
- ボイス日英 4700
- 効果音・環境音多数 483
- トータルサイズ 635MB
【小規模探索ゲーム向け】 もう一度 サウンドデザイナー側：単純管理、プログラマ負担ゼロにする方法
ロードは起動時にすべて行う形で、ストリーム再生は使わず、すべてメモリ再生にすることで
obbや分割adbでの対応をせず極力シンプルにあつかえる方法にした。
※このタイトルはもともとUnity Audioベースで作られていた経緯もある
この方法を採用したゲーム
ゴーストフォトグラファー（VR マルチ 探索ゲーム）
サウンドデータ構成
- BGM 7
- ボイス 0
- 効果音・環境音 124
- トータルサイズ 30MB
効果音のバリエーションが多く、インタラクティブなサウンドであるためADX2を利用。
ただ、ADX2のストリームはビルド後のデータ管理が煩雑になる経験があったため（本当は使いたいところだったが）使用せず。
メモリ再生のため遅延が少ないが、長尺のデータはメモリを圧迫するため、短いデータの組み合わせや高圧縮などサウンドデータで工夫を行った。
小さめのタイトルであればこれくらいの規模で許された。（と思っている）
メリット
- データ管理・管理者を用意せずともサウンドデータ作成に集中できた
デメリット
- あまり巨大なデータは作らないように気を使う必要があった
実際に困ったこと
- メモリを圧迫するため、実際にはゲームにも影響しているため最高圧縮設定
- ゲームの処理が重くても、サウンドではもうできることは無い
終わりに
ミドルウェアのゼロレイテンシー再生はデータ管理を無しにしてくれる希望がある一方、
スペックの厳しいスタンドアローンVRではゲームジャンルによっては無理がある面が分かった。
また、ストリーム再生というやや特殊なハード制御を行う都合、Android端末においてはデータの置き場所やパッキング・場合によっては展開が必要など様々な制約もうけることになり、環境自体の進化待ちという形で、万能な解決策には至らなかった。
データをプログラムに管理してもらう場合は、中間データも細かく分かれている必要があり、
オーサリングツールでのパッキングが逆に仇となってしまった。
（管理者からすると特殊な扱いのデータになってしまう）
この方向での進化としては、データのロードもイベント（キューレベルで）行うなどの可能性もあるのですが、データの分割自体もゲームごとに様々になるので、データ管理については、なかなか難しく感じている。
- 誰が実行時のデータ管理をするのか？
が課題として残っている。
プログラマにお願いするのが一つの答えかもというのが現状の落としどころ。