4

リアルタイムのマルチプレイヤー レーシング ゲームを作成中です。ここで、Node.js TCP (ネット) サーバーでゲーム ロジックを作成するのに助けが必要です。それが可能かどうか、それが正しいかどうかはわかりませんが、最善を尽くしています。私の壊れた英語を理解するのは難しいことを知っているので、この「絵」を作りました:)
お時間をいただきありがとうございます
プロセス

4

3 に答える 3

4

driushkin の回答を詳しく説明するには、リモート プロシージャ コール (RPC) とイベント キューを使用する必要があります。これは、投稿した画像のように機能します。各パケットは、いくつかの引数 (移動方向など) を持つ「コマンド」または RPC を表します。また、RPC が順番どおりに時間どおりに実行されるようにするためのイベント キューも必要です。これには、各コマンドを実行するためのタイムスタンプまたはフレームカウント (単純なスキームで将来のある時点で) と、同期された時計 (第二次世界大戦スタイル) が必要になります。

このスキームには重大な弱点が 1 つあります。ネットワークの遅延や悪意のあるユーザーなどにより、RPC メッセージが遅れる (適用されるべき時間よりも遅れて到着する) 可能性があります。単純なスキームでは、遅れた RPC は破棄されます。すべてのクライアント (オリジネーターも!) はサーバーが RPC を送信するのを待ってから動作するため、これは問題ありません (オリジネーターのクライアントがサーバー メッセージを待たなかった場合、彼のゲームの状態はサーバーと同期しなくなり、あなたのゲームが壊れます）。

このようなスキームに対するラグの影響を検討してください。クライアント A からサーバーへの遅延が 100 ミリ秒で、帰りの移動も 100 ミリ秒だったとします。これは、クライアント入力が次のようになることを意味します。

  • クライアント A がキーを押し、RPC をサーバーに送信しますが、ローカルに追加しません(0ms)
  • サーバーが RPC を受信して​​再ブロードキャストする (100ms)
  • クライアント A は自分のイベントを受け取り、最終的に処理のためにイベント キューに追加します (200 ミリ秒)。

ご覧のとおり、クライアントはキーを押してから 1/5 秒後に自分のイベントに反応します。これはかなり良い 100 ミリ秒のラグです。大洋横断ラグは片道 200 ミリ秒を簡単に超える可能性があり、ダイヤルアップ接続 (まれですが、今日でも存在します) では 500 ミリ秒を超えるラグ スパイクが発生する可能性があります。LAN などでプレイしている場合は問題ありませんが、インターネット上ではこの無反応は耐え難いものになる可能性があります。

ここで、クライアント側予測 (CSP) の概念が登場します。CSP は大きくて恐ろしく作られていますが、正しく実装されていて、実際には非常に単純です。CSP の興味深い機能は、クライアントが入力をすぐに処理できることです(クライアントは何が起こるかを予測します)。もちろん、クライアントは間違っている可能性があります (多くの場合そうなるでしょう)。これは、クライアントがサーバーから修正を適用する方法が必要になることを意味します。つまり、サーバーがクライアントからの RPC リクエストを検証、拒否、または修正する方法と、ゲームの状態をシリアル化する方法が必要になります (再シミュレートの基点として復元できるようにするため)。

これを行うための優れたリソースがたくさんあります。私は特にhttp://www.gabrielgambetta.com/?p=22が好きですが、優れたマルチプレイヤー ゲーム プログラミングの本を探すべきです。

Flex と AS3 に関するコメントを読んだ後でも、socket.io を提案する必要があります。使いやすさ (およびノー​​ドとの単純な統合) により、これまで使用した HTTP 経由のネットワーク ゲームの最高の (最高の?) オプションの 1 つになっています。使用できるように必要な調整を行います。socket.io 自体が利用できない場合でも、AIR/AS3 には少なくとも 1 つの WebSocket ライブラリがあると思います。

于 2012-06-01T16:02:02.237 に答える
2

これは、socket.ioが最適なもののように聞こえます。これは、ブラウザとサーバーでリアルタイムの可能性を提供するライブラリです。

于 2012-06-01T11:34:59.173 に答える
1

commandsこれは次のようにモデル化できeventsます: クライアントがコマンドmoveをサーバーに送信し、サーバーがこのコマンドを検証し、すべて問題なければ、イベントを発行しますis moving。

あなたの場合、P1（OK、移動できます）と残り（P1は移動中）に異なる応答をする必要はおそらくないでしょう。どちらの場合も後者で十分です。is movingイベントには、必要なすべての情報 (現在の位置、速度など) が含まれている必要があります。

この最も単純な形式では、サーバーからのイベントが到着するまでコマンドを発行する際に遅延が発生するため、すぐに移動を開始し、イベントが到着したときに必要に応じていくつかの補正アクションを適用することを回避できます。しかし、これは複雑になる可能性があります。

于 2012-06-01T11:55:38.903 に答える