28

ネットワークゲームを作ろうと思っています。私はこれに少し慣れておらず、推測航法とネットワーク遅延の適切な計画をまとめようとして、すでに多くの問題に遭遇しているため、このトピックに関する優れた文献を見てみたい. 私が考えた方法を紹介します。

もともとは、プレイヤーの入力をサーバーに送信し、そこでシミュレートして、ゲーム状態の変化をすべてのプレイヤーにブロードキャストするだけでした。これにより不正行為が困難になりましたが、遅延が大きい場合は、自分のアクションの結果がすぐに表示されないため、制御が少し困難でした.

この GamaSutra の記事には、帯域幅を節約し、クライアントでもシミュレートすることでローカル入力がスムーズに見えるようにするソリューションがありますが、チートプルーフは窓の外に投げ出されているようです. また、プレイヤーが環境を操作したり、岩を押したりし始めたときに何をすべきかわかりません。以前はニュートラルだったこれらのオブジェクトは、一時的にクライアントが PDU を送信する必要があるオブジェクトになるか、複数のプレイヤーが一度に送信する必要があります。誰の PDU が勝つでしょうか? オブジェクトが各プレイヤーによって二重に追跡されなくなるのはいつですか? (推測バージョンと比較するため)? 2 人のプレイヤーが相撲の試合に参加することは絶対に禁じられています (例: 互いに押し合い始める)。

この gamedev.net のビットは、gamasutra ソリューションが不適切であることを示していますが、別の方法について説明しているため、私の共同で岩を押す例を実際には修正できません。私が見つけた他のほとんどのものは、シューティング ゲームに固有のものです。SNES ゼルダのようにプレイするゲーム向けの何かをもっと見たいと思っていますが、もう少し物理学/勢いが関係しています.

  • 注: ここで物理シミュレーションについて質問しているわけではありません。他のライブラリがカバーしています。ネットワークの遅延にもかかわらず、ゲームをスムーズかつ反応的にするための単なる戦略。
4

5 に答える 5

21

ソースエンジンでValveがどのように機能するかを確認してください：http：//developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

一人称シューティングゲームの場合は、予測、補正、補間など、彼らが言及しているトピックのいくつかを掘り下げる必要があります。

于 2008-09-03T20:48:14.780 に答える
11

Glenn Fiedler によるこのネットワーク物理学のブログ投稿を見つけました。さらに、その下の応答/議論は素晴らしいものです。かなり長いですが、価値があります。

要約すれば

最新のゲーム物理シミュレーション (車両や剛体ダイナミクスなど) でクライアント入力が受信されるたびに、サーバーはシミュレーションの反復に追いつくことができません。したがって、サーバーは、サーバーが必要とする前にすべての着信パケットが JIT に入るように、サーバーよりも前にすべてのクライアントにレイテンシ + ジッター (時間) を命令します。

彼はまた、あなたが求めている種類の所有権を処理する方法の概要を説明します. 彼が GDC で見せたスライドは素晴らしいです!

不正行為について

Fiedler 氏自身 (および他の人) は、このアルゴリズムはチートに対する耐性があまり高くないことに苦しんでいると述べています。本当じゃない。このアルゴリズムは、従来のクライアント/サーバー予測と同様に悪用が容易でも困難でもありません ( @CD Sanchez の回答の従来のクライアント/サーバー予測に関する記事を参照してください)。

はっきりさせておくと、サーバーはネットワークの物理的な測位をジャストイン タイムで受信するため (従来の予測のように x ミリ秒遅れるのではなく)、ごまかすのは簡単ではありません。クライアントはすべて、従来の予測とまったく同じ遅延で対戦相手の位置情報を受信するため、まったく影響を受けません。

どのアルゴリズムを選択しても、メジャー タイトルをリリースする場合は、チート プロテクションを追加することをお勧めします。もしそうなら、手先のボットに対する暗号化(たとえば、「キーストリームが疑似乱数ジェネレーターによって生成される」XOR ストリーム暗号) とクラックに対する単純な健全性チェックを追加することをお勧めします。一部の開発者は、バイナリが無傷であることを確認する (クラッキングのリスクを減らすため)、またはユーザーがデバッガーを実行していないことを確認する (クラックが開発されるリスクを減らすため) アルゴリズムを実装していますが、それらについては議論の余地があります。

数千人のプレイヤーしかプレイできない小さなインディー ゲームを作成している場合は、1) 必要になるまでアンチチート アルゴリズムを実装しないでください。または 2) ユーザーベースが拡大します。

于 2009-05-07T15:23:40.747 に答える
0

XNAクリエーターズクラブのウェブサイトでネットワーキング教育のトピックをチェックしてください。ネットワークアーキテクチャ（ピアツーピアまたはクライアント/サーバー）、ネットワーク予測、およびその他のいくつかのトピック（もちろん、XNAのコンテキストで）などのトピックを掘り下げます。これはあなたが探している答えを見つけるのを助けるかもしれません。

http://creators.xna.com/education/catalog/?contenttype=0&devarea=19&sort=1

于 2008-09-16T16:48:22.967 に答える
0

エリア内の平均レイテンシーに応じて、すべてのクライアントにレイテンシーを課すことができます。そうすれば、クライアントはレイテンシの問題を回避しようとすることができ、ほとんどのプレイヤーにとって同じように感じるでしょう.

もちろん、すべての人に 500 ミリ秒の遅延を強制することを提案しているわけではありませんが、50 ミリ秒のユーザーは、ゲームプレイをよりスムーズに見せるために 150 ミリ秒 (100 ミリ秒を追加) で問題ありません。

手短に; プレイヤーが 3 人の場合:

  • ジョン: 30ms
  • ポール: 150ms
  • エイミー: 80ms

計算後、データをすべて同時にクライアントに送り返すのではなく、レイテンシーを考慮して、たとえば、John より先に Paul と Amy に送信を開始します。

しかし、このアプローチは、ダイヤルアップ接続やワイヤレス ユーザーが実際にすべての人を台無しにする可能性がある極端な待ち時間の状況では実行できません。しかし、それはアイデアです。

于 2009-05-07T15:32:39.587 に答える