Unity/UE4のメインループについて
UnityとUE4のメインループについて調べてました。あくまで素人の土屋が適当にぐぐったレベルの話なので、間違いがありましたらコメント欄などで教えて頂けると助かります。
Unityではupdateメソッド、UE4ではTickメソッドが相当するようです（UEの規約ではメソッド名の１文字目が大文字なんですな）。全てのオブジェクトがこれらのメソッドを持っていて、毎フレーム呼ばれます。UE4ではオブジェクトごとにTickの呼び出しを抑制するオプションがあります。
気になったのは、Unity/UE4では実行環境に応じてフレームレートが変わる可変フレームレートを採用していて、これらのメソッドが秒間に何回呼ばれるかは保証されていないという点。なので、例えばオブジェクトを移動させる場合、呼ばれた側で前フレームから何ms経過しているかを確認し、単位時間あたりの移動距離と割り算をする形になります。
ちなみにUnityではフレームレートを固定することもできますが、処理落ちしたら同じ状況になるかと思います（UEの方は調べてない）。まあ、元々３Ｄ空間でオブジェクトを移動させるためにはこの手の演算がいくらでも出てくるので、構わないのかもしれません。
２Ｄの場合
上記の何が気になるのかというと、土屋が通ってきたゲームプログラミングとの乖離が大きかったからです。土屋が使っていたゲームエンジン（YaneSDK2nd）では、メインループはロジックを担当するupdateと、描画を担当するdrawに分かれてまして、updateは常に秒間６０フレで呼ばれ、逆にdrawは１回の実行にかかった時間を計測し、処理落ちが発生した場合は次フレの描画を間引くという形になっていました。
この手法の利点は、ロジックは常に秒間６０回実行されることが保証されるため、オブジェクトの移動増分を固定のドット数で指定できるため、実装が容易になることにあります。当時のゲームプログラミングにおいて最大のボトルネックは描画だったため、こういうスタイルが採用されたのかなと想像します。
今思えばドット単位で描画座標を指定する２Ｄゲームプログラミングだったから成立したとも言えますし、今のアーキテクチャでは分離する意義が低いのかもしれません。ただ、実装は直感的ではなくなると思います。
ちなみに、司エンジンは、現状は可変フレームレートに対応していませんが、update/draw方式を採用しています。２Ｄのゲームを作る分には、こっちの方が開発が容易だと思っています。
