テーブルホッケーである高速の物理ゲームをやっています。マレット2つとパック1つ。ゲームはiphone / ipadで実行され、GameCenterを介してマルチプレイヤーの部分を実行しています。
これがネットワークシステムの動作方法です。マッチにスターを付けるクライアントはサーバーとして解決され、マッチリクエストを受け入れるのはクライアントです。
「サーバー」は物理演算を実行しており、応答は即時であり、クライアントも物理演算を実行しているため、メッセージ交換間でスムーズに見えます。私がサーバーとしてしていることは、パック速度と位置をクライアントに送信し、クライアントがサーバーに関連するパック速度/位置を調整してサーバーを同期させることです。そうしないと、物理が非同期になり、ねじ込みます。
ネットワークレイテンシが良好な場合、100ミリ秒以下の結果はかなり良好です。クライアント側でスムーズにプレイできるゲームが得られ、奇妙な動作は最小限です。ラグが約150〜200ミリ秒のときに問題が発生します。その場合、私のクライアントパックはすでにエッジと逆方向にヒットしていますが、サーバーから遅延メッセージを受信し、少し後ろに戻ってボールの動作に奇妙な感覚を引き起こしています。
私はそれについていくつか読んだ：
だから、どうすればこれを解決できますか？私が持っている最良のオプションを読んだ限り、タイムスタンプを使用してサーバー/クライアントでクロック同期を行い、クロックに関連する遅延メッセージが表示された場合は無視して、クライアントのシミュレーションでジョブ。皆さんはそれに同意しますか？また、データを信頼できない（UDP）で送信しているため、メッセージが遅れたり、メッセージが乱れたりすることがあります。
それが最善のアプローチである場合、クロック同期をどのように実装しますか？手順を読みましたが、よくわかりませんでした。
それは言う：
- クライアントは現在の現地時間を「時間要求」パケットにスタンプし、サーバーに送信します。
- サーバーが受信すると、サーバーはサーバー時間にスタンプを付けて戻ります
- クライアントが受信すると、クライアントは送信時間から現在の時間を減算し、2で除算してレイテンシを計算します。サーバー時間から現在の時間を差し引いてクライアント/サーバー時間のデルタを決定し、待ち時間の半分を追加して正しいクロックデルタを取得します。（これまでのところ、このアルゴリズムはSNTPに非常に似ています）
- クライアントは、手順1〜3を5回以上繰り返し、そのたびに数秒停止します。他のトラフィックは暫定的に許可される可能性がありますが、最良の結果を得るために最小化する必要がありますパケット受信の結果は累積され、最小遅延から最大遅延の順にソートされます。待機時間の中央値は、この順序付きリストから中間点サンプルを選択することによって決定されます。
- 中央値からの標準偏差が約1を超えるすべてのサンプルは破棄され、残りのサンプルは算術平均を使用して平均化されます。
この例に従って、私はこれを持っています：
ゲームがロードされ、クライアントの時間が0になったふりをして、時間を0としてサーバーに送信します。
メッセージがサーバーに到達するまでに150ミリ秒かかりますが、サーバーのクロックは既に開始されており、クライアントより1秒進んでいます。サーバーがメッセージを受け取ると、時間は1.15になり、その時間をクライアントに送信します。ラグが150ミリ秒で一定であるとしましょう。
これで、クライアントは1.15の時間を受け取り、送信された時間から現在の時間を差し引き、レイテンシを計算するために2で割ります。Wichは、0.3-0 = 0.3 / 2-> 150msです。
サーバー時間から現在の時間を差し引いてクライアントサーバー時間のデルタを決定し、半分の待ち時間を追加して正しいクロックデルタを取得します。
クライアント時間：0.3サーバー時間1.15
0.3-1.15 = .85 +待ち時間（.15）= 1
それはどのように同期されますか？何が欠けていますか？
マルチプレイヤーとネットワークの経験が初めてなので、少し混乱しています。
ありがとうございました。