What exactly is better about third party networking options?

I'm digging into the Unity Multiplayer API more and also keep looking at photon. I don't know a WHOLE lot, but I am having trouble seeing what exactly is better about photon, or any other 3rd party option.

Raknet seems pretty feature filled and like a pretty mature solid API. I don't see Photon offering any features far and above Raknet. The only thing I'm finding diffucult in Raknet is that you have to handle your own client prediction, but as I understand, you have to do that in Photon as well.

I've heard that there can be NAT punchthrough issues with Raknet. But I also read certain people saying that they alleviated though issues by properly setting up Raknet in Unity. Can anyone with a good amount of experience using both Raknet, and another package, succesfully, and to their fullest capabilities, give me a rundown on what exactly third party options offer over raknet when it comes to making just 4-32 player multiplayer games? Not MMO's.

 

First of all, while Raknet is the core UDP library that Unitys networking uses (in the same way that my networking framework, SlimNet, uses the C# library Lidgren for the low level UDP plumbing), it does not mean that you can equate Unitys built in networking with using Raknet from scratch. The networking in Unity is closed source and is basically a black box which you can not fix yourself, ever, and updates are tied to new releases of Unity. Also being built on top of Raknet (which is a very good UDP-library) does not equal being a good networking framework. You do not have access to Raknet itself when using Unity networking.

The built in Unity networking is known to be inefficient for games with many players (I've heard a lot of people that can't get more 24 players running smoothly) or games with many objects that are synced across the network. In general it is very inefficient as to how it packages and sends the data.

Third party solutions (no matter if you use Photon, uLink, SlimNet, SmartFox, Player.IO, Baduma, etc.) usually offer higher scale-ability because their network protocols are more efficient and more finely tuned (shameless self-plug: My solution SlimNet, while not 100% mature yet, also ships with the full source code to the server so you can change whatever you want inside the server or just read and learn from it.)

But, if you are going to build a small game, with player hosted servers for say 4-24 players, go with the built in Unity networking, it's by far the path of "least resistance" when it comes to these type of games.

 

Hey fholm, can you elaborate with some more concrete data? In what ways are third-party networking more "fine tuned"? Can you give some concrete examples of how these networking libraries have implementation differences or additional features from the Unity networking model? How is the Unity/RakNet implementation "inefficient"? I hope this doesn't sound pedantic or come off as trolling, but I feel it is important to justify these claims based on the infinite difference in price tags =D

As far as I can tell, unity has a networking library with fairly fine control over what packets are sent, how, over what protocols and frequencies and the contents of those packages, delta compression, replication, and more! (All the features I've used on AAA games, and many I didn't have!). Perhaps other APIs are more intuitive, but I agree with the OP that I do not undertand the need for a third party networking library, with the exclusion of taste and preference. I can certainly build a poor and inefficient networking implementation using the built in networking library - but the same is true for the other implementations. Number of players is a poor metric, do you have throughput examples?

I could believe, for example, that Unity has a larger than necessary packet header, perhaps, causing packet bloat, but that's just conjecture, I haven't run a snoop utility to inspect packet sizes fed in and transmission packet sizes sent out. 1mb Uncontrollable Heartbeat packets lol? Err, I don't know, if it's not actually a data transmission problem but a connection management issue? Like, the Unity/RakNet implementation has a lot of overhead per open connection for some reason?

I have looked at a lot of different third party libraries but nobody really talks about how they are quantifiably better or even different. It's all pretty vague. I'd love one of these implementors to sit down and generate a technical one sheet outlining the specific differences.

An open source server is nice! I haven't inspected these packages but are these closed source?
http://unity3d.com/master-server/index.html

Again, I hope this doesn't come off as trolling, I am just curious to know the technical details. Could you elaborate on your statements? Thanks!

 

Let me start by saying that for many types of games the default Unity Networking is fine - but it's also lacking several features for more demanding games. I can obviously not speak on the behalf of every third party networking solution, and some of the things I describe further down are missing from even the more complicated packages.

The first and most glaring one, is the extremely limited amount of types you can write by default into the BitStream class. This can be worked around somewhat by using Serialize(ref byte value), but even then it still prevents proper bit-packing from being done, as the lowest resolution you have is 8 bits. When writing large amounts of data with usually small values, this is incredibly limiting.

The delta compression that exists in Unity is reliable-only, which makes it pretty much useless for fast-paced games with high real time requirements. The holy grail of delta compression (unreliable delta compressed) is not available, and can not even be emulated without significant overhead as there is no way from the Unity side to see what packages made it.

I'm not sure you can claim that unity has "replication" as a feature, there is default functionality for sending position + rotation + velocity of a transform (by making a network view latch on to a Transform), but this really isn't enough and doesn't even cover the functionality of the simplest of games. There are some inefficiencies in the Unity network protocol in a few places, but its nothing huge (using 4 byte IDs for example, when 2 bytes is more then enough) and the way you build your game will have a larger impact of course.

But there are a lot of missing features, like not being able to easily send unreliable one-off messages (unity only has reliable RPCs). Also how you have to tie every piece of network code to a separate network-view, causing over-head and problems when instantiating complex objects.

 

Some other points:

Unity networking is server-client based (not peer to peer). Servers are run via a Unity client (usually one of the players).
Most third party solutions are server-client based with a dedicated server. Games go on, even if the player who started the match (Unity's host) leaves. This can make a difference if the game goes on for 3 other players instead of being cut off from it.

When a Unity server is player-hosted, latency/ping is usually worse. It relies on the connection of the player acting as server. These connections are rarely any better than the connection of a dedicated server.

Unity networking works with NAT punch-through to try to improve connectivity: as players host the network servers, the connection relatively often fails due to firewalls/routers etc. This is worse across different mobile networks. Connectivity can never be guaranteed.

A dedicated server, does not need NAT punch-through. Connectivity is close to 100%. This can make a completely different impression on your gamers.

And you're right: Client prediction has to be done in any case. Solving this is pretty much depending on the game style you want to do, so it's extremely hard to solve out of the box.

 

Hi
As fholm nicely said,
1- Unity's built in networking's replication/state sync is not as powerfull as it should be
2- unreliable RPCs are not supported in built in networking
3- sending custom types/classes easily is not possible and you can only serialize certain types.
4- It's not really a good implementation of raknet. It's some versions behind and does not support many of it's features.
5- Some middlewares provide functionalities like load balancing, special database support, custom data serialization, ...
6- It doesn't allow you to instantiate different prefabs with different codes for clients and servers so always all server logic will be available in clients. uLink allows for this, i'm not sure about others.
When your game becomes more complex, this single difference of having network roles or not can kill your project or make it happen.
7- middlewares provide ready functionality like lobbies, match making, rooms, login, friends, chat and ...
8- Some middlewares allow you to use unity as your server app host or use other platforms like java, python or pure .NET code as game server instead of unity instances.

Also see links in my signature on how to choose networking middleware for more info

Hope this helps

 

Thanks guys, incredibly helpful. I'll need to take some time to consider all this new information.

Thank you very much!

 

Interesting thread, not sure how I missed this.

I’m working heavily with unity’s in built network layer. I almost dropped it for uLink.. I then noticed, It’s possible to build up an architecture over the basic network principles without having to use any pre-built API.

However I’m not interested in the engine of the network layer, so it probably has some performance issues.

How can one see the bandwidth usage?

I quoted the above as it’s an interesting concept that impacts architecture and is something I’m working with at the moment.

It is possible to split the code between 2 scenes or even 2 projects... The trick is to keep the network view ID’s consistent. Check this post out for more info, http://answers.unity3d.com/questions/50697/how-to-send-rpc-from-one-client-to-anther-while-th.html

But the concept of having different prefabs created on player’s server, client and the peers is very interesting, I’m trying to work out if this would work under an FPS scenario using uLink...

Would solve allot of problems or open the door to more, lol....

 

I don't know what exactly to say cause it's not clear to me what you want.
Yes it's possible to make unity's built in networking a little more flexible and it's possible for any other API as well. You always can wrap some code with some other code and create powerful high level concepts.

If you have any uLink specific questions ask them in forum.muchdifferent.com or ask me directly by email ashkan@nooparmy.com or their support. Instantiating different prefabs for different roles in client and server is easy in uLink. When you call uLink.Network.Instantiate then you can assign different prefabs to arguments of the function for prefabs to be instantiated for Owner, Server and proxy.

Hope this helps

 

Dude I just run through this

http://developer.muchdifferent.com/unitypark/Tutorials/uLinkAuthoritativeServer

No need for unity networking any more <3 ... Cant believe how simple it is and it streamlines the development process...

Now I need to get some money ...

Also thanks for the info, will hit the uLink forum if I get stuck

 

Just read their manual and convert your game, it should not take more than a few weeks at most.

 

No need, I’m rebuilding an architecture around the uLink system, I’m personally calling the arch MCP (Model, Controller, Proxy) the similarities to MVC are very clear… Development speed is through the roof … I can now finally drink beer while I develop network code!

 

Not an answer to the original poster question, but his point shouldn't be lost on the developers of third party networking solutions. I just did a cursory glance at the websites of a few of the commercial products mentioned here and though I found a lot of feature lists, I didn't find any lists of "why should I use your networking solution instead of what's built in to Unity?" That would be a really helpful list and would help you differentiate your product and explain why I should spend money on it. Just a thought!

 

Well uLink at least had a PDF showing why you'll love uLink compared to built in networking.
-having many crutial missing features like unreliable RPCs, custom serialization, being able to release new code much sooner and ... are some of them.