チームでADX2を使う上で気をつけたいこと

こんにちは。ADX2ユーザーの川口です。

普段業務でADX2を使う身として、個人制作では起こりにくいのですが、チーム内で共有しておかないと陥りやすいトラブルがあります。

サウンド再生やデータ管理を行うプログラマーと、サウンドデータ制作者の間で擦り合わせておいた方が良いものを挙げてみます。

環境整備の面

SDKとオーサリングツールのバージョン不一致

プログラマーとサウンドデータ制作者それぞれが気をつけないといけません。
最新版がリリースされているからと、お互いに確認を取らないまま更新してしまうと、音が鳴らない、鳴っても想定通りの動きをしない場合がある、といったトラブルに陥りやすいです。

基本的にはSDKのリリースノートにある一覧のバージョンを合わせましょう。

基本的に、と書いたのは、SDKリリース後に個別のツール（特にAtomCraft）のバージョンが上がる事があります。
AtomCraftのバージョンの第3セグメント（上記画像でVer.3.43.08の08の部分）の更新は主にツール挙動に関するバグフィックスで、書き出されるデータには変更が無く、問題なく再生できます。

逆に第2セグメント以上の更新がある場合は、AtomCraftプロジェクトの内容に変更点が無くても書き出されるデータに差異がある場合がありますので、合わせる事を強く推奨いたします。

 

開発初期にすり合わせておきたい事

ADX2の初期化のタイミング

近年、バーティカルスライスという手法が用いられたりする中で、様々なシーンを個別に作り込む機会も増えています。そこで問題になりがちなのがADX2の初期化のタイミングです。それぞれのシーンを個別に確認するために複数の箇所で初期化処理を入れる事も多いと思います。

以下の例はUnityでの話になりますが、他の環境でもご参考にしていただければ。

シーンごとに作り込むとなると各シーンで ADX2の初期化が必要ですが、そうするとゲーム全体として動かした場合、シーン切り替え時に意図せず ADX2の終了→再初期化が起こる可能性があります。(この場合は音途切れなどが発生しうる)

各シーンに配置する初期化コンポーネントを DontDestroyOnLoad で破棄されないように設定し、シーン開始時＝そのシーンに配置された初期化コンポーネントの開始時に「すでに別シーンによって初期化済みなら自害する」ように実装することで、問題を回避できます。

Unity プラグインの初期化コンポーネント CriWareInitialzier であれば、上記の初期化済みチェックは実装済みなので、サンプルのようにDontDestroyOnLoad を有効にするだけで OK。

Prefab などを利用してすべてのシーンが同じ初期化設定を共有するのもおすすめです。

 

ゲーム内で扱う音源（AtomPlayer）の数や役割

ゲームによっては1つで充分な場合もありますが、3D空間上でキャラクター別に音の表現を行うのであれば最低でもその数は必要になります。

この数を設定するのは先ほど出てきたADX2の初期化のタイミングになります。
多めにしておけば再生命令が大量にリクエストされた際に音が鳴らないリスクを減らす事ができますが、適切な数を見極めるにはまずサウンド担当者側で演出に必要な数や役割(※)を見積もって提示し、担当プログラマーが対象のプラットフォームや端末のスペックも考慮した上で判断するのが大事かと思います。

※ 役割と書いたのは、BGMやUIなどと、3D空間用、メモリ上に波形データを全て載せるもの、ストレージからストリーミング再生するものなどの分類を指しています。

 

作ったサウンドデータのプレビュー手段について

AtomCraft、AtomViewerでプレビューする

サウンドデータを直接編集しないメンバーには、CriAtomViewerを使って音の確認をしてもらうと手軽で良いかと思います。

 

Unity Editor上でプレビューする

Editor上でもCriAtomSource にキューシート及びキュー名を指定してのプレビュー再生が可能です。

 

AtomCraft上でのプレビュー再生が難しいケース

他のキューシートに依存するデータを作成する場合、キュー単体でのプレビューが上手くいかない場合があります。
また複数の音源を別の場所に置いて同時に再生し、聞こえ方を確認したいという場合も複雑です。

セッションウィンドウを用いて行える場合も多くありますが、複数のAISACを変化させながら…といった挙動の確認は難しいため、実際にゲームを動かしながらプレビューできる仕組みをプログラマーに用意していただくか、インゲームプレビューという機能をご利用くださいませ。

 

ゲーム上での確認が難しいケース

関連するキューシートが正しく読み込まれていないと想定通りの音が鳴らないため、どの場面でどのキューシートのデータを読み込む必要があるかを共有する必要があります。

 

ゲームエンジンによる距離の扱いの違いについて

単位が違う

AtomCraftで指定する距離の値は1m単位です。
Unityの距離単位は1mなのでそのままデータを使えます。
UE4の距離単位は1cmなのでそのままでは数値の扱いがずれてしまいます。

UE4の場合は、エンジン側でCRIWARE UE4 Plugin の Distance Factor 設定に0.01 を設定することで、意図通りの距離計算ができます。

距離感の表現を行う際に全く違った音になるため、ご注意くださいませ。

 

事前になるべく検証しておいた方が良い機能

インゲームプレビューが滞りなく行えるかどうか

実際に動いているゲームのメモリ空間にアクセスし、ゲームを動かしたまま各種サウンドデータを調整ができたり、発音や停止の状態がタイムラインに描画されていくプロファイラーという強力なツールが使えるインゲームプレビューという機能があります。

AtomCraftを動かしているPCと、同一PC上で動いているアプリケーション（ゲームエンジン上での実行中や、ビルド後の実行ファイルでも可能です）や、同一ネットワーク上にある各種コンシューマー機、モバイル端末と相互アクセスする形で行います。

この機能を利用するためにはAtomCraft側でインゲーム用データをビルドするだけでなく、エンジン側でもインゲームプレビューを使うという設定を入れて貰う必要があります。詳しくは各プラグインのマニュアルを参照してください。

インゲームプレビューの接続中、ゲーム側のメモリ上にあるADX2のファイルが何らかの形で書き換えられてしまったり、再初期化によりacfが読み込み直されたりするとデータの不整合が起こり、接続が切れてしまいます。

この機能が使えることでサウンドデータを作り込む際の効率が飛躍的に向上するので、ぜひ予め検証しておく事を推奨いたします。

 

データ更新時に渡すべきファイルについて

基本的にはAtomCraftでビルド時に生成される、拡張子が acf、acb、awbの三種類のファイルを渡し、ゲームに組み込んでもらう事になります。

以下の画像ではキューシートが1つなのでそれぞれ1つずつですが、各プロジェクトでacfは1つだけ。
キューシートの数だけacbが存在し、そのうちストリーミング再生を行うものの数だけ、awbが存在します。

一つ前の項で挙げたインゲームプレビューを行うには、ビルド時にインゲームプレビュー用のバイナリ出力にチェックを入れてデータをビルドします。

通常ビルド時の出力先フォルダの下にできる、IngamePreview以下のデータを渡します。

 

その他

他にも

• バックグラウンドへ移行時、復帰時の挙動
• オプション設定などでボリューム調整を行う場合の挙動（カテゴリ、デフォルト値、最大時のラウドネス値など）
• リリース後のアップデート時の追加データの設計やバージョン管理

といった事前に擦り合わせておいた方が良い事はありますが、ターゲット次第で気をつけるところも違うため、また別の機会にご紹介します。

以上、ご参考になりましたら幸いです。