Unity を検索

自分のゲームに適したネットコードを選ぼう

2020年9月8日 カテゴリ: テクノロジー | 6 分 で読めます
シェア

皆さんの意思決定にお役立ていただけるよう、現在人気のあるマルチプレイヤーゲーム向けネットコードフレームワークについて、調査と評価を行いました。

コミュニティからのフィードバックを取り入れ、10 月 21 日に内容を更新しました。

更新履歴(ブログ記事および PDF ファイル)

  • 混乱を招かないように、比較表から DOTS を削除
  • Mirror のランキング修正
  • バイアスを発生させうるため、「Best in 」の文字を評価表から削除
  • 参考として、サードパーティ製フレームワークのリストを追加

すべてのマルチプレイヤーゲームの開発において、レイテンシ、パケットロス、シーン管理など、ゲームの体験に影響を与えるネットワーク関連固有の課題を考慮して解決しなければならず、その解決方法はゲームにより多岐にわたります。正しい解決策を見つけるには、ゲームのジャンル、プレイヤー数やネットワークされたオブジェクト数の大きさ、競争力に加え、ネットワーク層の制御がどのくらい必要かといった側面も考慮しなければなりません。また、想定するシナリオによって必要とされるネットコードソリューションにも違いが出てきます。

たった 1 つであらゆる種類のゲームや体験を完璧にカバーできるソリューションはありません。例えば『Apex Legends』のように、チート防止のための権限を持たせた専用ゲームサーバーを運用している FPS ゲームと、『Heroes Strike』のように、チート緩和のための決定論的ロールバック機能を備えた P2P トポロジの上で動く MOBA ゲームとでは、ネットコードに対する要件は全く違ってきます。

すべてのシナリオに適合する単一のネットコードソリューションはないのですから、開発者は、目の前にある選択肢を評価し、どのネットコードソリューション(またはソリューションの組み合わせ)が開発しているタイトルのニーズに最も適しているかを判断する必要があります。また多くの場合、既存のネットコードを拡張したりカスタマイズしたりする必要が生じます。

Unity とネットコード

すでにご存知かもしれませんが、Unity はファーストパーティのネットコードソリューションを 2 つ提供しています。UNet は GameObject を使うプロジェクト向けのソリューションで、現在は保守モードになっています。一方、DOTS-netcode は ECS を使うプロジェクト向けのソリューションで、現在はプレビュー版として提供されています。私たちは現在、コンソール向けにタイトルを出している顧客向けに UNet の LLAPI をサポートしていますが、多くの高レベルのネットワーキングのニーズについて完全なソリューションではありません。幸いにも、Unity には強力で非常に優秀なオープンソースコミュニティとパートナーエコシステムが存在しており、その貢献から様々なシナリオに合わせた数多くのソリューションが生み出されています。

私たちは最近、ブログ記事「2021 年へのロードマップ」で、ファーストパーティ製の Unity ネットコードソリューションをもってこの分野に貢献することを改めて表明しました。私たちがこのソリューションの開発に取り組んでいる間、クリエイターの皆さんのために、代替となるネットコードについて調査と評価を行い、皆さんご自身のタイトルに適したソリューション選択のお役に立つ情報を提供したいと思います。

情報で武装しよう

Unity のチームは、最も広く使用されているサードパーティ製のネットコードソリューションについてのフィードバックを収集し、どのフレームワークが最適に機能するかを決定するプロセスをガイドするために、ディシジョンツリーを作成しました。

これらのツールを作成するために 3 つのソースからデータを集めて分析しました。

  • 特定のネットコードフレームワークを使用した経験に関して 200 名以上の Unity ユーザーに対して行った調査
  • Unity を使ったマルチプレイヤーゲームを積極的に出荷しているユーザーを対象とした 20 件以上の詳細なインタビュー
  • Unity のチームが MLAPI、DarkRift 2、Mirror、Photon Quantum を使ってプロトタイプを構築する中で得た教訓

顧客に人気のあるネットコードソリューションを以下に示す軸でスコア化し、ランク付けしてもらうようにお願いしました。

  • 安定性/サポート:バグやクラッシュの可能性、問題を修正したり問題のデバッグに関するサポートの応答時間、API への破壊的変更が起きる可能性の 3 つの軸に沿って評価しました。
  • 使いやすさ:一般的なタスクに着手、実行することがどの程度容易であるか、良質なサンプルの提供、ドキュメント、チュートリアル、プロトタイピングのためのシンプルな API などが提供されているかという観点も含めて、ユーザーに評価していただいた結果をまとめました。
  • パフォーマンス:この項目については、ガベージコレクションやアロケーションができるだけ少ないこと、レイテンシオーバーヘッドが最小限であること、計算パフォーマンスが高いこと、可能であればマルチスレッド機能を備えていること。これらの観点で評価を行いました。
  • スケーラビリティ:この項目はパフォーマンスに似ていますが、パフォーマンスを大きく犠牲にすることなく、より多くのクライアント接続をサポートする能力に焦点を当てています。
  • 機能の幅広さ:オブジェクトや変数の複製、RPC、シーン管理などの中間レベルの機能に焦点を当てた評価軸です。予測やラグの補償など、高レベルの機能についても加味しています。
  • コスト:ライブラリおよびソリューションのコストと、別途管理しなければならない運用上のオーバーヘッドなど、隠れたコストの両方を考慮しています。

ここから私たちの調査結果と推奨事項へと読み進む前に、2 つポイントを強調しておきたいと思います。1 つ目は、皆さんのゲームで使うネットコードソリューションの選択とは重要な決定事項であり、調査結果だけを頼りにせず、ぜひ皆さんご自身でも評価していただきたいということです。今回の記事を書いたのは、最も一般的な選択肢をまとめた内容を共有することで、皆さんの意思決定プロセスを楽なものにしたいと思ってのことではありますが、皆さんがそれぞれ自分のゲームに特有の事情を考慮して、独自の評価を行うべきだと考えます。2 つ目は、このリストはすべての選択肢を網羅しているわけではないということです。特にトランスポートレベルでは、enet、litenetlib、ruffles、telepathy など、すでに確立したソリューションが多数存在していますが、それらは含まれていません。

これから示す情報は取り掛かりにすぎません。ぜひ完全版のレポートもダウンロードして、目を通されることをおすすめします。完全版のレポートでは、これらのサードパーティ製のネットコードソリューションについて、より詳細に説明しています。

注意:

完全版のレポートは PDF 形式で配布されており、このレポートでは、顧客の言及が最も多かった複数のソリューションをカバーしています。ただし、レポートに掲載したもの以外にもいくつかのソリューションの名前を挙げる顧客もいました。また、Forge、Normcore、Bolt、LL(Enet、LiteNet)など、まだ評価するのに十分な顧客からのエビデンスを集めていない他のソリューションについて議論している方もいらっしゃいました。言及されたソリューションが皆さんの環境における選択肢になるかどうかを考える際に、このポイントは考慮しておくことをお勧めします。

この表だけでは決められませんか?

ネットコードソリューションの選択という、重要な意思決定のプロセスを容易に行うための図も作成しました。私たちが皆さんの決定に影響を与える可能性のあるすべての技術的な変数を把握することは不可能であるため、抽象化によって重要なディテールがそぎ落とされている可能性があることにはご注意ください。この図は、皆さんのゲームが成功を収めるまでの道のりをサポートするソリューションの評価を始めるときに考慮すべき要素の一部をカバーするものです。

ネットコードソリューションの初期的な評価を始めるための大まかなガイド図

ここで、このディシジョンツリーで使われている重要な用語とこのツリーの中での意味を簡単にまとめておきます。

  • ゲーム専用サーバー(Dedicated game server; DGS):クライアント-サーバーネットワークの実装であり、サーバーがクライアントデバイスとは別に専用のコンピュート上でホストされるものを指します。このオプションは高価ですが、スケーラブルで安全です。
  • リッスンサーバー(Listen server):クライアント-サーバーの実装のうち、サーバーがクライアントデバイス上でホストされるものです。安価ですが、スケーラブルではなく、安全ではありません。
  • 決定論的ロックステップ(Deterministic lockstep):P2P 実装では、入力のみが他のすべてのプレイヤーに送信され、「ロックされたステップ」で同期されます(すなわち、同じシミュレーションのティックで一度に同期されます)。クライアント上の決定論的処理によって、すべてのクライアントが同じ状態を維持することが保証されます。このシステムは安価で安全ですが、複雑な決定論の実装が要求されます。
  • 決定論的ロールバック(Deterministic rollback):これは決定論的ロックステップを強化したもので、クライアントは更新を待っている間に入力を先行して予測します。この設定はより複雑ですが、ロックステップよりも応答性の高いゲームを可能にします。比較的安価で安全ですが、非常に複雑な決定論とシミュレーションの実装が要求されます。

完全版のレポートで私たちの分析の詳細をご確認ください(英語、ダウンロードする前にいくつか設問があります)。マルチプレイヤーとネットワークの概念にある程度精通している方には、このレポートはより理解しやすいものでしょう。復習が必要と感じる方は、こちらの講演をご覧ください。要点のほとんどをカバーしています。

 


 

本記事で共有した情報が皆さんのお役に立てば幸いです。フォーラムで私たちの分析に関するご意見やご質問、バグや気になるデータ点に関するご指摘などをお聞かせください。

2020年9月8日 カテゴリ: テクノロジー | 6 分 で読めます