Search Unity

We evaluated and researched today’s most popular netcode frameworks for multiplayer games to inform your decision. 

Updated on 21st October to incorporate feedback from the community

Changelog (blogpost & pdf):

  • Removed DOTS from the comparison table to avoid confusion
  • Adjusted Mirror’s ranking 
  • Removed the “Best in <category>” assessment to reduce potential bias
  • Added an additional list of third-party frameworks for reference

Every multiplayer game has to account and solve for inherent network-related challenges that impact the game experience, such as latency, packet loss, and scene management, and games solve these challenges in a variety of ways. Finding the right solution depends on a game’s genre, the scale of its players and networked objects, competitiveness, and other aspects, like how much control is needed over the networking layer. Different scenarios require different netcode solutions.

There’s no perfect, one-size-fits all solution for all kinds of games and experiences. For example, an FPS game running on a dedicated game server with server authority for cheat prevention, such as Apex Legends, will have completely different netcode requirements than a MOBA running on a P2P topology with deterministic rollback for cheat mitigation like Heroes Strike.

Because there’s no single netcode solution for all scenarios, developers need to evaluate the options and decide which netcode solution – or combination of solutions – best suits a title’s needs. In many cases, they may also need to extend or customize existing netcode. 

Unity and netcode

As you may already know, Unity has two different first-party netcode solutions. UNet solves for GameObjects and is currently in maintenance mode, while DOTS netcode solves for ECS and is in Preview. We currently support UNet’s LLAPI for customers shipping on consoles, but it isn’t a full solution for most higher-level networking needs. Luckily, Unity has a strong and very talented open source community and partner ecosystem, and their contributions provide numerous solutions that are well-suited for different scenarios.

We’ve recently reiterated our commitment to contributing to this space with a first-party Unity netcode solution in our Road to 2021 blog post. While we’re working on this solution, we want to make it easier for creators to explore and evaluate various netcode alternatives to make the right choices for their titles. 

Arm yourself with information

Our team has gathered feedback about some of the most widely used third-party netcode solutions, and we’ve created a decision tree to help guide you through the process of deciding which framework might work best for you.

To create these tools, we gathered and analyzed data from three sources: 

  • A survey of over 200 Unity users that asked for information about their experiences with specific netcode frameworks
  • Over 20 in-depth interviews with users actively shipping multiplayer games with Unity
  • Learnings from prototypes we built with MLAPI, DarkRift 2, Mirror, and Photon Quantum.

Customers scored and ranked the top netcode solutions across different axes based on their experience:

  • Stability/support: This was evaluated along three axes – the likelihood of bugs or crashes, response time to fix issues or help debug a challenge, and the likelihood of breaking changes to the APIs.
  • Ease of use: We compiled users’ evaluations of how easy it is to get started and perform common tasks, including the provision of good samples, documentation, tutorials, and the solution’s offering of simple APIs for prototyping.
  • Performance: To score this, we looked for limited GC/allocations, minimal latency overhead, performant compute, and ideally the ability to multithread.
  • Scalability: Similar to performance, we evaluated the solution’s ability to support a larger number of connected clients without a large sacrifice in performance.  
  • Feature breadth: We focused on mid-level features like object and variable replication, RPCs, scene management, and so on. We also looked for higher-level features like prediction and lag compensation.
  • Cost: This consideration factored in both the cost of the libraries/solution and possible hidden costs, such as operating overhead that has to be managed separately.

Before jumping into our study’s results and recommendations, it’s important to stress two points. First, choosing a netcode solution for your game is a critical decision, and you should still perform your own evaluation. We want to make the process easier for you by sharing our summary of the most common options, but you should do your own assessment as well, based on the specifics of your game. Second, this list doesn’t represent all of the alternatives, especially at the transport level, where many solid solutions exist, such as enet, litenetlib, ruffles, telepathy, and others.

The information below is a start, but we recommend that you also download the full report, where we go into greater detail about these third-party netcode solutions:


The PDF covers solutions most referenced by customers, but there are more! Some customers discussed other solutions for which we haven’t yet gathered enough customer evidence to evaluate, such as Forge, Normcore, Bolt, LL (Enet, LiteNet, and so on). We encourage you to add these to your considerations to see if they would be an option for your set-up.

Still need help deciding?

We’ve also created a diagram to help walk you through the process of making this critical decision. Please keep in mind that all abstractions miss critical details – we can’t possibly share every technical variable that might influence your decision – but these are some of the elements you should consider as you start evaluating solutions to support your game’s pathway to success.  

High-level guide to starting to evaluate a netcode solution

Here’s a quick glossary of some of the key terms used in the decision-making tree, and what do we mean by them.

  • Dedicated game server (DGS) – a client-server network implementation where the server is hosted on dedicated compute – i.e., separately from the client devices. This option is expensive, but scalable and secure.
  • Listen server – a client-server implementation where the server is hosted on a client device. It’s inexpensive, but not scalable and not secure.
  • Deterministic lockstep – a P2P implementation where only inputs are sent to all other players and synchronized in a “locked step” (i.e., synced for the same simulation tick all at once), and determinism on each client ensures that they all stay at the same state. This system is inexpensive and secure, but with complex determinism.
  • Deterministic rollback – an enhancement of deterministic lockstep where clients forward-predict inputs while waiting for updates. This setup is more complex but enables a more responsive game than lockstep. It’s relatively inexpensive and secure, but with very complex determinism and simulation.

To see our analysis in more detail, check out the full report. This in-depth overview will be more comprehensible if you have some familiarity with multiplayer and networking concepts. Need a refresher? This talk covers most of the essentials.  



We hope this information is helpful, and please let us know if you have any comments or questions about our analysis, or if you find any bugs or concerning data points.

42 replies on “Choosing the right netcode for your game”

Good article with factual information. I feel what’s missing is that, for each evaluation criteria, there is a lot more depth than just “netcode”. For example for performance, scalability and costs, that’s not just a question of netcode, it also depends on what tools you use and how you manage your infrastructure. The problem I’m seeing is a dev might go with a specific netcode because its great on the “scalability” or “costs” scale, but if other variables like infrastructure and server management tools are not taken into account in the equation, they might end up with some nasty surprises.

Given the 5-star scale here, I feel like Normcore should at least get a special mention, since for VR project its Ease Of Use would be rated at about 8, thereby ruining the scale of several other systems I’m familiar with. It can be used for non-VR as well, with maybe a 4-star rating for Ease Of Use. Support and stability is 5 stars. The main downside is low feature set, which honestly is what makes it distinct relative to the rest of the list, and therefore worth calling out.

Was using Photon PUN to develop a smaller version of MOBA title for over a years now for a customer project, I’m not very sure whether I’m choosing the correct networking for my game, even its wrong I think its too late to switch

PUN is alright until you hit a big amount of players, and have to scale in a cost efficient manner. Then hopefully by this point the game can make enough money to justify moving to a different netcode

You say MLAPI is the “best overall” but it uses UNET by default. This makes zero sense since you’re basically recommending in 2020 after explicitly saying it’s deprecated to continue using it? And if you want something that isn’t “in maintenance mode”, aka dead, then you need to roll your own or adopt another which adds much more nuance and complexity then this over simplified blog post says. Am I missing something?

While MLAPI does use UNet as its default transport, it is really easy to switch to another transport using the MLAPI installer. For example, when you click on the transports tab, you see Ruffles (made by MLAPI developer), LiteNetLib, and other options. UNet is the default transport because (AFAIK) it is built-in to Unity, so providing it by default causes less bloat (as opposed to including Ruffles in the MLAPI dll, even if you don’t use it).

It may be best for Unity to make note in the chart or article somewhere that they’re not recommending the default MLAPI you get. That’s not going to be obvious for most people. Netcode != transport layer but people looking for solutions that aren’t already specialized in this area will likely not understand. It reads “we recommend MLAPI”. There is a small note about transport level just above the chart but it’s not clear.
This may also apply to the others as well but I’m not familiar with all of them besides DOTSNetcode kind of which I know doesn’t use unet in anyway

Also how did this affect Performance or Scalability grading? Transport layer is a huge part of performance. If you use a transport layer with any netcode solution (not just MLAPI) that isn’t performance or fits your needs, then the netcode choice can be kind of irrelevant.

So for that chart/grading of Performance and scalability, what transport was used in this article?

These are great questions.

First of all, as Gavin mentioned, MLAPI’s only dependency on “UNet” is that it uses LLAPI as the default transport – which is in maintenance mode and is not the most efficient transport available today. However, LLAPI is also the only transport we’ve found so far today that is reasonably stable AND supports console launches, so we don’t fault MLAPI for keeping it as the default offering for now.

As for performance ratings, as we’ve said, the stars are an aggregation from 3 data sources:
– user ratings in the survey – MLAPI supports many transports, so it’s not clear which one users were using when they rated the solution for perf/scale
– in-depth user interviews and project evaluations – in the cases we discussed, some used LLAPI, and some used a variety of others including ENet, Photon, etc.
– our own prototyping – so far has included LLAPI and ENet, and Enet absolutely is the more efficient solution between the two.

All this said, you are correct – interpret the ratings as a “typical case” primarily from user ratings that were verified in interviews and prototypes. It is not an exact science :)

What was the data source for the ratings of DOTS-Netcode? (did you just rate it yourselves? how humble of you to put 4 stars in feature breadth)

So the performance ratings on each of these, and possibly other categories, you and we as readers don’t actually know what they mean and what the metric was for them? You’re just taking “user ratings”. There’s no actual testing being done here, in other words, these ratings could all be completely incorrect?

What about forge networking remastered? I was playing around with that lately and found it good to use. A bit hard to learn for a new user like me but under the hood, its multi-threaded and has a low overhead. Did you guys gave it a shot and if yes, what cause it to be not in the list?

I second this as well. Forge Remastered seemed to be pretty accessible. Last I was looking at it, there were some questionable performance problems but it’s flexible. It has all the basics you need for P2P and maybe a midscale, non-competitive game in my opinion. If you want to do a competitive, massive scale game you’d have to make a bunch of stuff on your own. I presume that’s maybe why it’s not listed here? Still, I’d make the same argument as some others in the list.

I’m also interested in any feedback that the author might have on why Forge was skipped or why it didn’t make the cut. It’s worth noting that Forge is free, completely open source, and the discord server just passed 3,000 members.

There are 2 versions of Forge:
Remastered – Large developer base and well tested
Alloy – New (2020) and made for larger teams who need extreme flexibility and the ability to modify behavior of Forge in a modular way without needing to modify the Forge source code.

Hi Lovepreet (& Brent & O)

We included Forge in the survey, and while 9 users had attempted to use it, almost none recommended it highly. It scored 2 out of 5 overall. The biggest concern cited was in stability/support – it seems that the original creators have not been as active recently, so bugs and issues have not received a prompt response. For this reason, we did not pursue it further into in-depth interviews and prototyping, and hence, we don’t have sufficient data to include it in the full report.


I’m also positive that’s not true. The discord is always active and the creator there, or at least some of the OG people, are always improving it and people using it. There’s even as previously mentioned Alloy which is version 3.0 of Forge. It’s being worked on to this day, with more updates than Unity even gives to its own packages. This is misinformed.

Ironically I’m the creator of Forge, I don’t have any mentions or DMs in Discord from anyone asking any specific questions related to evaluating Forge. I’d highly suggest checking out Forge Alloy :). The wiki on GitHub is up to date on how to use Alloy. Forge is free, open source, has no limitations, and I have no intentions to charge for anything. It’s a labor of love and the community is active, awesome, and contribute a lot to the GitHub. Also my email is a bit spammed now so I’m sorry if you sent something there, the Discord is the best way to reach me :).

I do want to point out that open source and GitHub are the biggest factors to this project. If I do get hit by a bus someday and can’t work on it any longer, well there are a ton of people who can and have. There is no need to link me personally working on Forge at every moment to the value of the library. It is a community project now more than it is mine honestly and I consider all contributors as the creators of Forge. So I suppose in that sense we have 46 (and growing) creators of Forge haha. With over 1,200 stars and nearly 300 forks of Forge on GitHub, there is no way the project will ever “die” :)

I thought Dots netcode will be the best thing.but as with unity’s these late reley behavior i am fed up amd i know many others who also has given up..unity always says one netcode is not suitable for every game.. everyone who is doing complex networking stuff knows that amd they also know that there are very less no of unity multiplayer title which use unity’s netcode (hlapi or llapi) because those netcode are never good enough for complex multiplayer stuff..that is why i switched to unreal has the best networking stack. atleast far more better than unity or unity’s hlapi’s a bit better version which is called mirror..though it is not even close to my suggestion ..stick with raknet,dark rift 2 or wven mlapi but avoid unet or mirror. and best thing will be wait until dots netcode is gets any stable release.

Hey Pritam, thanks for participating in the conversation and sharing your experience. Let me chime in for a few of the points you mentioned, hope this helps:
– First, DOTS is a great technology and is a big part of the future ahead :) We also understand that some users need stable options now, and that many prefer to stick with GameObjects, so we are pursuing both.
– Yes LLAPI and HLAPI are in maintenance mode bc they each had flows that required a full rewrite to solve, but, thankfully, the Unity community & ecosystem stepped up and thanks to them there are plenty of options to build multiplayer games in Unity today. We continue to accelerate releasing a solid & stable solution asap.
– There are multiple multiplayer networking games built in Unity (recent e.g. Mediatonic’s Fall Guys), so it is indeed possible to succeed today.
– Unreal has a great networking layer, but as we mention in the blog post, there is no single netcode solution that solves perfectly for every game.


Hey Alan, thanks for your comment. We did include Bolt in the survey. While it does offer a solution for client-server games, many users cited severe enough challenges with performance and scale that we found MLAPI, DarkRift, and Mirror to be better options to reach successful outcomes for client-server games. Once we learned of these significant struggles, we did not progress into deeper evaluation with interviews and prototypes, so the evaluation is not sufficiently complete to include in the full report.

Hello everyone, I just want to let you know that if you consider getting into MLAPI, and you get stuck during any part of the process, make sure to join our discord by clicking the button near the top of the page here: . The discord is full of people who are willing to help you out with your issues and help you make an awesome game.

I know it’s difficult to assess all the options as you mentioned, however I’d be keen to see a more of the results from your surveys for the adoptions of the different solutions if you are looking to publish those results?

As a business we’ve recently just evaluated the different multi-user options for our next project (so much so that this would have been very useful a month ago!), and very quickly came across Nakama from Heroic Labs ( and VERTX ( which are not listed on your findings? Did these solutions come up at all during your research?

We know of some users who leverage Heroic Labs for services, but we’ve not found users who have successfully used it for networking; therefore, we do not have sufficient data to offer recommendations for it. VERTX is similar, we have not seen any proof-points for it, and we cannot share a perspective about it.
As we state in the doc, the landscape is broad!


When I started my project this summer with Unity, it was clear the network landscape was ‘complicated’. Official support for UNET was in sunset mode and DOTS wasn’t ready yet. There were many 3rd parties claiming defacto status, but nothing stood out as a clear winner. I opted for Mirror based on the limited research I could find on the options out there that might be best for my small multiplayer game. It was a bit scary to think I might have chosen wrong and waste many development hours down the wrong path. Luckily for me, Mirror has proven to be the right choice for my needs. But I could have really used this article back then :)

Thank you to whomever wrote this blog post for anyone coming to Unity fresh now with a multiplayer game idea. This is the sort of guidance the community needs if you are encouraging first time game developers to try the engine, as I did.

Hey Sazboom, I’ll take your comment to the team behind the content, thanks for sharing. It was quite a team effort to process all the data, talk to customers & run the prototypes. Sorry that we couldn’t release it on time for your early journey though! Cheers ;)

To be honest Mirror is best of all with there is solution for everything. For example you can easyly implement Steam p2p with just change transport layer component. I would give just 5 stars Scalability just for this.

I think the point is that their test doesn’t actually provide any data so users should probably understand this blog post as little more than a public note that Unity’s solution for networking is pretty much the least ideal solution of them all and that there are better alternatives on the Asset Store.

The ratings and analysis are whimsical and unverifiable, at best.

Hi Jes, thanks for your comment and for sharing DOTSNet lib.
The report is scoped to the top options shared by the community and customers when it comes to building GameObjects-based games today. We added dots-netcode as a reference to the table but didn’t go in-depth with DOTS-based options because it’s not yet sufficiently stable for most users.
On top of that, the report doesn’t represent the entire landscape, but the most common entry points.
Hope this helps!


DOTSNet is made by the guys who make Mirror… which is pretty cool – it means that they have a lot of experience with game networking code so that explains all the good reviews. Price is pretty high. When my DOTS/ECS based games is ready for multiplayer I’ll definitely be giving that one serious consideration. Thanks for the link.

DOTSNET is currently 50% off. And it scales like mad. There are demos of 10k+ entities all broadcasting position/rotation running at like 50fps on a laptop and 70k entities running at around 20fps.

Comments are closed.