マルチプレイヤーの同期とパスファインディング


8

クライアントでポイント&クリックタイプのインターフェイスを使用しており、サーバーでA *を実行してパスを検索しています。

ゲームはRTSのように制御されますが、世界は永続的であるため、プレーヤーはいつでも参加/離脱できるはずであり、画面には最大で30ユニットしかありません。

パスを計算した後、サーバーとクライアントの間でプレーヤーの動きを同期させる最良の方法は何ですか?

サーバーはすべてのアニメーションステップ/フレームでクライアントを同期する必要がありますか?または、パス上の各ノードと移動している各プレーヤーについて、「位置X、Yに移動する」ことをクライアントに伝えるだけですか?または、クライアントとサーバーの両方でアニメーションタイマーを実行し、暗黙的に同期させるのが最善ですか?

パスベースの移動の典型的なデータ交換はどのようなものですか?

編集:

「RTS」と言ったのでロックステップを提案している人もいますが、ゲームはRTSではなく、インターフェイスの種類が同じです。大きな違いは、いつでもプレーヤーをゲームに参加させたり、ゲームから離脱させたりできるようにする必要があることです。より具体的でなくてすみません。

回答:


2

別の方法は、ユニットを所有するクライアントでパスファインディングを行うことです。これには、作業をより均等に分散できるという利点があります。サーバーですべてのパスファインディングを実行することの欠点は、サーバーがすべてのパスファインディングを実行する必要があることです。「move to X、Y」コマンドのみをクライアントに送信することの欠点は、各クライアントがすべてのパスを見つける必要があることです。代わりに、ロックステップサイクルのすべての「ティック」で、各クライアントはサーバーに、文字通り、各ユニットの次のステップを伝えます。サーバーは、ユニットが実際にそこに移動できることを確認し、ユニットを移動します。クライアントにはすべての情報(特に、他のクライアントのユニットが行っていること)がないため、無効な移動コマンドはエラーとして扱われません。これは、帯域幅をあきらめて、パスの計算により多くの時間を費やすことになります。

サーバーをピアに置き換えます。この方法は、ユニットの動きが考慮される順序がすべてのマシンで同じであることを確認する限り、ピアツーピアゲームでも機能します。


1

RTSゲームには通常、ロックステップ同期があります(同期はフレームごとに発生します)。クライアントへのパスをすべて伝えると、ハッキングされたクライアントが追加情報を悪用する可能性があります。


1

どちらでもない。送信する必要があるのはコマンドだけです。例:これらの20ユニットは(X、Y)に移動し、各プレイヤーがそこに到達する方法を理解できるようにする必要があります。トリッキーな部分は、それらがすべてまったく同じことを実行することを確認することです。これを達成するためにロックステップモデルが使用されます。以下のリンクで詳細に説明する必要があります。また、重要な部分のみを同期する必要があります。ゲームプレイを変更しないものは同期されません。RTSゲームのアニメーションは通常、視覚的な側面のみを対象としています。

もう1つ、RTSゲームは通常クライアントサーバーではなく、P2Pです。そうすれば、不整合が検出されたときに切断するだけなので、プレーヤーの1人がチートすることはできません。

ここにあなたが始めるのに役立つ何かがあります: http: //www.gamasutra.com/view/feature/3094/1500_archers_on_a_288_network_.php http://altdevblogaday.com/2011/07/09/synchronous-rts-engines-and- a-tale-of-desyncs / http://altdevblogaday.com/2011/07/24/synchronous-rts-engines-2-sync-harder/


問題は、プレイヤーがいつでも参加したり離脱したりできるようにすることです。このゲームはRTSではなく、同様のインターフェースを備えています。
cloudhead

言うよりも多くの場合、常に50の完全に動的なオブジェクトは、RTSメカニズムを調べる必要がある場合があります。あなたのゲームはCIVやLOLのようなものですか?
PeterØlsted、

Diablo、Dungeon Siege、HoNに似ていますが、ポイントアンドクリックです。画面上に最大20ユニットを超えることはできません。
cloudhead、2011

1

パスが計算されると、サーバーはそのパスを使用してキャラクターを制御します。パスが存在しても、この問題に違いはありません。定期的な位置の更新であろうとなかろうと、同じデータを送信するだけです。通常は、ユニットが停止したときに通常の位置(クライアントで補間されて滑らかにする)と個別のメッセージを送信すると問題ありません。


わかりました、それは私が目指していることのようなものです。
cloudhead、2011

1

私のゲーム(マルチプレイヤーRPGタイプのゲーム)では、パスの一部をクライアント(近くのNPC用)に送信します。次の3つの位置とNPCが存在するべき時間。プレーヤーの場合は、最新の有効な位置とそのタイムスタンプを送信するだけで、クライアントで推測航法(または必要に応じてより複雑なもの)を実行できます。

これは、ほとんどの場合、プレーヤー/ NPC間の衝突がないため、完全に問題なく動作します(ラグが小さい場合、実際には何も気づきません。たとえば、250ミリ秒以上のラグがある場合、2つの画面(2つのプレーヤーの)同時にですが、「1つの画面」ではまだあまり目立ちません)。

だから私は言います:サーバーのオーサリング(プレーヤーの検証位置+タイムスタンプ、そして最初はAIについても、後で大きな問題なしにNPCのためにさらに複雑なシステムを作成できます)+クライアントの予測を使用します。

ps。私は、サーバーを再起動しなければならない前に、signed intが約3週間しか保持しないことを除いて、完全に問題なく機能するミリ秒の精度を使用します。

また、時間予測をチェックアウトすることもできます(つまり、サーバーと可能な限り密接に同期することを試みます)。

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