はじめに

約1年前、Oculusは私の研究を後援する提案をしてきました。 基本的に、彼らは次のように述べました。「こんにちはGlenn、VRのネットワーク化された物理学には多くの関心があり、GDCで素晴らしい講演をしました。 開発者に見せることができるVRのネットワーク物理学のモデルを準備できると思いますか？ おそらくタッチコントローラーを使用できますか？」



私は、 「くそー！」と答えました。 もちろん。 非常に興味深いでしょう！」しかし、正直なところ、私は2つの条件を主張しました。 最初に：私が開発したソースコードは、十分に無料のオープンソースライセンス（たとえば、BSD）で公開する必要があります。これにより、私のコードが最も役立ちます。 2番目：終了したら、このサンプルを開発するために行った手順を説明する記事を書く権利があります。



Oculusのメンバーは同意しました。 そしてこの記事！ ネットワーク物理学の例のソースコードは、 ここから入手できます 。 私が書いたコードは、BSDライセンスの下でリリースされています。 次世代のプログラマーがネットワーク物理学に関する私の研究から何かを学び、本当に素晴らしいものを作成できることを願っています。 頑張って

何を構築しますか？

私が最初にOculusとプロジェクトについて話し合い始めたとき、テーブルのようなものを作成することを想像しました。4人のプレーヤーが座って、テーブルの上にある物理的にシミュレートされたキューブと対話できます。 たとえば、投げたり、塔を捕まえて構築したり、手を振って互いの塔を破壊したりします。



しかし、UnityとC＃を数日間学習した後、私はついにRiftの内部に行き着きました。 VRでは、スケールが非常に重要です。 立方体が小さいとき、すべてが特に面白くありませんでしたが、そのサイズが約1メートルになったとき、素晴らしいスケール感がありました。 プレイヤーは、高さ20〜30メートルのキューブから巨大なタワーを作成できました。 気持ちは最高でした！



VRですべてがどのように見えるかを視覚的に伝えることは不可能ですが、次のようになります。









ここでは、タッチコントローラーを使用してキューブを選択、ドラッグアンドドロップできます。 プレーヤーが自分の手からリリースするすべてのキューブは、他のシミュレーションキューブと対話します。 立方体を立方体の塔に投げ入れて壊すことができます。 各手にキューブを取り、それらをジャグリングすることができます。 キューブからタワーを構築して、獲得できる高さを確認できます。



これはすべて非常に興味深いものですが、すべてがそれほどクラウドレスではありません。 Oculusをクライアントとして使用して作業を開始する前に、タスクと必要な結果を判断する必要がありました。



成功の評価として次の基準を提案しました。

1. プレイヤーはサイコロを遅滞なく拾い上げ、転がして捕まえる必要があります。
2. プレイヤーはタワーにキューブを積み重ねることができなければならず、これらのタワーは目立った震えなしで安定します（休息するようになります）。
3. プレイヤーのいずれかによって放棄された場合、シミュレーションと対話する場合、そのような対話は遅滞なく発生するはずです。

同時に、最も深刻なものから最小のものまで順番に一連のタスクを作成しました。 これは研究論文であるため、私たちがやろうとしていることに成功するという保証はありませんでした。

ネットワークモデル

まず、ネットワークモデルを選択する必要がありました。 本質的に、ネットワークモデルは、遅延をどの程度正確に隠し、シミュレーションの同期を維持するかという戦略です。



3つの主要なネットワークモデルのいずれかを選択できます。

1. 決定的なロックステップ
2. クライアント側予測を備えたクライアントサーバー
3. 権限スキームを使用した分散シミュレーション

ネットワークモデルの正しい選択はすぐに確信しました。これは、プレイヤーが対話するキューブに対する権限を獲得する分散シミュレーションモデルです。 しかし、私はあなたと私の推論を共有する必要があります。



まず、Unity物理エンジン（PhysX）は決定論的ではないため、決定論的ロックステップモデルを簡単に除外できます。 さらに、PhysXが決定論的であったとしても、プレイヤーのシミュレーションとのやり取りを遅延させる必要がないため、このモデルを除外できます。



その理由は、確定的ロックステップモデルの遅延を隠すために、シミュレーションの2つのコピーを保存し、レンダリングの前にローカル入力（GGPOスタイル）で強化されたシミュレーションを予測する必要があるためです。 シミュレーション周波数が90 Hzで、遅延が最大250 msの場合、これは視覚レンダリングの各フレームに25の物理シミュレーションステップが必要であることを意味します。 25Xのコストは、CPU使用率が高い物理シミュレーションでは単純に非現実的です。



そのため、2つのオプションが残っていました。クライアント側の予測を備えたクライアントサーバーネットワークモデル（専用サーバーの場合もあります）と、安全性の低い分散シミュレーションネットワークモデルです。



サンプルは競合的ではないため、専用サーバーをサポートするコストを追加することを支持する議論はほとんどありませんでした。 したがって、実装した2つのモデルのどちらに関係なく、セキュリティは本質的に同じでした。 唯一の違いは、ゲーム内のプレイヤーの1人が理論的に不正行為を行った場合、またはすべてのプレーヤーが不正行為を行った場合にのみ表示されます。



このため、分散シミュレーションモデルがより論理的な選択肢でした。 実際、同じレベルのセキュリティを提供しましたが、プレイヤーは対話するキューブを管理し、これらのキューブの状態を他のプレイヤーに送信する権限を取得するだけなので、コストのかかるロールバックや再シミュレーションは必要ありませんでした。

認可スキーム

対話するオブジェクトの（サーバーとして動作する）アクセス許可を取得すると、遅延が隠される可能性があることは直感的に明らかです。サーバーであるため、遅延はありませんか？ ただし、この場合の競合の解決方法は明確ではありません。



2人のプレイヤーが同じタワーと対話する場合はどうなりますか？ 遅延のために2人のプレイヤーが同じキューブをつかむ場合は？ 紛争が発生した場合、誰が勝ち、誰の条件が調整され、どのようにそのような決定を下すのか？



この段階で、私の直感的な考えは次のとおりでした：オブジェクトの状態を非常に迅速に（1秒あたり60回まで）交換するため、イベントとしてではなく、ネットワークプロトコルを介してプレーヤー間で送信される状態でエンコードとしてこれを実装するのが最善です。



私はしばらくこれについて考え、2つの基本的な概念に到達しました：

1. クレデンシャル
2. 所持

各キューブには、デフォルト値（白い色）または最後に対話したプレーヤーの色のいずれかを持つアクセス許可があります。 別のプレイヤーがオブジェクトと対話した場合、パワーが変更され、このプレイヤーに渡されます。 シーンでスローされたオブジェクトの相互作用にパワーを使用することを計画しました。 プレーヤー2によってスローされたキューブは、彼が相互作用するすべてのオブジェクト、およびそれらが相互作用するすべてのオブジェクトに対して再帰的に権限を取得できると想像しました。



テニュアの原則はわずかに異なります。 あるプレイヤーがキューブを所有している場合、最初のプレイヤーが所有を放棄するまで、他のプレイヤーはそのキューブを所有できません。 プレイヤーが他のプレイヤーの手からキューブをつかむことを望まないので、キューブを選ぶプレイヤーに所有権を使用することを計画しました。



権限と所有権を状態として表現し、転送できることを直感的に理解しました。各キューブが2つの異なる連続した番号を転送するときに追加されます：序数の権力と序数の所有権。 その結果、この直感的な理解はその公平性を証明しましたが、私が予想したよりも実現するのがはるかに困難であることが判明しました。 これについては、以下で詳しく説明します。

状態の同期

上記の許可ルールを実装できると信じて、最初のタスクは、UnityとPhysXを使用して、フローの一方向で物理を同期する可能性を証明することであると判断しました。 以前の仕事では、ODEを使用してネットワークシミュレーションを作成したため、これが可能かどうか全く分かりませんでした。



調べるために、Unityでループバックシーンを作成しました。このシーンでは、キューブがプレーヤーの前に落ちました。 キューブは2セットありました。 左側の立方体は、権威の側を表しています。 右側のキューブは、左側のキューブと同期したい非認証側を示しています。









キューブの両方のセットが同じ初期状態から開始されたとしても、キューブを同期するために何も実行されていなかった当初、最終結果はわずかに異なっていました。 これは、トップビューで最も簡単に確認できます。









これは、PhysXが決定論的ではないために発生しました。 非決定論的な風車と戦う代わりに、左側から（権限あり）状態を取得し、それを右側（権限なし）に1秒間に10回適用することにより、非決定性を打ち負かしました 。









各キューブから取得される状態は次のようになります。

struct CubeState { Vector3 position; Quaternion rotation; Vector3 linear_velocity; Vector3 angular_velocity; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、この状態を右側のシミュレーションに適用します。各キューブの位置、回転、線形、角速度を左側から取得した状態にスナップします。



この簡単な変更は、左右のシミュレーションを同期するのに十分です。 1/10秒の間に、PhysXには、目立った変動を示すために更新間で逸脱する十分な時間がありません。









これは、マルチプレイヤーのステートフル同期アプローチがPhysXで機能することを証明しています。 （安reliefのため息） 。 もちろん、唯一の問題は、圧縮されていない物理的な状態を送信すると、チャネルを占有しすぎることです...

帯域幅の最適化

インターネット上のネットワーク物理学のサンプルの再生可能性を確保するために、帯域幅を制御する必要がありました。



私が見つけた最も簡単な改善方法は、単に休止状態のキューブをより効率的にエンコードすることでした。 たとえば、静止した立方体の線形速度と（0,0,0）の角速度を常に（0,0,0）繰り返すのではなく、1ビットのみを送信します。

 [position] (vector3) [rotation] (quaternion) [at rest] (bool) <if not at rest> { [linear_velocity] (vector3) [angular_velocity] (vector3) }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、ネットワークを介して送信される状態をまったく変更しないため、 ロスレス送信方式です。 さらに、ほとんどのキューブが統計的にほとんどの場合静止しているため、非常に効果的です。



帯域幅をさらに最適化するには、 損失のある伝送技術を使用する必要があります。 たとえば、ネットワークを介して送信される物理状態の精度を低下させるには、最小最大値の特定の範囲内の位置を制限し、1/1000センチメートルの解像度に離散化してから、この離散化された位置を既知の間隔で整数値として送信します。 同じ単純なアプローチを直線速度と角速度に使用できます。 回転させるには、 3つの最小の四元数成分の透過率を使用しました。



ただし、これによりチャネルの負荷は軽減されますが、同時にリスクは増大します。 ネットワーク上でキューブの塔（たとえば、10〜20個のキューブを積み重ねたもの）を送信すると、サンプリングによって塔が揺れるエラーが発生する可能性がありました。 おそらくタワーの不安定性につながる可能性もありますが、特に面倒でデバッグが困難な方法、つまりタワーが正常に見え、他のプレイヤーが見ているときにリモートで見る場合（権限なしでシミュレートする場合）のみ不安定ですあなたは何をしますか。



私がこの問題を見つけた最良の解決策は両側の状態を離散化することでした。 つまり、シミュレーションの各ステップの前に、ネットワークを介して送信する場合と同じ方法で物理状態をインターセプトおよび離散化し、その後、この離散状態をローカルシミュレーションに適用します。



次に、非認証側での離散化状態からの外挿は、シミュレーションを当局と正確に一致させ、高い塔の震えを最小限に抑えます。 少なくとも理論的には。

休息する

しかし、物理的状態の離散化により、 非常に興味深い副作用が発生しました！

1. PhysXエンジンは、各フレームの開始時に各ソリッドの状態を強制的に変更することを余儀なくされ、CPUリソースのほとんどを消費していることを知らせてくれます。
2. 離散化は、PhysXが頑固に排除しようとするエラーを即座に、そして大幅に飛躍させて、お互いの侵入状態からキューブを削除するエラーを追加します！
3. また、ターンを正確に想像することは不可能です。これは、キューブの相互侵入にもつながります。 興味深いことに、この場合、キューブはフィードバックループにとどまり、床の上を滑り始めます。
4. 大きな塔の立方体は静止しているように見えますが、立方体は表面上でわずかに離散化されて落下するため、エディターでの慎重な研究により、実際には小さな値で変動していることがわかります。

CPUリソースを消費するPhysXエンジンの問題を解決することはほとんどできませんでしたが、オブジェクトの相互侵入から抜け出すための解決策を見つけました。 各ソリッドにmaxDepenetrationVelocityを設定し、キューブが反発できる速度を制限します。 毎秒1メートルの速度で十分であることが判明しました。



キューブを休めることははるかに困難でした。 私が見つけた解決策は、PhysXエンジン自体の静止状態の計算を完全に無効にし、それらを各キューブの位置と回転の循環バッファーに置き換えることです。 キューブが最後の16フレームの間に移動せず、有意な値だけ回転しなかった場合、強制的に停止させます。 ブーム！ その結果、完全に安定したサンプリングタワーが得られました。



これはハックのように聞こえるかもしれませんが、PhysXソースコードにアクセスする方法がなく、PhysXソルバーを書き換えて残りの状態を計算する資格がないため、他のオプションはありませんでした。 自分が間違っていると思ったら幸せになりますので、より良い方法を見つけることができたら、教えてください

優先アキュムレーター

別の深刻な帯域幅の最適化は、各パケット内のキューブのサブセットのみの転送でした。 これにより、転送されるデータの量を正確に制御できます。最大パケットサイズを設定し、各パッケージに適合する更新セットのみを送信することができました。



実際の動作は次のとおりです。

1. 各キューブには、各フレームで計算される優先度メトリックがあります。 値が大きいほど、送信の確率が高くなります。 負の値は、 「このキューブを送信する必要がない」ことを意味します 。
2. 優先度インジケータが正の場合、各キューブの優先度アキュムレータの値に追加されます。 この値は、各フレームで優先度アキュムレータが増加するように、シミュレーションの更新間で保存されます。つまり、優先度の高いキューブの値は、優先度の低いキューブの値よりも速く成長します。
3. 負の優先度メトリックは、優先度アキュムレータを-1.0にリセットします。
4. パケットが送信されると、キューブは優先度の最も高いアキュムレーターから最も低いアキュムレーターの順に並べられます。 最初のn個のキューブは、パッケージに含まれる可能性のあるキューブのセットになります。 優先順位が負のアキュムレーター値を持つオブジェクトはリストから除外されます。
5. パッケージが書き込まれ、キューブは重要度の順にパッケージにシリアル化されます。 パッケージは、必ずしもすべての状態の更新に適合しているわけではありません。キューブの更新には、現在の状態（静止時、静止時など）に依存する変数のエンコーディングがあるためです。 したがって、パッケージをシリアル化すると、キューブがパッケージに含まれているかどうかを判断するフラグが各キューブに返されます。
6. パッケージで転送されたキューブの優先順位アキュムレーターの値は0.0にリセットされ、他のキューブが次のパッケージに含まれる正直な機会を与えます。

このデモでは、高エネルギー衝突に最近関与したキューブの優先度を大幅に上げるための値を選択しました。非決定的な結果のため、高エネルギー衝突は偏差の最大の原因の1つです。 また、最近プレイヤーが投げたキューブの優先度を上げました。



静止しているキューブの優先度を下げると結果が悪くなることは、まったく直観に反することが判明しました。 私の理論では、シミュレーションは両側で実行されるため、静止しているキューブはわずかに同期がとれず、状態を十分に速く調整できず、キューブに遭遇する他のキューブの偏差につながります。

デルタ圧縮

上記のすべての方法を使用しても、データ転送はまだ十分に最適化されていません。 4人用のゲームの場合、ホストごとにすべてのシミュレーションが1 Mbit / sチャネルに収まるように、プレーヤーあたりのコストを256 kbit / sよりも低くしたかったのです。



私の最後の秘compressionは 、 デルタ圧縮です。



デルタ圧縮は、一人称シューティングゲームでよく使用されます。世界のすべての状態は、以前の状態と比較して圧縮されます。 この手法では、以前の完全な状態（「スナップショット」）が参照ポイントとして使用されますが、 参照ポイントと現在のスナップショットの間で一連の差分（ デルタ ）が生成され、クライアントに送信されます。



すべてのオブジェクトの状態が各スナップショットに含まれているため、この手法は（比較的）実装が簡単です。つまり、サーバーはクライアントが受信した最新のスナップショットを追跡し、このスナップショットと現在のスナップショットの差分を生成するだけです。



ただし、優先ドライブを使用する場合、パッケージにはすべてのオブジェクトの更新が含まれておらず、デルタコーディングプロセスはより複雑になります。 これで、サーバー（または権限を持つ関係者）は、以前のスナップショット番号に関連するキューブを単にエンコードできなくなりました。 代わりに、受信者が各キューブがどの状態でエンコードされているかを知るために、 各キューブに対して参照ポイントを示す必要があります。



サポートシステムとデータ構造も、はるかに複雑になります。

1. 最後に受信したスナップショットの数だけでなく、受信したパケットをサーバーに通知する信頼性システムが必要です。
2. 送信者は、送信された状態にパケット確認レベルをバインドし、各キューブの最新の確認済み状態を更新できるように、送信された各パケットに含まれる状態を追跡する必要があります。 次回キューブが送信されるとき、そのデルタは基準点としてこの状態に関連してエンコードされます。
3. 受信者は、各キューブの受信状態のリングバッファを保存して、このリングバッファのアンカーポイントを見てデルタからキューブの現在の状態を再作成できるようにする必要があります。

しかし、最終的には、このようなシステムは柔軟性と占有帯域幅を動的に調整する能力と、デルタコーディングによる桁違いの帯域幅の向上を兼ね備えているため、複雑さが増すこと自体が正当化されます。

デルタコーディング

これですべてのサポート構造ができたので、アンカーポイントの以前の状態に対するキューブの違いをエンコードする必要があります。 これを行う方法？



状態が参照ポイントの値と比較して変化していないキューブをエンコードする最も簡単な方法は、わずか1ビットです： 変更はありません 。 さらに、これはチャネルの負荷を軽減する最も簡単な方法です。これは、ほとんどのキューブがいつでも静止している、つまり状態が変化しないためです。



より洗練された戦略は、可能な限り少ないビットで小さな変更をエンコードすることを目的として、現在の値と参照値の差をエンコードすることです。 たとえば、位置デルタは、基準点に対して（-1、+ 2、+ 5）になります。 最大の四元数成分はアンカーポイントと現在の回転との間で異なることが多いため、これは線形値ではうまく機能するが、3つの最小四元数成分のデルタではうまく機能しないことがわかりました。



さらに、違いをコーディングすることでいくつかの利点が得られますが、私が求めていたほどの改善はありません。 ストローにしがみついて、 予測を追加したデルタコーディング戦略を思いつきました。 このアプローチでは、重力による加速度の影響下で立方体が弾道的に移動すると仮定して、基準点から現在の状態を予測します。



浮動小数点計算では決定論が保証されないため、予測コードは固定小数点で記述する必要があるため、予測は複雑でした。 しかし、数日間の実験の後、位置、線形、角速度の弾道予測器を作成することができました。これは、約90％の離散解像度でPhysX積分器の結果に対応していました。



これらのラッキーキューブはもう1つのビットでエンコードされています。 理想的な予測で 、これにより桁違いの改善が見られました。 予測が完全に一致しなかった場合、予測に対して小さな誤差オフセットをエンコードしました。



私が費やしたすべての時間の間、ターンを予測する良い方法を見つけることができませんでした。 この原因は、特に固定小数点数では数値的に非常に不安定な四元数の3つの最小成分の表現にあると考えています。 将来的には、離散化されたターンに3つの最小コンポーネントの表現を使用しません。



また、違いとオフセットをコーディングするとき、ビットパッカーを使用することがこれらの値を読み書きするための最良の方法ではないことも痛いほど明白でした。 インターバルエンコーダーや算術コンプレッサーのようなものは、小数ビットを表現し、違いに応じてモデルを動的に変更できる、はるかに優れた結果を提供できると確信していますが、この段階では、すでに自分のチャンネルの制限に適合しており、追加することができません実験。

アバターの同期

数ヶ月の作業の後、私は次の進歩を遂げました。

• UnityとPhysXで状態同期が機能するという証拠
• 両側の状態をサンプリングしながら、リモート表示が可能な安定したキューブタワー
• 占有チャネルは、4人のプレーヤーが1 Mbpsに収まるレベルまで削減されます。

次に実装する必要があるのは、タッチコントローラーを介したシミュレーションとのやり取りです。 この部分は非常に興味深く、プロジェクトの私のお気に入りの段階になりました。



これらの相互作用をお楽しみください。 挙手、投げ、手から手への移動などの簡単なアクションが正しく感じられるように、多くの実験と微調整を行う必要がありました。 適切な投forのためのクレイジーな設定でさえ、素晴らしく機能し、高いタワーを高い精度で組み立てることができました。



しかし、ネットワークを介した共有に関しては、この場合、ゲームコードは重要ではありません。 ネットワークを介した送信で重要なのは、アバターが頭と両手で表示され、追跡機能付きのヘッドユニットとタッチコントローラーの位置と方向で制御されることです。



それらを同期するために、 FixedUpdateのアバターコンポーネントの位置と向きを他の物理状態とともにインターセプトし、このビューステートをリモートビューポートのアバターコンポーネントに適用しました。



しかし、これを初めて実現しようとしたとき、すべてがひどく見えました。 なんで？



デバッグ後、アバターの状態がタッチ機器からUpdateイベントのレンダリングのフレームレートでサンプリングされ、それがFixedUpdateを介して他のマシンで使用されていることがわかりました 。



この問題を解決するために、アバターの状態をサンプリングする際に物理とレンダリング時間の違いを維持し、各パッケージにそれらをアバターの状態に含めました。 次に、結果のパケットに遅延100ミリ秒のジッターバッファーを追加しました。これにより、パケット配信の時間差によって生じるネットワークジッターを排除し、適切なタイミングでサンプルを再作成するためにアバターステート間の補間を保証しました。



キューブがアバターの手の子であるときにアバターが保持するキューブを同期させるために、キューブの優先度インジケーターを-1に設定し、その状態が定期的な更新で物理状態に送信されないようにしました。 キューブが手に取り付けられると、アバターの状態として、その識別子、相対位置、および回転を追加します。 リモート表示では、キューブはアバターの最初の状態を受け取るとアバターの手に取り付けられます。アバターの最初の状態では、キューブは子の子になり、キューブのケイビングまたはリリースの瞬間に対応する物理状態の定期的な更新が再開されると手から切り離されます。

双方向の流れ

タッチコントローラーを使用してプレーヤーとシーンの相互作用を作成したので、2番目のプレーヤーがシーンと相互作用する方法について考え始めました。



2つのヘッドマウントデバイスの狂った絶え間ない変更に関与しないように、Unityテストシーンを拡張し、最初（左）と2番目（右）のプレイヤーのコンテキストを切り替える機能を追加しました。



最初のプレーヤーを「ホスト」、2番目のプレーヤーを「ゲスト」と呼びました。 このモデルでは、ホストは「実際の」シミュレーションであり、デフォルトではゲストプレーヤーのすべてのキューブを同期しますが、ゲストがワールドと対話すると、対応するオブジェクトに対する権限を受け取り、その状態をホストプレーヤーに転送します。



明らかな競合を発生させずにこれが機能するためには、ホストとゲストの両方が、権限と所有権を取得する前にキューブのローカル状態を確認する必要があります。 たとえば、ホストは、ゲストが既に所有しているキューブの所有権を取得しません。逆も同様です。同時に、承認が許可されます。これにより、プレイヤーはキューブを他の人の塔に投げ入れ、他の誰かが構築している間にそれらを壊すことができます。



ネットワーク物理学を実装するために私のモデルでシステムを4人のプレーヤーに一般化すると、すべてのパケットがホストプレーヤーを通過するため、アービターになります。実際、真のピアツーピアトポロジを使用する代わりに、ゲーム内のすべてのゲストがホストプレーヤーとのみデータを交換するトポロジが選択されます。これにより、ホストは、どの更新を受け入れ、どの更新を無視し、それに応じて調整するかを決定できます。



これらの修正を適用するには、ホストにゲストを制御させ、「いいえ、このキューブの権限/所有権がなく、この更新を承認する必要があります」と伝える方法が必要でした。また、ホストがゲストと世界とのやり取りの順序を決定できるように、クライアントが遅延や一連の遅延パケット配信の増加を感じないようにする方法も必要でした。これらのパッケージは、他のゲストのその後のアクティビティよりも好ましくないはずです。



前の直感的な予感のように、各キューブに2つの序数を使用してこれをすべて実装しました。

1. 権限の順序
2. 所有権の順序

これらの序数は状態が更新されるたびに送信され、キューブがプレイヤーによって保持されると、それらはアバターの状態に含まれます。ホストはプレーヤーから更新を受信するかどうかを決定するために使用され、ゲストがサーバーからのステータス更新が新しいかどうか、またゲストがキューブに対する権限を持っているか、所有している場合でも適用されるかどうかを決定するために使用されますそれら。



プレイヤーがキューブを介してパワーを獲得するたびに、またプレイヤーにパワーが属するキューブが休眠状態になるたびに、通常のパワーの数が増加します。ゲストマシンにキューブに対する権限がある場合、このマシンの権限は、ホストから確認を受け取るまで保持されます元の権限に戻る前に。これにより、重大なパケット損失が発生した場合でも、ゲストが所有する休止状態のキューブに対する権限が最終的にホストに転送されます。



所有者の序数は、プレイヤーがキューブを取るたびに増加します。所有は権威よりも「強い」ので、任期の序数の増加は権威の序数の増加に勝ちます。たとえば、あるプレイヤーがキューブを操作する直前に別のプレイヤーがキューブを操作すると、キューブを取得したプレイヤーが勝ちます。



このデモでの私の経験に基づいて、これらのルールは競合を解決するのに十分であると同時に、ホストおよびゲストの世界と遅延なく相互作用することを発見しました。実際には、大幅な遅延が発生した場合でも、修正する必要のある競合はまれであり、それらが発生した場合、シミュレーションによって競合はすぐに一貫した状態になります。

おわりに

堅牢な立方体タワーを備えた高品質のネットワーク物理学は、分散シミュレーションのネットワークベースのモデルを使用して、UnityおよびPhysXで実装できます。



このアプローチは、専用サーバーとクライアント側の予測を備えた信頼できるサーバーのネットワークモデルのレベルでセキュリティを提供しないため、協調ゲームプレイにのみ使用するのが最適です。



私の仕事とこの研究を行う機会を提供してくれたOculusに感謝します！



ネットワーク物理学のサンプルのソースコードは、ここからダウンロードできます。