マルチプレイヤーゲームの開発者は、しばしばジレンマに直面します。
- 既存のゲームサーバー（ゲームが直接実行される）を使用してチャット機能を提供する
- 個別のサーバーを使用してチャット機能を実装する
最後に-それは単なるチャットですよね？ 小さなメッセージは、ユーザーからユーザー/小さなユーザーグループに送信されます。それだけです。 それでは、既存のサーバーに機能を追加するだけではどうですか？ 何がおかしいのでしょうか？
一見するとこのソリューションは良いように見えますが、それに関連していくつかの問題が発生する可能性があります。 以下では、ゲームサーバーとさまざまなソーシャル機能（特にチャット）を分離する必要がある理由について説明します。 この分離により、ゲームのパフォーマンスとスケーラビリティを向上させると同時に、新しい「ソーシャル」機能を簡単に追加し、将来的に機能を拡張できるようになります。
マイクロサービスはゲームをより管理しやすくします
マイクロサービス指向のアーキテクチャは、大規模なアプリケーション（この場合はゲーム）を小さなモジュラーサービスに分割します。このサービスは、互いに独立して変更でき、単純なパブリックAPIを介して相互作用します。 このアプローチにより、新しい機能の追加が容易になり、既存の機能がサポートされます。
ゲームサーバーをチャット機能から分離すると、アプリケーションインフラストラクチャ全体が管理しやすくなり、完全にマイクロサービス指向のアーキテクチャに近づきます。 ゲーム内のチャットと、ゲームの基本機能を提供するゲームサーバーとの「関係」を詳しく見てみましょう。
「モノリシック」アーキテクチャを使用する場合、開発チームは1つのテクノロジースタックに制限されます。これは、ゲームがすでに作成されたプログラミング言語、データベース、開発環境と同じものです。 チームへの新しいプログラマーの参加、または新しいテクノロジーの導入は、アーキテクチャへのマイクロサービスアプローチにより、はるかに簡単かつ迅速に実現されます。
また、モノリシックアーキテクチャでは依存関係がより顕著になります。 アプリケーションの唯一の機能が失敗すると、ゲーム全体が動作不能になる可能性があります。 ゲームをマイクロサービスに分割すると、単一のモジュールのバグを簡単に分離して修正できます。
ゲームサーバーの主な目的は（うまく機能している、または少なくともうまく機能しているはずです）、プレーヤーの動きと状態に関する情報を実際に同期してプレーヤーに送信することです。 これらの目標を達成するためにゲームサーバーで使用されるテクノロジは、チャットを実装するための最適なソリューションとは言えません。 既に述べたように、分離されたコンポーネントは、サポートと独立したスケーリングにおいてより便利です。
上の図は、チャットとゲームサーバーが互いに別々に存在するゲームのインフラストラクチャを示しています。
チャットに加えて、承認、統計、最高のプレイヤーに関する情報など、ゲームサーバーとは別に存在する他のサービスを追加することもできます。
シームレスなゲーム体験と効果的なチャットの提供
一般的にゲームのパフォーマンスは、マルチプレイヤーゲームにとって非常に重要な要素です。 ゲームの速度が遅いと、プレイヤーは必然的に失われます。 モノリシックアーキテクチャを使用すると、ゲームはテスト段階で優れたパフォーマンスを発揮できますが、戦闘状態では世界中に多数の本物のプレイヤーが散らばっており、チャット側と側方の両方からの情報のやり取りが大幅に遅れ、遅延が増加します実際にゲーム。
チャットとゲームのロジックを分離すると、プロセッサとネットワークリソースを最も効率的に使用できます。 ゲームサーバーの主な目的は、各プレーヤーに「シームレス」な（最小数の遅延/遅延を伴う）ゲームエクスペリエンスを提供することです。 したがって、最大のゲームパフォーマンスを実現するには、サーバーの計算能力を使用する必要があります。
たとえば、LoLやEVE Onlineなどのバトルアリーナゲームがあるとします。 1つのゲーム世界で数百人のプレイヤーを同時にプレイする機能を提供したいと考えています。 これらは、ゲームサーバーを介してリアルタイムで送信されるプレイヤーのすべてのアクションに関する情報を表す数千のメッセージです。 ここにチャットメッセージを追加します。 一部のプレーヤーは、ゲームサーバーの速度を特別に遅くするためにチャットでスパムする可能性があります（その肩には、ゲームの世界に関する情報の転送とチャットメッセージの送信の両方があります）。 もちろん、そのようなプレイヤーをキャッチして、たとえばチャットをブロックすることもできますが、これを行うには、ゲームサーバーで追加の計算を実行する必要があります。そのため、ゲームに使用できるリソースの一部を使い果たしてしまいます。
ゲームサーバーには、物理学、グラフィックス、サウンドに関連するさまざまな計算が既にロードされています。 プレイヤーからプレイヤー/グループ/チームへのメッセージ送信、それらの解析とルーティングの機能を追加すると、アプリケーションインフラストラクチャが徐々に複雑になり、ゲーム全体のパフォーマンスが低下します。
マルチプレイヤーゲームのチャネルとは別にチャットチャネルを起動しようとすると、チャットメッセージのルーティングの問題を解決する代わりに、複雑なゲームの仕組みを実装するために使用できる貴重な計算能力が失われます。
UDP対 TCP：両方が必要な場合と、1つで十分な場合
オンラインゲームを実装するためのUDPプロトコルとTCPプロトコルの選択に移りましょう。 特定の状況でどちらを選択するのが適切ですか？
動的なマルチプレイヤーゲーム（シューティングゲーム、MOBAなど）は、UDPプロトコルを使用してプレイヤーの動きを同期し、ゲームの状態を更新します。 UDPは、この情報の送信を非常に高速で交換するのに理想的ですが、メッセージの正しい配信と正しい順序での受信を保証するものではありません。
TCPはメッセージ配信を保証するため、チャットの実装に最適です。 ゲーム自体がUDPプロトコルを使用し、さまざまなソーシャル機能がTCPプロトコルを使用している場合、優れたパフォーマンスを実現できます。
高いダイナミクスを持たないゲーム（ターンベースの戦略など）では、TCPは信頼性が高いため、チャットとゲームロジックの両方を実装するのに適したオプションです。 もちろん、同時に、ゲームサーバーとチャットサーバーを分離する必要はなくなりません。 特に、ゲームが人気を博し、何千人ものプレイヤーが同時にプレイを開始したとき。
マルチプレイヤーゲーム自体の機能の許容遅延とソーシャル機能（チャットなど）の遅延を決定する基準は異なるため、遅延も注意が必要な要素です。 マルチプレイヤーゲーム（プレイヤー間でゲームの状態を同期し、あるプレイヤーに関する情報を別のプレイヤーに転送することを含む）では、遅延は20ミリ秒を超えてはなりません。一方、チャットアプリケーションでは、許容される遅延は250ミリ秒です。
したがって、標準が異なる2種類のリアルタイムメッセージングがあります。 それらが独立して動作する場合、関連する要件に基づいて、それぞれの実装を簡単に変更できます。
チャットの拡張性
チャットをスタンドアロンアプリケーションとしてサポートし、標準の業界プロトコル（XMPPやWebSocketsなど）を選択するか、リモートサービス（PubNubなど）を使用すると、新しいソーシャル機能を簡単に追加できます。
まず、チャットの基本機能を実装するだけで十分です（メッセージングに十分です）。 基本的なチャットインフラストラクチャを実装することで、後で拡張を開始でき、コードを少し追加するだけで、次のようなさまざまなチャット機能を簡単に追加できます。 ネットワーク上のユーザーの存在のインジケータ。 プレイヤーが通常チャットから期待する未読メッセージやその他の便利な機能のカウンター。
おわりに
大小のゲーム開発会社（Pocket GamesやEVE Onlineを含む）は、徐々にこのアーキテクチャに移行しています（または既に切り替えています）。 スケーラビリティと高いパフォーマンスで始まり、新しいテクノロジーを（1つのスタック内にロックすることなく）実装する自由で終わることから、チャットサーバーとゲームサーバーを分離することが利点です。