オンデマンド ウェビナーでは、プリンシパル パートナー エンジニアの Aaron Moon が、サーバー アーキテクチャからスケール テストまで、マルチプレイヤー ゲームのローンチをマスターする方法について説明します。
または、以下を読んで、次の点について理解を深めてください。
ゲーム アーキテクチャを設計する上で重要なのは、最初から効率性を考慮することです。メトリック、ログ記録、テレメトリ、収益化に早期に焦点を当てすぎると、ゲーム アーキテクチャが過度に肥大化する可能性があります。これらすべてを実行時にゲーム サーバーに詰め込むと、実際には投資収益率 (ROI) が低下し、総所有コストが増加する可能性があります。
代わりに、できるだけ早く、最小限の実行可能な製品 (MVP) から始めましょう。サーバーを実行し、クライアントを動作させ、ネットコードと マッチメーカー システムをロックインして、そこから構築します。また、 ホスティング プロバイダー を早めに確保することも検討してください。ホスティング プロバイダーは、開発時間を節約できる構築済みのソリューションとインフラストラクチャを提供している可能性があります。
ゲームデザインにおいて、シンプルとはどのようなものですか?上の画像は、ゲーム サーバー インスタンスだけでなく、マッチメーカー、ログ記録、メトリック実行可能ファイルなど、同じマシン上の多くの補助プロセスを含む複雑な設計を示しています。
この複雑さは、スケールテストを開始するまで必ずしも明らかになるわけではありません。スケールテストを開始すると、何千人ものプレイヤーがいる場合、これらのものがうまく連携しないことに気づき始める可能性があります。また、補助サービスにはリソース フェンシングがないため、マシン上のリソースが消費され、プレーヤーのパフォーマンスに影響を与える可能性があります。物事をシンプルに保つことで、これらの問題を軽減することができます。
ゲーム サーバーの設計に関して言えば、シンプルとは、単一の実行可能ファイルや回復力のあるマッチメーカー (マシンではなくバックエンド サービスでホストされる可能性があります) などのものを単一のサーバー インスタンスにまとめることです。こうすることで、ゲーム サーバーの 1 つが失われても、他のプレイヤーに影響が及ぶことはなく、影響を受けるエリアも小さくなります。大規模に運用する場合、この設計のゲーム サーバーが故障しても、プレイヤーのエクスペリエンスには影響しません。
コストリスクを最小限に抑えるには、デバッグ、ウォッチャー、マッチメイキングなどの補助プロセスを同じマシン上に保持しないでください。ゲーム サーバーがダウンし、そのサーバーがクラウド マシンに拡張されている状況では、補助プロセスが「ゾンビ化」したままになります。これらは依然としてリソースを消費しており、スタジオにコストがかかりますが、シャットダウンする方法はありません。
代わりに、マッチメイキングやデバッグなどの補助プロセスをゲーム サーバーのサブプロセスにすることを検討し、シンプルに保ちます。その後、ゲーム サーバーが失われた場合、サブプロセスはバックグラウンドで実行されたままにならず、ゲーム サーバーとともに失われます。この場合、サーバーが動作を停止した場合でも、「ゾンビ」プロセスに関連する余分なリソースやコストをかけずに、別のサーバーを起動できます。
ゲーム ループがインフラストラクチャとどのように相互作用するか、インフラストラクチャがゲームをどのようにサポートするかを念頭に置いておくことをお勧めします。たとえば、ゲームにロビーとマッチメーカーがある場合は、ロビー内外でのマッチングや、それらのロビーからのセッションを行う理由が必要です。
どのようなセッション設計になっているか考えてみましょう。MMO のような永続的なゲームを構築しているのか、それともランタイムが毎回再起動する短いセッションのゲームを構築しているのか。各ゲーム ループの設計にはリスクとメリットが伴います。短い、長い、継続的なゲーム セッションを設計する際に考慮すべき重要な点をいくつか紹介します。
長時間実行されるセッションのあるマルチプレイヤー ゲームでは、メモリ リーク、RAM 使用量の増加などの問題が発生する可能性がありますが、これらの問題はゲームを大規模に実行するまで現れない可能性があります。
長時間のゲームセッションに関連するリスクは次のとおりです。
短いゲームセッションには依然としてリスクとプレイヤーのエクスペリエンスに関する考慮事項が存在します。たとえ 2 人用ゲームが 2 分だけだったとしても、数十万 (またはそれ以上) の同時対戦を実現するにはコストがかかり、リスクが生じる可能性があります。
短いゲームセッションに関する考慮事項は次のとおりです。
短いセッションベースのゲームの長所と短所は次のとおりです。
長所
短所
永続的なマルチプレイヤー ゲーム (MMO など) では、特定の問題やリスクが発生する可能性があります。たとえば、サーバー間でのプレイヤーの移行などの状況をサポートするには、高価なサーバーや強力なハードドライブを含む、より堅牢なバックエンド システムが必要になります。
永続的なゲーム セッションの設計に関する考慮事項を次に示します。
永続的なセッションベースのゲームの長所と短所は次のとおりです。
長所
短所
プレイヤーエクスペリエンスに問題が発生する可能性に備えて、大規模な準備をしておくことをお勧めします。マルチプレイヤー ゲームの起動、実行、更新は混乱を招く可能性があるため、「混乱耐性」について状況テストを実行し、ゲームのバックエンドがその混乱に対処できるように設定されていることを確認することが重要です。
たとえば、全員がゲームからクラッシュして、同時にマッチメイキングに戻ろうとするとどうなるでしょうか?そのような状況に対するバックエンドの対応を把握し、その問題に対処するように設定しておくと、長期的には頭痛の種を減らすことができます (また、評判を守ることにも役立ちます)。
起動時にゲームにパッチを適用する必要がある可能性があります。そのため、運用中および起動中にパッチを適用できるインフラストラクチャを構築することが重要です。これにより、発売日の混乱やオンザフライでのパッチ適用がはるかに迅速かつスムーズに行われ、プレイヤーへの影響も限定的になります。
これを解決する 1 つの方法は、ゲームの複数のバージョンを同時に実行することです。ただし、インフラストラクチャが複数のバージョンを処理できることも確認する必要があります。さらに、さまざまなバージョンをすべて備えたサンドボックスも必要になります。
複数のバージョンを同時に実行する機能がすでに組み込まれている場合は、パッチを適用してもダウンタイムやプレイヤーの中断は発生しません。
頻繁なスケールテストは重要なので、サービスを選択する際には、スケールテストを支援できるプロバイダーを見つけることが重要な考慮事項となるはずです。
スケール テストで重要なことの 1 つは、サーバーのテッセレーションとデフラグです。サーバーのテッセレーションはコストに関する重要な考慮事項です。基本的に、ホスティングにはまず安価な金属製のマシンを使用する必要があります。プレイヤーベースが変動するにつれて、よりコスト効率の高い、より高価なクラウド マシンを迅速に削除する必要も出てきます。
Game Server Hosting (Multiplay)、 コストの高いマシンへの割り当てを回避するため、プレイヤー数が減少したときに、より迅速にマシンを削除できます。
当社のシステムがこれを実行できるかどうかは、マッチの寿命によって異なります。マッチ期間が短くなると、コストのかかるマシンへの割り当てをより早く終了できるようになります。試合が長くなると、試合が終了するまでマシンをシャットダウンできなくなります。
次のマルチプレイヤー ゲームを構築する準備はできていますか?始めるにあたって役立つリソースをいくつかご紹介します。 Game Server Hostingによるスケーリングの詳細、Game Server Hostingと Matchmaker に関する オンデマンド ウェビナー 、以下で提供するマルチプレイヤー ソリューションをご覧ください。
