小規模な協力型マルチプレイヤーゲームの開発における 8 つの要素：『Breakwaters』の場合

マルチプレイヤーゲームでは、専門的な知識、ホスティングやプレイヤーとのコミュニケーションサービスなどの継続的なサービス、メンテナンスコストなど、開発に先立つ作業が必要になります。 

この記事の残りの部分では、マルチプレイヤーゲームを構築する際に考慮しなければならないマルチプレイヤーゲーム開発の 8 つの要素を取り上げ、それらが小規模な協力型ゲームにどのように適用されるかを説明します。. さらに、Soaring Pixels Games 社の Phillip Heckinger 氏に、近日発売予定のタイトル『Breakwaters』について、同社がゲーム開発において取った手法について、どうして、どのようにしてそれを選んだのかを伺いました。

ゲームタイトルを発展させるためのマルチプレイヤー向けネットワークソリューションを選択または開発する際に考慮すべき、8 つの重要な要素があります。 

• レイテンシ：ゲーム内で許容できるレイテンシの長さ
• セッションあたりのプレイヤー数：各ゲームセッションでのネットワーク接続プレイヤーの数
• 同期するシミュレーションの規模：接続したプレイヤー間で同期した状態を維持することを選んだシミュレーションの量
• 精度：共有された体験で要求される正確性
• 費用：ゲームの制作、維持、運営にかかる費用
• 複雑さ：ネットワークソリューションの複雑さと、それを上手く実装するためにチームにどれだけの経験を要求するか
• チート緩和：プレイヤーのチート行為を防止しようとすることがどの程度重要なのか
• ロックイン：将来の変更が困難なソリューションであるかどうか

この 8 つの要素と、それぞれのネットワークモデルがサポートできることを考えることで、どのモデルを使うべきかが絞られてきて、開発のプロセスを始めることができます。

サンプルゲームの「Boss Room」は、理想的な例です。プレイヤーやシミュレーションの規模が小さく、協力型かつクライアントホストのゲームです。 

Boss Room での各要素について評価した結果は以下の通りです。

• レイテンシ：最大 200ms のレイテンシが許容されます（リレーサービスのホップを含む）
• セッションあたりのプレイヤー数：最新の PC で動作するクライアントホストの場合、10 人を目標とする
• 同期するシミュレーションの規模：すべてのプレイヤーと AI のトランスフォーム、アニメーション、行動
• 精度：カジュアルな戦闘の仕組みのため、中程度
• 費用：制作と維持については無料、ライブ運営時に使用するリレーサービスについては低費用
• 複雑さ：マルチプレイヤー開発の原則を経験の浅い開発者に教育できるように、複雑さを抑える必要がある
• チート緩和：協力型のコンセプトに焦点を当てており、チートをしても明確なプレイヤーの利益にはならないため、懸念事項ではない
• ロックイン：いつかサンプルを進化させて、専用サーバーでどのように運用するかを示したい

これらの要素を考慮してどのようにサンプルゲームを作っていくか決めていった過程については、こちらのブログで詳しく紹介しています。

小規模な協力型ゲームには、他のゲームとは異なるニーズがあることを念頭に置いておく必要があります。たとえば、『オーバークック』を開発した Team17 は、当初はピアツーピアモデルを採用していましたが、開発中に代わりに専用サーバーを使用するように変更しました。

これはこの作品のローンチ時に想定される需要と総プレイヤー数の規模に対応するためです。 

では、自分のゲームに適したモデルを知るにはどうすればいいのでしょうか。今回は、Soaring Pixels Games のオーナーである Phillip Heckinger 氏に、小規模な協力型ゲームタイトルを開発するにあたり、ネットワークについてどのようなアプローチを取ったのかを伺いました。

『Breakwaters』は、現在アーリーアクセス中のアクションアドベンチャーゲームで、海の世界を舞台に、プレイヤーが建築、工作、そしてサバイバルに励むという内容になっています。『Breakwaters』のモデルを選択するにあたり、8つの要素がどのように影響したのか、Soaring Pixel Gamesに聞いてみました。

1 セッションあたりのプレイヤー数

本作には、オンライン協力モードが搭載されており、友人同士で協力して波の打ち寄せる海岸で作業したり、同時に接続された 4 人のプレイヤーのグループで巨人を倒したりすることができます。Soaring Pixels では、プレイヤーが心地よいと感じる人数を探りつつ、1 セッションあたりの人数を増やすことを検討しています。 

複雑さ

『Breakwaters』は、水のシミュレーションシステムが要求される野心的なゲームです。スムーズなゲームプレイを維持し、シングルプレイヤーのロード時間を短くするために、Soaring Pixels Games はシミュレーションを異なる抽象度のレイヤーに分けてゲームを構築しました。 

同社は、空間的な関連性と距離に基づくアクティベーションをシングルプレイヤーのために利用し、また、これらのシステムはマルチプレイヤー用に拡張することもできました。シミュレーション、レンダリング、人工知能は、それぞれ独立したシステムで処理されています。このような設計にしたことが、Soaring Pixel Games にとってシングルプレイヤーでのプレイヤーのパフォーマンスを向上させるための最適化に役立っただけでなく、マルチプレイヤーでプレイヤーにシミュレーションや権限をより簡単に分散させることができるようになる効果ももたらしました。 

精度

『Breakwaters』は PhysX をベースに構築された疑似決定論的なカスタム物理エンジンを使用しており、チームは決定論をある一定の精度でロックすることにしました。このゲームのシステムの大部分は、世界のどこに何があるのかを大まかに知っているだけで、ヒューリスティックな情報を得ることができます。これは、遅延評価によって、イベントやプレイヤーのアクションに関連して、更新が必要なものを素早く特定できるからです。

多くの場合、回転の値はシステムのシミュレーション操作にとって重要ではありません。さらに精度が必要な場合は、更新頻度を上げて精度を高めるシステムになっています。 

チート緩和

Heckinger 氏によると、このゲームは協力してプレイするように設計されているため、チート緩和は現在のところ優先事項ではないとのことです。このことは、シミュレーションの同期を管理する権限を誰に持たせるかなど他の要素についての対応にも柔軟性を与えます。

「私たちは対戦プレイそのものを心配しているわけではありません。ただ、ゲームが大きくなっていけば将来的に対処することにはなるでしょう。私たちはみんながゲームを楽しんでくれることに関心があります。そのためにプレイヤー自身がちょっとしたチートをしたいということであれば、これはプレイヤーのゲームですので、どうぞご自由にお楽しみくださいという姿勢です」と Heckinger 氏は付け加えました。

同期したシミュレーションのスケール

広大なワールドを持つゲームでは、プレイヤーがマップ上のどこにいるかに応じて、たくさんのものを複数のシステムから起動させなければならなくことがあります。プレイヤーは信頼できるクライアント機関であり、複数のプレイヤーが世界全体の所有権を共有するマルチプレイヤーゲームが立ち上がっています。Soaring Pixel Games がこれを実現できた秘訣は、シングルプレイヤー用のゲームアーキテクチャの設計方針にありました。 

Heckinger 氏いわく、「私たちが考えていたネットワークの問題の多くは、ゲームの設計上、シングルプレイヤーを作った段階ですでに解決されていました」。

洗練された Level Of Detail と空間的関連性のシステムにより、チームはマルチプレイヤーを作る時に、シミュレーションに重要なものやプレイヤーのゲームプレイエリアに直接影響を与えるものを決定することができました。 

このアプローチによって、すべてのものがネットワークコンポーネントを必要とするわけではないので、自分の世界のシミュレーションからネットワークコンポーネントを必要とするものを切り出す、ということが可能になりました。オブジェクトは独立したネットワークエンティティではないので、関心のあるオブジェクトのうちネットワークコンポーネントを持たないものは、代わりにアドレス指定可能なネットワークコンポーネントを持つシステムに登録されるかもしれません。これらのコンポーネントは、共有されたシミュレーション全体で関心のあるオブジェクトにマッピングすることができ、シミュレーション全体の同期を取りすぎないようにすることができます。 

レイテンシの許容度

『Breakwaters』は、低レイテンシでの細かく小さな入力に頼らないゲームスタイルを採用しています。また、Soaring Pixel Games はクライアントに権限を託すことにしたので、このゲームのシステムの多くは、状態変更許可のためのネットワークメッセージ（リモートプロシージャコール）を必要とせずに、クライアントサイドでの状態変更を可能にしています。 

Heckinger 氏いわく、「私たちのゲームのインタラクションは、他のスタイルのゲームよりも大きなレイテンシを許容します」。

さらに、ゲーム作りの経験とノウハウを持つ Soaring Pixel Games のエンジニアは、伝送に適したデータサイズの分割方法を最適化し、必要に応じてイベントに「OK」のマークを付け、最大で 0.5 秒遅らせることができるシステムを構築することができました。Soaring Pixels Games の哲学は、プレイヤーが最適ではないことを選択した場合、最適ではない結果が生じる可能性があることを、プレイヤーも理解するだろう、というものです。 

同社は、プレイヤーが現実世界のどこにいても互いに接続できるが、その距離のためにレイテンシが大きい常態でのプレイが発生する可能性を許容する選択をしました。プレイヤーが 1 か所で 1,000 本の木を切り倒してドロップを得ることも止めようとしません。Phillip は、レイテンシやマルチプレイヤーのゲームプレイの最適化には、専用のホスティングソリューションが適していることを認めており、これが次の要素につながります。

費用

Soaring Pixels Games は、予算と費用の観点から、クライアントがホストするリスンサーバーは、同社のチームが最初に導入できる最も費用に対する効率の高いオプションであると考えました。チームが好む要素の多くは、クライアントがホストするリスンサーバーでもカバーできるにもかかわらず、チームは専用サーバーの使用を希望していました。最終的には、ビジネスと費用が大きな決め手となりました。

Heckinger 氏は、「もし高額な料金の請求さえなければ、私たちはサーバーホスト型のソリューションを使用するでしょう」と語っています。「私たちのソリューションにとって、サーバーホスト型のソリューションが費用面で効率の良い方法だとは思いません。しかし、将来的には、ユーザーが自分のサーバーをホストできる機能を提供し、より世界に密着した体験ができるようにしたいと考えています」。

ロックイン

数ある要素の中でも、Soaring Pixel Games が最も重視していたのがロックインでした。Heckinger 氏は、チームもよく自問自答していたと述べています。「1 つのシステムに依存しないために、最もリーズナブルな方法は何か」と。

『Breakwaters』チームでは複数の異なるプラットフォーム向けにリリースする必要があり、それぞれのプラットフォームにさまざまな異なる要件があることを認識していました。チームにとって重要だったのは、異なるサービスやスタック間でゲームコードをより簡単に移植できるように、抽象化やラップができるような簡単な統合ポイントを持つソリューションを見つけることでした。

1 つのソリューションに固執するのではなく、クライアントサイドとホスト・サーバーサイドの両方を C# で抽象化した独自のカスタムネットコードレイヤーを構築することにしたのです。 

決断

ロックインを避け、その他の要素を考慮した結果、Soaring Pixels Games は、クライアント・サーバー型のネットワークモデルを使用する方向に強く傾きました。特に、ベースとなるゲームアーキテクチャにクライアント・サーバーと同様のパターンを構築していたことから、クライアント・サーバー型のネットワークモデルを使用することになりました。チームは、リスンサーバーと呼ぶクライアント・サーバー型のネットワークモデルを採用しました。これはプレイヤーの 1 人をセッションのホストとしつつ、プレイヤーが共有されたシミュレーションの異なる部分で権限を共有できるようにしたものです。 

このモデルを採用しておけば、ビジネス上のニーズに応じて、将来のどこかでホスティングやサーバー機能を専用サーバーに移行することも可能です。これにより、ゲーム開発の柔軟性を維持しつつ、ゲームの成功度合いやプレイヤーのニーズに応じてサーバーモデルを後から変更することができます。 

皆さんのゲームの要件は、『Breakwaters』と一致するでしょうか。リスンサーバー型のクライアント・サーバー型ソリューションを検討することは、皆さんにとって正しい道かもしれません。 

小規模な協力型ゲームを開発しているなら、Netcode for GameObjects でゲームをネットワーク化し、Relay と Lobby を使ってプレイヤー同士をつなぐ方法をご検討ください。

Netcode for GameObjects 

Unity の新しいファーストパーティネットコードソリューションである Netcode for GameObjects は、『Breakwaters』のような、クライアントがホストとなる協力型ゲームの開発に置いて合理的なソリューションを提供することに重点を置いています。ここで対象としているゲームは、200ms 程度までのレイテンシに寛容で、不正行為にそれほど厳しくなく、適度な速度でのインタラクション・ゲームの傾向があるものです。 

*他の種類のゲームを開発しようとしている場合も、コードベースがオープンソースかつ MIT ライセンスで配布されているので、GitHub から直接アクセスして修正して使うことができます。

Relay

小規模な協力型ゲームでプレイヤーをつなぐためには、費用対効果が高く、安全性の高いリレーサービスが適しています。Unity の新しい Relay サービス のオープンベータが開始されました。これにより、費用のかかる専用のゲームサーバーがなくても、プレイヤー同士をつないで素晴らしいマルチプレイヤーゲーム体験を提供することができます。 

Lobby

皆さんが小規模な協力ゲームを作る時、どのようにしてプレイヤー同士をつなぎ、参加したゲームセッションを共有すればよいでしょうか。現在オープンベータ版が提供されている Unity の新しい Lobby サービスがぴったりかもしれません。Lobbyᴮᴱᵀᴬ は、プレイヤーが簡単なゲーム属性を使って、他のプレイヤーが検索して見つけ、参加することができる公開のロビーを作れるようにします。また、招待制のロビーを作って、特定の参加者だけが参加できるプライベートな空間を作ることもできます。

マルチプレイヤーゲームのコンセプトによって、開発や運用を成功させるために必要なもの（利用可能なソリューション）は異なります。今後、各要素についてさらに詳しく掘り下げる記事や、ゲームの種類によってどのように各要素を調整すればよいかを解説する記事を公開する予定ですので、今後ブログで公開されるコンテンツにもご期待ください。 

『Breakwaters』に関心を抱かれた方は、Steam で 11 月に早期アクセスが開始されますので、チェックしてみてください。