物理学によるマルチプレイヤーネットワーキング


12

私は、物理学を使用したマルチプレイヤーネットワーキングがレーシングゲームでどのように実装されているのか興味があります。私たちは、異なる人々によって制御される複数の高速移動車両で物理的な世界を持っています。車両には武器があり、互いに射撃できるとしましょう(ツイストメタル、Vigilante v8)

ヒットとコリジョンが心配です。権限のあるサーバーまたはより良い代替手段?

回答:


5

通常、サーバーが使用され、クライアントと定期的に共有される「真実」状態を保存します。衝突はクライアントとサーバーで独立して発生し、クライアントの状態は、通常推測航法と呼ばれるプロセスと同様のプロセスを使用して、以前の状態から推定されます。サーバーの状態がクライアントに到達すると、違いがある場合、クライアントは現在の状態から、ほとんど補間によって受け取った状態に移行します。

ただし、多くのオブジェクトの衝突が実際の問題になる可能性があるため、一般的に行われるのは、クライアントのシミュレーション時間をサーバーのシミュレーション時間よりも少し遅れて、さまざまな柔軟性を追加することです。 ValveのSource Engineネットコードに関するこの記事は非常に説明的です。また、使用するネットワークミドルウェア/ライブラリについて未定の場合は、RakNetとその「ReplicaManager3」コンポーネントを調べることをお勧めします。


2

できることがいくつかあります。

  1. サーバー上のすべての物理オブジェクトを集中化し、すべてのクライアント上のプレーヤーオブジェクトに座標を同期できます。これは最も簡単で、多くの欠陥なしで動作しますが、多くのリソースを使用し、多くの帯域幅を必要とします。特定の半径内にある他のプレーヤーのプレーヤーにのみ値を送信することにより、帯域幅の使用を最適化できます。

  2. Neensterが述べたように、サーバーとクライアントに物理をシミュレートさせることができます。サーバーはクライアントを修正することがよくあります。これは、すべてのクライアントがすべてのプレイヤーに対して独自の物理を計算することを意味し、サーバー上でキー押下イベントを同期して、すべてのクライアントの各プレイヤーの軌跡を示します。5秒ごとにサーバーが物理シミュレーションをブロードキャストし、すべてのクライアントが変更を受け入れます。これにより、ほとんど目立たないわずかなオフセットが作成される可能性がありますが、ネットワークラグおよびパケット損失(高トラフィックUDPでは避けられない)の間に、プレイヤーおよび/または他のプレイヤーが画面上でグリッチし、位置を迅速かつ途切れることなく変化することに気付くでしょう(語?)。

  3. 各クライアントに独自の物理を計算させ、座標を同期させることができます。これにより、クライアント間で共有されるオブジェクトの物理をシミュレートすることが難しくなります。特定のオブジェクトが必ずしもクライアントに属しているわけではないため、おしゃれな何かをしたい場合には、実装するのはかなり複雑な概念です。

最初の方法がおそらく最も簡単で、わずかなラグで約4〜5人のプレイヤーを獲得できるはずです。一致するサーバーごとに一致する必要があります。LANマッチをしている場合、これは先への道です。

2番目の方法がおそらく最も実用的ですが、実装が難しい場合があります。また、サーバーで物理シミュレーションを実行することは非常に機知に富んでいます。サーバーを集中管理している場合、おそらく複数のマシンに負荷を分散する必要があります。サーバーに10個の一致を許可し、一致が最も少ないサーバーに新しい一致を読み込みます。

3番目は間違いなくサーバー上で最もストレスが少なく、ピアツーピアネットワークスキームを実行している場合はおそらく最適なソリューションです。前述したように、プレーヤーオブジェクト以外のオブジェクトは他のクライアントでも変更できるため、同期するのは難しい場合があります。

あなたのゲームがどのように機能するのかわからないので、どちらを使用するかを説明できません。私にできることはあなたに事実を伝えることだけです。さらに質問がある場合は、お気軽にコメントしてください。


クライアントにその物理学を任せることは許容できる解決策であることを提案しますが、不正行為とは関係ありませんでした。
cubuspl42

@ cubuspl42トピックを継続するために、詳細は省略しました。OPはソリューションをさらに探求して、不正行為を軽減する潜在的な方法を探求できると考えています。
-tsturzl

そのような方法の1つは、各クライアントが提供するものの偏差をしきい値に制限できるようにすることです。たとえば、ほとんどのクライアントは、特定のオブジェクトが位置5,8または6,9にあると言いますが、座標として12,19を報告します。これは部分的な解決策にすぎませんが、ほとんどのゲームでは不正行為に対する部分的な解決策しか提供されていないため、それがなぜ発生しますか。この解決策は、彼らが不正行為をしているという意味ではありませんが、彼らの位置を修正する必要があり、彼らにとって遅れとして現れることを意味します。
tsturzl

まあ、私は少し同意しません。いくつかのタイプのチートは修正可能ですが、いくつかは修正できません。たとえば、私の意見では、競争力のあるオンラインシューティングゲームのスピードハックを作ることができれば、それは悪いゲームデザインです。または、ゴッドモードと無限の弾薬でマップを飛び回ることができるクレイジーなハック(ある時点でCrysis 1で起こったと思います)。これらは修正可能で、ゲームを正しく設計するだけです。wallhackのようなものはほとんど修正不可能です(サーバーからの膨大なリソースが必要になります)。Aimbotは事実上修正不可能です。解決策3は、この種の不正行為のリスクを高めます。
cubuspl42

@ cubuspl42私はあなたが例が何であるかの考えを逃していると思う。オプション3は、まさにあなたが話している問題を防ぐことができます。通常、速度を共有するTCPがあり、クライアント間の速度を簡単に確認してコンセンサスを形成できます。また、クライアントが同期クロック(HWクロックからの接続で確立可能)。
-tsturzl
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.