選択肢が多いからこそ
オーディオミドルウェア CRI ADX2には、目的のサウンド演出を手軽に実現するための機能が数多くあります。
同じ目的を達成しようとしても複数の手段が考えられる場合があり、どの手段を用いたら良いのか迷うことがあります。
そういった場合の判断基準として、例えば
- 実装の手軽さ
- 修正の手軽さ
- 演出結果の精度
などがあると思いますが、今回は特に手段の多いループ再生（繰り返し鳴らし続ける音）について、細かい違いと仕様変更があった場合の軌道修正のしやすさ、というものについて書いてみます。
繰り返し鳴らす手段あれこれ
例えば数字やゲージのカウントアップアニメーションや、リールや歯車などが回転するアニメーションのように、短い音を繰り返したくさん鳴らして表現したい演出を例として、ADX2の機能を用いた実装手段を考えてみましょう。
手段1:CueにワンショットのSEを置き、アニメーションに合わせて都度再生する
手段2:Cueに置く波形ファイルにループマーカーを指定する
手段3:Cueに置いた波形ファイルのウェーブフォームリージョンに自動繰り返し設定をする
手段4:Cueにループマーカーを設定し、単音の波形を繰り返し鳴らす
手段5:Cueにブロックを指定し、ブロックの繰り返し回数を無限にする
手段6:Cueにアクショントラックを追加し、自身のCueを繰り返し呼ぶ
手段7:Cueにループマーカーを設定し、ループ内でCueリンクを用いてワンショットのCueを繰り返し呼ぶ
手段1:CueにワンショットのSEを置き、アニメーションに合わせて都度再生する
サウンドデータ側ではワンショットの音だけを用意し、アニメーションに合わせて毎度再生イベントを呼ぶ、ある意味スタンダードな方法です。
サウンドデータ側はいたってシンプル且つ、Cueに設定できる各種ランダマイズ要素を扱う際に結果が分かりやすいというメリットがあります。
分解能に気をつけよう
注意したいのは音の鳴るタイミングの細かさ（以下、分解能と表記します）がゲーム内の単位時間に依存する点です。仮に60fpsで動作するものなら約16.67msec、30fpsなら約33.33msecです。今回、手段2〜7で作ったデータは80msec周期で音が鳴るように作ってありますが、同様の頻度で鳴らす場合に音の間隔が不自然になる場合もあります。
上記の例では音の鳴る間隔が(5f→5f→5f→5f→4f→5f→)…や、(3f→2f→3f→2f→2f→)…と繰り返す形になり、等間隔とは言えません。聞こえ方が気にならない方も多くいらっしゃいますので妥協できるポイントでもあります。
そもそもフレーム単位で管理するパターンアニメーションで作られている場合はこのような問題になりにくいのですが、キーフレームアニメーションの補完であったり、毎フレーム決まった角度の回転をさせる…といった作り方の場合に起きやすいので、プログラマーさんと相談しつつ進めるとよいでしょう。
手段2:Cueに置く波形ファイルにループマーカーを指定する
波形にループマーカーを設定するため、分解能…というか繰り返しタイミングの精度はサンプリング周波数単位です。波形編集ソフトで設定するため、何か修正がある場合は波形編集ソフトに戻らないといけませんが、仮実装としての手っ取り早さはかなりポイント高いです。
手段3:Cueに置いた波形ファイルのウェーブフォームリージョンに自動繰り返し設定をする
手順1と2のハイブリッド的な印象です。手軽さは2に次いで非常に楽です。
ワンショットの波形をタイムライン上に自動で繰り返し並べていくわけですが、間隔の調整が容易です。
分解能はmsec単位です。
手段4:Cueにループマーカーを設定し、単音の波形を繰り返し鳴らす
手順3に近く、出音もほぼ同じです。分解能もmsec単位です。
細かい違いですが、手順3の場合は自動繰り返しのパラメーターとしてランダム要素があるので発音の間隔やニュアンスをわざとバラけさせるような演出のアレンジが可能です。
手順4では何か他のトリガー（アクションイベントやコールバックなど）を追加する事で、発音するたびに何かを行いたい場合に便利です。
手段5:Cueにブロックを指定し、ブロックの繰り返し回数を無限にする
手順4に近いです。仮演出として、今後その演出の前後に何か動きが追加されそうな場合はこの手段で実装するのもアリかもしれませんが…無理に使う必要はないでしょう。
手段6:Cueにアクショントラックを追加し、自身のCueを繰り返し呼ぶ
毎回トリガーされるので再生されるCueの数が手段1と同じです。
細かい理由は不明ですが、波形にループマーカーをつける手段2に次いで、繰り返しタイミングが正確です。
後ほど、比較画像を載せます。
手段7:Cueにループマーカーを設定し、ループ内でCueリンクを用いてワンショットのCueを繰り返し呼ぶ
リンク先のワンショットCue側で色々と遊びを含む演出をしたい時に利用したら良さそうな手段です。
ゲーム内の状況に合わせて音色を変えたい、といった時には有効かと思います。
プロファイラーによる比較
手段2から7の再生状況をプロファイラーで見たものを並べました。
結果は地味に違います。
オレンジ色がCueの再生状態、水色がWaveformの再生状態を表します。手段1のワンショットは割愛していますが、手段7で大量に呼び出しています。
CueやWaveformを繰り返し呼ぶ系では発音数の上限に気を使う必要が出て来やすいことと、繰り返す手段によってはあ間隔に若干のバラつきが生まれる、という結果になりました。
手段6の周期の安定っぷりがちょっと意外な結果でした。
手段7で一度case1のCueが抜けているのにWaveformの再生が記録されているのは…プロファイラー側の取り零しでしょうか。
比較を終えてみて
どの実装手段がベスト、というのは状況次第なのですが
仕様が確定するまで
手段1、2、3が手堅いのではないかと思います。
繰り返しタイミング最重視
手段2でしょう
繰り返しタイミング以外がFixしていて、Fix後にサウンドデータの差し替えだけ可能
手段3
QA中とかコード変更させてもらえないけどサウンドデータだけなら致命的なバグは起きにくいから差し替えが許されやすいみたいな状況
繰り返し前後に追加演出あり
手段1か手段5も良さそう
演出によって鳴らすCue（の内容）を変えたい
手段7 (ワンショットで鳴らすのはセレクタCueなど)
総括
ある程度、仕様が固まるまでは手段1〜3で様子を見て、その後の演出の幅を広げていく際に、作り込みたい要素によって4〜7の手段を使い分けていただければ良いのかなと思います。
もちろん手段1〜3のままでも良いかもしれません。
全ては目的次第という事で、実装例や判断基準の紹介でした。
最後までお読みいただき、ありがとうございました。