ゲームサイクルまたはElectroCardioGama

ゲームループは、すべてのゲームのパルスです。 それなしではゲームは機能しません。 ただし、残念ながらすべての新しいゲーム開発者にとって、このトピックに十分な注意を払う良い記事はネットワーク上にありません。 しかし、悲しいことはありません。ゲームサイクルの問題に注意を払うユニークな記事を読む機会が得られたからです。 勤務中、私はしばしば小さなモバイルゲームのために多くのコードを扱わなければなりません。 そして、ゲームサイクルの実装はいくつあるのだろうと思うたびに。 あなたも、そのような一見シンプルなものがどのように可能か疑問に思うかもしれません。多くの実装を思いつくことができます。 しかし、できます！ そして記事では、ゲームサイクルの最も一般的なオプションの長所と短所についてお話します。 また、ゲームサイクルを実装するための最善の選択肢についても説明します。

（Kao CardosoFélixに感謝します。この記事はブラジル系ポルトガル語でも利用できます）（ロシア語でもおおよそありがとうございます。）

ゲームサイクル

各ゲームには、ユーザー入力の読み取り、ゲームの状態の更新、AIの処理、音楽や効果音の再生、グラフィックのレンダリングを行う一連の呼び出しが含まれています。 この呼び出しシーケンスは、ゲームループ内で実行されます。 つまり、ティーザーで述べたように、ゲームサイクルはすべてのゲームのパルスです。 記事では、上記のタスクの実装の詳細については説明しませんが、ゲームサイクルの問題のみに集中します。 同じ理由で、タスクのリストを2つの機能（状態の更新とレンダリング）に単純化します。 以下は、ゲームループの最も単純な実装のサンプルコードです。

bool game_is_running = true; while( game_is_running ) { update_game(); display_game(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この実装の問題は、時間を処理しないことです。 ゲームは実行中です。 弱いハードウェアでは、ゲームの実行速度は遅く、強いハードウェアでは高速です。 むかしむかし、コンピューターのパフォーマンスが異なるマシンでほぼ同じであることがわかっていたとき、そのような実装は問題を引き起こしませんでした。 今日、パフォーマンスが異なるプラットフォームが多数ある場合、時間処理が必要になります。 これを行うにはいくつかの方法があります。 それらについては後で説明します。 それまでの間、後で使用するいくつかのポイントを明確にしましょう。



Fps

FPSは「Frames Per Second」（1秒あたりの人員、約Transl。）の略です。 上記のゲームループ実装のコンテキストでは、これは1秒間のdisplay_game（）の呼び出し回数です。



ゲーム速度

ゲーム速度は、1秒間のゲーム状態の更新回数です。 つまり、1秒あたりのupdate_game（）の呼び出し回数。

一定のゲーム速度に応じたFPS

実装

タイミングの問題に対する最も簡単な解決策は、25回/秒の固定周波数で単純に呼び出しを行うことです。 このアプローチを実装するコードは次のとおりです。

 const int FRAMES_PER_SECOND = 25; const int SKIP_TICKS = 1000 / FRAMES_PER_SECOND; DWORD next_game_tick = GetTickCount(); // GetTickCount() returns the current number of milliseconds // that have elapsed since the system was started int sleep_time = 0; bool game_is_running = true; while( game_is_running ) { update_game(); display_game(); next_game_tick += SKIP_TICKS; sleep_time = next_game_tick - GetTickCount(); if( sleep_time >= 0 ) { Sleep( sleep_time ); } else { // Shit, we are running behind! } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは1つの大きなプラスの実装です：シンプル！ update_game（）が1秒間に25回呼び出されることがわかると、残りのコードの記述は蒸しカブより簡単になります。 たとえば、再生機能の実装は簡単なタスクになります。 ゲームでランダム変数が使用されていない場合は、ユーザー入力でログインして後でプレイできます。 テストマシンでは、FRAMES_PER_SECONDの妥協値を見つけることができますが、高速または低速のハードウェアではどうなりますか？ 調べてみましょう。

弱い鉄

アイロンが特定のFPSに耐えることができる場合、問題はありません。 マシンがFPSを特定のレベルに維持できない場合、問題が発生します。 ゲームの実行速度が遅くなります。 最悪の場合、ゲームはいくつかの間隔より遅れますが、他の場合は正常に動作します。 時間はさまざまな速度で流れ、最終的にはゲームをプレイできなくなります。

生産的な鉄

強力なハードウェアでは問題はありませんが、コンピューターはアイドル状態になり、「貴重な」（明らかに皮肉ですか？-およそTransl。）プロセッサー時間を浪費します。 25..30 FPSからゲームを開始することを恥ずかしく思います。 プロセッサを最大限に使用したときに表示されるものと比較して、ゲームの魅力が失われます。 一方、モバイルプラットフォームでは、より良い結果が得られる可能性があります。エネルギーを節約できます。

おわりに

FPSを固定ゲーム速度に結びつけることは、コードをシンプルに保つシンプルなソリューションです。 ただし、問題があります。FPSの値を高く設定しすぎると、弱いハードウェアで問題が発生します。 値を低く設定しすぎると、強力な鉄が非効率的に使用されます。

可変FPSゲーム速度

実装

この問題の別の解決策は、ゲームをできるだけ速く実行し、ゲームの速度を現在のFPSに依存させることです。 前のフレームの描画に費やした時間を使用して、ゲームが更新されます。

 DWORD prev_frame_tick; DWORD curr_frame_tick = GetTickCount(); bool game_is_running = true; while( game_is_running ) { prev_frame_tick = curr_frame_tick; curr_frame_tick = GetTickCount(); update_game( curr_frame_tick - prev_frame_tick ); display_game(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コードは複雑です update_game（）で時間差を処理す​​る必要があります。 しかし、コードは少し複雑になりました。 私はこのアプローチを実装した多くの賢い開発者を見ました。 確かに彼らの一人は、このようなサイクルを自分で実装する前にこの投稿を読みたいと思うでしょう。 以下に、このアプローチが弱いハードウェアと強力なハードウェアの両方で深刻な問題を抱えている理由を示します（そうです...強力なハードウェアでも）。

弱い鉄

ハードウェアが弱いと、ゲームが「重くなる」場所で遅延が発生することがあります。 これは、3Dゲームで描画されるポリゴンが多すぎる場合に必ず当てはまります。 その結果、FPSで障害が発生すると、ユーザーの入力処理が遅くなります。 ゲームの更新はFPSの失敗に対応します。その結果、ゲームの状態は顕著な遅れを伴って変化します。 その結果、プレイヤーの反応時間はAIと同じように遅くなり、単純な操作でさえ不可能になる可能性があります。 たとえば、通常のFPSで克服できる障害は、低FPSでは克服されません。 物理を使用する場合、弱いハードウェアでさらに深刻な問題が発生します。 物理シミュレーションは爆発する可能性があります。

強力な鉄

上記のゲームサイクルの実装が高速ハードウェアで正しく動作しない可能性があることに驚くかもしれません。 残念ながらできます。 そして、理由を示す前に、コンピューターでの数学のいくつかのポイントを明確にしましょう。 浮動小数点形式の数値の表現の有限ビット深度を考慮して、一部の値は表現できません。 そのため、値0.1はバイナリ形式で表現できず、double型の変数に格納されると丸められます。 Pythonコンソールを使用してこれを実証します。

>>> 0.1

0.10000000000000001





これ自体は大胆ですが、逐次計算では問題が発生します。 オウムの速度が0.001の車があると仮定します（自由な翻訳、約Transl。）。 10秒後、マシンは10.0オウムの距離を移動します。 この計算をフレームに分割すると、FPSをパラメーターとして次の関数が得られます。

>>> def get_distance( fps ):

... skip_ticks = 1000 / fps

... total_ticks = 0

... distance = 0.0

... speed_per_tick = 0.001

... while total_ticks < 10000:

... distance += speed_per_tick * skip_ticks

... total_ticks += skip_ticks

... return distance







そしてヌカ、40 FPSの移動距離を計算してみましょう。

>>> get_distance( 40 )

10.000000000000075







ちょっと待って！ これは10.0オウムではありません！ どうした すべてがシンプルです... パス計算を400フレームに分割したため、加算中に大きなエラーが蓄積されました。 100 FPSで何が起こるか想像してみてください。

>>> get_distance( 100 )

9.9999999999998312







わあ！ エラーはさらに大きくなりました!!! これは、100 FPSでさらに追加するためです。 その結果、エラーはさらに蓄積されます。 したがって、ゲームの動作は40 FPSと100 FPSで異なります。

>>> get_distance( 40 ) - get_distance( 100 )

2.4336088699783431e-13





この違いは取るに足らないものであり、無視できると思うかもしれません。 ただし、この値を計算に使用すると、問題はより深刻になります（例として、diff。Ur、約Transl。の統合）。 したがって、エラーは非常に大きく蓄積する可能性があるため、ザカカピット（元のトランザクションよりも多少打ち消されます）大きいFPS上の製品。 これはどれくらいありそうですか？ おそらく注目を集めるのに十分です。 このようなゲームサイクルの実装を備えたゲームを見ることができて光栄でした。 そして実際、大きなFPSで問題が発生しました。 開発者は、ゲームコードのコアに「犬が埋もれている」ことに気付いた後、大量のコードをリファクタリングしてバグを修正しました。

おわりに

一見すると、このタイプのゲームサイクルは非常に良いように見えますが、最初は初めてです。 弱い鉄と強力な鉄の両方が問題を引き起こす可能性があります。 さらに、状態更新関数の実装は、最初の実装に比べて複雑になりました。 だからそれの炉にいるのですか？

一定のゲーム速度と最大FPS

実装

最初の実装である「一定のゲーム速度に依存するFPS」には、弱いハードウェアで問題があります。 FPSとゲームステータスの両方の更新の遅れを生成します。 この問題の可能な解決策は、固定の頻度で状態を更新することですが、レンダリングの頻度を減らします。 以下は、このアプローチの実装コードです。

 const int TICKS_PER_SECOND = 50; const int SKIP_TICKS = 1000 / TICKS_PER_SECOND; const int MAX_FRAMESKIP = 10; DWORD next_game_tick = GetTickCount(); int loops; bool game_is_running = true; while( game_is_running ) { loops = 0; while( GetTickCount() > next_game_tick && loops < MAX_FRAMESKIP) { update_game(); next_game_tick += SKIP_TICKS; loops++; } display_game(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ゲームは1秒あたり50回の固定頻度で更新され、レンダリングは可能な限り高い頻度で実行されます。 状態の更新よりもレンダリングが頻繁に実行される場合、隣接するフレームの一部が同じになるため、実際にはゲームの状態を更新する頻度によって最大FPS値が制限されることに注意してください。 弱いハードウェアでは、ステータス更新サイクルがMAX_FRAMESKIPに達するまでFPSは減少します。 実際には、これは、レンダリングFPSが5（= FRAMES_PER_SECOND / MAX_FRAMESKIP）を下回った場合にのみ、ゲームの速度が低下し始めることを意味します。

弱い鉄

弱いハードウェアでは、FPSはドロップアウトしますが、ゲーム自体は通常の速度で高い確率で動作します。 アイロンが最小FPSにも耐えられない場合、状態の更新も遅くなり、レンダリングは滑らかなアニメーションのヒントさえ失います。

強力な鉄

ゲームは問題なく強力なハードウェアで動作しますが、最初の実装と同様に、プロセッサは非効率的に使用されます。 迅速な更新と弱いハードウェアで作業する能力とのバランスを見つけることが重要です。

おわりに

固定のゲーム速度と可能な限り最高のFPSを使用することは、実装が簡単で、コードをシンプルに保つソリューションです。 しかし、まだいくつかの問題があります：状態の更新頻度を高く設定しすぎると、弱いハードウェアで問題が発生します（最初の実装の場合ほど深刻ではありませんが）。アニメーションの滑らかさが増しますが、代わりに頻繁なレンダリングに費やされます）。

可変FPSに依存しない一定のゲーム速度

実装

以前の実装を改善して、弱いハードウェアでより速く動作し、強力なハードウェアで視覚的に魅力的にすることは可能ですか？ まあ、私たちにとって幸いなことに、はい、それは可能です！ ゲームの状態を毎秒60回更新する必要はありません。 ユーザー入力、AI、およびゲームの状態の更新は、1秒間に25回更新するだけで十分です（これに同意するわけではありませんが、常に約ではありません）。 それではupdate_game（）を1秒間に25回呼び出してみましょう。 ただし、鉄が引っ張るのと同じ頻度でレンダリングを実行してください。 ただし、レンダリングが遅い場合でも、状態のリフレッシュレートには影響しません。 これを実現する方法を次のコードに示します。

 const int TICKS_PER_SECOND = 25; const int SKIP_TICKS = 1000 / TICKS_PER_SECOND; const int MAX_FRAMESKIP = 5; DWORD next_game_tick = GetTickCount(); int loops; float interpolation; bool game_is_running = true; while( game_is_running ) { loops = 0; while( GetTickCount() > next_game_tick && loops < MAX_FRAMESKIP) { update_game(); next_game_tick += SKIP_TICKS; loops++; } interpolation = float( GetTickCount() + SKIP_TICKS - next_game_tick ) / float( SKIP_TICKS ); display_game( interpolation ); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その結果、update_game（）の実装はシンプルなままです。 ただし、残念ながら、display_game（）関数はより複雑になります。 補間と予測を実装する必要があります。 しかし、心配しないでください。見た目ほど難しくありません。 後ほど、補間と予測がどのように機能するかを説明しますが、最初にそれらが必要な理由を示します。

補間が必要な理由

ゲームの状態は1秒間に25回更新されます。 したがって、補間が使用されない場合、フレームは同じ最大周波数で表示されます。 ここでは、1秒あたり25フレームが誰かに見えるほど遅くないことに注意する必要があります。 たとえば、フィルムでは、フレームは毎秒24フレームの頻度で変化します。 したがって、毎秒25フレームで十分と思われますが、高速で移動するオブジェクトには十分ではありません。 そのようなオブジェクトの場合は、状態のリフレッシュレートを上げて、よりスムーズなアニメーションを取得する必要があります。 リフレッシュレートの増加に代わるものは、正確に補間と予測の組み合わせです。

*注 perev。：NeoAxisの物理オブジェクトのエンジンでは、フラグContinuous Collision Detectionを設定できます。 上記のゲームサイクルの実装と同様に実行されるのは、単なる処理であると思われます。

補間と予測

上記のように、状態は独立した頻度で更新されます。 したがって、連続する2つのティックの間で描画が開始される場合があります。 状態を10回更新したとします。 次に、描画が呼び出され、10から11ティックの間に実行されます。 10.3の離散時間とします。 その結果、「補間」の値は0.3になります。 例として、次のように動く車を想像してください。

position = position + speed;





状態更新サイクルの10番目のステップで位置が500である場合、速度は100です。11番目のステップで位置は600になります。レンダリング中のマシンの位置はどうなりますか？ 最後のステップでポジションを取ることができます。 500.しかし、次のステップで位置を予測し、時間10.3で補間する方がはるかに優れています。 次の形式のコードを取得します。

view_position = position + (speed * interpolation)





したがって、マシンは位置530に描画されます。変数「補間」には、通常、現在のフレームと次のフレームの間の時間の相対位置0〜1の値が含まれます（理解を深めるためにやり直します。 スムーズなアニメーションを確保するために、予測を複雑にしすぎる必要はありません。 もちろん、衝突検出の直前に、あるオブジェクトが別のオブジェクトと部分的に交差する状況が考えられます。 しかし、前に見たように、ゲームの状態は1秒あたり25回更新されるため、レンダリングアーティファクトは1秒間だけ表示されます（オブジェクトの密度が高く、衝突が多い場合はどうでしょうか？-およそTransl）。

弱い鉄

ほとんどの場合、update_game（）はdisplay_game（）よりもはるかに高速に実行されます。 実際、弱いハードウェアであっても、update_game（）関数は1秒間に25回呼び出されることは当然と考えることができます。 したがって、1秒あたり15フレームの頻度でレンダリングが実行される場合でも、ゲームはユーザー入力を処理し、問題なく状態を更新します。

強力な鉄

強力なハードウェアでは、ゲームは25ティック/秒の固定速度で動作しますが、レンダリングは高速になります。 補間+予測は、アニメーションの魅力を追加します。 実際、レンダリングはより高いFPSで実行されます。 美しさは、このようにあなたがFPSで不正であるということです。 ゲームの状態を頻繁に更新するのではなく、画像のみを更新します。 ただし、同時に、ゲームのFPSは高くなります。

おわりに

更新とレンダリングを相互に分離することが最善の解決策のようです。 ただし、display_game（）で補間と予測を実装する必要があります。 確かに、このタスクはそれほど複雑ではありません（プリミティブメカニック、オブジェクト、およそTranslを使用する場合のみ）。

おわりに

ゲームループは、考えられるほど単純なものではありません。 4つの可能な実装を検討しました。 そして、それらのうち、少なくとも1つ（状態の更新がFPSに密接に関連している）があり、絶対に避ける必要があります。 モバイルデバイスでは、一定のフレームレートが許容される場合があります。 ただし、ゲームを異なるプラットフォームに移植する場合は、リフレッシュレートとレンダリング頻度を分離し、補間と予測を実装する必要があります。 予測と補間に煩わされたくない場合、状態を更新する頻度を高くすることができますが、弱くて強力な鉄の最適値を見つけるのは難しい作業です。



<％place_your_game_title_here％>をコーディングするために行進します！

関連記事（翻訳者から）

1. habrahabr.ru/blogs/silverlight/125037-SLのゲームサイクル
2. habrahabr.ru/blogs/gdev/112444-Unity3Dにはゲームループ自体はないという記述があります（明らかに隠されていますか？）
3. habrahabr.ru/blogs/gdev/102930-ゲームエンジンの作成について
4. habrahabr.ru/blogs/android_development/136968-ココナッツのゲームの例
5. gafferongames.com/game-physics/fix-your-timestep-ゲームの離散時間に関する別の記事