2 / 4 フレームと楽曲の時間
画面の更新と音声の進行を比べ、楽曲の時間を基準にする理由を確認します。
フレームとデルタ時間
ゲームは通常、ユーザーの入力を調べ、ゲームの状態を更新し、画面を描いて表示する処理を繰り返すことで成立しています。
画面やゲームの状態を更新する一回の区切りがフレームです。
1秒間にフレームを60回更新するのであれば、60 fps（frames per second）での動作となります。
実際の更新間隔は、ゲームにかかっている負荷や動作環境によって変わります。
ここで、毎フレーム3ユニット移動する処理を記述すると、60回更新したときの移動量は180、30回なら90です。
同じ1秒でも、更新回数によって移動量が変わってしまいます。
ゲームの動作速度が実際に動かしてみないとわからない場合、フレームごとの処理だけに頼ると移動量が不安定になり、ゲームが破綻する危険があります。
そこで、アクションゲームでは前のフレームから現在のフレームまでの時間差を計測し、累積することで時間を扱います。
このフレーム間の時間差がデルタ時間です。
例えばキャラクターの移動を扱うなら、移動速度を秒速で決めておけば、フレームごとの移動量はデルタ時間を掛けることで求められます。
今回の移動量 = 毎秒の速さ × デルタ時間UnityのUpdate内では、Time.deltaTimeからゲーム内のデルタ時間を秒で取得できます。
UnityのTime.deltaTime
ですが、Time.deltaTimeにはゲームに設定された時間倍率も反映されるため、現実の経過秒数と常に同じとは限りません。
また、あくまでフレームごとの時間計測であるため、得られる時間は歯抜けのある離散的な値になります。
楽曲の時間
楽曲の時間には、曲全体の長さと、現在どこまで再生したかという位置があります。
この回で使う曲の時刻は、再生開始を0秒とした位置です。
音声データは、波形を細かな間隔で数値にしたサンプルの列です。
音声システムはこの列を順に再生デバイスでアナログ化処理することで実際の音として出力します。
一方、ゲームの画面はフレームごとに更新されます。音声の進行と画面の更新回数は、常に同期できるとは限りません。
音声は画像と比べてリアルタイム性が求められます。
再生が間に合わず音が途切れるような事態を避け安定して音を出力するため、バッファが使われます。
このバッファは小規模であることが普通ですが、それでも音の再生リクエストから実際に音が出力されるまでには多少の遅延が生じます。
音源の読み込みにも準備が必要です。
長い音源では、データをすべてメモリ上に展開するわけにはいかない場合があります。
こうした際は、直近の再生に必要なデータだけを順に読み込むストリーミング再生が用いられます。
音源ファイルを開きセットアップを行う等の処理が必要となるため、音の再生リクエストから実際に音が出力されるまでにはより大きな遅延が生じるのが普通です。
つまり、音源の再生の要求を出した瞬間を、そのまま音が聴こえた瞬間と扱うことはできません。
また、映像的な遅延が発生した際に、音声を遅延させるわけにはいきません。
音を主体的に扱うコンテンツにおいて、音源の時間は支配的です。
リズムゲームなどでは、通常のゲーム制作とは異なり、音源の時間を基準にゲームの進行を制御する必要があります。
これはキャラクターのセリフや楽曲再生のタイミングが厳密に管理されているムービーシーンなどでも同じことが言えます。
- 毎フレームの移動量と、毎秒の速さから求める移動量の違いを説明できる。
- 音源の再生要求と、実際に音が出る時刻を区別できる。