Official The open source MLAPI project joins the Unity family.

great news!

i hope we can finally make multiplayer games in unity soon

 

I have an question, snapshots after 3 years ?
But atleast newbies can make a multiplayer game!

 

Congrats, now you have 5 more network libraries than every other engine

 

Mirror Networking has 5+, sorry garry i didnt really understand u, awesome to see you here i always follows ur blog

 

Garry's not the only person who gave up on this.
Engine fragmentation gets worse with every Unity's decision lately. Things used to be plain simple, we were able to search a problem and instantly find an answer - which is no longer the case when you have 5 different ways to do stuff.
Besides, studios generally don't like when someone is pulling the carpet from under their feet every year by deprecating something instead of improving it.

I do realize that this is a step in the right direction though, because this is a legit attempt to revive a networking solution. HLAPI was pretty bad, but it wasn't hopeless.

 

Obviously there might be a decent bit of work building native integrations into editors, etc.

Is there any general ideas of the scope of changes coming to the public facing API?

If someone wanted to start using MLAPI now, can we expect migration plans to accommodate the changes to the API from above?

Excited to see what comes from this!

 

Pretty excited about this, can't wait till it is officially included to the Package Manager!

I was low-key hoping Unity would come out with their own solution, using the current DOTS networking as a foundation, and have a built-in support for testing multiple instance of multiplayer clients and server in the same project like the new DOTS networking.

But with MLAPI, it seems like this would no longer be possible?

I am currently using ParrelSync, but this causes a lot of lost time from having multiple clone projects to recompile every time there is change. Sure it is faster than actually having to build, but it is still a huge pain.

I am reading something about snapshots and client side prediction from the blog post.
Will we be getting a child class of Network Behaviour, and an upgrade to Tracked Object similar to DOTS networking's Ghost Snapshot behaviour?
Hopefully it does go that way! It really simplifies everything hard about the server authoritative model.

 

Amazing! Huge fan of MLAPI, glad Unity is willing to adopt it and keep it open source.

 

Testing multiple client and server instances is indeed much more troublesome without DOTS. We are looking into ways to provide a way to do fast iteration of multiplayer games so that users don't have to rebuild or clone Unity projects.

The goal of our snapshot and prediction efforts is to provide something which simplifies a server authorative model. So it will be very similar in concept to the ghost snapshot system in DOTS netcode.

 

Just started playing around with this today. Any chance you guys will include rigidbody physics syncing? In it's current state it is very jittery using dedicated server. The Transform sync component works pretty good for translation though.

 

I really like this move. In terms of tutorials, If we could get a simple server-authoritative tutorial, with two player characters and the ability for either move and to spawn a projectile that would be a huge step in the right direction.

Is client-side prediction and reconciliation as a stretch goal two much to ask?

 

May also be beneficial to reach out to developers who've already been teaching us to do server auth.
FirstGearGames comes to mind instantly (First Gear Games - YouTube)

 

Thanks for the reply Chris. When I first started game programming I looked at an engine called nengi.js. The Tutorials do a really good job of explaining in appropriate detail the core concepts of how to implement something that I think most multiplayer game programmers are looking for. It was about a week of learning and I was able to start implementing new features and moving quickly.

Please go check out the tutorials as I think that using a similar pattern for what you're doing in MLAPI/Unity would really benefit your user base ( and myself )

 

It was all I needed to one day be wonderful, hopeful that Unity will listen to the audience and maintain a lib with good network support

 

As a beginning dev, I want to thank you guys so much for being a bridge to a hole that is preventing a lot of ppl from making their dreams come true. So thanks for looking out for the little guys lol.

 

Happy to hear the news regarding a multiplayer solution!

Something I have noticed in all UNET-derived networking libraries is that they inherit the assumption that you always have a single server or client in the same process (e.g., NetworkingManager.Singleton.StartServer() and
NetworkingManager.Singleton.StartClient()). While I understand the practical convenience of this approach, it means one cannot instantiate multiple servers or clients in the same process, just like you could with UNET's NetworkServerSimple, which complicates certain development and testing scenarios. This reliance on statics also has the potential to break fast enter play mode. I am curious: what are your thoughts/plans on this area?

 

Documentation is currently the main problem of this solution, a lot of pages are bare bones or even blank... but since you intend to make breaking changes, it's normal not to produce any doc that might get outdated in a matter of weeks so this point is understandable.

Is the full team working on MLAPI this: Albin Corén, Christopher Pope, Luke Stampfli; because if so it is quite alarming. If I recall correctly the whole net stack HLAPI/LLAPI was handled by a grand total of 4 or 5 people which was already ridiculous. I hope you do not intend for the community to do all the heavy-lifting while enjoying the ride, because it should be the other way around if Unity take on MLAPI.

With all that said, it is kind of a good news, only because the author of MLAPI did so much in so little time, so we should expect a lot if he's working on it full-time.

Another good point is the fact that someone at Unity realized and admitted that Unity NetCode based on ECS was so late that something needed to be done to fill the gap, we just have to wait for the news announcing how much delay this one will have.

Could we have some sub-forums for net stack dependant topics instead of packing everything in the same multiplayer forum ? Something like "New to Multiplayer", "Game Object net stack MLAPI", "Game Object net stack 3rdParty", "Entity net stack NetCode", "Entity net stack 3rdParty"...

And please get your commercial team to find a better name for Unity NetCode, this is a generic name for a very precise and vaporware use !

 

We're aware of the state of MLAPIs documentation. We've a team working on documentation and hope that we can deliver good documentation once we have our first Unity release of MLAPI.

Our team is much larger then just Albin, Chris and I. We (me and Chris) are just Solution Architects who's role is to support people at using MLAPI. We have a large team working on MLAPI and other teams working on tools and samples for it.

About splitting the Forums up into sub-forums. We were thinking about that as well. There are some pros and cons to it. Will see what we can do.

 

@Unity I am relatively sure you know this already but I say it so you may find confirmation in it:
UNET wasnt completely bad , it just had some tech issues , MLAPI will be much better , we CAN do it, I know it!

Edit: Stay calm and first solve the problem, then write the code !

 

Absolutely right you are!

 

Why MLAPI vs one of the many other open source solutions available? I have been recommended other frameworks way more often than MLAPI when researching multiplayer solutions so I'm curious about your selection process.

 

I'm going to use MLAPI for my next project with a dedicated server(s), but is there a lobby/room feature built-in in MLAPI?

 

In its blog post, Unity promises a large investment in MLAPI tools, samples and documentation. Unity also emphasizes that you can use Unity to create games like Fall Guys.
Therefore, as a sample of MLAPI, a sample of multiplayer battle royale with 60 or 100 people is absolutely necessary. The current trend of battle royale games and the blank space in Unity's net code so far have been pressure to encourage users to move to UE4. If you prove that battle royale is possible in Unity, I will not have to move to UE4, and it will be convincing that I can get performance even if it is not ECS Net Code.

Epic has made a number of optimizations, including Replication graph, in the development of Fortnite. They are being fed back as new features in UE4. Therefore, it is relatively easy to develop 100 player multiplayer with UE4.
However, optimizations made by third parties in Fall Guys development are not fed back to the Unity engine. If I try to make a battle royale, it will be remade from scratch.
If Unity have a lot of large-scale multiplayer techniques, it would be helpful if you could give us feedback as samples.

 

OK, naiive question. But I was using legacy Networking code from way back in Unity 4.7 days. This had a simple way to connect two plays with nat-punchthrough. (It had a facilitator which you could host on your own cloud instance).
This could connect two players peer-to-peer in the server/client role.

Is this possible using MLAPI?

 

Meh, if it can't do nat punch through to do p2p games then no good for me. I'll stick with Unity 2018.1.

Unless there is a way to use this with the "legacy" faciliator . I can host the facilitator on my own cloud instance, I don't need to pay for a service. (For lobbys I can either use the masterserver or, for example, Steam Lobbys if I'm using Steam.)

Any ideas how to use MLAPI with the facilitator? The faciliator has source code you can read.
It looks like you just send a GUID code to the facilitator, it records your public IP address and then when another player connects to it, it passes the public IP addresses between the players. Seems simple enough. But I would need some more documentation to get it to work with MLAPI.

 

At the time of Fall Guys' launch, Unity's network had only UNET in maintenance mode. There was no place to receive feedback.
I will quote from a blog post.
"As evidenced by the success of games like Mediatonic ’s Fall Guys: Ultimate Knockout, great multiplayer games are possible in Unity today, and we will keep making it easier."
When I read this, I get the impression that Unity supports battle royale. In fact, it turns out that there is no support timeline.

I searched the asset store for multiplayer templates, most of which integrate PUN. Large-scale multiplayer is not possible with PUN.
This is a situation caused by the long absence of Unity's netcode.
Some assets have Mirror integrated. Assets such as uSurvival, created by the creators of Mirror, support large-scale multiplayer.
What about MLAPI? Right now we have no assets and few samples.

 

I don't think the democratic game engine Unity is obliged to support battle royale. Very few developers have the capital to prepare a server to host a large-scale battle royale game. There is no incentive for Unity to work hard to support that few.
It may be a source of trouble to give an environment where anyone can easily create a battle royale.
As long as it's clear that Unity doesn't have a timeline to actively support large-scale battle royale, I can tell my company. "If we want to make a large-scale battle royale, we should move to UE4."

 

User Ziflin was commenting in the blog post originally about them making their own networking API to support Multi-Scene workflows / Additive Scene-loading (loading, unloading, probably async, moving GameObjects between Scenes, etc.) as has been the available workflow in Unity for quite some time now.

From what I understand MLAPI only supports the early Unity single-concurrent-Scene type of workflows.

Similar to Multi-Scene/additive workflows, another big performance enabler in development as of the few last years has been the Addressables system.

Given that you're obviously first prioritizing the immediate API changes, rebranding, documentation and samples to offer MLAPI as a legitimate Unity solution, how would you comment on and describe your current understanding on the focus of the team(s) involved order of priority for the following?

1. Multi-Scene workflows with MLAPI
2. Addressables workflows with MLAPI

 

P2P games is definitely something we want to support with MLAPI. The faciliator is very old legacy tech it is very unlikely that we will support it and I'm honestly not familiar with the code so I'm not sure on what you would have to change to make it work with MLAPI.

For NAT punchthrough there is a puncher application for MLAPI which can be self hosted, you can find it here: https://github.com/MidLevel/MLAPI.Puncher (The puncher is a separate application from the creator of MLAPI and not officially supported by Unity).

As a side node since you mentioned Steam for lobbies. Steamworks also has a networking solution which uses punchthrough with a fallback relay server which makes sure that users can still connect even when the NAT punchthrough fails. I'd recommend to give it a try if you are already using Steam for lobbies and other stuff. There is a transport extension for MLAPI to support Steam Networking: https://github.com/Unity-Technologies/MLAPI.Transports/tree/master/SteamP2PTransport

 

You are right, MLAPI currently only supports a single scene workflow currently. Improving scene management and multi scene workflows is on our radar but we are not at the point where we can share specific plans for it. Multi-scene support is quite a broad topic and can be used to solve different problems. Is there any specific feature which you are looking for?

Addressables support would be a nice addition to MLAPI. The current workflow of having to register everything as a prefab in the NetworkingManager is quite restrictive, loading networked objects from Addressables is something we are looking into as a possible solution. This might be a feature which will slowly evolve over time as we add more support to it.

We cannot comment yet on the priority/focus on those two features yet, as you mentioned first priority right now is immediate changes which are necessary to bring MLAPI into a releasable state.

 

Thanks! I will try the MLAPI.Puncher and give it a go! I don't know a whole lot about MLAPI, but from what you're saying the Unity implementation of MLAPI isn't really designed for P2P but maybe it will work OK. Has anyone else tried this?

Steam Networking would be one answer I've looked into but, it means you can only sell your game through Steam. (Edit: Ah yes I could just swap in the Steam transport for the Steam edition. Excellent). Which mostly I do anyway, but I'm also thinking about making a multi-player game for the Oculus store. I haven't really heard of any games which use Steam Networking, so it's hard to say how reliable/fast it is.

On another note the old RakNet system was bought by Oculus and made open source. Seem like that was 4 year before Unity removed it from their engine. Not sure if Faceook are using it for anything though. Maybe they are using it for their P2P networking?

Unfortunately it's hard to find documentation about the old facilitator, but because it has source code I can run it and see what packets are being send by Unity 5.6 with Network.InitializeServer(..) etc. I think I could hack in a few days . It uses UDP packets by the way. RakNet is opensource now but I think the Unity implementation is based on an older vesion.

(I did have one other working system in which I ran Unity 2019 and Unity 2017 simultaneously, with Unity 2019 doing the graphics, then talking through "pipes" to Unity 2017, which used the legacy networking code for multiplayer!!! It did work, but not a very elegant solution! )

Edit: BTW when I say "p2p" I mean one person is acting as a host, but that host need not necessarily be on a public server. e.g. they could be in their house behind a wifi router.

 

Hello, sorry a quick question about MLAPI: [is this the best place to ask?]

What do I choose as the "transport"? The choice is Unet or Multiplex. I'm a bit confused as I thought this was a replacement of Unet. Does that mean I should select Multiplex? Which is the best one?

I've just trying it out and it looks very good!

BTW will there be a "transport" for Oculus p2p? I'm sure I could write my own once I get my head round it.

 

The Multiplex transport is a special transport to allow connections from multiple transports to the same server. The Unet transport would be the default transport to use. You are right MLAPI will be replacing UNet. We will be providing a new transport soon which is not based on UNet, for now the UNet transport is the recommended default option.

Regarding Oculus and p2p. I don't think that Oculus has a platform specific networking solution like Steam, Discord or some Consoles have. In the future we wish to provide a p2p transport that works on most platforms including Oculus. Currently the MLAPI puncher and relay applications should allow you to do that as well but you'll have to self host the server applications.

 

I don't understand this. I actually don't understand any of the communication from Unity in the past few years. I honestly have no idea where you're headed or how long you're planning on taking to get there. Which makes it extremely hard for me to make choices regarding what to use within Unity and extremely frustrating for me to use Unity in general.

You have this blog post: https://blogs.unity3d.com/2019/06/1...4.1900127728.1609967242-1347783713.1604433061

Was this acquisition not known about at all then? Then as in 27th April 2020 as that's when it says the blog post was last updated and the information in it still reads like an alternative universe to me. No mention of MLAPI and why would you acquire MLAPI and put resources into in now if DOTS networking is right around the corner?

Quoting the blog post:

So DOTS networking is on the final stretch and per the graphic in that blog post you actually recommend that we use it if our game is to be released in Q2 2021 or later, but instead of putting more resources into it and finishing it you're putting resources into something completely different? What's the point of MLAPI? Should I only use it if I start making my game now and plan to release it before Q2 2021? And can DOTS networking actually be used without DOTS in general or do you actually estimate that DOTS is production ready early this year? If DOTS networking requires DOTS then shouldn't there be a disclaimer in that blog post / graphic? And if not then my question is very valid, is it not? Why would we ever use use MLAPI if DOTS networking is almost ready and can be used for everything?

And then you have this blog post: https://blogs.unity3d.com/2020/09/0...4.1900127728.1609967242-1347783713.1604433061

Which now states:

I have no idea what it used to say, but how does that avoid any confusion? I'm way more confused now. Was DOTS abandoned between April and September of last year?

Are you, Unity as a whole, this bad at communication or do I struggle with reading comprehension? I thought the scriptable render pipelines and everything going on there was hard to follow, but what is even going on here?

I would ideally like to start experimenting with multiplayer games today, but I have no idea when/if I will release any. Maybe this year. Maybe next year. Maybe 2025. And I could just postpone the whole experiment if Unity has no idea which framework they'll stick with. I just want to know that when I actually put effort into learning a networking framework that I'm not learning something that you'll replace before I've even gotten started. I started learning UNET a long time ago, but I felt like I was barely done with a beginner tutorial before you had abandoned it.

PS: And just to be clear. I have zero experience with DOTS and I would like to not even touch it with a stick until it actually replaces what's in Unity today and I'm forced to use it .

 

Thanks a lot for the extremely fast reply. I honestly didn't expect that.

I actually read into DOTS to try and understand what it is about because up to this point I've completely ignored it, but I interpreted from that one blog post that it's closer than I thought, which also seemingly may be completely false. I found this "tutorial" which states DOTS is indeed the end goal for Unity (as I feared): https://learn.unity.com/tutorial/what-is-dots-and-why-is-it-important

But there's no date on that tutorial so based on what you're saying here what's in there may very well have changed as well. And either way, that end goal may be in 2025 or 2030 for all I know.

I'm old (relatively ), grumpy and I don't like learning new stuff anymore, so I'll stay away from DOTS for now and hope it is indeed a long time until I'm forced to learn it. I just want to make games using stuff that works and ideally the same stuff that other people also use so that I can rely on the community for help when I need it. However this part of your reply still confuses me:

MLAPI and New MLAPI? Then what is this https://github.com/Unity-Technologies/com.unity.multiplayer.mlapi? Old or new? Should I wait until "soon" then? I have no deadlines. I just don't want to start out with something only to realize in a couple of months that I should have been using repo x or branch y that's incompatible with what I already started out with.

 

will check the develop branch for new concepts of MLAPI, including UPM for example.

 

The repository will contain both the current and the new MLAPI. You can find the current MLAPI in the master branch and the wiki explains how to install and use it. We are working on the next version of MLAPI in the develop branch. There will be quite a bit of changes to increase performance and hopefully provide a better developer experience. You can find more about our plans for MLAPI in the announcement blog post.

 

Alright, thanks. Then I'll wait until the new MLAPI is the only MLAPI.

 

Thanks for the info!!!

Regarding Oculus. I believe it DOES have it's own p2p networking. And if it can't do a direct connection it relays it through the Facebook servers. (Correct me if I'm wrong!)

Ironically I think the Oculus networking is based on RakNet (which Facebook bought) which is the equivalent of the legacy Unity Networking taken out in 2018.2. (The one that worked and was replaced by Unet for reasons unknown).

Thus if I used MLAPI, and used a transporting layer for Oculus, it would in effect be using the legacy Unity Networking from Unity 4.7. Small world. (Only difference is the facilitator will be on the Facebook server instead of the Unity/your own server.)

MLAPI is kind of weird in that it has to spawn things instead of just syncing things already in a scene (it will fail if the object is already in the scene) and it allows the clients to take control of updating objects instead of having the server take control of all the objects (which I think is conceptually simpler). I preferred the old system but I'm sure I could get used to it if there was a nice tutorial.

I'm also someone who is not keen to learn DOTS at this stage. It is like learning an entirely new game engine. And from what I've seen on YouTube it isn't even that efficient. I don't use Unity because I think it's the most efficient game engine, more that it's easy to use and cross-platform.

 

I started evaluating MLAPI but I'm little bit confused about its current state. Am I evaluating something that's going to change completely in near future or will I be able to upgrade? Is there any roadmap or time frame available for future updates? If I go with dev branch, what documentation should I follow?