再生システム：入力またはイベントを記録しますか？

私はこれを読みました：再生システムを設計する方法しかし、それは私の質問に実際には答えません。

私のゲームは、サーバーの「モデル」および「コントローラー」とは別のプログラムとして、ゲームのクライアントの「ビュー」で構築されています。（mmoのように、またはこの方法で構築されたマルチプレイヤーゲーム）。サーバー側は常にゲームの「真実」であり、クライアントからの入力としてアクション要求を受け入れ、イベントと「現在の状態」メッセージを出力するだけです。

ゲームモデルとルールは固定の「ティック」更新サイクルで完全に決定的であるため、サーバー側では、クライアントビューに送信されたイベントとアクションリクエストの両方を記録できます。どちらも特定のサイクル番号に関連付けられています。

問題は、この場合、再生システムをセットアップするには、入力、またはユーザーアクション要求（そこで提案されている）またはイベントを使用する必要があるかどうかです。

どちらもまったく同じ出力を生成するように思えます。私が見ることができる唯一の違いは：

• イベントは実際の出力を提供しますが、イベントを発生させるにはアクション要求を処理する必要があります。
• アクションリクエストは、記録するデータがはるかに少ない場合があります。

他に考慮すべきことはありますか？

決定論的なシステムを考えると、それらは論理的に同等なので、要約はかなり正確です。ただし、出力イベントではなく、入力アクションの記録に向けて私を左右する2つの点があります。

1. アクションを保存すると、イベントを再生するだけではなく、より多くのコードを実行するので、アクションを後でテストデータとして使用できます。これは、クラッシュバグの診断、ビルド間の動作の回帰の検索などに役立ちます。
2. 将来、特定のアクションのために送信するイベントを変更したり、何らかの理由で別のクライアントに別のイベントを送信したりする可能性があります。この場合、再生が無効または不完全になる可能性があります。同じ問題が理論的には入力にも当てはまる可能性がありますが、通常、入力のドメインは出力よりも制約が厳しいため、変更する可能性が低く、後方互換性がある場合に対応しやすくなります。（入力は、プレーヤーと他の入力ソース（例：乱数ジェネレーター）が実行できるものに制限されますが、出力には、それらの入力のすべての結果と、ゲームのルールによって生成されたその他の出力（プレゼンテーションヒント、定期的なサーバーなど）が含まれますサイドイベントなど）

どちらでも機能しますが、考慮すべき点がいくつかあります。

まず、時間情報を記録する必要があることを覚えておいてください。あらゆる種類の可変フレームレートを使用するゲームの場合、これは特に注意が必要です。ゲームが最初にシミュレーションに使用したのとまったく同じタイミング情報をリプレイデータが提供できることを確認する必要があります。

また、ゲームの動作の微調整も考慮する必要があります。もし、レコードの入力とは、微調整した場合どの入力がどのように扱われるか、どのように物理学解決さ、などの一部を、あなたの記録が無効になります。ゲームのイベントを記録したとしても、それらのイベントの解釈の変化の一部が変化すると、行き詰まります。

再生だけが必要な場合は、タイミング情報とともにプレーヤーエンティティの位置と回転の特定のリストを記録することをお勧めします。プレイバックを実行している間は、できる限り多くの物理演算やその他のゲームプレイロジックを無効にしてください。これがどれほど簡単か、実現可能かは、同期する必要のある他のオブジェクトの数によって異なります。