プログラマ専用SNS ミクプラ

おかげさまで現在ゲームを作っております。問題発生です。

ゲーム制作の上で必ず問題になるのが「FPS」ですが、ちょっと懸念すべきことが。
Dixqさんのサイトや他の大量のサイトでもFPSに関する解説はたくさんあり、それで
解決できているつもりでいました。
しかし、ちょっと考えてみました。このようなサンプルでは、FPSを制御するために
待機時間を計算し、Sleep関数などで待機させています。
ということは、例えば60FPSで動作させたいときに、ユーザーが70FPSで操作しようとすると
上手く60FPSに抑えられると思うのです。つまり、60FPSユーザーよりも
早く画面処理が進んでしまう事態を抑えられているわけです。
しかし、例えばユーザーが故意に30FPSで動作させようとしたときはどうなるのでしょう？
さまざまなサンプルでは抑える処理はしていますが早める処理はしていません。
つまり、60FPSユーザーよりもゲーム進行速度が半分になってしまうのでは？と考えました。
LAN対戦など厳密な時間が要求されるゲームで、相手が自分よりゆっくり操作して
いわゆる「チート」を行われては不公平甚だしいです。
これを抑制するためには、30FPSユーザーには画面更新は半分に、つまり
ところどころフレーム落ちが発生してしまうが、1秒間に移動する距離は同じ、ということに
せざるを得ないと思うのです。

しかし、このような説明をされているサイトなどにいまだ出会えておりません。
そもそも、このような事態は本当に起こりうるのでしょうか？

乱文失礼しました。ご存知の方いらっしゃいましたらご教示ください。

そういう場合は、１フレームの経過時間で移動速度を可変します。
前からの経過時間が15msなのか30msなのかで移動速度が変わるわけです。
過去ログにも話は出てきていたはず。

ちなみに処理落ちさせてスローなまま放置していものと経過時間で強引に補正しているゲームの２種類があります。
どちらが良いかはゲームによります。

ウチのブログで公開しているFPS制御のフレームワークは、更新関数の引数でコマ落ちしたフレーム数を取得できるようになってます。

PCのタイマー自体をいじられたらどうしようもありませんが。

フレームという単位で計測すると端末によって速度差がでるので最近のゲームフレームワークはデルタタイム・デルタフレームというのをサポートしています。
デルタ時間はフレームとフレームの差分ミリ秒で表すので秒計算すればFPSが１０だろうと３０だろうと６０だろうと同じ時間にあるべき位置に物体を移動させることができます。

http://unity-yb.github.io/articles/fram ... pdate.html
http://www40.atwiki.jp/spellbound/pages/1331.html
どちらもUnityというゲームエンジンでの話になっていますが、結構興味深い内容です。

スマートフォンアプリ開発だと端末によって処理速度が違うので
フレーム計算だと「～という端末ではこの演出が早すぎる」とか「～という端末だとこの演出が遅すぎる」とかデバッグシートに散々書かれるので
フレーム計算ではなく、差分ミリ秒で計算しないとエライ目に会います
（私は酷い目に会いました）

実時間で処理すると、ハードウェア的な外部の遅延の影響で演出がすっ飛んだりすることがあったりします。

景品の抽選なんかのときにそういったことが起きると損害賠償にまで発展する場合があるので、フレームで処理するか実時間で処理するかはケースバイケースだと思います。

実時間で処理するのは一過性の演出に限ると個人的には思っています。

#後から担当したプログラマがフレーム数をチェックする対策コードを外してしまってたいへんなことになったことが実際にありました。

例えば60FPSのゲームで30FPSしか出ないとき、60FPS基準の更新関数を2回ずつ呼び出すというのはマイナーな手法なんですかね。
フレームワークの根っこで経過時間(デルタ時間)をフレーム数に変換する手法はガラケーアプリよりもはるかずっとむかしから使っているのですが。

各オブジェクトを倍の距離ずつ動かしても辻褄が合うように作るのはたいへんだと思うのですけど海外のゲームはそちらが主流だという話も耳にします。