回答:
さて、この本があります-これは少し古く、私は実際にそれを読んだことがありませんが、評判の良い出版社からです。新しいものも見つけましたが、今まで聞いたことがありません。どちらもMMO（または少なくともオンライン）ゲーム開発の問題をカバーすると主張しています。とは言うものの、クライアント側の予測は、同時プレーヤーベースの規模に関係なく、ほぼ同じであり、Googleにはそれに関する多くの情報があります。
実用的な観点から見ると、インディー/ホビーの開発者にとって、「大規模」と見なされるのに十分な理論的ピーク同時実行性を達成するのに十分なプレーヤーを獲得するのに十分人気のあるゲームをまとめることはかなり難しいことを理解することが重要です。しかし、この手法は研究にとって教育的である可能性があります。
実行できることには、主に2つの分類があります。
2番目の問題は、実際にはゲームデザインとソーシャルマニピュレーションの問題です。マルチプレイヤーゲームは自然にソーシャルであり、その魅力の一部であるため、プレイヤーのクラスターをあまり落胆させたくないので、特にトリッキーです。一方、世界中の誰もがゲームで最高の戦利品を落とす1人の男をスポーンキャンピングするゲームは、スケーリングが難しくなります。
最初のオプションとして、段階的なメッセージングを検討することができます。他のプレーヤーについては、ポジションなど常に知っておくべき重要なことがいくつかあります。しかし、ヘルスなどの他のことは、現在のプレーヤーがまだ見ることができないオブジェクトにとってはそれほど重要ではない可能性があるため、近くにある他のすべてのエンティティの相対距離に基づいてそのプレーヤーに送信するものをゲートします-これは基本的にスロットルです質問の最後の部分で述べたように、送信したデータとそれをフィルタリングします。
非常に大規模なマルチプレーヤーアーキテクチャでは、すぐにアクションを実行する必要がないレポートもバッファリングされます。サーバーに送信される文字保存メッセージはデルタで行うことができ、重要なポイントでのみ完全な更新が行われます。これらの更新はスロットルサーバーでバッファリングされ、実際に文字データを安定して保持するサーバーに送信されます。定期的な方法-プレーヤーのベースが拡大するにつれて、ディスクIOとネットワークトラフィックの最適化について心配する必要があります。キャラクターデータベースをスラッシュさせたくない。
パケットのレートとサイズは、MMO以外のゲームと同様に、ゲームによって大きく異なります。これは実際には非常に要件固有のものであり、一般化された標準はありません。
上記の回答に加えて、TCP_NODELAYとウィンドウスケーリングの動作方法を確認してください。TCPの詳細を理解し（そして、はい、順不同で到着する差分更新を処理する見通しが面白くない限り、UDPではなくTCPを使用したいと思います）、再送信は遅延制御にとって重要です。