MMORPGのUNITYにおけるネットワークと動き

BeamServer2 DLLを使用してC＃で専用サーバーをプログラミングしています。最初は、他のプレイヤーがすでに作成したOmuniマップ上で動くのを見たいと思っていました。これは、フレームごとにサーバーに自分の位置を送信することで行いました。これはうまくいき、私は数人の友達と遊ぶことができましたが、運動は遅れがありませんでした。そこで、サーバーが他のクライアントに到達するのを妨げることなくサーバーが誤った位置を送信できないように、動きの平滑化といくつかのセキュリティを追加しようとし始めました。

私がやったのは、remotePlayerにMovementControllerを持つmasterClientを作成したことです。クライアントが移動したいときは、ローカルに移動し、移動する方向を示すメッセージをサーバーに送信します。その後、サーバーは速度を取り、それをmasterClientに送信します。masterClientは、remotePlayerが自分自身を移動するように、remotePlayerを移動します。彼が動くのをやめると、彼は自分の位置を入れたメッセージを送ります。次に、マスタークライアントは、自分が来た位置がクライアントからの位置と同じくらい近いかどうかをチェックします。サーバーのクライアントの位置にサーバーを置いたクライアントのpingに従って現実的な場合は、

これは機能しますが、まだ問題があり、これを修正する方法がわかりません。クライアントの動きをスムーズにする必要がありますが、自分の位置に（x / 2、y / 2、z / 2）をたたきつけて、次のフレームで実際の位置に置くことができることに気付き、失敗しました。すぐに再試行します。それが追加されても、遅延が修正されているかどうかはわかりません。

他のテクニック、提案、質問、...？ありがとう、ディーデ。

「遅れのない」リアルタイムネットワークゲームのプログラミングには、多くの問題/タスクが伴います。

• ハードウェア速度（クライアントとサーバーの両方でプレーヤーに必要なCPU電力）
• ネットワーク距離と機器（接続LANまたはWAN？）
• サーバー帯域幅（プレーヤーの数）

第二に、あなたは常にゲームでごまかそうとする「悪者」を持っています。ゲームが公開される場合は、私が座って「偽の」ネットワークパッケージを挿入した場合にどうなるかを考えてください。誰かが「到達できない位置」または「完全なヘルス/弾薬」を投稿したかどうかを検討します。

最初にあなたのアーキテクチャについて私の提案は次のようなものになります：

• サーバーは、すべての重要なデータを制御し、動きを計算および検証します。
• クライアントは、画面に表示するものに関するデータと、移動するオブジェクトに関するいくつかの「先を考える」データを受け取ります。

私が知っているほとんどのリアルタイムFPSは、ある種の「この速度でこの方向に移動していることを知っているので、サーバーから他の詳細を取得するまでシミュレーションします」

したがって、クライアントは「要求したもの」を投稿する必要があり、その方向に移動し始める可能性もありますが、サーバーが移動を拒否すると、サーバーによって「強制的に戻される」場合があります。ここで、クライアントがマップの外に「誤った座標」を投稿した場合、または突然「ジャンプした」場合を考えなければなりません。サーバーは、前のポイントから新しい位置が可能かどうかを追跡する必要があります。または、サーバーは「CLIENT MOVE FORWARD 200」というメッセージを受信し、サーバーはマップとゲームデータに従ってこれが何を行うかを処理します。

これにより多少の遅延が生じますが、繰り返しになりますが、クライアントがこれらのデータを受信して​​計算を行う場合、ms / frameごとに更新する必要はありません。画面に目立った遅延がなく、少し遅れることがあります。

おそらく、マップを「仮想タイル」（ベクターゲームの場合）に分割して、オブジェクトが次に配置される場所をすばやく計算できるようにすることもできます。

World of Warcraft / Battlefield / Counterstrike

WOWもこの方法でやっていると思います。キーを押すと、サーバーはあなたの動き「ウィッシュ」を受け取り、「あなたは今動いています」と応答し、クライアントはこれを表示します+サーバーは何らかの「セッションpr。クライアント」でサーバー上の新しい位置をシミュレートします。これは、サーバーが全員を追跡し、基本的にこれを「ターンベース」として実行する必要があるため、「ゲーム対プレイヤーの最大数」が厄介になってきていることですが、リアルタイムに見えるほど高速です。

そう...

Foreach (Client in GameSessionList)
{
   ParseInput();
   ParseMovement(); // including collission test
   ResponseSend(); // new positions+movement data for client and objects/other players
}

遅延補償の難しい部分は、故障したクライアントから更新を受け取ることです。時間Tで送信された遅延クライアントのコマンドは、T + 40msで送信された遅延のないクライアントコマンドの後に到着する場合があります。取得した順にコマンドを適用すると、あらゆる種類の不快感が生じます。一方、それを正しく行うには、時間を巻き戻し、それ以降に発行されたすべてのコマンドを再生する必要があります。

これを回避する簡単な方法はありませんが、複数の有効な解決策があります。ここで説明されている比較的簡単なものを見つけることができます。

この分野には多くの研究があります。

非ネットワークゲームのようにクライアントを作成します。つまり、クライアント上で即座に行うことは何でもします。次に、それに並行して、ネットワークコードを追加します。このコードは、移動データを取得します。座標、方向、速度のように単純です。検証するサーバーにこれを送信するだけです。サーバーがOKまたは新しいポジションを送信します。

つまり、クライアントコードはすべて、世界で単独のように実行されます。次に、サーバーまたはOKから新しい修正データを受け取ります。前方に押して10秒間押し続けると、サーバーはその1つのデータのみを受信します。転送ボタンを押しているだけでも、毎秒データを送受信していると考えるかもしれません。あるいは、ラグスパイクにぶつかった場合、永久に実行される可能性があります。