Choosing the right netcode for your game

I'm disappointed.
Or maybe this is the wrong word. I am Shocked. I'm angry.

Unity, my dear friends, I love you guys, I really do, My company and it's games are made on Unity, and I have done plenty of consultant work for companies making real production multiplayer games. and I can tell you, this blog, and this report is just.. Wrong, I mean.. completely wrong.. outright. misinformation.

Who wrote this blog? who made this research?
Is it anybody that actually knows how to make multiplayer games?
Doesn't seem like it.

I am just perplexed. This document reads like a high school report. I don't want to offend somebody but really. it does.
Somebody has to be harsh and say the truth. as example you use a unknown made up term "DGS", again, no offence to the author, it's just a very entry level paper, which isn't expected. Neither is networking entry level stuff

Sorry for the longread but here are the facts.

TLDR:
- You are comparing completely different things, more like apples and oranges, on arbitrary undefined meaningless statistics.
- The market research doesn't include half of the solutions.
- Some solutions are outright a wrong way how to network your game and will hurt anyone trying to build a game on them.
- The products are not tested on actual real world production games successes.
- Winner is not a winner
- Unity has no viable solution.

Wrong compare
Each solution presented is very different, some don't do much for you more than syncing some variables/RPC's you present it, some take the whole task of networking out of your hands so you can actually just make a fun game.
This is a giant difference. As example your "winner" MLAPI doesn't do much of what you want a library to do for you, Concepts like RPCs are fire and forget, you have no idea which order they come in. Every server auth movement example have to make up for this, by implementing reconciliation... this library doesn't take care about a basic tick-engine, correction, reconciliation, prediction, etc etc etc.
Whilst on the other side of the spectrum Quantum, is a fully deterministic framework where you can literally make a game almost like a single player game, and it's completely networked out of the box, you don't have to think about anything, it just works... and it's amazing too. How is MLAPI better?
The statistics you give stars for in your compare are just silly, it is not defined how you get those stars, what they mean and they are on points that are not even helping your customers choose a library. You have not provided any actual data, just your conclusion with no way to back it up (which basically means its arbitrary).
Also I seen some straight up miss-information and/or lies about some solutions (Quantum, Mirror, etc.)

Leaving out solutions
I understand you have to make a scope for this compare, but from my research and knowledge in the production game field, MLAPI is barely used, whilst Forge was left out, as example. (not that those are good solutions but just saying)

Wrong way to do networked games
I see the options a developer has to network their game in Unity as a trap into a minefield.
Once a developer chose a certain solution, and tries to make his game in it, he usually is stuck in it's (usually wrong) way of doing things. As a industry professional with experience, and in contact with many other industry professionals in the field of networked games I have seen too many projects fail.
Most networking solutions are focused on one thing:
How to pack data and send it and receive it, whilst this is just not how you network a game.
A networked game is all bout the simulation. Let that sink in, SIMULATION.
Everything revolves around that, How do you simulate a game, across devices. so for a player it is fun and smooth.
The way how to pack data, and take care about packet loss or delays, it is things way less important than the simulation.
Exactly in this field, most solutions fall flat, they don't take care about it, you have to build it yourself, so what is the point of the library then at that point?
Networking is way more than having some data on one end and having it on the other end.
Even worse is advising people to use a low level library that uses TCP for it's reliability, ever network engineer knows that TCP data will push UDP data out of the pipe, which is why reliable UDP libraries were designed in the first place.

Real world production games
This is the big/main one for me, What actually should matter is what games have been made on each solution, and what these developers had to do/workaround or make themselves to make their games in a released and working state.

Winner is not a winner
You recommend your users to MLAPI as the best overall, I want to say that this is biased.
The lead developer recently got hired by Unity (this is not mentioned)
There are no launched games or proven to actually work in real world scenarios (both MLAPI itself and the relay and punch and its udp library) Compared to other solutions there is really no community surrounding it.
The library itself is basically a re-hashed version of UNET, which by most is deemed not a good library or the right way to do networked games.

The real winner, is a solution that solves the problems your users have to make a networked game.
hint; it is not MLAPI or Mirror.

So this is what you recommend... a fresh re-hash of your old UNET-architecture with no launched games, not proven to work in real world scenario and no community almost?
Where the author works for you since this month..

Unity has not it's own viable solution
The real reason we are all talking about these things, and we are having libraries to compare is because Unity has not reacted to the market and presented us with a proper networking solution developer in-house, it has failed on this job for 10 years already.
Every solution presented was a wrong way to do networking, from Raknet to UNet and now to the new dots networking, this is not how you network a game.
You guys have to get together, possibly to be harsh, fire the networking team, fire the networking lead, and start over.
Find real industry professionals that have multiplayer production games under their belt, hire them, give them a salary they cannot refuse steal them if you have to.. Let them make an actual multiplayer solution that we can use.
Recently with all the IPO build-up you bought companies that didn't help your customers, like Multiplay, or Vivox you paid millions!, why don't you guys use such money to hire good developers with multiplayer experience.. or as an alternative buy up Exitgames/Photon, integrate it into the engine, they seem to have multiplayer down. That would have been an actual useful acquisition.

Whatever you do, the clock is ticking, Your competition, as example Unreal has a good multiplayer solution build into the engine for years, and developers are not blind, if your choice is to walk this minefield, or roll your own solution, or just go for the competing engine.. think about it.

With love and hope,

Maxim.

 

Ok, I've never written much on this forum. But I fully share Vincenzo's thoughts.

I would just add that it is useless and counterproductive to publish such articles. I understand the need to make Unity look better than it currently is. And I think I understand this need.
But this is masochism.

You haven't been able to come up with a decent solution in ten years and keep moving forward as if we haven't all noticed.
And the more we ask for a decent solution, the more you keep feeding us terrible and unclassifiable things.

I'm starting to get fed up, I'll start evaluating alternatives, like everyone else.

 

Mirror is not using Linq in hot path.

We would kindly ask you to please stop publishing misinformation about our work.

 

Hi, And welcome to his forum!

Years? feels more like 3 Decades.

I love when developer talks about of what they are actually doing with all the difficulties and characteristics. Probably this blog is more for or from marketing. We are all pointing eye to the Unity framework because it has done amazing things and we pretend. So this is the Unity 2021 software roadmap. I look forward to March 2022 when Unity 2021.3LTS will be released.

 

Can you stop using fall guys as an example (I see someone mentioned it in the comments)? They wrote their own networking and as such they’re not an example of “hey look, you can do multiplayer in Unity”.

Because yeah, I can potentially do anything if I write my own rendering / input / UI / networking / audio / light mapping (all things a game engine is supposed to handle), but if I write my own because your features aren’t there or are bad, you don’t get to say “hey look, you can do X with Unity, isn’t Unity great?”, okay?

Going back to this article:

1. Unity does not have two solutions. It has an abandoned one and a not ready one, which adds up to 0 solutions. (This describes a lot of Unity features these days sadly)

2. That there are so many, good even, community solutions is a result of people getting fed up with how you handled networking so far. It’s proof you’ve managed things poorly. You don’t get to use them for your marketing and you don’t get to judge them.

 

Also since in the blog post you’re implying that you’re covering the most common networking solutions and ratings are based on the feedback you got from customers: are you telling us DOTS networking (a solution with 0 major games on the market I believe) is a very common, highly rated solution, based on feedback from your customers or did you rate it on your own, based on nothing?

 

If you want to have a production-ready and easy to use networking solution you also need to have a good gameplay framework.
UE4 is a perfect example - by grabbing a sample project and compiling it you will have an autoritative client-server based action game (skeleton of a game of course) with the quality of UT ( or Forntnite these days) with features like client-side prediction, rollbacks etc.

This not only includes a "networking" solution (non-reliable and reliable state replication, RPCs etc) but a solid foundation of using it in a proper way - all the game building blocks: server-side game controller, player controllers with local prediction etc.

This approach works good because it not only makes things possible to code but shows a proper way of doing so in the lease problematic way.

Unity should really make a good gameplay framework (or a set of frameworks fopr action games, turn based games etc).
and then build a networking solution that works well under that hood.

For now, there is no even an out-of-the-box character controller available from first party devs...

 

Just a correction, Photon Quantum supports up to 64 players (not sure if this information is available in any of their public materials).

In the Road to 2021 blog post, it's stated:

Do we know if Mediatonic used any of the publicly available networking packages? Based on their dev logs it sounds like it's all custom, and if so maybe not the best example!

 

No one using SpatialOS? Interesting as it's the only networking that supports both Mono and DOTS.

 

It's been 20 days

 

The problem with Spatial OS is that it's a typical big Venture Captial blow up company.
And they claim to have the most amazing solution, and looking at their SDK, it isen't bad. They use kind of proper game networking models, nothing revolutionary (like Photon Quantum) But at least get the basics right for Eventual Consistency, and scaling across multiple servers for an MMO.

The problem what i heard from developers using their tools is the price, The prices are so high that even if your game gets successfull you are unable to make any profit because of the insane CCU and server hosting costs they ask. meaning any MMO you build or even small game simply has to pay too much premium to Spatial OS, and it's basically a sinkhole.

This is why that famous Spatial OS MMO quit.

Looking at their game they build a custom networking based on unity stuff. from the looks of it it's a basic Client Authority, syncing player state. So nothing fancy. Easy to cheat, not very good.

 

At least first server instance (100-300 players) is free. Unlucky that Unity bought Multiplay that created conflict of interest.

I guess over time they will lower their pricing but looking at their news from time to time it seems like they are focusing on Unreal a lot more. It could be a lost opportunity. Even if right now it's pricy and in alpha state who knows if in 5 years 500 players multiplayer won't be a standard and Unity will be left behind.

 

Unity is already left behind COMPLETELY on multiplayer compared to other engines like Unreal.. So that is not news.

 

Not completely: Fall Guys, Among Us, Garena Free Fire, Escape from Tarkov, Rust, Albion.

Obviously all of them have to use custom solutions. Albion uses Unity only as rendering layer.

 

So because the company that wants to "democratize game development" Unity has no solution at all, the only successful multiplayer games on the platform use custom solutions. Which are very hard to build.

If you make a similar list of successful unreal multiplayer games, almost all of them use the build-in network engine...

You exactly proven my point. Unity is been completely left behind on multiplayer.

 

Unity "has no solution at all" because it is in development, not because they aren't working on it. Yeah they are going a whole lot slower than I would have expected (and I'm skeptical about their commitment based on past behavior), but you're talking about it as if they have no plan for an in house solution at all when the opposite is true.

 

They really don't have a real plan though let me explain.

Their current plan is:
- MLAPI will become a package for unity (possibly with some fixes/additions) as an official network solution for Monobehaviour games.
- Networking Package will become the network solution for DOTS based games (won't work with monobehaviour).

So the problems with this plan is this:
MLAP
MLAPI is unproven, untested, no production games build on it.
It does not come with even the basics of what you need to sync your game state and handle the simulation, nothing happens on ticks, no prediction, rollback, etc. it's nothing more than a RPC system with fluff on top.
It's basically the same Stuff as what UNET did (Syncvars/RPCs), which even Unity agrees today was not the way to network a game.
The relay included is untested... And there is almost no community using it or working on the project.
It's code is convoluted and looks like Enterprise software i had to write back in the early 2000's which performs bad because of all the interfaces, inheritance and overloads and properties.

Networking Package
The new Unity DOTS networking package Unity has been developing now for 3 years, it is not moving anywhere, the last 12 months the updates posted on github have been nothing more than some small tweaks. so this project seems to be dead now or at least moving in very slow pace.
The contents are lack-lustre, The techniques used are ALRIGHT, there is Eventual Consistency here, some delta compression and other stuff, but it's implemented in a very convoluted way, completely forced to be on Jobs and DOTS which actually hurts it's performance, throwing threads at a problem doesn't make it faster perce.
Another problem is that DOTS itself is unstable and unfinished, and No games are being made on DOTS, except some hobby projects. The estimation from the professionals I know that work with Unity, and Unity developers themselves is that DOTS is not ready for at least another year, but also that project seems to go very very slow now and doesen't meet any of it's targets so who knows..

I would no be surprised if unity gives up on DOTS in about a year from now, the IPO is over anyway. the money has been made, and then they will start to fix what they have. perhaps.

 

I would like to share with you my last product, it has the potential to help a lot of user cases because it integrates the three main communication methods used in all kind of applications, not only games.
Until it gets the review to be published, here is the main Sockets Under Control description.

With this I'm trying to discharge developers from basic problems of communication, allowing him to center in the interchange procedures.
I'm not really sure if there is a way to fulfill all game needs with a full featured layer, normally the best results are achieved using custom/adapted solutions.

I've tested this asset successfully using industrial environments (factories and gambling) with 100+ concurrent users, custom local and online servers, several technologies and different devices communicating all at once in real time.

Hope you find it useful, and give me feedback and support to improve it at maximum keeping it simple as it is (at least from the user perspective, it took approximately five years in development).

 

Sockets is like the least important thing in game networking, like seriously the least important. It's all about syncing game state, handling client input, prediction, correction, rollback, and so much more. it's about how you handle the game simulation.

You can find 385903 socket libs online and Reliable UDP libs and so on, they are not special or interesting.

 

Thanks for the feedback, I used to think the same until I had to develop my own real time networking system using WebSockets (including a custom cloud server as a hub and other two TCP servers for game authority and financial accounts) and synchronizing it with a local UDP network (because broadcasting was mandatory).

Then I found the way to join all those 6375618 partial features into one single comprehensive solution, perfectly accurate for all purposes, because it not only works in UDP but also in TCP and Websockets, covering 5 different operative systems, 5 web browsers and 4 development environments/platforms.

Once you figure out your all-purpose game synchronization system, please build it on top of this sockets, they will save you countless hours of technical problems and support. Believe me, that's what I do for a living.

 

Do you have a source for that? This is the first time I hear about it

 

Sadly this has been leaked on discord server by the developer of MLAPI. Probably should not be a public information yet. But it is legit.

 

@DavidSalgado
It has been weeks, and the misinformation is still there. Why does it take so long to fix a paragraph in a PDF?

 

I'd like to see actual benchmark results that were mentioned in pdf. Facts not opinions.

 

I have some feedback.

Positives.
Its good to have DOTS based networking. The tech looks promising in its own way.
Negatives.
You cant use open-vr with NetCode and QA's answer to my question was that its not the NetCodes fault and bug request should be directed to Valve.

But why does the open-vr work with other network solutions?
I also took at the source of the error in the netcode and the origin was a such unreadable long function with full of magic numbers I don't think this NetCode thing is going to work for me.

 

I wrote a really long reply here exposing pros. and cons. for all the libs we've tested. Decided against it. Here are my, utterly subjective but fairly well evaluated, opinions. Take them for what they are.

TLDR:

• Don't use UNET stuff by default. If you really have to, use mirror.
• None are a magic bullet. Those that pretend to be so come with platform-lock-in, weird pricing and or paradigm shifts and a high dose of risky tech-lock-in. There's always a balance to be had.
• If your game is simple enough, build your own. ( it really is not all that difficult for most genres )
• If you plan on supporting multiplayer through your long-tail ( profitably ) stay away from pricing schemes you can't correctly estimate. Most 3rd party providers can't ( or sometimes won't ) correctly project expected usage either.
• Use Playfab for all your online needs at first. Simple to use, free while in development. No real lock-in or tech enforced. Be careful opting for it after release. See the above.
• Use LiteNetLib for all your network transport needs. It's free, it's stable and it's easy to use. Most 3rd party libs use it too when they say fast UDP.
• Ignore DOTS-NET for now. The only possible exception to this is if you REALLY need to have a dots built game ( and even then, I'd think twice about using DOTS-NET ).
• Do NOT ignore old-school solutions just because they are no longer trending. Client-server is valid, lockstep (especially timeout/ hybrid variants ) is valid, mesh-topologies are valid, etc. Just make sure you choose the right solution for your project.
• Assume every 3rd party provider wants to lock you in. Carefully read and query the vague wording around everything. Have answers in writing and guarantees wherever possible. Note customer support's tone ( especially to issues you raise ) ... you'll be working with them a lot.
• Try to separate library from hosting/ service. Cost savings are generally massive. Insistently ask how much this costs and if they can guarantee you have the option to migrate their stack somewhere else, whenever you feel like it.
• Run a basic SWOT and RISK analysis before settling into any kind of lock-in.

 

Using MLAPI now. NOT production ready. I'm under the opinion that Unity does not have a good solution currently.

 

I'm really new to multiplayer(I haven't really implemented multiplayer in my prototype mainly because there wasn't any universal solution before), could you point to some resources for this, I would really like to learn at least basics of implementing a custom solution

 

Guys, I'm a senior dev who works mostly backend services like this. If I was to start on a free library/service for this.. what features are key for you?

I'm assuming :
Position/scale of objects.
Physics "hits"
..anyhow I don't want to serialize everything, so I'd love key data points.

 

Look at what Tom Weiland has been doing, and expand on it. https://www.youtube.com/channel/UCa-mDKzV5MW_BXjSDRqqHUw