TL; DR

Unity- GitHubでプレイヤーの身体の動きのクライアント側の予測を実装する方法を示すデモを作成しました。

はじめに

2012年の初めに、Unityでのプレーヤーの物理的な動きのクライアント側での予測の実装方法に関する投稿を書きました。 Physics.Simulate（）のおかげで、私が説明した不器用な回避策は不要になりました。 古い投稿は今でも私のブログで最も人気のあるものの1つですが、現代のUnityではこの情報はすでに間違っています。 したがって、2018年版をリリースしています。

クライアント側には何がありますか？

競争力のあるマルチプレイヤーゲームでは、可能な限り不正行為は避けてください。 通常、これは、権威主義的なサーバーを備えたネットワークモデルが使用されることを意味します。クライアントは入力された情報をサーバーに送信し、サーバーはこの情報をプレーヤーの動きに変換し、プレーヤーのステータスのスナップショットをクライアントに送信します。 この場合、キーを押してから結果が表示されるまでに遅延があり、アクティブなゲームでは受け入れられません。 クライアント側の予測は非常に一般的な手法であり、遅延を隠し、結果の動きを予測し、すぐにプレーヤーに表示します。 クライアントはサーバーから結果を受信すると、クライアントが予測した結果と比較します。結果が異なる場合、予測は誤っていたため修正する必要があります。

サーバーから受信したスナップショットは、常にクライアントの予測状態に関して過去のものです（たとえば、クライアントからサーバーにデータを転送してから150ミリ秒かかる場合、各スナップショットは少なくとも150ミリ秒遅れます）。 この結果、クライアントが間違った予測を修正する必要がある場合、過去のこの時点までロールバックし、ギャップに入力されたすべての情報を再現して、現在の場所に戻る必要があります。 ゲーム内のプレイヤーの動きが物理学に基づいている場合、1フレームで複数のサイクルをシミュレートするにはPhysics.Simulate（）が必要です。 プレイヤーを移動するときにキャラクターコントローラー（またはカプセルキャストなど）のみを使用する場合は、Physics.Simulate（）を使用せずに実行できます。パフォーマンスが向上すると思います。

Unityを使用して、 Glenn Fiedlerによる「Zen of Networked Physics」と呼ばれるネットワークデモを再現します。 プレイヤーは物理的な立方体を持っており、そこに力を加えてシーンに押し込むことができます。 デモでは、遅延やパケット損失など、さまざまなネットワーク状態をシミュレートします。

仕事を始める

最初に行うことは、自動物理シミュレーションをオフにすることです。 Physics.Simulate（）を使用すると、いつ物理システムにシミュレーションを開始するかを伝えることができますが、デフォルトでは、固定プロジェクト時間デルタに基づいてシミュレーションを自動的に実行します。 したがって、 [ 自動シミュレーション ]ボックスのチェックを外して、 [編集]-> [プロジェクト設定]-> [物理]で無効にします。

始めるために、単純なシングルユーザー実装を作成します。 入力はサンプリングされ（移動する場合はw、a、s、d、ジャンプする場合はスペース）、すべてAddForce（）を使用してリジッドボディに適用される単純な力になります。

public class Logic : MonoBehaviour { public GameObject player; private float timer; private void Start() { this.timer = 0.0f; } private void Update() { this.timer += Time.deltaTime; while (this.timer >= Time.fixedDeltaTime) { this.timer -= Time.fixedDeltaTime; Inputs inputs; inputs.up = Input.GetKey(KeyCode.W); inputs.down = Input.GetKey(KeyCode.S); inputs.left = Input.GetKey(KeyCode.A); inputs.right = Input.GetKey(KeyCode.D); inputs.jump = Input.GetKey(KeyCode.Space); this.AddForcesToPlayer(player.GetComponent<Rigidbody>(), inputs); Physics.Simulate(Time.fixedDeltaTime); } } } 

ネットワークが使用されていないときにプレーヤーが移動する

サーバーへの入力の送信

次に、入力をサーバーに送信する必要があります。サーバーは、このモーションコードも実行し、キューブ状態のスナップショットを作成して、クライアントに送り返します。

 // client private void Update() { this.timer += Time.deltaTime; while (this.timer >= Time.fixedDeltaTime) { this.timer -= Time.fixedDeltaTime; Inputs inputs = this.SampleInputs(); InputMessage input_msg; input_msg.inputs = inputs; input_msg.tick_number = this.tick_number; this.SendToServer(input_msg); this.AddForcesToPlayer(player.GetComponent<Rigidbody>(), inputs); Physics.Simulate(Time.fixedDeltaTime); ++this.tick_number; } } 

ここまで特別なことは何もありません。注意したいのはtick_number変数を追加することだけです。 サーバーがキューブの状態のスナップショットをクライアントに送信するときに、この状態に対応するクライアントのタクトを確認できるようにする必要があります。これにより、この状態を予測クライアントと比較できます（少し後で追加します）。

 // server private void Update() { while (this.HasAvailableInputMessages()) { InputMessage input_msg = this.GetInputMessage(); Rigidbody rigidbody = player.GetComponent<Rigidbody>(); this.AddForcesToPlayer(rigidbody, input_msg.inputs); Physics.Simulate(Time.fixedDeltaTime); StateMessage state_msg; state_msg.position = rigidbody.position; state_msg.rotation = rigidbody.rotation; state_msg.velocity = rigidbody.velocity; state_msg.angular_velocity = rigidbody.angularVelocity; state_msg.tick_number = input_msg.tick_number + 1; this.SendToClient(state_msg); } } 

簡単です-サーバーは入力メッセージを待機し、それを受信するとクロックをシミュレートします。 次に、結果のキューブの状態のスナップショットを作成し、クライアントに送り返します。 ステータスメッセージのtick_numberが入力メッセージのtick_numberよりも1つ多いことに気付くかもしれません。 これは、「タクト100のプレーヤーの状態」を「タクト100の最初のプレーヤーの状態」と考える方が個人的に直感的に便利だからです。 したがって、メジャー100のプレーヤーの状態とメジャー100のプレーヤーの入力は、メジャー101のプレーヤーの新しい状態を作成します。

状態_n +入力_n =状態_{n + 1}

私はあなたがそれを同じようにとるべきだと言っているのではなく、主なことはアプローチの不変性です。

また、これらのメッセージを実際のソケットを介して送信するのではなく、パケットをキューに書き込んでパケットの遅延と損失をシミュレートすることで模倣することも言わなければなりません。 シーンには2つの物理キューブが含まれています。1つはクライアント用で、もう1つはサーバー用です。 クライアントキューブを更新するとき、サーバーキューブのGameObjectを無効にします。逆も同様です。

ただし、ネットワークバウンスとパケット配信を間違った順序でシミュレートすることはありません。そのため、受信した各入力メッセージは前のものよりも新しいと仮定します。 このシミュレーションは、1つのUnityインスタンスで「クライアント」と「サーバー」を非常に簡単に実行し、1つのシーンでサーバーキューブとクライアントキューブを組み合わせるために必要です。

また、入力メッセージがリセットされてサーバーに到達しない場合、サーバーはクライアントよりも少ないクロックサイクルをシミュレートするため、異なる状態が作成されることに注意してください。 これは事実ですが、これらの省略をシミュレートしたとしても、入力は依然として正しくない可能性があり、これは異なる状態につながる可能性があります。 この問題は後で対処します。

また、この例ではクライアントが1つしかないため、作業が簡単になることも追加する必要があります。 複数のクライアントがある場合、a）Physics.Simulate（）を呼び出すときに、サーバーで1人のプレイヤーのキューブのみが有効になっていることを確認するか、b）サーバーが複数のキューブから入力を受け取る場合、それらをすべてシミュレートする必要があります


75 msの遅延（150 msの往復）
0％の紛失パッケージ
黄色のキューブ-サーバープレーヤー
青い立方体-クライアントが受け取った最後のスナップショット

これまでのところすべてが良さそうに見えますが、ビデオに記録したものを少し厳選して、かなり深刻な問題を隠しました。

決定の失敗

これを見てみましょう：


痛い...

このビデオはパッケージを失うことなく記録されましたが、シミュレーションはまったく同じ入力でも変わります。 なぜこれが起こるのかはよくわかりません-PhysXは十分に決定論的でなければならないので、シミュレーションが非常に頻繁に分岐することは印象的です。 これは、GameObjectキューブを常に有効または無効にしているためである可能性があります。つまり、2つの異なるUnityインスタンスを使用すると、問題が減少する可能性があります。 GitHubのコードで見た場合、バグになる可能性があります。

それはそうかもしれませんが、クライアント側での予測では不正確な予測が不可欠な事実なので、それらに対処しましょう。

巻き戻しできますか？

プロセスは非常に簡単です-クライアントが動きを予測するとき、彼はステータスバッファ（位置と回転）と入力を保存します。 サーバーからステータスメッセージを受信した後、受信した状態をバッファから予測された状態と比較します。 差が大きすぎる場合は、過去のクライアントキューブの状態を再定義し、すべての中間メジャーを再度シミュレートします。

 // client private ClientState[] client_state_buffer = new ClientState[1024]; private Inputs[] client_input_buffer = new Inputs[1024]; private void Update() { this.timer += Time.deltaTime; while (this.timer >= Time.fixedDeltaTime) { this.timer -= Time.fixedDeltaTime; Inputs inputs = this.SampleInputs(); InputMessage input_msg; input_msg.inputs = inputs; input_msg.tick_number = this.tick_number; this.SendToServer(input_msg); uint buffer_slot = this.tick_number % 1024; this.client_input_buffer[buffer_slot] = inputs; this.client_state_buffer[buffer_slot].position = rigidbody.position; this.client_state_buffer[buffer_slot].rotation = rigidbody.rotation; this.AddForcesToPlayer(player.GetComponent<Rigidbody>(), inputs); Physics.Simulate(Time.fixedDeltaTime); ++this.tick_number; } while (this.HasAvailableStateMessage()) { StateMessage state_msg = this.GetStateMessage(); uint buffer_slot = state_msg.tick_number % c_client_buffer_size; Vector3 position_error = state_msg.position - this.client_state_buffer[buffer_slot].position; if (position_error.sqrMagnitude > 0.0000001f) { // rewind & replay Rigidbody player_rigidbody = player.GetComponent<Rigidbody>(); player_rigidbody.position = state_msg.position; player_rigidbody.rotation = state_msg.rotation; player_rigidbody.velocity = state_msg.velocity; player_rigidbody.angularVelocity = state_msg.angular_velocity; uint rewind_tick_number = state_msg.tick_number; while (rewind_tick_number < this.tick_number) { buffer_slot = rewind_tick_number % c_client_buffer_size; this.client_input_buffer[buffer_slot] = inputs; this.client_state_buffer[buffer_slot].position = player_rigidbody.position; this.client_state_buffer[buffer_slot].rotation = player_rigidbody.rotation; this.AddForcesToPlayer(player_rigidbody, inputs); Physics.Simulate(Time.fixedDeltaTime); ++rewind_tick_number; } } } } 

バッファされた入力とステータスは、メジャー識別子がインデックスとして使用される非常に単純な循環バッファに格納されます。 そして、物理学のクロック周波数に64 Hzの値を選択しました。つまり、1024要素のバッファーは16秒間のスペースを提供しますが、これは必要なものよりもはるかに多くなります。


訂正中です！

冗長入力転送

通常、入力メッセージは非常に小さく、押されたボタンを組み合わせて数バイトのビットフィールドにすることができます。 メッセージにはまだ4バイトを占めるメジャー番号がありますが、キャリー付きの8ビット値を使用して簡単に圧縮できます（おそらく0-255の間隔は小さすぎるので、安全に9または10ビットに増やすことができます）。 場合によっては、これらのメッセージは非常に小さいため、各メッセージで大量の入力データを送信できます（以前の入力データが失われた場合）。 どのくらい前に戻りますか？ さて、クライアントはサーバーから受け取った最後のステータスメッセージの測定番号を知っているので、この測定値より先に戻ることは意味がありません。 また、クライアントによって送信される冗長な入力データの量に制限を課す必要があります。 デモではこれを行いませんでしたが、完成したコードに実装する必要があります。

 while (this.HasAvailableStateMessage()) { StateMessage state_msg = this.GetStateMessage(); this.client_last_received_state_tick = state_msg.tick_number; 

これは単純な変更であり、クライアントは最後に受信したステータスメッセージの測定番号を書き込むだけです。

 Inputs inputs = this.SampleInputs(); InputMessage input_msg; input_msg.start_tick_number = this.client_last_received_state_tick; input_msg.inputs = new List<Inputs>(); for (uint tick = this.client_last_received_state_tick; tick <= this.tick_number; ++tick) { input_msg.inputs.Add(this.client_input_buffer[tick % 1024]); } this.SendToServer(input_msg); 

クライアントから送信される入力メッセージには、1つのアイテムだけでなく、入力データのリストが含まれるようになりました。 小節番号のある部分は新しい値を取得します-これがこのリストの最初の入力の小節番号です。

 while (this.HasAvailableInputMessages()) { InputMessage input_msg = this.GetInputMessage(); // message contains an array of inputs, calculate what tick the final one is uint max_tick = input_msg.start_tick_number + (uint)input_msg.inputs.Count - 1; // if that tick is greater than or equal to the current tick we're on, then it // has inputs which are new if (max_tick >= server_tick_number) { // there may be some inputs in the array that we've already had, // so figure out where to start uint start_i = server_tick_number > input_msg.start_tick_number ? (server_tick_number - input_msg.start_tick_number) : 0; // run through all relevant inputs, and step player forward Rigidbody rigidbody = player.GetComponent<Rigidbody>(); for (int i = (int)start_i; i < input_msg.inputs.Count; ++i) { this.AddForcesToPlayer(rigidbody, input_msg.inputs[i]); Physics.Simulate(Time.fixedDeltaTime); } server_tick_number = max_tick + 1; } } 

サーバーは、入力メッセージを受信すると、最初の入力の測定番号とメッセージ内の入力データの量を認識します。 したがって、メッセージの最後の入力のビートを計算できます。 この最後の測定値がサーバー測定値以上である場合、サーバーがまだ見ていない入力が少なくとも1つ含まれていることがわかります。 もしそうなら、それはすべての新しい入力データをシミュレートします。

入力メッセージの冗長な入力データの量を制限すると、十分な数の入力メッセージが失われると、サーバーとクライアントの間にシミュレーションのギャップが生じることに気づいたかもしれません。 つまり、サーバーはメジャー100をシミュレートし、ステータスメッセージを送信してメジャー101を開始してから、メジャー105から始まる入力メッセージを受信できます。上記のコードでは、サーバーは105に進み、最新の既知の入力データに基づいて中間メジャーをシミュレートしません。 あなたがそれを必要とするかどうかはあなたの決定とゲームがどうあるべきかに依存します。 個人的には、ネットワークの状態が悪いため、サーバーがマップ上でプレーヤーを推測して移動することを強制しません。 接続が回復するまで、プレーヤーをそのままにしておく方が良いと考えています。

Zen of Networked Physicsデモには、クライアントによる「重要な動き」を送信する機能があります。つまり、以前に送信された入力と異なる場合にのみ、冗長な入力データを送信します。 これは入力デルタ圧縮と呼ばれ、それを使用して入力メッセージのサイズをさらに削減できます。 ただし、このデモではネットワーク負荷の最適化がないため、これまでのところこれを行っていません。


冗長な入力データを送信する前：パケットの25％が失われた場合、キューブの動きは遅くて痙攣し、引き続きスローバックされます。


冗長な入力データを送信した後：パケットの25％が失われた場合でも、補正は引きずられますが、キューブは許容可能な速度で移動します。

可変スナップショット頻度

このデモでは、サーバーがクライアントにスナップショットを送信する頻度が異なります。 頻度を減らすと、クライアントはサーバーから修正を受信するのにより多くの時間が必要になります。 したがって、クライアントが予測を間違えた場合、ステータスメッセージを受信する前に、クライアントはさらに逸脱する可能性があり、これにより、より顕著な修正がもたらされます。 スナップショットの頻度が高い場合、パケット損失はそれほど重要ではないため、クライアントは次のスナップショットを受信するために長く待つ必要はありません。


スナップショット周波数64 Hz


スナップショット周波数16 Hz


スナップショット周波数2 Hz

明らかに、スナップショットの頻度は高いほど良いので、できるだけ頻繁に送信する必要があります。 ただし、追加のトラフィックの量、そのコスト、専用サーバーの可用性、サーバーのコンピューティングコストなどに依存します。

平滑化補正

不正確な予測を作成し、必要以上にぎくしゃくした修正を取得します。 Unity / PhysX統合への適切なアクセスなしでは、これらの誤った予測をデバッグすることはほとんどできません。 私はこれを前に言ったが、私は再び繰り返す-あなたが私が間違っている物理学に関連する何かを見つけたら、それについて私に知らせてください。

古き良きスムージングで亀裂を光沢化することで、この問題の解決策を回避しました！ 修正が行われると、クライアントはプレーヤーの位置と回転をいくつかのフレームの正しい状態の方向に単純に滑らかにします。 物理キューブ自体は即座に修正されます（非表示）が、表示専用の2番目のキューブがあり、スムージングが可能です。

 Vector3 position_error = state_msg.position - predicted_state.position; float rotation_error = 1.f - Quaternion.Dot(state_msg.rotation, predicted_state.rotation); if (position_error.sqrMagnitude > 0.0000001f || rotation_error > 0.00001f) { Rigidbody player_rigidbody = player.GetComponent<Rigidbody>(); // capture the current predicted pos for smoothing Vector3 prev_pos = player_rigidbody.position + this.client_pos_error; Quaternion prev_rot = player_rigidbody.rotation * this.client_rot_error; // rewind & replay player_rigidbody.position = state_msg.position; player_rigidbody.rotation = state_msg.rotation; player_rigidbody.velocity = state_msg.velocity; player_rigidbody.angularVelocity = state_msg.angular_velocity; uint rewind_tick_number = state_msg.tick_number; while (rewind_tick_number < this.tick_number) { buffer_slot = rewind_tick_number % c_client_buffer_size; this.client_input_buffer[buffer_slot] = inputs; this.client_state_buffer[buffer_slot].position = player_rigidbody.position; this.client_state_buffer[buffer_slot].rotation = player_rigidbody.rotation; this.AddForcesToPlayer(player_rigidbody, inputs); Physics.Simulate(Time.fixedDeltaTime); ++rewind_tick_number; } // if more than 2ms apart, just snap if ((prev_pos - player_rigidbody.position).sqrMagnitude >= 4.0f) { this.client_pos_error = Vector3.zero; this.client_rot_error = Quaternion.identity; } else { this.client_pos_error = prev_pos - player_rigidbody.position; this.client_rot_error = Quaternion.Inverse(player_rigidbody.rotation) * prev_rot; } } 

誤った予測が発生すると、クライアントは修正後の位置/回転差を監視します。 位置補正の合計距離が2メートルを超える場合、立方体は単純に動きます-スムージングは​​依然として悪く見えるので、少なくともできるだけ早く正しい状態に戻ります。

 this.client_pos_error *= 0.9f; this.client_rot_error = Quaternion.Slerp(this.client_rot_error, Quaternion.identity, 0.1f); this.smoothed_client_player.transform.position = player_rigidbody.position + this.client_pos_error; this.smoothed_client_player.transform.rotation = player_rigidbody.rotation * this.client_rot_error; 

各フレームで、クライアントはlerp / slerpを正しい位置/回転に向けて10％実行します。これは、動きを平均化するための標準のべき乗則アプローチです。 フレームレートによって異なりますが、デモの目的にはこれで十分です。


250ミリ秒の遅延
パッケージの10％を失った
スムージングなしでは、補正は非常に顕著です


250ミリ秒の遅延
パッケージの10％を失った
スムージングを使用すると、修正を認識しにくくなります。

最終結果はかなりうまくいきます。パケットを模倣するのではなく、実際にパケットを送信するバージョンを作成したいと思います。 しかし、少なくともこれは、物理的なプラグインなどを必要とせずにUnityで実際の物理オブジェクトを使用するクライアント側予測システムの概念実証です。