Search Unity

Navigating Unity’s multiplayer Netcode transition

June 13, 2019 in Games | 7 min. read
Share

Is this article helpful for you?

Thank you for your feedback!

This blog was last updated, 27th April 2020.

As many of you know, we put UNet into maintenance mode because we believe there is a better way forward with our new connected games stack. Since this announcement, we have learned that many of our developers need guidance about the best path for their game during this transition period. In this post we’ve consolidated key questions you’ll need to answer and highlighted how you can make critical decisions about your networking stack. 

As you see at the bottom of the flowchart, you have many options, ranging from continuing to use UNet as-is, to targeting our new DOTS based Netcode (efficient, high-level netcode) and Unity Transport Package (lower-level networking stack). Which option you choose depends on the specific needs of your game. In this blog, we’ll walk you through each question and how you should think about them.

Scale

When we talk about the scale of a multiplayer game, we most frequently refer to the maximum number of players in a single session or connected to a single server. In this case, peer-to-peer (P2P) topologies typically struggle when you attempt to sync more than 24 players at a time, so for sessions supporting 25 or more players, we recommend moving to a dedicated game server (DGS) topology.

Beyond this, even on a DGS, the power and scalability of the server runtime also matters. For example, the FPS Sample leverages Unity’s “headless” server runtime, and we’ve tested the ability to synchronize up to 80 connected game clients using its sample netcode; we should note that this Sample is not yet using the latest transport, so please pull latest libraries for your game. However, the Unity “headless” runtime is not as efficient or scalable as our future DOTS server runtime, and it is likely difficult to scale the server much beyond that player count. At 80+ players per session, you’ll either need to become an early adopter of the new DOTS-Netcode and Unity Transport Package (UTP), or investigate creating your own stack.

One additional note, scale can also be measured by number of networked objects or AI (i.e. nonplayer characters), so for example, if your world requires synchronizing 500+ objects or AI, you will also likely need to move to the new DOTS-Netcode and UTP, and likely consider ensuring deterministic simulation with the new stateless physics.

Cheating

The next question to consider for your game is the likelihood of cheating. In general, the more popular your game becomes, the more likely it is that the game client will be hacked to provide unfair advantages. Even games that are not direct player-vs-player (PvP) still encounter cheating, for example, when you incorporate mechanics like:

  • Pay gates -- limiting access to content until players have purchased a pass or item;
  • Leaderboards/tournaments -- indirect competition that adds an incentive to cheat;
  • Prestigious/rare items -- low-probability items that are difficult to attain.

Experiences such as a shared concert have no incentive to cheat and are typically safe from exploitation. However, we’ve found that many games that become a popular struggle with cheating much more than their developers originally expected.

When hacked clients and cheating do occur, the best option is to prevent it entirely with “server authority”. With server authority, the server code decides who died, who won, what loot was awarded, etc., so even if the game client is hacked, the worst cases won’t reach other players since the most-contentious data will be determined by the server.

In comparison, in P2P topologies, the game clients are the authority of their data, so in these cases, the best a developer can do is attempt to detect cheating by sending data to the cloud, running rules against it, and attempt to ban the players who cheated. Unfortunately, gamers are crafty and love to reverse-engineer these kinds of rules to work around them, so often the developer finds themselves in a frustrating game of whack-a-mole. In most cases, DGS topology is the simplest and ultimately most effective solution to ensure a fair game that can earn revenue.

Latency

Now we need to talk about “latency tolerance” in your game. If it takes 1 second to get an update from the other networked players, how will the player experience feel? Will it feel so “laggy” that players quit? This is what we mean by “latency tolerance” - the maximum latency your game can tolerate before the experience becomes unenjoyable and unplayable.

Fast-paced games (like FPS games on PC/Console) usually require communication between clients to be less than 150ms, and ideally less than 50-100ms. In these cases, a DGS topology is required since a P2P Relay roughly doubles the expected latency per player, and frequently cannot ensure less than 200ms of latency consistently as a result.

Some semi-fast paced games fall somewhere in-between and could be supported with a P2P topology. For example, some shooter games on a mobile device can tolerate up to 200-250ms latency since the limited precision of the “fat thumb” inputs already implies the game will need to be a bit slower paced. In these cases, UNet LLAPI with a 3rd-Party Relay (e.g. Photon or Steam) could be sufficient, assuming your game has a low likelihood of cheating and player scale is small.

Most other games (even some card games) cannot tolerate greater than 1s of latency, which is why our “UNet” (HLAPI + Relay) solution can lead to some very poor player experiences depending on how far the player is from an active relay datacenter. It’s rare that this system is the right choice for your game.

Launch Window

Assuming that you’ve ended up with a DGS topology, we need to know when you hope for your game to launch, because your options will change based on what will be available. Here’s a high-level outline:

  • Right now: the Unity Transport Package and Reliability are available in preview, and this can be paired with the new DOTS Netcode preview. . Given the Preview state of these libraries, you could use LLAPI or external libraries instead if you need a more stable API surface immediately.
  •  Q2 2021: Production-quality DOTS-Netcode - we’re targeting a production-quality release in early 2021 for  DOTS-Netcode and UTP to be sufficiently stable and full featured. By this time, developers should have a fairly stable API surface, tech stack, and better documentation.

So, if you plan to launch before Q2 2021, you should plan to use off-the-shelf (OTS) solutions, such as Forge, Photon or DarkRift 2, that may also work for DGS games (note: we have not verified the quality of these OTS options).

I want to prototype my game today; how do I get started now?

This is a tricky question and depends on your outcome in the flow chart above.

  • P2P topologies: UNet and Relay services exist today, and UNet will remain supported in 2019.4 LTS for at least 2 years. The Unity Relay will remain active until at least 2022. If these options work for your game, it’s a fairly safe bet to go ahead and use them.
  • DGS topologies: To ensure the smoothest transition to the future DOTS-Netcode, you can get started today using the Preview UTP and DOTS Netcode. If efficiency and scale aren’t as critical, and you want a mature API surface immediately, you can consider prototyping with other 3rd-party netcode stacks like Forge, DarkRift 2, or Photon.

What's next?

We appreciate your patience as we work on the future of connected games at Unity. We're hard at work getting in place an end-to-end solution to help you make connected games that are performant, scalable, unique, and reliable. Stay tuned to the blogs and forums where we will be posting developer diaries keeping you up to date on our progress in developing services like DOTS-Netcode, UTP, matchmaking, and more!

June 13, 2019 in Games | 7 min. read

Is this article helpful for you?

Thank you for your feedback!