Search Unity

Unity の新しい GameObject 向けマルチプレイヤーネットワーキングフレームワークの成長を加速させる

, 12月 3, 2020

オープンソースの MLAPI プロジェクトが Unity ファミリーに加わりました。Unity が、Unity のファーストパーティ GameObject 向けのマルチプレイヤーネットワーキング(ネットコード)フレームワークの開発を進めていく中で起こりうる変更点のいくつかをご紹介します。

2021 年の Unity の最優先課題の 1 つは、セットアップや拡張が簡単で、ハイパフォーマンスを要求されるタイトルのニーズに合わせてスケールアップし、Unity エコシステムにシームレスに統合された GameObject 向けのファーストパーティマルチプレイヤーネットワーキングソリューションによって、Unity エコシステムを拡大することです。

既存の UNet HLAPI アーキテクチャは、大規模なゲームをサポートする際に求められる、根本から大きく発展させていくような作り方には適していません。だからと言って、私たちは車輪の再発明を行おうとしているわけでもありません。Unity エコシステムでは現在、複数の強力なソリューションが提供されていますが、私たちが思い描くスケーラブルなフレームワークを提供するための最善の方法は、コミュニティに既に存在する素晴らしい仕事を基礎として、フレームワークを構築することです。

私たちは様々なオープンソースソフトウェア(OSS)の代替案を検討し、私たちのニーズに合うフレームワークを見つけました。OSS のマルチプレイヤーネットワーキングフレームワーク「MLAPI」が、その開発者 Albin Corén 氏と共に、Unity ファミリーに加わったことに感激しています。

今日の時点で、すでに MLAPI を Unity のファーストパーティ GameObject 向けネットコードソリューションとなるものに統合し、進化させる作業を行っています。今後も完全にオープンソースで開発を続けていく予定です。開発をオープンにし、コミュニティからの貢献も歓迎します。興味のある方は、GitHub の MLAPI レポジトリをのぞいてみてください。

近日中に予定されていることは以下の通りです。

  • ソリューションアーキテクトの新しいチームがすでに MLAPI Discord サーバーUnity Multiplayer フォーラムに参加しており、マルチプレイヤーゲームの開発に関する質問に答えたり、ガイダンスを提供したりしています。
  • 近日中に、MLAPI のリポジトリを GitHub の Unity 組織に移動し、新しいコードのチェックインを開始します。これはオープンソースのままで、完全な開発履歴と過去のリリースをすべて保存し、今後の開発はすべてオープンにした状態で行われます。
  • プロジェクトのライセンスに変更はなく、引き続き MIT ライセンスの下で提供されます。
  • コードベースは今後数か月の間に進化していきます。現時点で提供している MLAPI を使って評価を行うことをお勧めしますが、将来のスケーラビリティとコアシステムの拡張性を確保するために、Unity は破壊的な変更を行う見込みであることを心に留めておいてください。Unity はこれらの変更を、行うだけの価値があるものにするために尽力します。また、皆さんが移行を行う際にも支援を惜しみません。
  • 今後も、多くのトランスポートとインターフェースを取るための抽象化レイヤーをサポートし、この中間レイヤーソリューションとの LLAPI と Unity Transport Package の統合を維持していくことを約束します。

MLAPI のアーキテクチャをその深い部分に至るまで調査しました。その結果、このフレームワークを基礎として新しい機能を構築する前に、いくつかの重要な領域を進化させたいと考えています。注力する分野には以下のものが含まれます。

  • リモートプロシージャコール(RPC):現在 MLAPI には「利便性の高い(convenience)RPC」と「パフォーマンスの高い(performance)RPC」の 2 つの RPC システムがあります。「利便性の高い RPC」はパフォーマンスのオーバーヘッドが発生します。「パフォーマンスの高い RPC」は、このオーバーヘッドに対処しますが、使い方が少し複雑です。Unity では、この両方のシステムを、パフォーマンスが高く、使いやすく、使用時のパターンもクリーンな 1 つのシステムに置き換えるための選択肢を検討しています。
  • スナップショット生成:MLAPI の現在の設計には、デルタ圧縮やクライアント側予測のような機能を組み込む上での課題があります。これを克服するために、スナップショット生成とパケット送信システムの分離に取り組んでいます。
  • ネットワーク妥当性のモデル:各プレイヤーに適切なデータを送信することで、開発者は帯域幅のコストを最小限に抑え、プレイヤーのゲームプレイ体験を最高のものとすることができます。MLAPI に変更を加えることで、パフォーマンスを向上させ、不正行為の可能性を下げ、送信データ量を減らすことで運用コストを下げるための新しい方法を使えるようにします。

アーキテクチャと機能に関する作業に加えて、ドキュメント、サンプル、ハウツー、開発者ツールなどの整備にも取り組んでいます。すべての開発者がマルチプレイヤーネットワーキングの専門家レベルの知識を持つ必要をなくし、マルチプレイヤーゲームの開発をより簡単に行えるようにしていきます。

前述したように、今回の発表は、GameObject を使うパターンに沿って開発をしている開発者に向けたものです。これまでの意思決定や、あるいは開発しているタイトルが非常に高いパフォーマンスを要求するといった事情により、Entity Component System(ECS)を使うパターンに沿って開発をしている、または評価を行っている開発者にとっては、Unity NetCode パッケージ(プレビュー版)が、引き続き Unity が提供するファーストパーティフレームワークとなります。

私たちの目標は引き続き、大勢のプレイヤーを一堂に集めることを可能にする技術を提供して、クリエイターを成功に導くことです。

近日中にこのブログで新たな情報をお知らせします。引き続きご注目いただくと共に、GitHub プロジェクトをチェックして、もしご質問があれば MLAPI Discord チャンネルでお伝えください。

19 replies on “Unity の新しい GameObject 向けマルチプレイヤーネットワーキングフレームワークの成長を加速させる”

Please, what is the best way for use Service Discovery (MDNS) for cross-platform (win, mac, Linux, iOS, Android)? I want to use the Network Discovery, but it is not supported and I didn’t find any replacement.

Many thanks.
Vilem

Besides (CPU & bandwidth) performance and maintainability, one of the reasons I wrote a custom network API earlier this year was to support the kind of additive scene loading that our game requires. Clients need to be able to make requests to load into a new scene, and the server needs to properly handle the loading/unloading of them as well as movement of GameObjects between scenes. In what timeframe will MLAPI be able to support these types of features?

Hi Ziflin, this is a great topic, please post this on the forums, and we can discuss there. Thanks!

wondering the same think!
The year is almost finished and NOTHING new about DOTS !

Unity needs consistency and to not change the API every 3 years!
Also it needs communication.
It lacks in both areas unfortunately :(

Hey there. We are aware of the community’s concerns in regard to the future of DOTS. Rest assured that it is something we are still actively working on, and hope to have more to share soon.

Please keep an eye here on our blog, as we’ll be sharing regular development updates.

great mlapi is very lean and effective framework the only downside to using it right now it’s that if there’s something you didn’t do right you’ll just get weird errors on console

but I love the approach Alvin has made really clean easy to implemen
really can’t wait for this to be production ready 2021 here we goo

Are you considering to use code gen for RPCs (and possibly other features)?
I kinda like the code gen in entities package and this seems like a good use case. I hated UNetWeaver.

However if you’ll make code gen, please make it extensible, so we can plug in custom types, enums, etc.
The UNetWeaver sucked, because it was impossible to add custom types or change it’s behavior.

For current project (Volcanoids), we’re using heavily modified UNet without UNetWeaver, we’ve also replaced transport by ISteamNetworkingSockets.

Sync vars are usually very easy to write directly into Serialize/Deserialize.
For RPCs we use custom solution with some boilerplate, but it’s not that bad:

// Rpc definition
static readonly RpcCall m_rpcDeath = new RpcCall((comp, killer) => comp.OnRpcDeath(killer), Channels.DefaultReliable);

// Calling RPC from inside Health component
m_rpcDeath.CallRpc(this, killerNetIdentity); // calls OnRpcDeath on clients

Dammit, comment box consumed my generic arguments, RpcCall should be generic with two arguments: Health (derived from NetworkBehaviour) and NetworkIdentity.

There are also overloads for different number of arguments. Serializer for arguments it looked up once when static variable is initialized. It creates no garbage and performance is good (extra cost compared to manually written message is couple of virtual calls one per argument).

True, but reading this announcement makes it atleast seem like unity will try to fix/improve it into something actually usable.

So again the networking code is thrown in the bin.. what is wrong with a simple dot net solution?

Please add Host Migration :-) <3

And yes, this is a great decision, and the author is one I trust technically – he's one of the smartest you have on your teams.

Comments are closed.