[Official] Multiplayer Improvements

Is no one else here concerned about UNET at all?

Let's look at the facts:

• 49 replies full of useful suggestions since March 10, 2016.
• 0 UNET changes since then. No improvements. No 5.4 fixes. No 5.3 path fixes. No support. Nothing.
• Almost no UNET improvements for a year now, except that Matchmaker which is only sometimes supported here because we have to pay for it.
• Bitbucket source code still outdated.
• Erik Juhl was last seen: May 31, 2016
• The whole UNET team has more posts on their 1 hour reddit AMA than on this forum.

Why is nothing happening?
What is this team of 6 professionals doing?
Why does no one talk to us?

Am I missing something?

 

The same questions came to my mind as well.

For example, we still have no information what is currently being worked on as it regards UNET. Then, there are many advanced questions in the network forums which remain unanswered because they cannot be fully answered by the community and UNET staff forum attention is nearly zero. Also, what happend with the collected community feedback? etc.

 

To the Unity networking staff:

I (and others as well, I'm certain) really, really appreciate your hard work and the fantastic LLAPI / HLAPI. The example projects are really great, specifically the Meteoroid Network project. At the same time, I have to echo the sentiments expressed above.

If you guys are busy with unet stuff you can't talk about, or even if the team has been pulled off / apart to work on other parts of the Engine (or people quit, etc), we will understand. But the lack of any response in this forum at all (not even a 'like' for a single post since mid-April by anyone in the team?) has me nervous and feeling that this API will be / has been abandoned, or else that some kind of major political restructuring is going on internally that will almost certainly have a negative effect on my game schedule, which relies on the unet team for answers the community is not yet knowledgable enough to provide (and since I can't afford paid support yet...)

Please just chime in with a 'guys we are busy at the moment but aware of your pain and will post more when able,' something as simple as that would have a calming effect on this niche community within Unity even if there are no other major updates in the immediate future.

In your debt for an unbelievable product,
Arun Mehta

 

Hey everyone, just wanted to share some of the networking-related improvements and fixes that Unity 5.3.6 brings:

• WebSocket: Improved memory allocation and socket writing procedure (fixed not expected connection closing)
• Multiplayer: Cleaned up the connection containing StateUpdate channel can cause crash.
• Multiplayer: Fixed: Calling NetworkDiscovery.StopBroadcast() and NetworkServer.Reset() crashes editor. (761566)
• Multiplayer: NetworkTransport.SetBroadcastCredentials crashes unity. (794054)
• Multiplayer: ReliableFragmented channel can drop data. (788808)
• Multiplayer: WebSockets: Fixed crash on NetworkClient.SendByChannel call. (760104)
• Networking: Adding parameter ConnectionConfig.WebSocketReceiveBufferMaxSize (bytes) for manually increasing webSocket buffer and preventing disconnect with log message """"*** sending new, pending truncated **"""". (791362)
• Networking: Fixed an issue of different error-messages when setting 65535 and 65537 to m_MaxDefaultConnections in HostTopology. (788877)
• Networking: Fixed an issue whereby calling NetworkDiscovery.StopBroadcast() and NetworkServer.Reset() crashes editor. (761566)
• Networking: Fixed System.Net.NetworkInformation.Ping on recent versions of OSX. (801973)

So, clearly there are some people still hard at work on the unet API we love & cherish, what's not clear is why they are not involved in the community here anymore; perhaps there is another more popular thread/forum? If anyone knows of any better resources (web/Slack/Reddit/irc etc.) than the official Unity forums trouble-shooting unet code, please post!

Best wishes guys,
Arun

Note: BitBucket source code still behind (5.4)

 

Hi Erik,
I saw in the official physics feedback thread, you posted a cool rundown of what will be worked on in the coming months. Could you do the same for UNet?

 

Hey isidro, do you know if these 5.3.6 fixes are included in latest beta 5.4 releases ?

 

Hey I'm not sure but I think I made a small mistake in my last post in saying that the docs are "behind..." We are still on the 5.3.x normal release cycle and the unet source available on BitBucket has options for 5.2 / 5.3 / 5.4 (presumably the current beta).

But since these updates came with a minor revision update, I don't know if they were merged into that source code, I would guess not but honestly this is exactly where a weekly scan of the active forum threads by a Unity employee in the unet team could deliver a 1-line answer and solve your pain.

Sad to say, but I'm guessing they only read new threads (and if that, how often is anyone's guess) so you are better off starting a new thread to ask this question; wish you luck on getting the answer, I would like to know as well!

Arun

 

I did a little search :

5.3.6 release : 20 july
5.4.0f2 release : 21 july

I found similarities, they are talking about the same bugs but with different sentences, as if they fixed them twice x)

3.5.6 - Fixes :

• Multiplayer: Cleaned up the connection containing StateUpdate channel can cause crash.

5.4.0f2 :

• Multiplayer: Fixed issue whereby cleaning up a connection containing a StateUpdate channel could cause a crash.

So they seem to fix both branches.

 

I too am concerned about the lack of recent updates to unity's networking. One of the biggest annoyances for us (and apparently many given the number of votes on the 7-year old issue) is that there is still no way to run multiple instances of the editor on the same project. This makes it very difficult and highly annoying to debug multiplayer games. We need to be able to see all the useful windows (Hierarchy, Inspector, etc) on all machines to track down sync issues. And we need to avoid the delays that using Build & Run cause (building, forced splash screens, no Debug.Log).

This was something that our previous engine had no problems doing and the 4 multiplayer games we made with it were significantly easier to develop because of this feature. If this isn't something that can be implemented in Unity I would like to know now so that we can research other engines without this issue.

 

I think people in this thread have already made a pretty good job of summing up all of the issues, but I'd just like to add/emphasize on something really important: we need more communication.

Right now UNET is in a state where it doesn't feel usable in most real-world projects. We don't want to be kept in the dark about UNET'S progress and its current roadmap. Otherwise, we'll just assume it's never going to get fixed and we're going to start using UE4 instead.

The UNET team needs to periodically share its roadmap and the stuff it is currently working on. Let us know that UNET will be usable one day

 

@PhilSA there are two games I know of that are using UNET:
Super Dungeon Bros (PS4/XBox/Steam)
Tricky Towers (PS4/Steam)

I wish I had concrete details on which components of the HLAPI / LLAPI / Unity cloud matchmaking services are being used... Let's hope that we get an update from @Erik-Juhl or another member of the team soon ^^ I think they are a little understaffed at the moment.

Arun

 

There are ways of running multiple editors of the same project
http://forum.unity3d.com/threads/editor-extension-multiple-unity-editors-same-project.417077/

Altough I am concerned aswell about unet, and the absolute most critical thing to me is the ability to send rpc's/syncvars to behaviours that:

1. hasAuthority
2. (!hasAuthority && !isServer)

 

I'm not quite sure what you're trying to say here...

 

Sorry for the wierd reply but basically I want to send rpc/messages to NetworkBehaviours that is a client but doesn't have authority or to only the networked behaviours that has authority.

The reason is that there is so much data being sent that doesnt have to be sent( EDIT:and data being recieved that it is not supposed to know about).

Ex ClientRpcAttribute sends to all clients, including the object that has authority. Which is fine as long as you ignore it on the recieving end that doesnt need it.

But think of an example where a new player establishes connection hence that client wants to know about the other nine player objects, all of those nine objects need to sync their data to the new connections corresponding objects.
How do I perform that sort of angled messaging?

I want to send to "OthersExceptOwner" (buffered)

Maybe Im being stupid and/or tired I dont know...

 

Okay. I think I see where you're going. If you're comfortable with messages, you can use the NetworkServer.SendToClient and NetworkServer.SendToClientOfPlayer methods to send messages to specific clients.

 

First i'm very confused by the AddHost method, for example while i compile to WebGL, i can not have a code like "AddWebsocketHost", it will cause compile error, even it is just a code will not be called (It will be only called while running as a server). And if you have and server hosted by AddHost, then i can not call AddHost with a port param, etc, there's many strange thing in AddHost/AndWebsocketHost.

Second, the Unity3D always crash while UNET get problem, see details here : http://forum.unity3d.com/forums/multiplayer-networking.26/

It was really a pain to use UNET LLAPI.

I can't get UNET works cool, and i can't do much thing since there is no source code to let me to do any research. But i need webgl support, is there any other low level network framework support websocket?

 

Automatic lerping when syncing the Transform in the Network Transform component!! I have a super simple 2 player combat, animation based game with only kinematic rigidbodies and dearly wish the transforms could be smoothly synced out of the box!

 

For everyone else who thinks that we need bandwidth consumption metrics for UNET matchmaking in the official analytics tools, please check this thread and vote on the respective feedback request.

 

Thanks for the update.

 

Stability sounds great, thanks for the update Larus!

I'd also like to point out one more time that bug #786248 is critical. I still encounter this on a weekly basis, even a year later. If you want to make UNET stable and usable for real world projects, then this bug should be fixed.

The bug was closed as 'by design'. We all do understand that redesigning software is hard. But if critical bugs exist, then the design has to be redesigned.

 

Thanks for the update!
These are some good news indeed and I think you have set the right priorities.
Looking forward to the next patches.

 

The not-good, the bad and the ugly:
"The client has no explicit knowledge of the player objects of other clients."

Really? I mean, really?
NetworkId's should have a ownerID. Local clients should know how many other clients are connected and who they are. What is the point of having such a non-generic network feature which is player object management if it is so loosely bound to the actual model (connection+connectionids+networkids).
If I don't want to stream scoreboard data to my clients, or even use events, I have to basically rewrite every single player control class that UNET provides. This is crazy.

 

I don't think it's (totally) crazy, given the basic complexity of secure, server-authoritative networking architecture in general.. But then again I am a networking noob who has been hacking my way through unet for several months with no prior networking experience (and perhaps I misunderstand your comment, @lucasmontec – apologies in advance if so).

What is crazy imho is that Unity's unet developers seem intentionally disengaged with official channels, i.e. these forums, the #networking channel in https://unitydevs.slack.com, etc., where supplying one answer or suggested work-arounds could inform the entire community. This would lead to exponential learning as the community starts being able to help each other more as well as more opportunities for feedback for Unity.

I can certainly understand what a drain it is to filter all the trolls and Unity noobs (i.e. those that can not fully articulate their question and/or do not provide adequate contextual information when the post such as full code, links, etc.). If this is the barrier to community engagement – as opposed to employee turnover, internal politics, or just plain being understaffed – I think it would be efficient to appoint a community rep within the unet team. Ideally this person would have a lot of patience, good English communication skills, and a desire to accelerate the adoption and joy of this API within the broader development community.

</rant>



Arun

 

It is not complex at all. It is just poorly designed API. The problem is how closed the system is. Most of it is static or hidden. We don't have enought documentation if what I say next is wrong but, there are no callbacks for when you call for a replace of player controller. All controllers in clients are viewed just as regular objects 'managed by the server'. There is no data that say to you that they belong to other clients... actually, you can't even know that other clients exist since there is no 'clientConnected' client-side. A client is a very veeeeery dumb 'view' component and I'm having huge mountains of trouble using the API to circumvent this. Loads of hacks.
This is not about security since clients don't need any information about the other clients connection. The only thing that should be exposed to a client is that other clients are connected to the server, their unique IDs, and objects owned by them should have this ID. A good API would also have a client side dictionary that speeds up looking for other-client owned objects, and, obviously, a list of playercontrollers the external clients have.

The big deal with Unity, and I certainly don't blame unity devs, is that most of the development time is spent doing ludicrous things like Unity Collab (a good excuse to make more money on top of already existing technology). They work on features that are clearly useless for experienced devs instead of integrating market prooven technology and moving on improving more important things (like readign our threads about how stuff need to be and actually making it).

Sorry if this is completely retarded. I just spent the whole night fighting UNET. It is a mega tsunami rant, but I really felt I needed to get this out of my chest. I do LOVE Unity and find it a really awesome platform to get stuff done but this is the exact reason I think people need to rant more. All the small teams! Lets rise together against the overcharging tirany! Don't let them charge you on things you could do by yourself!

 

Are there any plans to allow NetworkBehaviours on child objects of a NetworkIdentity? I can't find a non-painful way to implement this scenario.

(What I basically want is "m_MyView = GetComponentInParent<NetworkIdentity>();" instead of "m_MyView = GetComponent<NetworkIdentity>();" in NetworkBehaviour.cs, although I obviously have no idea if that would work like that.)

 

I'm not an expert in this, but I wouldn't be too surprised if allowing this would have some kind of network performance impact (needing one more parameter to sync any vars and execute RPCs, because we need to know if it's on a child object or not, etc....)

UE4 doesn't even have a notion of hierarchy/child objects. All you can have is a main object and its components. It's probably because this structure is more well-suited for networking

Just remember that there is always a way to arrange things so that all of your components are on the parent object

 

I am...divided on this. On one hand: good, about damn time. On the other hand...damnit.

Welp, nevermind, looks like I've got nothing to be worried about..

 

And that's what I did, but now I have over a dozen scripts on one game object - and I needed to interconnect references, which now all look like "SomePuzzle (Wheel)". I don't know of any way to even find out which Wheel scripts they reference in particular because they are all on the same GameObject. It's a maintenance nighmare.

 

Suggestion for UNET devs (and Unity in general):

I think it's safe to say, from everything I've seen on the forums, that people don't trust UNET at all right now. Tons of people are still looking for alternatives. So... have you ever considered making an actual game project with UNET to simultaneously drive its development and offer a solid proof to users that it is a good system?

It wouldn't need sophisticated art assets, lots of content, or any kind of visual polish. Just a fast-paced, high-precision, 16-players, publicly-accessible online game that would prove that UNET works well, and not just for overly-simple 4 player games or turn-based games. Something like Quake 3 with just one simplistic map would be perfect. And maybe add enough features so that it covers most of UNET's features. It doesn't even really have to be fun. It just needs to prove that UNET can handle this sort of game. You could also try 32, 64, and 128 player servers for stress testing. I'm sure 99% of unity devs would be pleased with UNET if they saw an online action game working with 64 players, or even 32.

Basically, it'd be great if you did what Epic is doing with UT and Paragon. I think the fact that they are developing actual games alongside their engine has a lot to do with why UE4 seems so much more stable and robust than Unity. There's no doubt in my mind that Unity would be a better engine today if they had started a game project around the time Unity 5 was in development, even taking into account the fact that you'd have to allocate some resources to game development instead of engine development.

This would convince people of Unity's worth much more than realtime movies like Adam and The Blacksmith, which almost don't prove anything. Don't get me wrong; Adam was really cool in a creative/artistic kind of way, but it doesn't say much about Unity's capabilities as a game engine. Not even when it comes to rendering, because it's such a highly-controlled environment that it's not really representative of what you'd have to deal with in a real game

 

Unity should terminate UNET and buy MuchDifferent's uLink system instead. It works, it's more than UNET has ever been and ever will be, and it's battle proven. It's also quite obvious that Unity has taken a good look at uLink when they designed UNET. So, acquire the original and save us all years of hassle.

 

I think once UNET is completed it will be really nice because it is integrated with existing Unity API. It's just buggy/incomplete at the moment, but they are working on that. So rather than suggesting they scrap the whole thing (which isn't going to happen) just help by bug reporting & suggesting improvements/features.

 

@larus When can we expect the network transport improvements/fixes? Any chance that'll be released in 5.5?

 

THIS! THIS IS WHAT UNITY NEEDS.
It really seems they do not use their own engine! Many obvious features missing!

 

Who are you?
One of developers of the game Celestial Command

What kind of game are you trying to build or would like to build?
I am trying to convert my game on the new network system (since you marked the previous system as deprecated)

How does Multiplayer fit into that? What use-cases do you have?
It does not fit. I can't do anything.

What are the GOOD things about the new Multiplayer system you like?
A short way to send RPC and ability to quickly send GameObject via RPC

What are the BAD things about the new Multiplayer system you dislike?
#1 Problem: Clients can't send [Command] from scene objects
#2 Problem: All objects with Network Identity are disabled until server started/connected

How can we make it BETTER?
Solve two problems explained above.

The problem #1 is super crucial, until it will not be solved - the new network system completely useless. Because in our architecture we have several empty game objects in the scene with a lot managers attached to it and clients should be able to send request to servers from these managers.
Of course there is ways to avoid this problem, but they are complex and we don't want to use such methods. It slightly better explained here.
If I explained the problem not very good, please inform me and we will provide a detailed demo project.

Also, you should improve official documentation. I suggested a couple of things here.

Also, until it will not be solved, please remove mark (deprecated) from NetworkView component.
And stop flood the console with yellow warnings for every RPC call in the code.
The new network system still can't replace the previous one and I want to continue use it in latest version of Unity.
Or at least add a check box in the options which will allows to disable those warnings.


Addition:
Please don't get me wrong, I am VERY admire the Unity, but this new network system and/or its manual is terrible. So hard to understand something about how it works. However previous network system I learned easily for a couple of hours.

We are love Unity. We think it brings a revolution in every new aspect of development. Everything so much easier than before!
For example, when I first time discovered network system (previous one, somewhere at version 3.*) in Unity, I was surprised how simple it is! I managed to build multiplayer game for a hour! It was a revolution! And so useful documentation. The most convenient documentation in the world!

Several times we teach other people how to create multiplayer games, and they was surprised, how it is possible to recreate multiplayer game for one hour, almost without any background information?! But it is possible with Unity! : )

After that, every big thing in Unity was a revolution.
Mecanim is more convenient way to assemble animation than anywhere!
UGUI is more convenient way to create a GUI than anywhere!

Seems like UNET is the next big thing. But unfortunately, I can't call it as a revolution. It violate a two main rules of "Unity" for me.
From my opinion, those rules is: Simplicity and Flexibility.

Unity have the best documentation which I ever seen. Except UNET, its documentation is terrible.
And Unity allows to create absolutely everything! Except UNET, in comparison to previous network system. Its possibilities is much less flexible. It force you to build a very specific and inconvenient architecture.

Hope you will fix it and turn the new system in something revolutionary, as always! : )
Until then, we will continue to use previous network system, which is great.

Thanks you for collecting our feedback! : )

 

I've seen several people talk about this, but I really don't think this should change. The client only being able to send commands from his "owned" object(s) is just a good client-server architecture decision that many other networking solutions also have made.

The solution to your problem is extremely simple; just give all your managers a reference to a NetworkBehaviour on the player object, and make them call RPCs on that script instead of in your managers directly

 

@PhilSA do you mind give some example coding information? i am stuck at this trying to give permission to client change something on server object.

 

Something I can immediately say would be nice (even though I'm barely getting into development) is to increase the max send rate for network transforms

 

if you want to change something (like a SyncVar) on a server object, simply make that change from a player-owned behaviour instead of directly in the server object. For instance....

Code (CSharp):

1. // This is on our server-owned object
2. public class SomeServerOwnedObject : NetworkBehaviour
3. {
4.     [SyncVar]
5.     public int TestValue = 1;
6. }

Code (CSharp):

1.  
2. // This is on our player-owned object
3. public class ClientController : NetworkBehaviour
4. {
5.     [Command]
6.     public void CmdSetTestValueOnObject(NetworkInstanceId objId, int newValue)
7.     {
8.         GameObject obj = NetworkServer.FindLocalObject(objId);
9.         if (obj)
10.         {
11.             SomeServerOwnedObject serverObj = obj.GetComponent<SomeServerOwnedObject>();
12.             if (serverObj)
13.             {
14.                 serverObj.TestValue = newValue;
15.             }
16.         }
17.     }
18. }
19.  

Since [Command]s are called on the server, the change will work properly. So instead of changing TestValue directly on the object, just change it through that CmdSetTestValueOnObject command. Having all commands flow through the player object helps you avoid safety mistakes and makes it easy to get a global overview of everything the client has a right to change. Keep in mind that whenever the client has a command to change something on the server, hackers can potentially use it to make any change they want on that thing. In some situations, it can also motivate you to reduce the amount of unique networked objects the system has to manage.

This reminds me though... one thing I think would be very useful is the ability to pass NetworkBehaviours as parameters to Commands and ClientRPCs, and also have them SyncVar-enabled. So instead of doing that whole NetworkServer.FindLocalObject thing to retrieve the NetBehaviour on the other side, it could all happen automatically in the background. I don't see any reason why this wouldn't be doable. It can find the NetworkBehaviour's NetworkInstanceId and component index on its own

 

I disagree and I've spent a lot of time trying to handle client-side control and I think it's really not simple. At first glance it seems simple, but once you work through it then you find it's not simple. Try setting up player characters with mixed client side & server side control. It's REALLY difficult.

Commands/RPC's are Unreliable and have Bugs.
1: They can be dropped if sent around the time of the scene change (The RPC can be sent... but is never received)
2: Commands can be sent to the wrong script (the hash messes up if you use inheritance or methods with the same name)
3: Overhead. 16bit mesgBase, ~8bit unet ID, Xbit cmdHash, + payload.
4: Duplication of code (often Command will be nearly identical to ClientRpc).

NetworkBehaviour OnSerialize/OnDeserialize has Issues
1: It can only be sent Server --> Client and not Client --> Server. Doesn't allow for client-control of player position.
2: SyncVars can become de-synced. OnSerialize is called when a new player connects or a scene changes. This can flag dirty bits as clear even though they are dirty. This can cause SyncVars to be out-of-sync on some clients. It also can cause client "owners" syncVars to be overridden by OnDeserialize (since the value can be changed even though the hook isn't called)
3: Very inefficient. 32bit mask sent for every script. If you are changing syncVars and have 20 scripts on the player, each at 10Hz (but not synced), and 5 clients then you could be sending as much as 32x20x(10x20)x5 = 640,000 bits/sec of bitmask overhead on the Server just for player characters!!! The actual overhead would be a little less if different scripts happened to be synced together.

Both RPC's and OnDeserialize are sent to all clients... you can't just send to 1 client (I think). Which means you are wasting network bandwidth as well as writing code to ignore information sent (without messing up the NetworkReader stream).

At first glance Commands/RPC's/SyncVar's/OnSerialize/OnDeserialize seem "simple" but in the end they just don't work and are buggy with lots of inefficient network bandwidth overhead. I think the only solution at the moment due to above issues is to write everything yourself MessageBase which isn't simple. It's taken me 3 weeks just to generate smooth client-side control of a RigidBody player.

 

This would resolve a lot of headaches I have with my project, which is a bit more ambitious than normal since everything but the terrain is networked, because it is spawned by players or has variables that need to be synced, and FindLocalObject isn't always working properly.

 

I use a script dictionary<uint scriptID, script> and assign scriptID's during OnSerialize/Deserialize(initial state = true). Add scripts to dictionary on initialization, and then remove scripts when object is destroyed. This allows networked access of scripts by dictionary. You could maybe do the same with a dictionary of networked GameObjects.

I haven't had issues with FindLocalObject though so I'm not exactly sure what the bug is.

 

It's not a bug, it's just tedious to have to do this:

Code (CSharp):

1. [Command]
2. public void CmdSetTestValueOnObject(NetworkInstanceId objId, int componentIndex, int newValue)
3. {
4.     GameObject obj = NetworkServer.FindLocalObject(objId);
5.     if (obj)
6.     {
7.         SomeServerOwnedObject[] serverObjs = obj.GetComponents<SomeServerOwnedObject>();
8.         if (serverObjs.Length > componentIndex)
9.         {
10.             SomeServerOwnedObject serverObj = serverObjs[componentIndex];
11.             if (serverObj)
12.             {
13.                 serverObj.TestValue = newValue;
14.             }
15.         }
16.     }
17. }

instead of this:

Code (CSharp):

1. [Command]
2. public void CmdSetTestValueOnObject(SomeServerOwnedObject obj, int newValue)
3. {
4.     obj.TestValue = newValue;
5. }

It's not such a big deal, because you could manage a dictionary like you were saying, or make a static method that retrieves a NetworkBehaviour based on netInstanceId and component index (if multiple components of the same type are present on the same GameObject). But it's such a basic thing that everyone needs that it'd be nice to have it right off the bat.

While we're at it, I'd also add to my wishlist:

• A "NetworkAddComponent" method that properly adds a NetworkBehaviour component on all server and clients
• SyncVar hooks firing on initial sync (when spawned), with a bool parameter in the hook delegate telling you if this is the initial sync or an incremental sync
• UNET gives me an impression of convolutedness in general. Very often the order of execution of things, or the reliability of things, are not clear at all and you kinda have to guess. Maybe it'd be worth sacrificing a bit of "automagicalness" in order to favor robustness, reliability and performance. I'll admit I don't have a clear idea of what I'd do instead, but I'm just thinking out loud. I just think everything should be a little bit more explicit, and not hidden in the background
• Fix all the inheritance and multiple components problems
• Network visibility should work with bounding boxes instead of physics colliders (that one seems really weird to me)
• Add callbacks for OnSerialize and OnDeserialize in NetworkBehaviours that we can use without breaking all the SyncVar stuff

 

I agree with all that.

 

Although I am definitely thankful for the Unet effort, I agree and this is basically my #1 request. I wish Unity had an internal game dev team that battle-hardened releases and documentation before they hit the public (not just UNET), and also drove priorities for some bugs out of necessity. The problem is, chasing documentation red herrings and API bugs is way more of a waste of time than simply waiting longer for a more hardened release.

Nothing would more profoundly light a fire under the API than a game developed internally that relied on it. In fact, I can't imagine another week would go by before that internal team demanded native support for multiple editor instances (without a hacky launch script to delete Temp folders and fool the editor, etc).

 

I am really struggling with UNET and it seems almost every day I find more UNET bugs or broken features. It's to the point where the majority of my time is now spent working around UNET bugs/issues. I have been trying to use proper channels... bug reporting and keeping a list in this post here.
http://forum.unity3d.com/threads/my-compiled-list-of-unet-bugs-issues.403578/

If these issues are being worked then some feedback is welcome. A status update and just knowing that issues are being addressed and that all the time building up sample projects & bug reporting is going to good use would be appreciated.

One of the biggest issues for me is how persistent DontDestroyOnLoad networked objects (i.e. your player) appear to be treated just like new scene objects every time a scene is changed. NetworkIdenity.observers is reduced and then built-back up again and OnSerialize/Deserialize(initialState == true) is called each scene change. This causes:
-RPC's to fail
-SyncList callbacks to fail
-SyncVar hooks to fail
-The object to be "spawned" multiple times by OnSerialize/Deserialize (initialState == true)

If you need help replicating bugs or need specific info then message me.

 

I would also recommend that people struggling with unet (like myself!) join the free Unity Dev slack channel:
http://unitydevs.slack.com (#network)

We can have asynchronous/synchronous discussions, pin relevant Unity Forum links, and there are several people in there who have experience actually shipping games using unet

Arun

 

Who are you?
I'm currently an independent video game developer building a multiplayer 2D "shooter". I've previously worked on multiplayer features at Insomniac Games, and SCEA.

What kind of game are you trying to build or would like to build?
I'm currently building a fast paced 2D arena shooter.

How does Multiplayer fit into that? What use-cases do you have?
The entire game is based around competition multiplayer. High speed accurately synced movement of both player objects and projectiles.

What are the GOOD things about the new Multiplayer system you like?
The HLAPI provided has removed most of the technical pain points for getting a basic server authority model multiplayer game running with minimal effort. I have been able to get a playable testable version of my project running with extremely minimal access to the NetworkTransport layer and with only minimal consideration for keeping state elements in sync allowing me to focus primarily on programming gameplay.

What are the BAD things about the new Multiplayer system you dislike?
The Unity provided components for things like NetworkTransformation sync are totally unreliable. They're to complex to subclass and build on top of and they don't do their expressed functions well enough to be solutions on their own. The provided documentation for the HLAPI is functionally insufficient. Even after extensive personal experimentation I still can't concretely tell you how the various HLAPI sync elements (var,list,event) behave with class inheritance and polymorphism.

How can we make it BETTER?
Providing a server.dll would be great! I would love an HLAPI feature that allows me to call an RPC only on a specific clients instance of the object rather then on all instances of a client object. The most common RPC pattern is "do this thing and ignore it everywhere but there" or stated "do this thing there but ignore it everywhere else". It would be nice if there was a component provided to help keep the transform hierarchy synced between instances of the game. I think it's a pretty common unity practice to rely on some manner of predictability in your scene hierarchy. If I make a "networkIdentity" object the child of another "networkIdentity" object before I spawn it it would be nice if NetworkServer.Spawn was smart enough to spawn that object and child it as it was on the server. Documentation wise I think it's VERY important to expressly and loudly outline when useage of the HLAPI does not conform to what would be expected from standard C# features (such as overriding hook functions).

I second this. I try and spend as much time in there as possible. It's nice to have somewhere to spitball when you're having issues. You can join the unitydev slack here.

I really think some additional community interaction would help everyone. If Unity doesn't want to run it's own internal game development teams to vet their emergent features the next best thing they have is their community in the trenches building stuff based on these earlier releases. I sort of hoped that's what this thread was about but it seems like it's largely been radio silence. As everyone has already identified the documentation is often insufficient and apparently a lot of what's going on in the HLAPI appears to occur behind an impenetrable black curtain. I've been stuck on this for a while now and can't seem to figure it out. I imagine this is something even the most Jr developer on their team could answer in 5 minutes if Unity had someone from the development team talking to the community as unet "emerges".

 

@larus last UNET post: August 17.
@Erik-Juhl last UNET post: May 23.
@JeremyUnity last UNET post: June 17.
@richard-lee last UNET post: September 21.
@aabramychev last UNET post: June 19.

 

A weekly sound-off on this forum from whoever is in charge of UNET development would be so helpful for easing folks worries. Dedicating half an hour a week is surely possible and would help present a better image of an organised company.

Also that NAT punch-through will be excellent.