2019年、あけましておめでとうございます。
コミケに行っていた方はお疲れ様です。
目標としていた2018年内のリリースとはなりませんでしたが、引き続き新Verの開発を行っておりますので、本年もどうぞよろしくお願いいたします。
前回までは筐体の話ばかりしてましたので、少しばかり開発で試行錯誤した話を。
ゲーマーならご存じの方も多いと思いますが、ゲームにおいての時間管理は一般に「フレーム」単位で行われます。最もよくこの単語が聞かれるのは格ゲーでしょうか。
フレームとは、画面の更新されてから次の更新までの時間で、この間に毎回<入力取得>→<判定>→<画面描画>の一連の処理を行っています。
この処理は、一般にディスプレイ更新に合わせて毎秒60回行われます。この状態がFPS値が60、または単に60FPSと言います。
因みにアニメーションは一般に24FPS。人間の目にとって、動いているように見える最低限のFPS値らしいです。
ゲームにおいてもFPS値が変わることがあります。主に、処理に時間がかかり更新間隔が伸びてFPS値が落ちること。10FPSともなれば秒間10回しか描画しないので画面の動きがカクカクに見えます。いわゆる処理落ちというやつです。
この10FPSの状態では60FPSに比べて処理回数は1/6になりますので、本来の1/6の速さでゲームが動作していることになります。
動きがゆっくりカクカクになり、ゲームによっては、シビアなタイミングを目押しで狙いやすくなるかもしれません。
ただし、音ゲーではそうもいきませんね。
音ゲーも基本的に60FPSで動作します。
ですが、処理落ちして10FPSになってしまったとき、ノーツの動きをゆっくりにすることはできません。曲は流れ続けるので、それに合わせなくてはいけないからです。
音ゲーはフレーム単位で動作しつつ、現実時間にリンクして表示や処理をしなければいけないわけです。
さて、これを実装するにはどうするかというと、動きをフレーム単位で決めるわけではなく、曲の再生状況(再生位置)に合わせてすべての処理を行います。
これにより、処理落ちしても曲とのズレを無くすことができます。
実は現在公開しているバージョン(~v0.2.3)では、曲の再生とは別にストップウォッチを作動させ、ストップウォッチを元に譜面を再生していました。
曲の再生と同期させるようにはしていたのですが、再生位置を変えると譜面と曲がズレやすくなっていたのはこのためです。
現在開発中のバージョンでは改善される……はず。
ただ、処理落ち自体を回避できるわけではないので、処理の軽量化をすすめないといけないですね。軽量化ってどうすればいいんだろう
余談ですが、先日、5年ほど前に作ったゲームを発掘しまして久々に遊んだところ、何故がFPSが本来の倍になっており、超高速の操作を強いられました。
もちろんマモトにプレーできず、スコアはぼろぼろ。。。
なぜこんなことになったのか……、もう実装を覚えてません。
(というかゲームライブラリ側で自動的に調整するはずなのですが……?)
ではまた次回。
何を書くかはまだ未定です。