あなたは多くの方法でそれを行うことができます、そしてすべてはあなたがすでに見つけたような欠点を持っています。それを行うための「最良の」方法はないと思います。
ゲームの一般的な方法は、「ゲームサーバー」を用意することです。サーバーはすべてのクライアントからの入力を受け取り、結果の状態を決定します。
たとえば、クライアントはキーを押すだけで送信でき、サーバーは自分の場所と描画する必要のある他のクライアントの場所を通知します。クライアントはローカルで同じ計算を行い、サーバーからの確認を待っている間、この状態を表示します。しかし、それは単なる予測です。
遅れると、実際のサーバーが位置を計算し、予測が同期しなくなったため、多くのゲームで位置間をジャンプしているのを観察できます。
サーバー側の状態決定のもう1つの利点は、クライアントがそれを簡単にだますことができないことです。すべてのチートを防ぐための絶対確実な方法ではありません。たとえば、照準ボットは、マウスを動かして完全に照準を合わせているユーザーをシミュレートするだけで、基本的には検出できません。一方、マップハック/ウォールハック(見えないものを見ることができるもの)は、現在見えないものについてクライアントに通知しないことで防ぐことができます。サーバーだけが完全な状態を知る必要があります。
サーバーアプローチは、専用ゲームサーバーなしでも使用できます。代わりに、クライアントの1つがサーバーの役割を持ち、ゲームの状態を決定します。一部のゲームでは、元のホストが脱落した場合でも、その責任がクライアント間で切り替わる可能性があります。ただし、それが発生した場合のスムーズなハンドオーバーはかなり注意が必要です。
サーバーがなく、すべてのクライアントが同等の責任を負っている場合は、どのクライアントがどのアクションの検証を担当するかを定義するスキーマについて考える必要があります。たとえば、シューティングゲームでは、Aは特定の方向にシュートし、Bはまだそこにあると思いますが、Bはもう少し進んでいるので、Aは「Bがヒットした」と考え、Bは「ショットが失敗した」と考えます->1回のシュートまたは打たれた人が何が起こるかを決める必要があります。
複数の意思決定者がいるスキーマは、すべてのゲームで機能するとは限らず、非常に複雑なタスクです。ゲームだけでなく、分散コンピューティング全般
JavaとSocketsはここでは単なるツールです。実際の問題は、ペンと紙を使って、シナリオに適したスキーマについて考える必要があるということです。
ミリ秒ごとの座標について:「私は時間ZでポイントX、Yにいます」などのメッセージを送信することもでき、他のクライアントがそのプレーヤーのパスを補間するため、すべての位置を送信する必要はありません。