RTSに適したネットワーキングアプローチ/プラットフォームの選択についてサポートが必要

私はしばらくの間、オンラインの2D RTSのようなゲームを作ることについて考えていました。（1試合で2-6人のプレイヤー、最大50-60ユニット、AIなし）。ここで重要なのは、ブラウザでゲームをプレイできるようにすることです。そのため、両方ともTCPソケットを使用して、フラッシュまたはJavaアプレットにする必要があります。最初は、市場への浸透とアクセスのしやすさから、完全にフラッシュに集中していました。ただし、さまざまなネットワークアプローチを確認した後、私は選択をすることができません。

私は、サーバーとすべてのクライアントがまったく同じシミュレーションを実行しているロックステップシミュレーションアプローチが本当に好きでした。アクションスクリプトであること。これがJavaの出番です。Javaクライアントとサーバーを使用すると、シミュレーション関連のコードを共有できます。これにより、開発時間を半分に短縮できる可能性があります。

しかし、その後、別のアプローチがあります。クライアントは、できるだけ長くゲームの状態を正しくシミュレーション（または外挿）しようとしますが、正しく実行する必要はありません。ある時点で、完全な状態のスナップショットを受け取ります。適宜調整してください。Flashは再び実行可能なオプションのように見えますが、「調整」部分がないため、ロックステップシミュレーションははるかに簡単に思えます。

それで私の仮定は正しいですか？何を提案しますか？

私が知っているすべてのRTSは、ネットワークモデルにロックステップシミュレーションを使用しています。多かれ少なかれ同じ理由で：

ロックステップを使用すると、必要な帯域幅の量を大幅に削減する入力を交換するだけで済みます。内挿/外挿アプローチを使用する場合、送信する60ユニットx 6プレーヤー相当の状態x 6プレーヤー-ホストしている人には、多くのアップストリーム帯域幅が必要になります。

さらに、ロックステップを使用すると、RTSが公正で戦略的になるために非常に重要である、まったく同じことが起こることを全員が確認できることを保証します。外挿の場合、実際に失った新しいスナップショットを受け取ったときにのみ、戦闘に勝利していることが画面に表示されます。そして最悪のケースは、自分が敗北していることを知っていれば、その戦いに勝てる可能性があることです。

最後の利点の1つは、ローカルで行う日陰があると非同期になるため、ロックステップにより不正行為が難しくなります。自分のシミュレーションだけでなく、全員のシミュレーションをだます必要があります。