Discussion What are the pros and cons of available network solutions/assets

[EDIT 04/04/23] WARNING: This list hasn't been updated in a few years so a lot of information is missing and outdated.

This is a simple list of the best solutions and assets and their pros and cons so that I (and others) can make the best choice for their multiplayer projects.

Here's a link to a similar google doc where you can get more information on some of the solutions listed here, and general networking terms:
https://docs.google.com/document/d/...sr1N3UAunUG9rnisY/edit#heading=h.ch4goz9wecxs

Here's a spreadsheet with even more information. thanks @F-R-O-S-T-Y and @Jamster !
Link to the excel sheet

https://forum.unity.com/threads/ben...dgren-miniudp-hazel-photon-and-others.512507/

Cheers

Fish-Networking
Pros:
- Free, and no concurrent user limits.
- Original code base.
- TCP and UDP support; can be swapped out. Other supported transports are Epic Online Services, Steam, and more.
- Good documentation, consistently named and commented API.
- Regularly updated, fast bug fixes.
- Long-term support and scheduled/limited API changes.
- Released games on product proven to scale to hundreds of CCU.
- Advanced Area of Interest system with condition stacking, and Network Level of Detail.
- Client-side prediction.
- Lag compensation.
- Scene manager for scene instances, global scenes, connection scenes, match scenes and more.
- Network object pooling.
- Most features of any free solution.
- Encryption layer.
- Addressables support for Scenes and Prefabs.
- Allows for custom sync types, serializers, AOI conditions and more.
Cons:
- Unity dependent.
- Match making requires a third party service.
Model:
- Client/server, or peer to peer with third party transports such as Steam.

Photon PUN2
Pros - matured with plenty of examples and tutorials
- free 100 CCU making it easy to test your game
Cons - Difficult to implement cheat prevention
Model - Client to client via cloud server

Mirror
Pros - UNET + 940 bug fixes and improvements.
Cons - No Lobby and only one client per Connection. which were native UNET HLAPI features that have been stripped out.
Model - Client/Server

Netcode for GameObjects
Pros - Supported by Unity
- Integrates well with Unity Multiplayer services
- Official project samples provided
- Good tutorials out already (see codemonkey multiplayer)
Cons - made for small scale co-op games. No client side prediction
- Parenting network objects to child gameobjects is painful
Model - Client/Server

SmartFoxServer
Pros:
- Fully authoritative
- Fully extensible with custom server-side logic
- very mature (available since 2004) with a lot of examples of increasing difficulty
- exhaustive documentation
- integrated HTTP tunneling
- protocol cryptography
- specific MMO-oriented API
- extended lobby features: rooms, buddies, messaging, match making, etc
- database integration
- free 100 CCU edition
- both perpetual and elastic licenses
- fast update cycle in case of bugs
Cons (?):
- different approach with respect to other solutions listed above
Model:
- client/server

MLAPI
Pros - similar structure to UNET but with many more features and greater stability.
Cons - No Custom Messages or SyncedEvent
Model - Client/Server

MLAPI, Mirror and UNET HLAPI Comparison Matrix

LiteNetLib
Pros:

• No dependency on Unity
• Gives you all the control
• It works
• Included writer and reader objects for managing data in packets
• Auto packet fragmentation
• Reliable, unorder, fragmented and non-fragmented flags
• Do it yourself

Cons:

• Do it yourself
• Expects you to know how networking works
• Have to setup an ownership handshake procedure yourself
• Connection IDs are longs and arent garuanteed to be unique (0.8 rectified this)

Model: Reliable UDP transport library


DarkRift Networking 2
Pros:

• TCP and UDP support, or can be swapped out for any other protocol or network library you fancy
  
• No dependency on Unity
• Very low level and gives you massive amounts of control
  
• Fully authoritative and extensible
• Unlimited users for free!
• Very well optimized
• Pretty good documentation
  
• Runs on .NET Core * /.NET Framework/Mono
• Includes source code *
• Includes matchmaking system *

* If you purchase the Pro version

Cons:

• Only one developer (me!)
• Requires mid tier C# skills

Model - Client/Server

TNet
Pros:
- Unique "make multiplayer and receive save load for free and without efforts" feature
- Battle tested on games Windward and Sightseer (created by developer of these games)
- Almost out of box support for huge multiplayer open worlds (more than 100x100 km)

Cons:
- Out of box does not supports parenting of one networked object into another (but with commenting a few line of code it became possible)
- Some kind limited \ inconvenient for games which have many hand-made levels (scenes) with manual level design (but very powerful for open world procedural games)
- Not free (95$) and demo \ free version is not available

 

Network library benchmarks.

 

Photon PUN actually built on a custom enet for reliable UDP (allowing TCP and other options transparently, which enables support for more platforms) and it's best described as "client to client via server". The connections are not direct (so no NAT and no problems when the "host" drops out of a match) but the server is agnostic to the specific game's logic. It's also not just a relay, as it can buffer messages and store custom properties.

 

SmartFoxServer
Pros:
- Fully authoritative
- Fully extensible with custom server-side logic
- very mature (available since 2004) with a lot of examples of increasing difficulty
- exhaustive documentation
- integrated HTTP tunneling
- protocol cryptography
- specific MMO-oriented API
- extended lobby features: rooms, buddies, messaging, match making, etc
- database integration
- free 100 CCU edition
- both perpetual and elastic licenses
- fast update cycle in case of bugs

Cons (?):
- different approach with respect to other solutions listed above

Model:
- client/server

 

Cheers, I haven't seen that one. I'll add it to the list and check it out!

 

UNET + 940 bug fixes and improvements.

 

MLAPI, similar structure to UNET but with many more features and greater stability. Written from scratch. Here is a comparison:
https://midlevel.github.io/MLAPI/features/

 

Mirror is getting a lot of traction as it builds on the culture and community centered around UNET. It is under constant development and the authors are accessible via discord.

Whichever solution you go for, as you know, it has to be understood inside and out. I'd advise placing the level of available support and existing examples at the top of your criteria.

Edit: UNET / mirror is not peer to peer. You have the flexibility to integrate with a myriad of hosting services like Amazon Game lift, AWS cloud compute, Digital Ocean etc...

My UNET development servers authenticate via Steam and run dedicated instances on Amazon Web services. I have the flexibility to move it to just about any other hosting provision I like without being locked into a particular SDK.

 

Mirror Cons: No Lobby and only one client per Connection. which were native UNET HLAPI features that have been stripped out.

 

@TwoTen Does MLAPI have any demo projects? Does it support a hybrid TCP/UDP system where we can use TCP for things like chat/inventory/file transfer etc... and UDP for player movement/actions etc...?

And made easy ?

 

Socket Class Pros:
- Create your own custom implementation that is optimal for what your game needs
- No waiting on 3rd parties for bug fixes
- No black box code you can't investigate while troubleshooting networking issues
- No worries that your network API will get deprecated, leaving your project in limbo

Socket Class Cons:
- Requires more time investment to develop your higher level API than using a premade API
- Requires at least mid tier C# skills
- Includes more fiddling with byte arrays than you may be interested in
- Less available help than going with an established network API with a community around it

https://docs.microsoft.com/en-us/dotnet/api/system.net.sockets.socket?view=netframework-4.7.2

 

Forge Networking: https://github.com/BeardedManStudios/ForgeNetworkingRemastered

I'm currently debating about switching over to this networking solution. I was hoping some people had some pros / cons for this as well.

 

LiteNetLib

Pros

• No dependency on Unity
• Gives you all the control
• It works
• Included writer and reader objects for managing data in packets
• Auto packet fragmentation
• Reliable, unorder, fragmented and non-fragmented flags
• Do it yourself

Cons

• Do it yourself
• Expects you to know how networking works
• Have to setup an ownership handshake procedure yourself
• Connection IDs are longs and arent garuanteed to be unique (0.8 rectified this)

Model: Client-Server

The fact that this networking middleware is external and doesnt rely on Unity means that I dont need to worry if its deprecate or experimental (like the current twilight zone of the networking APIs in Unity). It also helps that I'm able to use this API in an external application in order to host my networking process when using the editor, which allows me to compile and keep the active connections running after a hot reload.

 

Demo projects are not really available. It can use hybrid TCP/UDP yes, but it's not supported out of the box. By default, we instead use a channel based approach where you can set the QoS.

 

yeah sorry updated demo projects are an essential to me, networking isn't easy and trying to make sense of another multiplayer framework without a quick demo project to see what it has as features to see it working and then look at the working code is a huge help. I did notice you had pretty old demo project for mlapi that was the github account but again should ideally be an example project folder that just comes bundled with the latest releases that way it works with the latest source and can be removed in the project, probably helps if the example project doesn't need any changes to project settings aswel.

It seems no framework is really supporting it out of the box or providing a example project of it working, I wouldn't know how it could be supported going by the fact it isn't already supported makes me think it's not that easy to add in the framework otherwise it would already be.

 

SmartFoxServer 2X provides TCP and UDP out of the box and you can decide which requests use either of the two.
Demos are available for multiple platform, Unity included. The FPS demo specifically uses both TCP and UDP.
http://docs2x.smartfoxserver.com/ExamplesUnity/fps

Cheers

 

I don't see why you want TCP? What's wrong with RUDP?

As for figuring out how the lib works. That's what we have the wiki for https://midlevel.github.io/MLAPI/wiki/

 

Will give that a look at then.

 

the comment was more about the example demos.. RUDP might be fine overall.

 

Had a bunch of conflicts with Websockets with Smartfox because every framework wants to use the freaking names for things and not use namespaces.. not really good seeing as it's a bunch of dll's

And the Unity examples are downloading at 130kb/s

 

I am not sure what you mean by that, what conflicts? Care to clarify?

Thanks

 

it was conflicting with https://github.com/RevenantX/LiteNetLib which I'm currently using in the project.. and uprooting it out at this point would be a hassle, I'd rather move things over to another framework that is in the same project bits at a time if I'm going to switch

 

Thanks for your input everyone, this list is getting huge!
Who knew there were so many options.

Please, if anyone is able, take a look at the list and suggest any pros/cons where needed if you have experience with the solution.

Cheers

 

This ^^^

If you want the entire solution to be TCP, that is fine. It has its pros as well as its cons. But mixing both TCP and UDP together can create its own problems. For example, how do you deal with successfully connecting only one of the two? How do you deal with only one of the two timing out mid game? I know it can be dealt with, but it could get messy, where keeping it all UDP, and just applying reliability to the traffic that you need to be reliable, seems to me actually a cleaner solution.

 

I posted this Forum in Forge Networking's Discord and got this response:

How does Forge [Forge Networking Remastered] compare to other networking libraries?

1. Open source: Unlike Unity [UNET] or Photon [PUN/BOLT] Forge allows you access to the source code. This allows anyone to improve or fix possible bugs in Forge. With UNET a seeming lack of official support means you're stuck with Unity's black box. It also means someone with a passion to learn can see how Forge operates.

2. Cost: UNET as far as I can tell has two options. Unity can handle everything for you from hosting servers, matchmaking, relays servers, and NAT punch through but you will have to pay them per CCU's for the convenience of having everything done for you. Or UNET allows you to host your own servers for free, but you will have to handle all the back end things yourself. With Photon you must pay to use any of their services.

PUN is a networking library which tightly integrates with Unity. Hosting servers, matchmaking, relay servers, and NAT punch through are all handled for you but there are downsides which we will discuss under Server Setup. BOLT is probably the most fully featured networking library available for purchase. It handles many things automatically that other libraries including Forge require you to make yourself, but opinions vary on the reliability of Photon's customer support and how good the documentation actually is. Forge on the other hand is completely free. However, paying to host your own server, creating matchmaking and relays servers, or making NAT punch through work, must be done by you. You can either do this yourself with the help of pre-provided templates or take advantage of the built-in platform features that Steam, Xbox, and PS4 provide.

 

Ceciphar posted this in the Discord forum so I'll weigh in! Massive disclaimer: I'm the developer, but I'll try and make this unbias.

DarkRift Networking 2
Pros:

• TCP and UDP support, or can be swapped out for any other protocol or network library you fancy
  
• No dependency on Unity
• Very low level and gives you massive amounts of control
  
• Fully authoritative and extensible
• Unlimited users for free!
• Very well optimized
• Pretty good documentation
  
• Runs on .NET Core * /.NET Framework/Mono
• Includes source code *
• Includes matchmaking system *

* If you purchase the Pro version

Cons:

• Only one developer (me!)
• Requires mid tier C# skills

Model - Client/Server

I wonder if it's worth compiling this all in a GitHub repository/GitHub.io page for people to reference and maintain in the future?

 

agreed

 

I'm happy for someone else to do this if they want to post the link here if you do!

 

Does anyone have experience using GameSparks? Particularly the Real Time Services?
I've played around with the Authentication, leaderboards, messaging system and data storage and it seems great for that.
It seems like the realtime service is pretty barebones in that it simply allows you to send packets between players.
You have to handle network instantiation, networked positions and network events yourself using the packets.
I really like how it works bar the realtime stuff, but I'm not sure I want to use GameSparks if I need to end up integrating another solution to handle the realtime synchronisation.

I'm going to run through this tutorial which will hopefully give me some insight:
https://docs.gamesparks.com/tutorials/real-time-services/real-time-game-example.html

 

I don't know if it fits in here but if you're planning to create a game with many entities (RTS, Moba, ..) you may want to peek into
https://github.com/proepkes/UnityLockstep

Still in very early stages though

 

I am too looking for network solution, i think that forge have authoritative player controller in examples so i might use that.

edit: i can't find where i saw it

I also found this, is this only for p2p?
https://github.com/Facepunch/Facepunch.Steamworks

 

I re-read the updated first post and would like to point out a few things that are sometimes overlooked.
Disclaimer: I work on the Photon team for 10 years plus.

About Sockets:
When you start implementing a network lib with Sockets, be aware that you have to make them run on each target platform with each new update of Unity and on all devices that may or may not be bugged each. Routers and ISPs can cause issues, too. You can sink a lot of time on this, even on well supported platforms. Consoles are yet another topic.
Any network solution should give you a big boost in this regard already.

About player-hosted games:
Connectivity between players is not a given - even today. NAT punch through is a must-have but requires a service. When a player hosts the game and three or more connect to that machine, you are in trouble when the host goes offline, crashes or is too busy/slow to run the game properly. Also, the network should better be good.
The more players you get into a match, the more benefits has a dedicated server.

About Dedicated Headless Instances:
Yes, technically this is the best approach to be authoritative. Be aware that you have to manage the instances and machines to run those. There are services to do this (but it's another service to book). This approach affects matchmaking. It is costly per player, if you need the server CPU and GPU to run physics and the whole game. Cloud hosting sounds good but may be costly when traffic kicks in. Make sure to load test with full rooms, maxing out a machine.
Of course, various successful games use this approach.


Just a few thoughts.

 

If your game is targeting just 1 or 2 platforms this isn't a big deal (like if you're just going for Win/Mac standalone), but if you're going for a large number of platforms it could enter nightmare territory easily, so good advice.

This is no joke. What seems like a simple concept has months of my time building out my own system to handle this type of thing.

 

I wonder why, for example, RakNet isn't mentioned?
From what I've read people have had successful experience wrapping it and using from c# / Unity.
Seems more reasonable than writing your own engine on sockets, with lots of low level problems already solved.

 

When RakNet was bought by Oculus, I think a lot of people somehow lost track of it.
There are dozens of "low level" libraries that make UDP reliable (on demand), save and provide a bunch of features as stable solution. Unless you want to make a networking lib, consider this as a lowest level you want to go. Again, platform support should be a consideration.

 

I think another reason is the original Unity network solution, which was recently removed, was based on RakNet. So at the time if you wanted to use RakNet, you might as well use the built in Unity networking. Problems with Unity's legacy networking, whatever their cause, and their deprecating/removing that solution hasn't seemed to raise the appeal of using RakNet either, especially with more alternatives today than at the time.

RakNet's own website still claims it is integrated into Unity, and basically to just use the built in networking still rather than providing installation instructions, or to contact them for licensing of newer RakNet versions. Since it is no longer true that RakNet is integrated and has been deprecated for years, this doesn't inspire a lot of confidence in RakNet working with Unity either. (I have no idea if there are any problems, but if I was looking into using RakNet with Unity and saw this page, I'd probably just click away after seeing the out of date info still posted as current)

http://www.jenkinssoftware.com/raknet/manual/csharpunity.html

 

I agree with you, but you make it sound like there is a different solution instead of using sockets?
Sure if you use a networking lib you don't deal with them directly, but the libs still use sockets somehow/somewhere in their code?

 

I was unclear then. Yes, all network communication uses Sockets. I just wanted to point out that it can be tricky to deal with Sockets directly. Unity does a great job supporting Sockets on all platforms but there can be really sneaky issues from time to time.

 

Ah I see, makes sense, I was a little confused by that part.
I wonder if it would help to use .NET Core (or whatever it is called currently) for networking libs since their Socket implementation(s) should be built/tested with different plattforms in mind, atleast for windows/linux? I never tested it, but I think Unity supports .NET Core nowadays?

 

@Serinx LiteNetLib actually not client/server. You can use it as client/server but this is P2P (no diferrence in LiteNet)

 

Is it true P2P or everyone connects to a host?

 

LiteNetLib is not really a high level abstraction. Pretty much a Reliable UDP transport

 

UnityWebRequest
Pros:
- It's a HTTP request. How much easier can it get?
- Completely and utterly free, head to toe.
- The world's most successful networking technology.
- Write your server in any language and any platform.
- Want realtime networking? Use long polling or server sent events. You don't need web sockets.
- Great performance. Native buffers, worker threaded by default.
- Uses your platform's native web request, like libcurl or fetch, instead of mono.
- The Internet is purpose built and optimized, for decades, to serve HTTP data.
- The biggest software ecosystem in the world.
- The best documentation. Want to build an X using a web technology? Someone's already done it and wrote about it because "thought leadership."
- Server/client architecture that is proven, in a Darwinian way, to be the only one viable for any networking application besides copyright piracy and facilitating payments for illegal drugs.
- Extremely thoughtful in how it constrains you. Typically, there's a good reason HTTP/2 works the way it does.
- The best fit for pretty much every game people actually play that is developed by a small
team.
- A great fit for Apple Design, IGF, other festival winners.
Cons:
- A very bad fit for first person shooters.
- A very bad fit for Rocket League, a multiplayer physics game with, obviously, a deeply network-sync-optimized physics model that Unity doesn't have anyway.
- So a very bad fit for the top of the Steam charts?
- Big pain to develop web applications in Visual Studio on Windows. But the same could be said about iOS apps, and if you're in the business of making games for people who buy games, then this isn't a problem for you.

HTTP isn't at all as intellectually stimulating as writing your own networking layer. There's something to be said that stimulating is work that gets done, and so if your work isn't stimulating, you won't do it. I don't begrudge you for writing your own networking madness, because only the games that are fun to make get made, not the ones that are fun to play.

 

Can't confirm. ..can anyone confirm?

 

Hey,

I have started a google document where I am first trying to describe the high level networking solutions available. I've also written down as easily as possible explanations to some important concepts in game networking.
The document is still a work in progress. I have also enabled comments so if something is incorrect, should be changed or added, then you can either comment there or leave a post here.
I still need to somehow list all the features of each framework and also add suggestions on which frameworks to use for which type of games, add samples where the frameworks are used and much more stuff.

I am hoping to create a comprehensive guide to any developer that is stuck between deciding which networking solution to use. I am also hoping that this will be a collaborative work that can in future be pinned somewhere so it is easily accessible.

The link to the document:
https://docs.google.com/document/d/1ufcl6_ylbzthfmzzZ7HPiwDLR0sr1N3UAunUG9rnisY/edit?usp=sharing

Cheers!

 

That document would fit much better as a GitHub Repo, optionally with a Github hosted website to allow for contributions.

 

All the mentioned tools solve the gameplay itself, but how would you go about storing player data in between playing sessions? Thanks.

 

Any of the large Cloud Providers (AWS, Google Cloud, IBM, etc) have free tiers, storage, or limited practice server instances for you to save any data you need provided you have the skill and knowledge of their solutions.

 

Actually SmartFoxServer can be easily integrated with a database (MySQL for example) to store all the data you need.

 

Well both of these options are valid, but they seem a bit hardcore. Both are rather general. I would have to implement a lot of common logic (eg. player registration) myself. It's about a month of work and learning, before I get to the interesting game-related stuff.

The reason I'm asking is that I would like to create such a service. And I would like to make it such that you could already do a lot with it, with only little knowledge about databases or the internet. I already sketched out some code snippets of how I would like it to be used. Do you think anyone would be even interested at all? Thanks.