Choosing the right netcode for your game

Updated on September 14th 2021: For the most up-to-date information on Unity’s netcode solution, please refer to our Netcode page.

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.

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.

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:

• MLAPI
• DarkRift 2
• Photon PUN
• Photon Quantum 2.0
• Mirror

Note: 

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.

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.

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.