Unity's networking is DYSFUNCTIONAL.

State of the Networking:

My vps hosted master server still crashes every couple days, but Zumwalt is has reported that he should soon have an autorestart system for it ready to go.

I now have Unity powered dedicated servers beautifully integrated into my game - complete with fully automated connection initialization and load balancing. Unfortunately, although implementing dedicated servers has greatly increased the reliability of connecting to servers and and the average speed of packet transfers in my game, these advantages have been more than counterbalanced by a dramatic increase of the bug where NetworkViews refuse to serialize.

I can state with certainty that the bug always occurs between a non authoritative server and certain random connected clients (the packets always reach the server from the authoritative client instance correctly). This bug only affects NetworkView serialization - not RPCs, which always get transmitted correctly. This bug is also asymmetrical: The player who joined the server earlier generally can’t receive serialized views from players who joined later, but the latter players can almost always receive views reliably from the players that were in the server when they joined. If the earlier player exits and rejoins the server, the issue is reversed. And finally, the bug is highly selective: just because your client isn’t receiving the NetworkView packets from a given player doesn’t mean that other clients aren’t. From my experience, half or so of the players in each game can receive updates from everyone (even players who joined after them), and the other half only receive updates from players that were in the server before they joined it.

I have created a custom, super simple test project that demonstrates this bug - and sent it to Larus several weeks ago. I really don’t know where to go from here, and am starting to get pretty discouraged.

From my point of view, Unity is committing false advertising when they talk about how great their networking is. I have never seen a serious, physics enabled multiplayer fps type game that used Unity’s networking and that worked reliably. I feel like I have been some kind of test subject in a dreadful experiment - where a company releases a flawed product, claims it works great, and then provides no support when someone invests years of their life developing something with it only to find that the fundamental systems they were counting on don’t function as advertised.

Unity: Please prove me wrong!

-Aubrey

out of curiosity, how does the master server have anything to do with the speed of packet transfers otherwise?

I never said that it did - as you can see, I was speaking of dedicated servers.

durrr. I’m retarded. :slight_smile: sorry.

I’m wondering why I never read something about networking improvements in the change logs of any version since 2.1 or some infos in the roadmaps about it.
I’m pretty curious what will happen with Unity Networking in Unity 3.0+. Maybe they will silently drop it and replace it with something new ( like the Animation Editor in 2.5) ?


oxl

Well after almost 2 years of using unity’s painful networking stuff i decided to go the raknet plugin way. :x

Has anybody here played with Torque up to the point where its networking can be tested to this extent?

I’ve got the basic engine up and running, but you never can tell in 30 days what a product is really like, so it’s difficult to compare.

Their community gets just as uptight as this one, so it will probably take a lot of trolling around their forums to get a feel for how well the product is actually working and make a comparison.

There is no 30 day limitation on the previous indie version anymore, its free, so you can test it as long as you want.

And Unity Networking will likely not be dropped, because it is already RakNet, one of the strongest available networking layers in a price range most here can pay (the next higher I know is a few ten thousand dollar per title)

Also the implementation of RakNet is actually fine, it does the job its meant to do and told to do.
People just seem to ignore those points, try to do much more with it and then are puzzled why it just won’t work.

Glad to hear ! Though this argumentation makes no sense to me :

What does the first has to do with that “it is already Raknet” ? Because of the cash Unity may have spent on this ?

Well, show us one game, where it does the job its meant to do, maybe I was overlooking it. Please don’t post mine :slight_smile:


oxl

As for the “what has this to do”: well if a more powerfull networking is included, expect to pay more because each sold license of Unity has to pay higher license fees too. Thats what I meant :slight_smile:

Project: show me one project that actually attempts to use Unity 2.6, headless client and an optimized environment to do it.
Don’t expect magic, networking is an advanced to pro topic, not a beginner topic as which it is commonly missinterpreted.
Beginner + networking = lots of frustration and problems (especially if they move away from Network.Instantiate)

Common claims against the unity networking include bad stability, cpu hunger, losing master server connections and stuff like that and thats just not true.

I’ve had 10 headless clients running a modified network example (to cut the stuff thats headless client unfriendly or rewrite it accordingly) for 25 days on my WinServer 2008 Standard (Core2Duo E6600, 4GB RAM) and had 1s of cpu time per day on the unused ones and about 2.5s of cpu time on the server to which I connected for 3 - 5 mins per day to see if still all is working fine.
At no time, the servers got lost in the master server list (I’ve my own master server update function, I don’t relay on automagic like the masterserver property for this purpose as it does not work).

It looks like, to me, from reading the docs, that the people involved in writing the network stuff had no idea how networked gaming works. It also seems to me that the people involved in writing the docs have no idea how documentation works, either.

@dreamora:

I meant that I have the basic torque engine up and running, and was wondering if anyone can compare Unity networking to Torque networking.

This is very confusing… so are you saying that everything is working, so long as you don’t rely on unity to do it for you?

As you didnt’t show us one, I would like to show you mine, but I’m on (ex) Indie, so it shall NOT run around headless. :stuck_out_tongue:

And yes, I know that networking stuff is an advanced feature. It’s my daytime job since a decade and I worked with RakNet long before I discovered Unity.

Anyway, I’m stopping here, this has been discussed to dealth, and its always ending with " Unity networking just works, it must be you, noob.".

Maybe in my case, its true. Though I doubt that description fits to Robur, Ethan, Zumwalt or the others pulling their hairs of.


oxl

@Dreamora:

I am not requesting “more powerful networking”.
All I am requesting is that the networking work as advertised - or at the very least, that Unity acknowledge the bugs, and that they start providing all the users that the bugs are affecting with workaround suggestions and a roadmap for the bugs to be fixed.

When you said “People just seem to ignore those points, try to do much more with it and then are puzzled why it just won’t work.”, were you speaking of me? Are you seriously positing the idea that a 10 player vehicular combat game is beyond the scope of Unity’s networking abilities?

Your most recent post was a bit confusing to me: First of all, you begin on the rather shaky foundation of questioning the intelligence of anyone who discovers a flaw in Unity’s networking library. You also used several straw men to completely avoid discussing the issues that are currently the focal point of this thread: NetworkViews occasionally not serializing, and Zumwalt’s Master Server crashing.

It’s nice that your headless clients which were connected to 3-5 minutes a day worked well - but do you really consider that proof that Unity’s networking is rock solid, and that anyone who builds a real world implementation and runs into serious bugs is obviously just doing something wrong?

I understand your “show me” paragraph to be a challenge for someone to demonstrate that they are using Unity’s networking correctly, and are running into bugs - if so, I believe that Mars Explorer meets all your criteria except for being a headless client - which seems entirely unrelated to the stability of it’s networking implementation.

Thanks for sharing your thoughts.
Happy coding!

-Aubrey

Network service monitoring tool is coming, slowly but coming, originally I wrote it in c++, going to redo it in C# to see if I can get around an issue I found, will get it to you hopefully this week robur.
Zumwalt

FYI for those monitoring this thread, the master server crash that Robur is referring to with regards to my version of the master server, is the same thing you would experience if you use the latest beta build v7 from the download link. The only thing I did was make the thing available to run as a service instead of a console application, I changed no core code on its functionality. The problem that is happening that Robur has stumbled across is related to a buffer overflow issue, nothing more.

Which when this happens, C++ doesn’t handle it correctly and shuts down the service (aka crashes the master), if he was still running as a console application (which he can switch to, by simply running the original master console code with the same ports) the crash will still happen. I have tested this, same blooming error, just happens randomly. All I am doing at the moment is creating a watch dog service for Robur that will simply monitor the service on a timer, every 15 seconds it will send a heart beat to the service, if it gets a response, good, if it doesn’t get a response, it will simply do a net start command to get the mastser up and running again.

I will probably also enable an email alert feature to send him an email when the server is down and that action is being taken along with the results of that action.

The service also has verbose logging going on so he has complete logs to send to Unity of all data transactions up until the point of the crash. (just not the actual physical packet itself, that would be a nightmare). Robur goes days without a crash, but it crashes eventually and their is absolutely no pattern to it other than the same reason which simply points back like I stated, to a buffer overflow problem.

To Everyone Here;
Thank you all for your contributions to robur’s plight! I have no technical knowledge but I have played Mars Explorer consistently for over a year and I’m on this forum to remind anyone that these games are played by people…frustrated people…people that want an immersive experience. Said immersive experience is stopped cold by game bugs. I understand that server crashes are important but I am less concerned with server crashes and much more concerned about bugs inside the game that don’t allow all players to interact. I urge everyone to keep at this problem until solved for everyone’s benefit. Who’s at fault is not important. It’s WHAT’s at fault, am I right? Attached is only the tiniest sample of player non-connectivity. Based on discussion in the game, all players are moving about the map on their own screens and see all others laying still with the (no connection) sign.
Thanks!

Latest Status:

My master server crashes due to a buffer overflow every couple days, but Zumwalt pointed me to a windows service feature that autorestarts it as necessary - and it has been working great.

My dedicated servers are doing well.

My game’s networking is terrible.

There is a highly debilitating bug in Unity’s networking library relating to the serialization of NetworkViews - It has already been discussed in detail here and elsewhere. I provided Larus with a custom Unity project which I believe demonstrates the issue weeks ago. I have hundreds of players - and dozens of highly vocal ones (Greetings Kruncher!) who can attest that this is a serious problem - and has been for years. Unity appears to be simply ignoring me.

Aside from hearing from Unity, It appears that I have two options:

  1. Give up on Unity, and rebuild my game’s networking with a library that actually works.
  2. Figure out a way to work around this issue.

On the workaround front, the most obvious idea seems to be to utilize RPCs to transport all network data in my game - as they are unaffected by the state sync bug.

Can anyone offer advice on the practicality of syncing the position, rotation, and velocity data of up to ten players 15 times per second via RPCs? I understand that RPCs are a “reliable” transport mechanism and that they have considerably more overhead than an unreliably serialized NetworkView - could this overhead be prohibitive, or should I be able to switch over to RPCs without any problems? I will be running some experiments over the next couple days to see if RPCs are at all viable.

-Aubrey

You aren’t talking about the fact that your serialization / bitstream must have a constant size (which can easily be achieved by filling up a potentially smaller buffer with “dummy data”)? Cause that wouldn’t be a bug, thats a requirement of using delta compression, you can’t do delta compression against a variable amount of data.

What is missing though is a 4th network view mode: reliable (without delta compression) for exactly such circumstances where you just need the data to be received for sure.

Depends on your latency requirement. Low latency requirements are something you will have to drop if you work with RPCs.

Should Unity not be what you are looking for, then you have different options in different price classes. The list is starting from the least expensive to the most expensive solution

  1. Free crossplatform .NET: Lidgren (the ENet of .NET)

  2. Windows Standalone: DarkNet

  3. Large scale with lobby, rooms etc, tcp: SFS Pro, Neutron
    Large scale, high performance, low latency udp: Photon

  4. Ultra large scale and expandable to cluster, low latency, secure and optimized: NetDog

Mars Explorer server list restarts are very fast lately, ten-fifteen seconds in my experience.

Networking on Mars Explorer’s dedicated servers has recently degraded to 100% of players displaying the dreaded (No Connection) badge 100% of the time.
Those in the know have stopped using them.

We game geeks wish we could help you Aubrey.

No reply requested. Just keep on keepin’ on.

No Dreamora - I am not using delta compression, and don’t need a “reliable” bitstream in which each packet is error checked. Each player’s vehicle in my game has it’s own NetworkView, which uses an unreliable bitstream to sync positional data according to this script.

The problem is that at certain times (which seem completely random, and are becoming so frequent as to be the norm), everyone’s NetworkViews sync correctly with the server - but never make it to other connected clients. Any RPCs sent by each client are correctly transferred to other clients, but not a single NetworkView serialization ever reaches non authoritative clients from the bug effected players.

If you would like a firsthand demonstration of this issue - please check out this beta version of Mars Explorer, which includes dedicated servers:
http://dat.marsxplr.com/211/play

Join a game, play for a bit, and you should soon see new players who join and have “no connection” appended to their names in their onscreen badges and in the “Active Player’s” list. Each player is instantiated with a “non connection” flag, but the flag is cleared the instant that the player’s first NetworkView serialization is received. Note that the NC players can fire lasers, deploy and retract their wings, and chat just fine - RPCs are not affected by this issue (and are very helpful to demonstrate that I do indeed have the NetworkViewIDs properly configured).

Low latency really is a requirement for me - this game includes elements of vehicular combat after all - so I suppose that that rules out using RPCs instead of NetworkView serializations. I will create a test RPC version of Mars Explorer anyway just to see how it works.

If Unity’s networking worked correctly, it would be exactly what I am looking for! It is simple, elegant, integrated nicely with the rest of Unity, and would be more than ample for a project of this scale. Since it doesn’t work, if I don’t hear from Unity, I guess a switch is in order. Photon and Lidgren both look interesting, I may end up taking one of those routes.

Has anyone used Lidgren in a Unity FPS project yet? I couldn’t find any Lidgren powered projects on the Unity forums, but a simple library library like Lidgren might be just what I need.