sockets - 基本的なクライアント サーバー同期

Question

簡単なことをしましょう。クライアントが描画するクラウドと、クラウドを移動するコマンドを送信するサーバーがあります。クライアント 1 が 60 fps で実行され、クライアント 2 が 30 fps で実行され、スムーズなクラウド移行が必要であると仮定します。

最初の問題 - サーバーはクライアントと異なる fps を持ち、ティックごとに移動コマンドを送信すると、コマンドのスパム送信がはるかに高速になり、クライアントが描画されます。

考えられる解決策 1 - クライアントは、フレームの終了後に「i want update」コマンドを送信します。

考えられる解決策 2 - サーバーはクラウドの移動コマンドを x ミリ秒ごとに送信しますが、クラウドはスムーズに移動しません。ソリューション 3 と組み合わせることができます。

考えられる解決策 3 - サーバーが送信 - 「速度 x でクラウドの移動を開始」および「クラウドを x に移動」ではなく「クラウドの方向を変更」。クライアント上で実際に描かれた雲。

また、クライアント 2 はクライアント 1 よりも 2 倍遅く描画しますが、これをどのように補正しますか?

基本的な方法で描画されたクライアントとサーバーロジックをどのように同期しますか?

Answer 1

解決策 3 は、それができれば、群を抜いて最良の方法のように思えます。他のすべてのソリューションはあまりにもおしゃべりです。クライアントとサーバーの間で非常に頻繁に通信する必要があり、サーバーとクライアントの間のネットワーク接続が非常に良好でない限り、あまりにも頻繁です。

雲の動きがすべてベクトルとしてクライアントに送信できるほど単純な場合、クライアントは、新しい指示 (新しい開始位置とベクトル）サーバーからの場合、間違いなくそうする必要があります。雲の動きが単純なベクトルとして簡単に表現できない場合は、より複雑なモデルを選択し (ベクトルを経時的に変換する命令を追加するなど)、モデルのパラメーターをクライアントに送信できます。

クラウドがより大きな世界の一部であり、クライアントが世界の時間を追跡する場合、サーバーから送信される各命令セットには、モデルの初期条件が有効である時間を表すタイムスタンプが含まれている必要があります。

クライアント 2 の描画がクライアント 1 の 2 倍遅いことを補う方法についての質問については、両方のクライアントで世界時計を一定の速度で刻む必要があります。このレートは、どちらのクライアントの画面リフレッシュ レートとも関係がある必要はありません。