Search Unity

Accelerating Unity’s new GameObjects multiplayer networking framework

, 十二月 3, 2020

The open source MLAPI project joins the Unity family. Read on to discover some of the changes you can expect as we build Unity’s first-party GameObjects multiplayer networking (netcode) framework.

One of Unity’s top priorities for 2021 is to expand the Unity ecosystem with a first-party multiplayer networking solution for GameObjects that is easy to set up and extend, scales to meet the needs of high-performance titles, and is seamlessly integrated into the Unity ecosystem.

The existing UNet HLAPI architecture is not well suited for the in-depth evolution that is required to support games at scale. Rest assured, we don’t want to reinvent the wheel. The ecosystem currently offers multiple strong solutions, and the best path toward providing you with the scalable framework we envision is to build on the amazing work that already exists in the community. 

We considered various open source software (OSS) alternatives and found a framework that fit our needs. We’re thrilled to share that the OSS multiplayer networking framework MLAPI is joining the Unity family, along with its creator, Albin Corén.

As of today, we’re already working on integrating and evolving MLAPI into what will become Unity’s first-party GameObjects netcode solution. We plan to continue the development fully open source. Developing in the open and welcoming community contributions. If you are interested, you can join us on the GitHub MLAPI repo.

Here’s what you can expect in the short term:

  • Our brand-new team of solution architects have already joined the MLAPI Discord server and Unity Multiplayer forum to answer your questions and provide guidance when it comes to building multiplayer games.
  • Over the next few days, we will move the MLAPI repository into the Unity GitHub organization and start checking in new code. It will remain open source, preserving the full development history and all past releases, and all future development will take place in the open.
  • There will be no changes to the project license, it will continue to be an MIT license.
  • The codebase will evolve over the coming months. While we encourage you to evaluate MLAPI as it exists today, please keep in mind that to ensure future scalability and extensibility in the core systems we’ll need to introduce breaking changes. We will make them worthwhile, and we’ll be here to help you migrate.
  • We will continue to support an abstraction layer for many transports to interface with, and we are committed to maintaining the LLAPI and Unity Transport Package integrations with this mid-layer solution.

We have taken a deep look at MLAPI’s architecture, and we want to evolve a few key areas before we start building new features on top of this framework. Some areas of focus include:

  • Remote procedure calls (RPCs): Currently MLAPI has two RPC systems, “convenience RPCs” and “performance RPCs.” The convenience RPCs incur a performance overhead that performance RPCs address, but they are not straightforward to use. We are investigating options to replace both with a system that is performant, is easy to use, and has clean usage patterns.
  • Snapshot generation: MLAPI’s current design poses challenges for incorporating features like delta compression or client-side prediction. To overcome this roadblock, we’re working on separating snapshot generation from packet-sending systems.
  • Network relevance model: Sending the right data to each player enables developers to minimize their bandwidth costs and maximize players gameplay experiences. We’ll change MLAPI so new methods can be used to increase performance, lower the likelihood of cheating, and lower operating costs by lowering the amount of data sent. 

On top of the architecture and feature work, we’re working on documentation, samples, how-tos, developer tools, and generally making it easier for every developer to build multiplayer games without having to become a multiplayer networking expert. 

As we mentioned above, this announcement is focused on developers working with a GameObjects pattern. For developers that are working with, or evaluating, the Entity Component System (ECS) pattern, either because of preference or because their title needs that level of hyper performance, the Unity NetCode package (Preview) continues to be Unity’s first-party framework for the scenario.

Our goal remains to set creators up for success by providing the technology that enables them to bring players together at scale. 

We’ll share more soon on this blog. Stay tuned, check out the GitHub project and let us know if you have questions on the MLAPI Discord channel.

19 replies on “Accelerating Unity’s new GameObjects multiplayer networking framework”

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.

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?

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.

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.