socket.ioを使用して、他のMMORPGと同様の通信、つまりメッセージとの安定した接続があります。
これまでの私の設計では、クライアントはすべての更新フレームでプレーヤーの位置とアニメーションフレームを送信します。サーバーはそのメッセージを受信すると、すべてのクライアントにブロードキャストし、それに応じてグラフィックを移動します。
これらを「収集」して、たとえば1秒の1/10に1回放送するほうがよいでしょうか。
また、クライアントは、発生と同時に多くの異なるメッセージ（exp得、アイテムをクリック）を送信するのか、それとも1つだけ収集するのか？最初の方が簡単に実装できます。
回答:
高レベルの議論からこれに取り組み、あなたの質問に取り組みます。開示のために、私はsocket.ioを使用した個人的な経験はありませんが、MMORPGに関して問題の領域に多くの露出があります。
MMORPGエンジンのネットワークアーキテクチャの設計や、機能を提供するためのミドルウェアプロジェクトまたはオープンソースプロジェクトの選択は、チームのゲーム設計、予算、および技術的専門知識に影響される、より困難な決定の1つです。最終的な選択は、他のアーキテクチャ上の決定（および場合によっては設計上の決定）にも影響を与えます。
MMORPGの開発者として、私たちは大きな数が警告灯やサイレンをトリガーする大きな成功（破局的な成功とも呼ばれます）を計画しています。出現する恐ろしい大きな数字の1つは、N乗（以下、N ^ 2）であるアルゴリズムにあります。あなたの質問で私に飛びついた最初のことは、情報をブロードキャストするエンティティを要求するデザインのように聞こえるということです。他のすべての接続されたエンティティ。これはN ^ 2問題の典型的な例です。
MMOは一般に、いくつかの異なる方法で問題を攻撃することにより、N ^ 2の問題に対処します。エンティティが他のすべてのエンティティの一部のサブセットを認識し、プレーヤーをさまざまな「シャード」にパーティション化し、「ゾーン」内でプレーヤーをパーティション化し、インスタンス化する、意識システム（状況、空間など）。プレイヤーが一緒に集まること（Asheron Callのテレポートストーム）など
ほとんどのMMORPGと多くのFPSエンジンには、次のようなさまざまな機能をサポートするかなり高度なネットワークアーキテクチャがあります。
アンリアルネットワーキングのドキュメントとバルブネットワーキングのドキュメントは、さまざまな問題の優れた入門書を提供していることがわかりました。
それでは、質問に取り組みましょう。
これらを「収集」して、たとえば1秒の1/10に1回放送するほうがよいでしょうか。
ここで単純な「はい」または「いいえ」の答えを提供することは困難です。これは、スケール（監視エンティティの数）、更新の頻度、および更新のサイズに依存するためです。たとえば、更新のサイズによってバッファがどこかで破壊される可能性がある場合、それらすべてを収集することは恐ろしく間違っている可能性があります。
MMORPGとFPSゲームのクライアントは、「通常」よりも多くの更新フレームの更新を受信しなくても、「見た目」が正しいものを視覚化するように設計されています。信頼性の低い通信（UDP）を使用すると、いくつかの更新がvoidに失われることが予想され、クライアントは、信頼できるトランスポートで使用されるよりも頻繁な更新を送信することでこれを補うことができます。
socket.ioのドキュメントをざっと見たところ、信頼できる通信経路と信頼できない通信経路（その用語では揮発性）の両方がサポートされているようです。
私はこれに最初に取り組み、どの頻度で更新が必要かを考えます...
プレーヤーが一定の速度で直線的に移動している場合、観測クライアントはプレーヤーがいつどこにいるかを高精度で予測できるため、更新頻度を低くしても問題ありません。プレーヤーが狭い円を曲がったり、方向をすばやく変えたりしているときは、さらに頻繁な更新が必要になります。逆に、プレイヤーがまったく動いていない場合、動きの更新をまったく送信する必要はありません。
何があっても、クライアントからサーバーにすべてのフレームの更新を送信する必要はおそらくありません（通常）。サーバー自体は、メッセージがあるフレームごとにメッセージを送信するか、メッセージを遅延させるかを選択できます（帯域幅のシェーピング、優先順位付け、更新の有効期間を参照）。
他のタイプの更新には異なる特徴があります...たとえば、プレーヤーまたはクリーチャーが損傷したときに変更される「健康」フィールドを考えてみてください。これを実装する1つの方法は、各変更が発生するとすぐにブロードキャストすることですが、フレームまたは連続するフレームで値が複数回変更されると、処理と帯域幅を浪費します（帯域幅シェーピングを実装するネットワークアーキテクチャは、更新を結合することでこの問題を解決します使用可能な帯域幅がある場合、最新のものだけが監視クライアントに送信されます。
クライアントは、メッセージが発生したらすぐに多くの異なるメッセージ（exp得、アイテムをクリック）を送信するのか、それとも収集したメッセージを1つだけ送信するのか？
ここでも、単純な「はい」または「いいえ」の答えはここでは機能しません。収集によって正確に何を意味するかに応じて...どちらも異なる状況下で正しく、ネットワーク層の実装にも依存します。
1つのメッセージとして送信できる特定のエンティティのメッセージを収集すると（実装に応じて）、メッセージを送信するための帯域幅オーバーヘッドを削減（コストを削減）逆に（実装によっては、文字列によって通信されるフィールド/値のマッピングなど）帯域幅を増やすことができますより単純な特定のメッセージタイプと比較した要件。
socket.ioのドキュメントを確認すると、メッセージのオーバーヘッドはスペクトルの上限にあるように見えます。これは、単一の更新の多くではなく、更新を収集して集約メッセージとして送信するのに適しています。
たとえば、ほとんどのMMORPGとFPSは、気づいたオブジェクトの状態が変化しない限り、プレーヤーがクリックしたXイベントを監視しているクライアントに送信する必要はありません。 。
実際の例を次に示します。RuneScapeは、 0.6秒ごとに1回「ティック」します。あなたはそれについてここで読むことができます。彼らのスクリプトではおそらくミリ秒ではなくティックでタイミングと遅延を指定しているので、それは彼らの観点から物事を単純化すると思います。そしてもちろん、ティックレートがこのように大きい/遅い場合でも、接続が遅いユーザーは他のプレイヤーと比べて大きな不利にはなりません。
作業の1つの方法は、実際のデータ変更をそれらの変更のブロードキャストから切り離すことです。オブジェクトが変更されたら、変更を加えて「ダーティ」フラグを設定します。変更をブロードキャストするときは、フラグが設定されたオブジェクトのデータのみを送信し、フラグをクリアします。更新はブロードキャスト時の状態のみを送信するため、複数回変更される値はここで自動的にマージされます。サブオブジェクトまたは個々のプロパティにフラグを付けて、変更されたものだけをブロードキャストすることもできます。
ああ、そして通常、アニメーションフレームをサーバーや他のクライアントに送信することはありません。正確なアニメーションの状態は通常、プレゼンテーションの詳細と見なされ、解決するために各クライアントに残されます。代わりに、各クライアントが現在再生中のアニメーションを認識していることを確認するだけです。