基本的に物理学に基づいたサンドボックス/アクティビティゲームである2Dゲームを作りたいです。しかし、私には本当に理解できないことがあります。調査から、サーバーからの更新は約100ミリ秒ごとであるように思われます。プレイヤーが物理学を同時にシミュレートし、補間によって遅延補償を行うことができるため、これがプレーヤーに対してどのように機能するかを見ることができます。
私が理解していないのは、これが他のプレーヤーからの更新に対してどのように機能するかです。クライアントが100ミリ秒ごとにプレーヤーの位置のみを通知される場合、100ミリ秒で多くのことが発生する可能性があるため、その動作がわかりません。プレーヤーはその時間に2回程度方向を変えた可能性があります。誰かがこの問題について何らかの洞察を持っているのではないかと思っていました。
基本的に、これは撮影などでどのように機能しますか？
ありがとう
回答:
長い答えが嫌いな人のためのまとめ...
それはできますが、遅延がある場合、完璧なマルチプレイヤー物理学を行うことは不可能です。レイテンシが物理に影響を与える理由を説明した後、物理シミュレーションへのレイテンシの影響を減らすためのヒントを提供します。
マルチプレイヤー物理ゲームの作成には危険が伴います。「完璧な」オンラインマルチプレイヤー物理体験を作成することは不可能です。改善するためにできることはありますが、待ち時間を想定して完璧な物理学を作成する方法はありません。
問題は、物理学は現実的であるために高速で応答性がなければならないが、同時にすべての要因の組み合わせられたアクションに基づいて計算されなければならない、つまりすべてのプレイヤーの組み合わせられたアクションを意味します。また、遅延がある場合、これをリアルタイムで行うことはできません。
開発者は、さまざまな要素を制御できるかどうかを決定し、レイテンシが高くなりすぎるとプレーヤーのエクスペリエンスが低下することを理解する必要があります。もしあなたがそれで生きることができるなら（そしてあなたのプレイヤーもそうすることができるなら）、それのために行きなさい。物事をよりスムーズに実行し続ける方法についてのメモについては、この投稿の最後に向かってください。
物事が台無しになる方法を示す例
2人のプレイヤー（クライアント）がサーバーに接続されているゲームを想像してください。メッセージがインターネットを介してクライアントからサーバーに送信されるのに100ミリ秒（1/10秒）かかります。プレーヤーが何かをすると、何をしたかを示すメッセージがサーバーに送信されます。サーバーはメッセージを他のプレーヤーにブロードキャストし、すべてのプレーヤーが演技しているプレーヤーの行動を把握します。
次に、2人のプレイヤーが物理オブジェクトである木枠を地面に置いているシナリオを作成します。プレイヤーAが片側を叩き、ある方向に動いて送ります。しかし同時に、プレイヤーBは別の側でそれを打ち、別の方向に送ります。
これを処理するさまざまな方法と結果がどうなるか見てみましょう...
サーバー上で物理が計算された場合はどうなりますか？
サーバー上でのみ物理学が計算されているとします。プレイヤーAは「この方法でクレートをヒットしました」というメッセージをサーバーに送信し、1/10秒後にサーバーがメッセージを取得します。プレイヤーBは、「この他の方法でクレートをヒットしました」というメッセージを送信します。サーバーは、2つのアクションの組み合わせから物理的変化を計算し、「OK it this move。」と言ってメッセージを両方のプレイヤーに送り返します。両方のプレイヤーのアクションを組み合わせて、完璧な物理学が実行されます。
しかし問題は、どちらかのプレイヤーがクレートが反応するのを見るまでに2/10秒であることです。両方のプレーヤーからのメッセージは、サーバーに到達するのに1/10秒かかり、その後、両方のプレーヤーにサーバーの計算結果が送信されるのにさらに1/10秒かかります。
ボトムライン、ラグのあるゲームプレイ。
物理がクライアントで計算された場合はどうなりますか？
クライアントだけで物理を計算したとします。プレーヤーAの視点から見てみましょう。プレイヤーAがクレートをヒットすると、すぐに方向を変え始めます。プレーヤーAが何をしたかを示すメッセージもサーバーに送信されます。
しかし同時に、Bはヒットを行い、クレートが方向に向かっているのを見て、彼らが何をしたかについてメッセージをサーバーに送信しました。
2/10秒後に、サーバーからクライアントにメッセージが届きます。AはBが何をしたかを伝えられ、BはAが何をしたかを伝えられます。問題は、両方のクライアントが「まあ、プレーヤーXはこの場所でそのヒットを行ったかもしれないが、その場所には木枠がなくなったので、彼らのヒットは何もしなかった」ということです。
結論としては、2つのゲームが同期しておらず、プレイヤーが共有体験をしていないということです。彼らが両方とも異なるものを見た場合、マルチプレイヤーのポイントは何ですか？
物理がクライアントとサーバーの両方で計算されるとどうなりますか？
この場合、物理はクライアント上で計算されるため、プレーヤーは即座に遅延なしの反応を確認できますが、サーバー上でも計算されるため、すべてのプレーヤーにとって「正しい」です。
両方のプレイヤーがそれぞれの方向にクレートをヒットし、それぞれがヒットのみに基づいてクレートの動きを確認します。しかし、その後、2/10秒後にサーバーが戻ってきて、「実は、あなたは二人とも間違っています。木枠はこのようになりました。」と言います。突然、両方のプレイヤーは、クレートが劇的に方向を変え、グリッチが新しい場所に移動するのを目にします。
要するに、グリッチなゲームです。
結論
基本的に、何らかの遅延が存在する場合、複数のプレイヤーで完璧な物理ゲームを作成する方法はありません。かなり良いゲームを作ることはできますが、プレイヤーによっては過度のレイテンシーが悪い体験をするリスクが常にあります。ただし、ゲーム体験を良いものに保つためにできることがあります。
マルチプレイヤーゲームをうまく実行するためにできること
シンプルコリジョンボリュームを使用します。単純な立方体の形状を作成する場合、物理学で形状の詳細をすべてモデル化する必要はありません。スパイクボールは、物理学のスパイクボールとしてモデル化する必要はありません。代わりに、球体としてモデル化します。
小さな重要でないオブジェクトをクライアントのみのアイテムにします。例は、壊れた窓からの壊れたガラスの破片かもしれません。各クライアントに独自にシミュレートさせることができますが、それらが異なっていても問題にはなりません。
オブジェクトを物理オブジェクトにするのは、アクティブな物理オブジェクトの数を低く抑えるために物理オブジェクトにする必要がある場合のみにしてください。
マルチプレイヤー物理学を行うとき、ゲームをスローモーションで実行します。多分「弾丸時間」を考えてください。スローモーションゲームは遅延を補正し、複数のプレイヤーが物理学を一緒に操作できるようにします。
プレイヤーが何らかの種類の状況を一緒に設定できるようにし、その後、何らかの手がかりで、両方のプレイヤーの物理がシミュレートされ、両方がアクションの組み合わせの結果を見ます。プレイヤーは、完了するまでシーケンスに干渉してはなりません。
プレイヤーがお互いに干渉しないように、プレイヤーを分離します。これは、一度に1人のプレーヤーだけがコントロールできるボウリングやプールのようなゲーム、または各プレーヤーが独自の「サンドボックス」（ボウリングレーンのような）を持つ場合に最適です。
あなたがそれらを打つことができない場合、それらに参加し、物理学の遅れをゲームの一部にします。壊れた物理法則または何かがあるグリッチな宇宙にいることについての物語を想像してください:)
付録：シューティングゲームでの対処方法
シューティングゲームは、過度に複雑な物理演算を行わないことで対処します。クライアント側の効果を使用するため、プレイヤーはすぐに物事を見ることができますが、サーバーは何が起こったかを最終的に呼び出します。
プレイヤーAがプレイヤーBを撃つシナリオを想像してください。あなたの典型的なシューティングゲームはこのようなことをします...
それで、AがBにぶつかったように見えたときに、どうしてBを見逃すことができたのでしょうか？Bは移動した可能性がありますが、サーバーがクライアントに「Bはここに移動しました」というメッセージをまだ送信していないため、Aはまだ見ていません。
これについては、Valveのサイトに優れた記事があります。http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networkingを参照してください
このトピックに関する一連の記事をここに書いています：http : //www.gabrielgambetta.com/fpm1.html
最初の3つの記事では、トピックの紹介、クライアント側の予測、サーバーの調整、およびエンティティの内挿（これは特定の質問に答える部分です）を扱います。4番目の記事（近日公開予定）では、「シューティング」を扱います:)
ティムホルトの答えはほぼそれです。私の記事には、何が起こっているのかを理解するのに役立つダイアグラムがいくつかありますが、ティムと私は基本的に同じことを言っています。
応答性のために自分のキャラクターを完全に予測し、一貫性のために他のキャラクターを100ミリ秒遅らせることは不合理ではありません。これが悪いように見える場合は、自分のキャラクターをわずかに遅らせて、それらの同期を保つことを検討してください。いずれにせよ、ラグスパイクが発生した場合に誤った予測をスムーズにするための修正メカニズムが必要になります。そのシステムは、説明したような状況に対処します。レイテンシが100msであろうと1msであろうと関係ありません-クライアントはある意味で常に「遅い」ので、常に古いデータを扱っているように振る舞い、補間などの表面的な効果を適用して見栄えを良くする必要があります。
最終的には、利用可能なネットワークリソースに間に合わせることになります。理想的には、待ち時間がゼロの世界に住んでいて、すべてを完全に同期させることができます。現実的には、100、200、300ミリ秒ごとにクライアントを更新します。クライアントには、発生したことがスムーズに見えるようにするためのロジックが必要です。「滑らかさ」は非常に重要です。最終的には、クライアントとサーバー間でカオス的な同期が発生していても、ゲームは滑らかに感じる必要があります。
良い投稿とより良い答えを見つけることができます：
問題は実際にはレイテンシーではありません。それを引き起こした問題を隠すことは、非常によく補償され予測されます。パケット損失も問題ではありません。ネットワーキングシステムは、パケット損失に対して堅牢で許容できるように作成する必要があります。ただし、問題は遅延の急増と予測不可能な遅延です。同期が外れて到着するパケット、その一部はレイテンシスイングのためだけにドロップされ、レイテンシスイングなどのために予測および補間できない