Navigating Unity’s multiplayer Netcode transition

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.

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.

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!

66 Comentarios

You know in around 2014-2015 I was hearing about UNet. I was exicited. I waited soo long for it. And after it was released I had only problems with it. This time I will not let it happen again. It throw me years back because I could not release the game what I wanted to make.
I already started my own network system now. Ofc it takes time too but its less code.. and implemented my ideas and my needs. The best part is.. I can seperate server and client to make dedicated (console) server. It is super advanced.

The game Rust is good example. They just took raknet and made own system with it.

You guys are never learning, but thanks god that we have Steamworks and Photon services today so we can stay away from your failure attemtps of making something in the networking area since 2014 when UNet was introduced.

This is terrible advice. The best advice is to use steamworks.net. Honestly, with all the new features coming in Steamworks 1.44, enhanced latency using the Steam back end, etc, I think the use case for DOTS networking is limited to non-steam games.

These are ballpark figures based on real games’s data and experiences – largely assuming non-LAN scenarios. Agreed that in a LAN-based game (like VR installations), direct P2P could be much faster as long as the scale remains low. For large-scale LAN-based installations, we recommend a server that is hosted locally to achieve the best results.

For P2P games, many plan to run the server code alongside the client and adopt a client-server P2P model, so in this case, much of the new netcode could still be used. It’s still TBD if we create a new Relay, extend the life of the old one, or find another alternative.

Your post is unclear and probably very clumsy.. If I read well, that means all projects using the HLAPI have very bad performances and you know that since the begining. I understand you want to change everything in Unity, but you’re doing things bad, especially with communication.

So today if I want to make a multiplayer game with Unity there are not many options:
– Trying to open the FPS Sample, it’s heavy, so I’ll loose so much time to use something that will change in 3 months
– Using the UNet’s low level API
– Doing something by myself
– Don’t use the high level API because it’s very bad, we understood thank you
– Using a 3rd solution, but what about LAN?

When Unity 5 was released, you removed the old network API because it was so bad.. Today you’re doing the same thing BUT without any valid solution. You can’t ask us to spend so many time in the FPS sample. Is that really serious? A big company like this asking to its customers to look at a project to find themself how to use multiplayer?

Unfortunatly, this is the same type of communication of all sides. SRP is really not ready for production, we still have to wait, months to have something to use in production BUT you encourage us to use it, even if the label preview is on it.

The honest answer is that we’re still working on this actively today; it’s our goal to support «hybrid» games that blend classic Unity objects with new DOTS systems, but until we’ve determined the best path to get there, we don’t want to promise more.

I’m really excited about the DOTS networking future, and I’m not as pessimistic as most others in this thread, but there is something I’d like to point out even though it might come off as rude. It’s not my intention to be rude but I think it needs to be said. When Unity starts a presentation or blog post about networking and proceeds to talk about their server-hosting ambitions, it makes a lot of people in the community very uneasy. The main reason for that is this:

Server hosting is not *the* big problem that needs to be solved. Not even by a long shot. People are already perfectly okay with using Amazon or Google to host their servers, and they don’t feel like they need any help in that department. What they do desperately need help with is network game programming. They need a networking framework that makes it easy to make lag-compensated, client-predicted, cheat-proof, esports-grade online games, and they have been needing that for years.

It was not our intention to imply server hosting is the biggest challenge; we hear your feedback that building a game that connects players efficiently is the most urgent challenge. Thanks for making this clear.

Hello Brandi excuse me I’m a super noob in this and I’m learning Unity and i’m really bad at it anyway I have some tutorials about how to use basic multiplayer but now this are obsolete or not recommended, even this tutorials I have let me with a lot of questions (I’m not engineer nor study nothing related), and thanks to the information above I understand that the new complete multiplayer System, «DOTS-Netcode» will be available in 2020 3Q, that’s good to me because is a fair time to let me study how to make it work and understand the system so finally my question is can you please give a list of subjects, books , or similar to study, so that I put good base so I can understand easily the DOTS-Netcode and work with it when its Out, because like I said i’m really bad and looks like it’s gonna take me a lot of time to catch this, so for me it’s no bad the long wait, thanks in advance!

Let me reply to myself because I feel a little like a dummy. I failed to make the distinction between the DOTS-Netcode and the current Low Level Transport API. So I guess the high level API being made available in preview in the fall gives me a little bit of hope — there’s just nothing to look at currently, right? The only thing available at the moment to «see» or try out is what is available in the FPS sample.

Let’s see if I have this right. First trying to revoke editor licenses from competitor network services. Would be easy to chalk that up to mistaken legalese (clearly the clause was meant to cover streaming game services, and not managed hosting providers), but you were calling them on the phone and telling them «ooooo you’re in trouuuuble». Meanwhile you were busy deprecating UNet, which I understand as it’s an untestable, maintenance nightmare. If you only you had either a test harness for MonoBehaviour (I had to make my own), or your own engineers had used your so called «humble object» pattern, which the rest of the world simple knows as «not being terrible at coding». It WAS salvageable though. Nonetheless it’s hard to fault for for making it all OSS, which is indeed generous. But now it’s fully deprecated yet you have no alternative except this understaffed undertaking. Well cheers to the team for producing anything, to be honest. Of course they can iterate on it from here, but clearly you are spread thin and your networking is just one of the places it shows. I’m cheering you on from the bleachers, but I’m not seeing much that inspires confidence. I’m not buying licenses to grandiose future plans, as ideas are worthless without implementations.

Dude, seriously? This was debunked over and over again, ad nauseam.
«revoke editor licenses from competitor network services» Completely false. This was FUD from SpatialOS and spread around the net by angry arm chair lawyers.
«Meanwhile you were busy deprecating UNet» which is in 2022. And there will be plenty of options by then.
«yet you have no alternative except this understaffed undertaking» There are tons of alternatives, including Dark Rift, Photon Pun, Bolt.

«More than a year ago, we told Improbable in person that they were in violation of our Terms of Service or EULA.»
«Two weeks ago we took the action of turning off Improbable’s Unity Editor license keys»
These are statements in a blog in Jan by Joachim Ante. Is he incorrect about this also? Can you explain which parts exactly are FUD? My facts are from the unity side of the story, if we are willing to forgive me misremembering the in person communication as being a phone call. That’s my bad.

The deprecation warnings from the compiler seemed fairly clear cut about it being deprecated, as did the support article on the deprecation with the specific timeline. Does «busy deprecating something» not mean «very occupied with the deprecation of something»? Also note, deprecation and removal are not the same thing. Deprecation is more or less synonymous with discouraging, the idea being that you – as the API consumer – can’t say you weren’t warned that it might be removed at some point or that it’s not the optimal API to use. Obviously not a great choice for a new software project, right?

«you have no alternative except this understaffed undertaking» where «you» in this context means Unity Technologies. You disagree and then proceed to list a series of paid alternatives by third party devs. Gotcha, I know about each of those. I know some of the developers even. Some of those solutions are INCREDIBLE netcode, to be sure. Clearly everyone should be coughing up money for something from Exit Games, provided it fits their needs. But those are not Unity solutions, they are solutions which happen to exist in the Unity ecosystem. That’s all I meant …. not that «no solutions exist at all rawrrrrrrrrrrr». More the point was «wow you are pooching networking a second time, with a large community just waiting, because of what appears to be an under-allocation resources».

Maybe I’m totally wrong in something I’ve said, but it doesn’t seem that you’ve pointed anything out yet. Except possibly the phone call. Maybe there was a phone call and maybe not, but my point didn’t rely on whether or not telephony was the transport.

i don’t see how their clash is related to what we have today, so what you saying is not really a helpful feedback

the things that make me sad is 32 reliable packets in flight, locked receive to 60hz and fps oriented development progress while Photon is rolled out Quantum which seems really exciting for almost any kind of deterministic multiplayer games

Certainly we agree on quantum. Amazing stuff. I’m not sure I ever asked about how long that took to dev, so I’m equally unsure how to compare it against Unity’s work. I think Unity will get to that level, or close, eventually. They have the resources for it. But also when you reach a certain level of players, determinism starts to become rough. There are too many inputs to sync. Obvious though where it works, it is awesome.

I agree also that my statements are not constructive feedback, but merely pointing out what a long strange trip it’s been. And meant not as a kick in the crotch but more a «grrrrrrr I want you to succeed so why aren’t you?!» kinda way. But maybe I’ve got it all wrong about resource allocation and timings for everything to line up internally. Maybe they have it well handled and I just don’t see it that way from the outside.

From where you got those numbers? This graph doesn’t make any sense really, players count is an undefined factor, it can mean 1,000 messages per second or 100,000 of workload depending on a project, it can mean 1,000 CPU clock cycles or 100,000 per frame/iteration per client/player. The scalability section doesn’t carry any valuable information.

Same thing with the latency, from where 200 ms comes? What this 200 ms means? Network latency? Wireless or wired? What’s the nature of this latency? Processing latency? It doesn’t carry any valuable information as well.

I’m sorry but your DOTS netcode is FPS-specific feature-limited immature package that you crafted for about half of the year (or more…), and it doesn’t solve a single problem of the current situation with networking in Unity at all. Not even close. You can keep pushing snapshots interpolation, questionable codegen implementations, and other high-level abstractions on top of plain UDP sockets, but how it helps to an average customer?

Sorry but even though you have a point regarding the vagueness of the data in this post, you can’t just say something like your last paragraph without suggesting a clear plan as to what they should do instead.

Genre-specific network architectures are necessary for quality and performance. Codegen is the way pretty much all networking frameworks handle ease-of-use problems. Snapshot interpolation 100% makes sense and I don’t know what your problem is with it. «A layer on top of UDP» is exactly what a networking API should be.

And if all else fails, you have the transport layer to make your own custom solutions. So where is the problem? This solution will be suitable for nearly all online games except MMOs and RTSs. Just like UE4’s networking which allowed plenty of teams to make successful online games

> Sorry but even though you have a point regarding the vagueness of the data in this post, you can’t just say something like your last paragraph without suggesting a clear plan as to what they should do instead.

Say whaaat? A person who suggests using Photon Bolt over anything perfectly know what should be done for the general-purpose product, but Unity invests money into servers hosting company instead of software.

I don’t know what you are trying to say in other paragraphs it’s absolutely out of the context of the original question.

>Re-read the original question and think twice before wasting my time with another pointless reply.
Your question was «You can keep pushing snapshots interpolation, questionable codegen implementations, and other high-level abstractions on top of plain UDP sockets, but how it helps to an average customer?». You are talking about the «Multiplayer» repo here and you seem to have a problem with it because you ask how it’s helping us. Explain why «Multiplayer» repo is not helping us.

>Where did I say that something should be changed there?
So you think the effort put on «Multiplayer» is not helpful, and now you’re saying nothing should be changed? Explain.

I repeat:
You literally said that DOTS Multiplayer repo wasn’t helpful. And now you have to explain that statement.

This is not a pointless question; it’s a question that is problematic to you because you now realize that you were misguided and you’re looking for ways to avoid answering.

Photon Bolt is a networking framework that supports dedicated and client-hosted servers. It has state replication and tools for prediction & lag compensation. In many ways, it is similar to what DOTS Multiplayer wants to do, except the latter will have better performance for sure. But you have an unexplained problem with DOTS Multiplayer for some reason.

I am answering all of your questions and you are avoiding all of mine. This is because you are completely unable to answer my questions. Go ahead and keep embarrassing yourself showing the world that you can’t answer

I’m done trying to get answers out of you, but I think by now you have very clearly established that you do not know the first thing about networking.

As explained by my posts and Chris Burns below
– you do not understand what latency is because you think there’s a difference between a wired 200ms and wireless 200ms
– you very laughably cite «mature» transports like ValveSockets, Yojimbo and ENet as an example of why you think «layers built on UDP» are not good…. but you didn’t even realize that these 3 are all «layers built on UDP»
– You are absolutely incapable of explaining what you need in a networking framework

If this graph doesn’t make sense, it’s not for the reasons you have listed. Not that I actually want to defend Unity at this point, but now I am compelled.

I’m not sure where your idea that player count does not represent a specific set of network messages. A high quality networked simulation will attempt to assemble a single outbound message per user per ‘tick’ or ‘frame’ if you like, but not to be confused with a render frame. How it accomplishes that can vary, but that is the goal. So no … 1 player does not mean maybe 10 or maybe 100 msgs per frame unless your netcode is extremely basic. You will know exactly the amount of messages and it will be 1 or a very low number, or else, again, your netcode is extremely basic. You are correct that the amount of CPU is quite variable depending on implementation, but notice the graph doesn’t try to factor CPU at all. If you are making your own server, you will factor that and provide X compute across N games. If you are using Unity’s service they will have already factored CPU for you.

Latency …. this a blog post about networking. What do you think they mean by latency? Latency is not measured in terms of whether you are wired or wireless or using a tin can with a string attached. That is irrelevant. It is generally a measurement of the time it takes for packets to reach the remote endpoint from your network interface (aka whatever hardware on your computer is sending the data). Where does 200ms come from? Did you not read the Latency section below the graph? They bothered to explain this to you, but perhaps you didn’t bother to read it and felt you were asking a rhetorical question? Many (but not all) games start to fall apart after the 200ms point. Generally games are designed around a maximum acceptable latency so if you know yours then you can follow the chart. Maybe it’s not 200ms but it’s probably also not 200s.

Lastly, I don’t see DOTS as FPS specific, but OK. The only part I can get behind here is «feature-limited immature package», but I bet in some ways it’s already ahead of whatever your alternative was a month ago. That is unless you were going to pay money for something in which case you could get anything in between OK and *extremely* well crafted netcode. How is the «average user» going to figure out how to leverage a high performance, low level entity component framework without something like cecil to rewrite their code, or codegen to write their code? Then what if the system changes. Codegen is the optimal solution and as far as I’ve seen is fairly standard. You describe your data and the codegen figures out how to compress it and hands you back finished code for that. From there you can further optimize it if you know better, but more often the case will be that you don’t. This is all very weird because I’ve never seen someone say protobuf is dumb for doing this exact thing, but maybe it’s because the people implementing it aren’t «average users»? I assume by that we mean novice coders. No judgement, just facts. Unity is all about empowering those folk to make cool stuff.

«high-level abstractions on top of plain UDP sockets» you just described almost every API for networked simulation in history

I know enet inside and out. I have the benefit of over 20 years of low level IO and networking experience in C. enet is a very outdated, 1990s style IO model using the poll() API, which happens to be the slowest of all the IO APIs. Also enet is JUST UDP sockets, with a higher level abstraction over them.

In the more advanced netcode, the unreliability of UDP is handled at the application layer, and not at the transport layer. The conclusion I am drawing here is that you are mainly parroting things you’ve read and barely or not at all understood. Clearly you are dealing with challenges absorbing simple written information, whether from lack of desire or ability is the only unclear part. Also seems you might have a «tired of living in mom’s basement complex» which is causing all this hostility? Or maybe you aren’t even there yet :D

My diagnosis is that you don’t have a bright future in really any form of development environment, and you are going to badly need that codegen you tried to rail on. But I actually do hope you succeed in making something cool. Good luck, man!

> I know enet inside and out. I have the benefit of over 20 years of low level IO and networking experience in C. enet is a very outdated, 1990s style IO model using the poll() API, which happens to be the slowest of all the IO APIs.

Well, you have no idea what you are talking about for your 20 years old experience, my friend. Poll() is used there for efficient waiting of a single UDP non-blocking socket to avoid the overhead of communicating with the kernel when the socket has nothing to read instead of spinning and checking it. Open Google and start learning basics or at least take a look into the source code of modern transport like Valve’s GameNetworkingSockets where a similar technique is used.

> Also enet is JUST UDP sockets, with a higher level abstraction over them.

«No. It’s a full-featured protocol encapsulated into UDP»
I think you meant: Yes you are right that it is an abstraction, but it also features a reliability layer with reliable ordered mode, unlike Unity. «abstraction over UDP sockets» and «reliablity layer with full reliable ordered» are not mutually exclusive.

«avoid the overhead of communicating with the kernel …»
If you mean «avoid the overhead of additional unneeded IO syscalls» then it’s true, but that’s not exactly what enet does.
If you mean «poll can be called without resulting in a syscall» then no, it basically cant. If the parameters are invalid (eg. struct pollfd *fds param is not the compile time size known to glibc), then the glibc poll wrapper can possibly avoid a syscall. This will not be the case in enet, or really anyone’s code.

«… when the socket has nothing to read instead of spinning and checking it».
This is how poll is used generally, but there are caveats and also this isn’t quite how enet uses it.
One of the drawbacks to poll is that your thread can be spuriously awakened by certain signals. But it’s not bad with only one file descriptor.
In a way mentioning poll was a trap, since enet won’t even call poll if your enet_host_service timeout is 0, which I have seen several implementations use. Also enet does not exactly use poll to avoid syscalls, since it calls it at the *end* of enet_host_service. And the call will only happen if all sendmsg and recvmsg calls return EWOULDBLOCK and your timeout is large enough that there’s still something left for enet to sleep on.

So yes, enet is outdated and it does not achieve optimum efficiency. Does it totally suck? Well, not for what it is intended for, though there are better transports. Is it good enough? Probably yes, but not for much outside the gaming world. That’s all long moved on to libs with asynchronous IO, threading, and event loops built in eg. asio, aws-c-io, libuv. Regardless of what many seem to think, the challenge of realtime networked simulations does not strain your server’s network IO, and some solutions don’t use a transport reliability layer at all. Reliability can reside in the application layer where decisions on whether and what to retransmit can actually be made. The problem is almost always in how to shrink the amount of data you are transmitting each tick to fit within the MTU in such a way that it’s fast enough not to fall behind the tick rate, or to support X games per server. For this you will end up with something like a priority / LOD system or determinism and only sync inputs or some other solution.

Anyway I was wrong about your future as a dev. And I apologize talking trash in first place. You definitely have the persistence, but you have a level of certainty surrounding some things that doesn’t align with your knowledge. If you push past that you will go farther and faster. Also if either yojimbo or steam sockets have a C API I’ll review, since they’re both bsd 3clause.

Let’s recall how you started down this road of proving you might be the most ignorant person to ever try networking:
You: «What this 200 ms means? Network latency? Wireless or wired? What’s the nature of this latency? Processing latency?»

Definitely it means wireless latency + processing latency. You are on your way to stardom buddy :D Never stop pretend you know anything of substance … its going REALLY well so far ;)

You said: «You can keep pushing snapshots interpolation, questionable codegen implementations, and other high-level abstractions on top of plain UDP sockets, but how it helps to an average customer»

When I pointed out that almost every game network library in history is an abstraction over plain UDP sockets, you doubled down on your argument and provided a list of libraries that use plain UDP sockets. What you transmit over UDP does not transform the socket into something other than a UDP socket. I think you must know that, but you are just trying to climb out of a hole by digging harder.

I have worked with libraries that deliver all the high level features you want from Unity, not as a customer but as an implementer of the native IO layer. Those libraries did NOT have reliability implemented at the transport level AT ALL. If you think that is necessary then you are mistaken, though it’s clearly a commonly demanded feature. I understand the appeal, and I don’t fault anyone for wanting it.

In the case of ENet, you don’t need its socket abstractions to use the protocol with WebRTC for example or with any custom sockets. You don’t understand the difference between two simple things what is a networking library and what is a network protocol.

One more time for homebrew network programmers: Unity’s new transport is a plain UDP sockets without a protocol which means without: a secure connection association/handshakes, network conditions estimation and adaptation, flow/congestion control, recovery from data corruption, protection against denial-of-service and man-in-the-middle attacks, and many other essential stuff that makes a network protocol what it’s called.

I’m not impressed with your attempts to explain something more or less adequately, you better start reading books instead or take a few professional courses.

Let’s recap ….
Me: “high-level abstractions on top of plain UDP sockets” you just described almost every API for networked simulation in history
You: Learn mature protocols and transport layers such as Valve’s sockets, Yojimbo, ENet and so on before saying something like this.

Me: enet is JUST UDP sockets, with a higher level abstraction over them
You: No. It’s a full-featured protocol encapsulated into UDP

Phillipe: You realize that Valve’s sockets, Yojimbo, and ENet are literally “high-level abstraction layers over UDP sockets”, right?
You: Obviously? Of course they abstract sockets, I said somewhere that they don’t or what?
Yes, you literally did say that. Twice. But wait …. you are gonna basically say it again

You: Unity’s new transport is a plain UDP sockets without a protocol which means …….
You just did it again. You are confusing a socket with library features built over the socket. When your mistake is pointed out, you begin to explain (using 0 facts) how everyone else must be the idiot and they should google and read some books.

You: You don’t understand the difference between two simple things what is a networking library and what is a network protocol.
You merely *think* I don’t understand. You continue to misuse or confuse these concepts:
– UDP protocol
– UDP sockets
– higher level protocols built over UDP sockets/protocol
– abstraction

«plain UDP sockets» obviously means something to you that it does not mean to me or anyone I’ve worked with. You have now explained what you think it means. I disagree. A socket is just an identifier for you to perform IO calls. You are SAYING the word sockets, but what you MEAN is not the concept of sockets. You get that’s what is happening, right?

So far you’ve gone from «what is latency? wired or wireless?» to «you need to learn modern libs» to «you need to google the basics» to «enet doesnt use just UDP sockets» to «you need to read some books» to «you are a liar». Here are the facts:
OSI Layer 3: IP
OSI Layer 4: UDP
OSI Layer 5 to 7: Everything you have talked about or *meant* to talk about

Somehow you are talking about layer 5-7, but you are using terms that denote concepts from below, like «UDP socket». You stated that enet implements a reliability layer which is why its not just UDP sockets. Yes obviously it features reliability. But its reliability layer is not implemented at OSI layer 4, therefore everything it does boils down to just payloads over UDP sockets. You obviously know this on some level in your own way, so I don’t get what the charade is about. Layer 4 != Layer 5 or 6 or 7.

You are doing a poor job of proving it, but you clearly have a thinly veiled personal stake in believing I don’t know ANYTHING. Where I merely believe you misspoke, or are confused about some relatively minor details in the grand scheme. Honestly, I’m fine with you just telling everyone who will listen how some guy in the comments of a Unity blog post:
– lied about being over 40
– lied about having a career in C and networking IO
– wasn’t even willing to prove himself a non lying liar to a troll who wanted to see his upwork of all things

What people want: networking “archetypes”, with an option for full determinism, animator support, straightforward synchronization of custom data across connections, a transport layer with secure connection association and communication with the support of various delivery types or transport-agnostic modules (the second option would be perfect where byte arrays or Unity’s abstraction can be used back and forth).

This is getting really old. You are creating blog post every 1 and half year with all the plans and roadmaps for unity networking, yet you were unable to deliver any of it. Look at your git history of your new transport layer in last year… it was barely touched. If you want to see how networking is done you might look at your competition as that’s example of how it is done properly. Until unity is able to show something worth a while I would recommend you to use one of the available transports with you own hlapi otherwise you will end up rewriting you network code over and over. Unity networking is a joke atm but Im ready to be proven wrong…

I think you guys will have to deal with a lot of people who are angry at DOTS and who would want all new features to not be built for DOTS, but I’m here to show my full support for this new direction Unity is taking and I’m convinced people will soon realize that DOTS isn’t this big bad inaccessible monster that they think it is. The participation of asset store publishers will be key to the adoption of DOTS, I think

I’ve been heavily invested in studying and implementing online architectures in the past years (Quake 3, Tribes 2, Overwatch, UE4, Halo Reach, CSGO, etc….), and looking at the Multiplayer repo on Github, it seems like it’s really going in the right direction

I’m under the impression that it borrows concepts from the Tribes 2 model («Ghosting» of objects) and from rollback networking («Simulation» systems). Can you share some of your thoughts on the networking model of DOTS networking, even if not everything is set in stone?