ゲーム アーキテクチャを設計する上で重要なのは、最初から効率性を考慮することです。メトリック、ログ記録、テレメトリ、収益化に早期に焦点を当てすぎると、ゲーム アーキテクチャが過度に肥大化する可能性があります。これらすべてを実行時にゲーム サーバーに詰め込むと、実際には投資収益率 (ROI) が低下し、総所有コストが増加する可能性があります。

代わりに、できるだけ早く、最小限の実行可能な製品 (MVP) から始めましょう。サーバーを実行し、クライアントを動作させ、ネットコードと マッチメーカー システムをロックインして、そこから構築します。また、 ホスティング プロバイダー を早めに確保することも検討してください。ホスティング プロバイダーは、開発時間を節約できる構築済みのソリューションとインフラストラクチャを提供している可能性があります。

ゲームデザインにおいて、シンプルとはどのようなものですか?上の画像は、ゲーム サーバー インスタンスだけでなく、マッチメーカー、ログ記録、メトリック実行可能ファイルなど、同じマシン上の多くの補助プロセスを含む複雑な設計を示しています。

この複雑さは、スケールテストを開始するまで必ずしも明らかになるわけではありません。スケールテストを開始すると、何千人ものプレイヤーがいる場合、これらのものがうまく連携しないことに気づき始める可能性があります。また、補助サービスにはリソース フェンシングがないため、マシン上のリソースが消費され、プレーヤーのパフォーマンスに影響を与える可能性があります。物事をシンプルに保つことで、これらの問題を軽減することができます。

ゲーム サーバーの設計に関して言えば、シンプルとは、単一の実行可能ファイルや回復力のあるマッチメーカー (マシンではなくバックエンド サービスでホストされる可能性があります) などのものを単一のサーバー インスタンスにまとめることです。こうすることで、ゲーム サーバーの 1 つが失われても、他のプレイヤーに影響が及ぶことはなく、影響を受けるエリアも小さくなります。大規模に運用する場合、この設計のゲーム サーバーが故障しても、プレイヤーのエクスペリエンスには影響しません。

コストリスクを最小限に抑えるには、デバッグ、ウォッチャー、マッチメイキングなどの補助プロセスを同じマシン上に保持しないでください。ゲーム サーバーがダウンし、そのサーバーがクラウド マシンに拡張されている状況では、補助プロセスが「ゾンビ化」したままになります。これらは依然としてリソースを消費しており、スタジオにコストがかかりますが、シャットダウンする方法はありません。

代わりに、マッチメイキングやデバッグなどの補助プロセスをゲーム サーバーのサブプロセスにすることを検討し、シンプルに保ちます。その後、ゲーム サーバーが失われた場合、サブプロセスはバックグラウンドで実行されたままにならず、ゲーム サーバーとともに失われます。この場合、サーバーが動作を停止した場合でも、「ゾンビ」プロセスに関連する余分なリソースやコストをかけずに、別のサーバーを起動できます。

長時間実行されるセッションのあるマルチプレイヤー ゲームでは、メモリ リーク、RAM 使用量の増加などの問題が発生する可能性がありますが、これらの問題はゲームを大規模に実行するまで現れない可能性があります。

長時間のゲームセッションに関連するリスクは次のとおりです。

• DDoS攻撃:永続的なゲームセッション モデルではゲーム インスタンスの IP が変更されないため、DDos 攻撃を受ける可能性があります。
• クラウドコストが高い:プレイヤーがゲームをプレイしていなくても、常に、またはほぼ常にアクティブなゲームを維持するには、多くのコストのかかるリソースが必要です。
• パッチ適用による中断:パッチ適用は管理が難しい場合があります。ゲームにパッチを適用するには、アクティブな試合を終了する必要があり、その結果、プレーヤーのエクスペリエンスが悪くなる可能性があるためです。

短いゲームセッションには依然としてリスクとプレイヤーのエクスペリエンスに関する考慮事項が存在します。たとえ 2 人用ゲームが 2 分だけだったとしても、数十万 (またはそれ以上) の同時対戦を実現するにはコストがかかり、リスクが生じる可能性があります。

短いゲームセッションに関する考慮事項は次のとおりです。

• バックエンドの負荷が高い:短いゲームセッションを容易にするためにバックエンドに API 呼び出しを継続的に行うと、大きな負荷がかかる可能性があるため、回復力が必要です。
• インフラへの負担：短いセッションの合間にサーバーが再起動すると、プロセスの読み込み開始時に CPU と RAM の使用率が急上昇することがあります。これはコストがかかる可能性があります。
• 強力なマッチメーカーが必要です:セッションが短い場合は、新しいセッションや再接続などのマッチメイキング チケットを処理する効果的なマッチメーカーが必要です。
• サービス品質 (QOS):物理的な場所ではなく、実際のテレメトリとデータに基づいてサーバーの地域を決定するには、ゲーム クライアントに IP アドレスのリストをリアルタイムで送信できるプロバイダーが必要になります。
• メトリックとテレメトリ データが必要です:何か問題が発生した場合、プレイヤーはエラーを報告するのではなく、終了して別のセッションを開始する可能性が高くなります。こうした短いセッションからメトリックとテレメトリを取得しないと、ゲーム内で問題が発生していることを見逃してしまう可能性があります。

短いセッションベースのゲームの長所と短所は次のとおりです。

長所

• 長時間実行時の安定化は不要
• より迅速なパッチ適用が可能
• スケールダウンの容易さ
• アイドル状態なし
• 各セッションのログファイルによりトラブルシューティングが容易になります

短所

• コールバックが増えると、負荷が大きくなる
• 再起動にかかるクラウドコンピューティングのコストは規模が大きくなると小さくない
• 競合状態
• 起動時にMEM/CPUが急上昇
• マッチメイキングの複雑さが増す
• マシンのパフォーマンスの問題は隠れている可能性がある

永続的なマルチプレイヤー ゲーム (MMO など) では、特定の問題やリスクが発生する可能性があります。たとえば、サーバー間でのプレイヤーの移行などの状況をサポートするには、高価なサーバーや強力なハードドライブを含む、より堅牢なバックエンド システムが必要になります。

永続的なゲーム セッションの設計に関する考慮事項を次に示します。

• 予算が懸念事項となる場合があります:永続的なセッションを実行するには、より堅牢なバックエンド システムが必要なので、ユーザー数に基づいてメンテナンス コストを計算し、これが適切なセッション設計であるかどうかを理解する必要があります。
• クラウドは実現可能ではない可能性があります:永続的なゲームセッションの需要が高いため、クラウドはプロジェクトにとってコストがかかりすぎる可能性があります。
• ネットワーク品質は非常に重要です。レイテンシとレイテンシ管理は、プレイヤーの永続的なゲーム セッションの成否を左右するため、ネットワークを早期かつ厳密にテストすることが、優れたプレイヤー エクスペリエンスを実現するために不可欠です。
• パッチ適用は困難かつ危険です:メンテナンス関連のダウンタイムは、全体的な体験を向上させるために必要であっても、プレイヤーにとって決して良い体験ではありません。メンテナンス時間についてコミュニティとコミュニケーションをとることが重要です。複数のゲーム バージョンを同時に実行し、時間の経過とともにパッチを配布することも検討してください。

永続的なセッションベースのゲームの長所と短所は次のとおりです。

長所

• サーバーは常に稼働しています
• ゲームループを短くすることが可能
• バックエンドの負荷を軽減

短所

• 設計がより困難
• 時間の経過による不安定さ
• セッションのクリーンアップ
• アイドル状態の設計が必要
• マッチメーカーを意識する必要がある
• A/Bパッチ適用には時間がかかる可能性がある

プレイヤーエクスペリエンスに問題が発生する可能性に備えて、大規模な準備をしておくことをお勧めします。マルチプレイヤー ゲームの起動、実行、更新は混乱を招く可能性があるため、「混乱耐性」について状況テストを実行し、ゲームのバックエンドがその混乱に対処できるように設定されていることを確認することが重要です。

たとえば、全員がゲームからクラッシュして、同時にマッチメイキングに戻ろうとするとどうなるでしょうか?そのような状況に対するバックエンドの対応を把握し、その問題に対処するように設定しておくと、長期的には頭痛の種を減らすことができます (また、評判を守ることにも役立ちます)。

起動時にゲームにパッチを適用する必要がある可能性があります。そのため、運用中および起動中にパッチを適用できるインフラストラクチャを構築することが重要です。これにより、発売日の混乱やオンザフライでのパッチ適用がはるかに迅速かつスムーズに行われ、プレイヤーへの影響も限定的になります。

これを解決する 1 つの方法は、ゲームの複数のバージョンを同時に実行することです。ただし、インフラストラクチャが複数のバージョンを処理できることも確認する必要があります。さらに、さまざまなバージョンをすべて備えたサンドボックスも必要になります。

複数のバージョンを同時に実行する機能がすでに組み込まれている場合は、パッチを適用してもダウンタイムやプレイヤーの中断は発生しません。

頻繁なスケールテストは重要なので、サービスを選択する際には、スケールテストを支援できるプロバイダーを見つけることが重要な考慮事項となるはずです。

スケール テストで重要なことの 1 つは、サーバーのテッセレーションとデフラグです。サーバーのテッセレーションはコストに関する重要な考慮事項です。基本的に、ホスティングにはまず安価な金属製のマシンを使用する必要があります。プレイヤーベースが変動するにつれて、よりコスト効率の高い、より高価なクラウド マシンを迅速に削除する必要も出てきます。

Game Server Hosting (Multiplay)、 コストの高いマシンへの割り当てを回避するため、プレイヤー数が減少したときに、より迅速にマシンを削除できます。

当社のシステムがこれを実行できるかどうかは、マッチの寿命によって異なります。マッチ期間が短くなると、コストのかかるマシンへの割り当てをより早く終了できるようになります。試合が長くなると、試合が終了するまでマシンをシャットダウンできなくなります。