Navigating Unity’s multiplayer Netcode transition

 Recent News
Spread the love

 

Navigating Unity’s multiplayer Netcode transition

Unity Tech Blog –

 

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-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 classic Unity’s “headless” server runtime, and we’ve tested the ability to synchronize up to 80 connected game clients using its sample netcode. However, this 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 sample code from FPS sample for the higher-level netcode for a server-authoritative game (like forward prediction on clients and lag compensation on server). Given the Preview state of the new transport, you could use LLAPI instead if you need a more stable API surface immediately.
  • Fall (Q3) this year: Preview DOTS-Netcode will be available sometime this fall providing a server-authoritative stack, including entity serialization, delta compression, forward prediction, and interpolation. Given the Preview state, developers should still expect breaking changes to the API surface until the stack achieves verified state.
  • Spring/Summer (Q2) next year: Production-quality DOTS-Netcode – we’re targeting a production-quality release next spring/summer with the DOTS-Netcode and UTP 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 Q4 2019, the best you can hope for is what’s available today. We have a few developers already using the new Unity Transport Package and Reliability plus their own netcode based on FPS sample, so that route could work. If it’s too challenging, there are other off-the-shelf (OTS) solutions, such as Photon Bolt, that may also work for DGS games (note: we have not verified the quality of these OTS options).

If you plan to launch before Q3 2020, you can begin to adopt the preview version of the DOTS-Netcode starting this Fall, but expect some breaking changes to the API surface over the following few months. If your team is comfortable with this, then early adoption is the best way to future-proof your tech stack. If not, then consider some of the other options described.

If you are launching Q3 2020 onwards, then we recommend you target the new stack; it will be the only fully supported Unity networking stack from end-of-2020 and beyond. One additional note is that the new netcode has some strict dependencies on DOTS technologies, and developers will at least need to be comfortable creating a hybrid game with some classic game object code alongside some new ECS code. These workflows will improve over time, but early adopters will likely experience more ease-of-use challenges than with current UNet netcode.

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.

  1. P2P topologies: UNet and Relay services exist today, and UNet will remain supported in 2019.4 LTS for 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.
  2. DGS topologies: To ensure the smoothest transition to the future DOTS-Netcode, get started today using the Preview UTP with sample netcode from the FPS sample. While the FPS netcode isn’t using DOTS explicitly, it is built with ECS in mind and is a good starting point that is reasonably efficient. 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 Photon Bolt or Forge.

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!

https://blogs.unity3d.com/2019/06/13/navigating-unitys-multiplayer-netcode-transition/