タグ付けされた質問 「networking」

情報交換の目的でケーブルバインドまたはワイヤレス通信リンクを介して接続された2台以上のコンピューター。

3
一部のネットワークゲームが補間を使用し、一部がリモート移動にパスファインディングを使用するのはなぜですか?
これは少々未解決の質問ですが、私は誰かが両方の正当な理由を提供してくれることを望んでいます。 両方の簡単な例: 補間モデル クライアントが位置の更新を頻繁に受信し、リモートがこのデータの補間を使用して位置を更新するValveモデルを考えてください。 経路探索 このモデルでは、ユーザーが宛先を送信し、全員がその宛先にパスファインディングすると考えます。 どのタイプのゲームがそれぞれに適していますか?

5
ネットワークラグの補償を回避するためのゲームメカニクスのトリック?
ネットワーク遅延補償を実装するのは難しいですが、どうすればそれを回避できますか? たぶん、ラグをゲームの非クリティカルな部分として、または自然な部分としてさえ受け取られるような方法で、トリックを使用してゲームの仕組みを構築することは可能でしょうか? それらのテクニクスとは何ですか?また、そのようなテクニクスを使用する既存のゲーム(MMORPG、戦略など)はありますか? 更新: ターンベースのゲームにはラグ補正は必要ありませんが、リアルタイムのアプローチ(またはリアルタイムの印象、重要な部分-ユーザーをブロックして待つことはできません)を見るのは興味深いでしょう。 遅延補正を回避する主な理由は単純さです。
20 networking  mmo  rpg  rts  lag 

3
マルチプレイヤーゲームをNATの背後で確実に動作させるにはどうすればよいですか?
クライアント/サーバーが100%のゲームでさえ、クライアントがNATの背後にあると問題が発生する場合があります。ピアピアゲームはさらに大きな問題です。一部のゲームでは、複数のトランスポート(UDPやTCPなど)または複数の接続(音声用の異なるUDPポートなど)を使用する必要があります。 NATルーターの背後で実行しているときにゲームが確実に動作することを確認する方法は何ですか? ピアピア:集中型サーバーは存在しません。プレイヤーAがゲームを開始し、プレイヤーBが参加したい クライアントサーバー:既知のアドレス(ホスト名)にある集中サーバーは、すべての着信接続を受け入れます。各クライアントはそのサーバーとのみ通信します。 コンボ:サーバーは単なるマッチメイキングですが、ゲームの更新はピアツーピアです。異なるピアは、潜在的に異なるIP /ポートを持つ各プレーヤーを見る場合があります(たとえば、一部のクライアントは同じNATの背後にあり、一部は異なるルーター上にあります)

10
MMOはPvP中の切断をどのように処理する必要がありますか?
MMO(必ずしもMMORPGである必要はありません)で、PvPの途中で切断されたプレイヤーに対処するためのテクニックは何ですか? 特に、ネットワーク(または実生活)の問題のために切断された人々に悪影響を与えないようにし、それらに関与している人々に悪影響を与えないようにするにはどうしますか? そして、重要なこととして、切断を不正行為の方法として使用できないようにするにはどうすればよいでしょうか?

5
環境のような巨大で静的なオブジェクトは、最新のマルチプレイヤーゲームでサーバーからクライアントに送信されますか?
信頼できるシステムがあり、プレーヤーが試合に参加すると、既にスポーンされたすべてのオブジェクトを取得します-それ自体(クライアント)でスポーンされます。 次のようになります。 Client アクセストークンを Server Client から受け入れを受け取ります Server Client シーンをゲームシーンに切り替えます Serverプレイヤー、クレート、やり取りできるオブジェクトを送信して、clientそれらを生成して表示できるようにします。 しかし、地上オブジェクトはどうですか?今のところ、サーバーとクライアントにまったく同じシーンがあります-1つの静的なプレーンがフロアとして機能しています。現在、私は新しいもの、木、階段を追加し、一緒に物を作ります。 私は思った-私たちは良いです。しかし、環境も同期すべきではありませんか?どういうわけかネットワーク化されていますか?サーバーが所有していますか? 取りましょうLeague of Legends: 静的な環境で、おそらく1つのメッシュ(階段、草、壁、店)を組み合わせたものです。しかし、それは本当にクライアントに保持されているのですか、それともロード画面の間にサーバーによって送信されたのですか?
18 unity  networking  maps 

9
リアルタイムデバッグ手法
変数を微調整し、数分かかるコードをコンパイルし、コードを実行し、微調整が間違った方向にあることを認識し、プロセスを繰り返し実行するルーチンとはまったく異なります。 セッションの進行中にゲームロジックとの対話を開始したいと思います。これをどのように処理しましたか? iOS、C / C ++、およびC#/ XNAのソリューションを聞くことができます。

4
ネットワークゲームで堅牢な方法でエンティティIDを割り当てるにはどうすればよいですか?
ネットワークゲームのエンティティシステムに取り組んでおり、各エンティティに一意の32ビット整数IDを割り当てています。このIDを使用して、エンティティおよびエンティティ自体への参照をシリアル化できます。 現在、エンティティが作成されるたびにカウンターをインクリメントしています。IDが最終的に使い果たされると思いますが、40億のエンティティがあるとは本当に思っていません。また、これにより、エンティティ#5が破棄され、IDが5になった場合に問題が回避されます。新しい#5を参照するのか、古い#5を参照するのですか? 問題は、衝突の処理/回避方法がわからないことです。現在、クライアントが現在の「フリーID」よりも高いIDを持つエンティティの更新を受け取ると、それまでのフリーIDにぶつかります。しかし、それはあまり堅牢ではないようです。 競合することなくエンティティを割り当てることができるように各クライアントに範囲を割り当てることを考えました(上位nビットはプレーヤー番号です)が、範囲が時間とともに重複し始めた場合にどうなるか心配です。 これを処理するより良い方法はありますか?idがオーバーフローしたり、許可された範囲の終わりを超えたりすることさえ気にする必要がありますか?これらのケースを検出するコードを追加できますが、クラッシュ以外の事態が発生した場合はどうなりますか。 もう1つのオプションは、128ビットGUIDのように一意である可能性が高いものを使用することですが、ネットワークトラフィックを最小限に抑えようとしているゲームにとっては非常に重いようです。また、現実的には、32ビットまたは24ビットの整数に収まるエンティティが一度に必要になることはありません。 ありがとう!

4
単純なUDPゲームには何が関係しますか?
使い捨てテストとして、1週間でUDPを使用した簡単なゲームを作成しようとしたことがあります。それは恐ろしく行きました。 私は早くそれを捨てました。私が抱えていた主な問題は、すべてのプレーヤー/敵/オブジェクトのゲーム状態を古い状態に復元し、プレーヤーがプレイしている時点までゲームを早送りすることでした(つまり、ジャンプの0.5秒前。プレイヤーがジャンプを逃すようにする) たぶん、この方法は最も簡単な方法ではありませんか?私はそれが疑われるが、最初から間違って設計し、2日目の終わりに気付いた。(だから私はあまり勉強しなかったか、そんなに時間を無駄にしなかった) 私自身と他の人にとって、単純なUDPゲームには何が関係し、どのように書くのですか?または、状態を適切に復元する予測問題をどのように解決しますか? これをCW bcとしてマークします。役立つ答えがたくさんあることを知っています。

5
何が良いですか?多数の小さなTCPパケット、または1つの長いパケットですか?[閉まっている]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 私が作っているゲームのために、サーバーとの間で大量のデータを送受信しています。 現在、次のような位置データを送信しています。 sendToClient((("UID:" + cl.uid +";x:" + cl.x))); sendToClient((("UID:" + cl.uid +";y:" + cl.y))); sendToClient((("UID:" + cl.uid +";z:" + cl.z))); 明らかに、それぞれのX、Y、およびZ値を送信しています。 このようなデータを送信する方が効率的ですか? sendToClient((("UID:" + cl.uid +"|" + cl.x + "|" + cl.y + "|" + cl.z)));
16 networking 

5
リアルタイム戦略ゲームのネットワーキング
私は自分が取っているコンピューターサイエンスコースのリアルタイム戦略ゲームを開発しています。それのより難しい側面の1つは、クライアントとサーバーのネットワーキングと同期であるようです。このトピック(1500人の射手を含む)を読みましたが、他のモデル(たとえばLAN経由)とは対照的に、クライアント/サーバーアプローチを採用することにしました。 このリアルタイム戦略ゲームにはいくつかの問題があります。ありがたいことに、プレーヤーが行うすべてのアクションは決定論的です。ただし、スケジュールされた間隔で発生するイベントがあります。たとえば、ゲームはタイルで構成されており、プレイヤーがタイルを取得すると、そのタイルの値である「エネルギーレベル」は取得後1秒ごとに増加します。これは、私のユースケースを正当化する非常に簡単な説明です。 現在、サーバーにパケットを送信して応答を待つシンクライアントを実行しています。ただし、いくつかの問題があります。 プレイヤー間のゲームがエンドゲームに発展すると、毎秒50を超えるイベントが発生することが多く(前述のスケジュールされたイベントにより、蓄積されます)、同期エラーが発生し始めます。私の最大の問題は、クライアント間の状態のわずかな逸脱でさえ、クライアントが異なる決定を意味する可能性があり、それが完全に別個のゲームに雪だるま式になるということです。もう1つの問題(現時点ではそれほど重要ではありません)は、待ち時間があり、結果を確認するために移動してから数ミリ秒、さらには数秒待つ必要があることです。 これをエンドユーザーにとってより簡単に、より速く、より楽しくするためにどのような戦略とアルゴリズムを使用できるのだろうかと考えています。これは、1秒あたりのイベント数が多く、ゲームごとに複数のプレイヤーがいることを考えると、特に興味深いものです。 TL; DRが1秒あたり50イベントを超えるRTSを作成している場合、クライアントを同期するにはどうすればよいですか?

4
UDPを使用した確認応答の信頼性
UDPについて質問があります。コンテキストでは、リアルタイムアクションゲームに取り組んでいます。 私はUDPとTCPの違いについてかなり読みましたが、私はそれらをかなりよく理解していると感じていますが、正しいと感じたことのない作品が1つあります。それは信頼性、特に承認です。UDPはデフォルトでは信頼性を提供しないことを理解しています(つまり、パケットがドロップされたり、順番どおりに到着しないことがあります)。ある程度の信頼性が必要な場合、私が見た解決策(概念的には理にかなっています)は、確認応答を使用することです(つまり、サーバーはクライアントにパケットを送信し、クライアントがそのメッセージを受信すると、確認応答をサーバーに送り返します) 。 確認応答がドロップされるとどうなりますか? 上記の例(1つのサーバーが1つのクライアントにパケットを送信する)では、サーバーはパケットの確認応答が受信されるまでフレームごとにパケットを再送信することにより、潜在的なパケット損失を処理します。それでも帯域幅または順序が乱れたメッセージの問題に遭遇する可能性がありますが、純粋にパケット損失の観点から、サーバーはカバーされます。 ただし、クライアントが到着しない確認応答を送信すると、サーバーは最終的にそのメッセージの送信を停止せざるを得なくなり、そのパケットに含まれる情報が必要な場合、ゲームが中断する可能性があります。サーバーに対して同様のアプローチをとることができます(つまり、ACKに対するACKを受信するまで確認応答を送信し続けますか?)等々)。 ここで私の基本的なロジックは正しいと思うので、2つの選択肢があります。 単一の確認応答パケットを送信し、最善を期待します。 少数の確認応答パケット(おそらく3〜4)を送信し、すべてがドロップされるわけではないと仮定して、最善を期待します。 この問題に対する答えはありますか?基本的に何かを誤解していますか?知らないUDPを使用する保証はありますか?私は自分の論理が健全であると納得するまで、あまりにも多くのネットワークコードを使って前進することをheします。
16 networking  udp 

2
Quake 3のような精密なネットワークゲームでサーバーとクライアントのクロックを同期させる方法は?
私は2Dトップダウンシューターに取り組んでおり、Quake 3のようなネットワークゲームで使用されるコンセプトをコピーするために最善を尽くしています。 信頼できるサーバーがあります。 サーバーはクライアントにスナップショットを送信します。 スナップショットには、タイムスタンプとエンティティの位置が含まれます。 スナップショット位置間でエンティティが補間されるため、動きがスムーズに見えます。 必要に応じて、エンティティの補間は「過去に」わずかに行われるため、複数のスナップショットを補間します。 私が直面している問題は「クロック同期」です。 わかりやすくするために、サーバーとの間でパケットを転送する際のレイテンシーがゼロであると少しの間ふりをしましょう。 サーバーのクロックがクライアントのクロックより60秒進んでいる場合、スナップショットのタイムスタンプはクライアントのローカルのタイムスタンプより60000ミリ秒進んでいます。 したがって、クライアントのクロックが追いつくのに時間がかかるため、エンティティスナップショットが収集され、クライアントが特定のエンティティが移動するのをクライアントが見るまで約60秒間待機します。 スナップショットを受信するたびにサーバーとクライアントのクロックの差を計算することで、この問題を克服することができました。 // For simplicity, don't worry about latency for now... client_server_clock_delta = snapshot.server_timestamp - client_timestamp; エンティティが補間にどの程度沿っているかを判断するとき、単にクライアントの現在の時間に差を追加します。ただし、これに関する問題は、スナップショットが他のクロックよりも速く/遅く到着するために2つのクロックの差が突然変動するため、ジャーキネスが発生することです。 知覚可能な遅延が補間のためにハードコードされている遅延と、通常のネットワーク遅延によって引き起こされる遅延のみであるように、クロックをどのように密接に同期できますか? 言い換えると、ジャーキネスを導入せずに、クロックが大幅に非同期化されたときに、補間の開始が遅すぎる、または早すぎるのを防ぐにはどうすればよいですか? 編集:Wikipediaによると、NTPを使用して、インターネット上のクロックを数ミリ秒以内に同期できます。ただし、プロトコルは複雑に思えますが、おそらくゲームで使用するには過剰ですか?

3
クライアントとサーバーの両方を同時に効率的にコーディングするにはどうすればよいですか?
クライアントサーバーモデルを使用してゲームをコーディングしています。シングルプレイヤーでプレイする場合、ゲームはローカルサーバーを起動し、リモートサーバー(マルチプレイヤー)のようにローカルサーバーと対話します。これは、シングルプレイヤーコードとマルチプレイヤーコードを別々にコーディングしないようにするためです。 コーディングを始めたばかりで、大きな問題に遭遇しました。現在、私はすべてのゲームクラスをパッケージに編成して、Eclipseでゲームを開発しています。次に、サーバーコードで、クライアントパッケージのすべてのクラスを使用します。 問題は、これらのクライアントクラスにはレンダリングに固有の変数があり、これは明らかにサーバーでは実行されないことです。 サーバーで使用するクライアントクラスの修正バージョンを作成する必要がありますか?または、クライアント/サーバーがそれを使用しているかどうかを示すために、ブール値でクライアントクラスを変更するだけです。他にオプションはありますか?サーバークラスをコアクラスとして使用し、レンダリングクラスで拡張することについて考えただけです。

2
ゲームのホストはオーソリティか、それとも別の愚かなクライアントでしょうか?
1人のプレイヤーがホストし、他のプレイヤーが接続するネットワークマルチプレイヤーゲームを設計するとき、私が知っている2つの戦略があります。 ホストプレーヤーのゲームをオーソリティにし、他のすべてのプレーヤーがダムクライアントとして現在のゲーム状態に追いつくようにします。コードでは、現在のプレーヤーがホストかどうかに応じて、多くの特別なケースが必要になります。 別のスレッドで非表示の専用サーバーを実行することにより、ホストを他の全員と同様にダムクライアントにします。専用サーバーが権限となり、ホストは他のユーザーと同様に(localhostを介して)接続します。 これらのそれぞれの利点/欠点は何ですか?最もよく使用されるのはどれですか(またはゲームのタイプ/サイズによって異なりますか)?

3
ログインサーバーをゲームサーバーと区別する必要がありますか?
MMOサーバーを作成することを考えており、他のゲームがどのようにネットワークを構築しているかを見てきました。私が気づいたことの1つは、ログインサーバーとゲームサーバーが常に存在することです。 私はまだこれを行うべきかどうかを決定していますが、最初にいくつかの意見を聞きたいです。これの利点は何ですか?また、ログインサーバーはゲームサーバーとどのように通信してログインを処理しますか?

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.