Unity を検索

Unity のマルチプレイヤー Netcode の移行ガイド

2019年6月13日 カテゴリ: ゲーム | 7 分 で読めます
取り上げているトピック
シェア

Is this article helpful for you?

Thank you for your feedback!

このブログは 2020 年 4 月 27 日に更新されました。

多くの皆様はすでにご承知のことと存じますが、Unity は新しいコネクティッドゲームスタックにより大きな将来性があると判断したため、UNet はメンテナンスモードになりました。この発表を行って以来、多くの開発者の皆様より、移行期間中のゲームの扱いに関するガイダンスをご希望される声が寄せられました。本記事では、ネットワーキングスタックに関する重要な決定を皆様それぞれに行っていただけるように、皆様にご確認いただく必要のある主な質問事項をまとめたガイドをお届けします。

下のフローチャートの下部に、「UNet をそのまま使い続ける」から「新しい DOTS ベースの Netcode(効率性の高い高水準 Netcode)および Unity Transport Package(低水準ネットワーキングスタック)の使用に切り替える」まで、多数の選択肢が用意されています。皆様のゲームの独自のニーズに合わせて最終的な選択を行ってください。以下、それぞれの質問(確認事項)について、その考え方も含めてご説明します。

スケール

マルチプレイヤーゲームの「スケール」(規模)と言うと、最も一般的には、単一のセッションにおけるプレイヤーの最大人数、あるいは単一のサーバーに接続されたプレイヤーの最大人数のことを指します。この場合、ピアツーピア(P2P)トポロジーでは一度に 24 人を超えるプレイヤーを同期しようとすると問題が生じることが多いため、25 人以上のプレイヤーに対応するセッションに関しては、専用ゲームサーバー(DGS)トポロジーへの移行が推奨されます。

これを大幅に超える数になると、DGS であっても、サーバーランタイムの性能とスケーラビリティが影響してきます。例えば『FPS Sample』 はクラシックな Unity の「ヘッドレスな」サーバーランタイムを使用しています。Unity では、そのサンプル Netcode を使用して、最大 80 のコネクティッドゲームクライアントを同期する性能のテストを行いました(2020 年 4 月追記:このサンプルでは最新の Transport が使われていませんので、ゲームに使用される場合は、最新のライブラリをプルしてください)。しかし、この Unity「ヘッドレス」ランタイムは、Unity の将来的な DOTS サーバーランタイムよりも効率性とスケーラビリティが低く、これを大幅に超えるプレイヤー数にまでサーバーをスケールするのは恐らく困難です。各セッションのプレイヤー数が 80 を超える場合は、新しい DOTS-Netcode と Unity Transport Package(UTP)のアーリーアダプターになられるか、独自スタックの開発を検討していただく必要があります。

また追記として、スケールはネットワーク接続されたオブジェクトや AI(非プレイヤーキャラクター)の数でも測ることができます。したがって例えば 500 個以上のオブジェクトや AI の同期が必要なワールドの場合も、恐らく新しい DOTS-Netcode および UTP への移行が必要となり、新しいステートレスな物理システムによって決定論的シミュレーションを可能にすることをご検討されることになるでしょう。

チート

ゲームに関して次に確認すべき事項は、チートの可能性です。一般的に、ゲームが人気になればなるほど、ゲームのクライアントがハックされて不正なアドバンテージが提供される可能性が高くなります。チートは、直接のプレイヤー対プレイヤー(PvP)のゲームだけではなく、例えば以下のような仕組みを導入したゲームなどにも起こり得ます。

  • ペイゲート ― プレイヤーがパスやアイテムを購入するまでコンテンツへのアクセスを制限する
  • リーダーボード/トーナメント ― チートのインセンティブとなる間接的な競争
  • 名誉となるアイテム/レアなアイテム ― 獲得しにくいアイテム

公開コンサートなどの体験にはチートのインセンティブがないため通常は不正が起こりません。しかし、人気の出たゲームの多くが、開発者の予想を遥かに超えたチート問題に悩んでいます。

クライアントのハックやチートが発生する場合の最善の策は、「サーバー権威」を使ってそれを完全に防止することです。サーバー権威を使用した場合、「誰が死んだ」「誰が勝った」「どの戦利品が獲得された」などがサーバーコードによって決定されるので、ゲームクライアントがハックされてもその最悪の影響が他のプレイヤーに及びません。最も問題となりやすいデータがサーバーによって決定されるためです。

一方 P2P トポロジーでは、ゲームクライアントがデータへの権威を持つので、開発者に取れる対策は、データをクラウドに送信し、それに対してルールを適用してチートを検知し、チートを行ったプレイヤーのバン(アクセス禁止)を試みることしかありません。残念ながら、このようなルールを解析して回避することを楽しむ一部の巧妙なゲーマーが存在するため、開発者が「もぐらたたきゲーム」のようなもどかしい状況に陥ることもしばしばあります。ほとんどの場合においては、収益の得られる公正なゲームを確実に実現できる最もシンプルで効果的なソリューションは、DGS トポロジーです。

レイテンシ

ここで、ゲームの「レイテンシ耐性」について触れる必要があります。ネットワーク上の他のプレイヤーから更新を取得するのに 1 秒間掛かるとしたら、プレイヤー体験にどのように影響するでしょうか。「ラグがある」感覚が強くなり、プレイヤーがゲームを止めてしまうでしょうか?これが「レイテンシ耐性」です ― つまり、プレイヤー体験が「楽しめない」「プレイしたくない」ものにならない限界の、そのゲームに許容される(耐えられる)最大のレイテンシーです。

ペースの速いゲーム(PC やコンソールの FPS ゲームなど)におけるクライアント間の通信時間は通常、150 ミリ秒未満(理想的には 50~100 ミリ秒未満)である必要があります。この場合、P2P Relay がプレイヤーごとの予測レイテンシーのおよそ倍となり、レイテンシーを 200 ミリ秒未満に抑えられないことが往々にしてあるため、DGS トポロジーが必要となります。

ペースの「若干速い」ゲームの一部はその中間程度となり、P2P トポロジーでも対応可能な場合があります。例えば、一部のモバイルデバイス向けシューティングゲームは、最大 200-250 ミリ秒のレイテンシーが許容されます。指入力の精度に限界があるため、そもそものゲームのペースを若干遅くする必要があるからです。このような場合、チートの可能性が低くてプレイヤー数のスケール(規模)が小さいゲームであれば、UNet LLAPI とサードパーティ製の Relay(Photon や Steam など)で事足りることもあります。

これ以外のほとんどのゲームにおいては(一部のカードゲームも含め)、レイテンシ耐性は 1 秒を超えられません。このため「UNet」(HLAPI + Relay)のソリューションでは、アクティブなリレーデータセンターからのプレイヤーの距離によっては、プレイヤー体験の質が非常に低くなる可能性があります。このシステムを選択すべきゲームは稀です。

公開時期

DGS トポロジーを採用される場合、ゲームの公開予定時期が重要になります。時期によって採用可能な選択肢が変わるためです。以下の概要をご確認ください。

  • 2020 年 4 月 27 日現在:Unity Transport and Reliabilityプレビュー版が公開されています。これは新しい DOTS-Netcode プレビュー版と組み合わせることもできます。これらのライブラリーはプレビュー版のため、より安定した API サーフェスがすぐに必要な場合は、LLAPI または外部のライブラリをお使いいただくことも可能です。
  • 2021 年第 2 四半期:製品品質の DOTS-Netcode を提供予定です。十分に安定し予定している機能をすべて搭載した、製品品質の DOTS-Netcode および UTP を 2021 年の早い時期にリリースする予定です。この時期までに、開発者の皆さんに非常に安定した API サーフェス、技術スタック、およびより完成度を上げたドキュメンテーションをご提供できるよう、作業を進めてまいります。

このため、2021 年第 2 四半期より前に製品のローンチを計画されている場合は、Forge、Photon、または DarkRift 2 など、DGS を使うゲームでも問題なく利用できると思われる、現状利用可能なソリューションの利用をご検討いただくことをおすすめいたします(注:これらのソリューションの OTS オプションの品質について、Unity では検証していません)。

今すぐにゲームのプロトタイピングを行いたいと考えています。今すぐ開始するにはどうしたら良いですか?

この答えは、上のフローチャートから導き出された結果によって変わります。

  • P2P トポロジー ― UNet および Relay サービスが現段階で提供されており、UNet は 2019.4 LTS でサポートが最低 2 年間継続されます。Unity Relay は少なくとも 2022 年までは継続されます。これらの選択肢がご自分のゲームに適合すれば、ご採用いただいて問題ないでしょう。
  • DGS トポロジー ― 将来の DOTS-Netcode へ最も円滑に移行するには、今すぐ Preview UTP と DOTS-Netcode を使い始めることをおすすめいたします。効率性とスケールがそれほど重要ではなく、完成度の高い API サーフェスが今すぐ必要な場合は、Forge、DarkRift 2、または Photon などの他のサードパーティー製 Netcode スタックでのプロトタイピングをご検討ください。

今後に向けて

Unity では今後、コネクティッドゲームの将来に向けての取り組みを進めて参ります。私達は、高性能かつスケーラブルで、唯一無二の安定したコネクティッドゲームの制作を支えるエンド・ツー・エンドのソリューションを確立に力を注いでいます。今後もブログフォーラムにて、DOTS-Netcode や UTP、マッチメイキングなどのサービスの開発の進捗状況を開発者がお伝えして参りますので、どうぞお見逃しなく!

2019年6月13日 カテゴリ: ゲーム | 7 分 で読めます

Is this article helpful for you?

Thank you for your feedback!

取り上げているトピック