Search Unity

  1. Check out our Unite Austin 2017 YouTube playlist to catch up on what you missed. More videos coming soon.
    Dismiss Notice
  2. Unity 2017.2 is now released.
    Dismiss Notice
  3. The Unity Gear Store is here to help you look great at your next meetup, user group or conference. With all new Unity apparel, stickers and more!
    Dismiss Notice
  4. Introducing the Unity Essentials Packs! Find out more.
    Dismiss Notice
  5. Want to see the most recent patch releases? Take a peek at the patch release page.
    Dismiss Notice
  6. Unity 2017.3 beta is now available for download.
    Dismiss Notice

Unity Multiplayer [Official] Multiplayer Improvements

Discussion in 'Multiplayer Networking' started by Erik-Juhl, Mar 10, 2016.

  1. uWHATMATE

    uWHATMATE

    Joined:
    Jul 19, 2016
    Posts:
    2
    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?
     
    Last edited: Jul 19, 2016
  2. moco2k

    moco2k

    Joined:
    Apr 29, 2015
    Posts:
    251
    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.
     
    Last edited: Jul 19, 2016
    Ghosthowl, akuno, _FLX and 3 others like this.
  3. isidro02139

    isidro02139

    Joined:
    Jul 31, 2012
    Posts:
    63
    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
     
  4. isidro02139

    isidro02139

    Joined:
    Jul 31, 2012
    Posts:
    63
    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)
     
  5. rikey

    rikey

    Joined:
    Mar 3, 2015
    Posts:
    147
    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?
     
    isidro02139 likes this.
  6. _FLX

    _FLX

    Joined:
    Nov 10, 2015
    Posts:
    79
    Hey isidro, do you know if these 5.3.6 fixes are included in latest beta 5.4 releases ?
     
    isidro02139 and rikey like this.
  7. isidro02139

    isidro02139

    Joined:
    Jul 31, 2012
    Posts:
    63
    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
     
  8. _FLX

    _FLX

    Joined:
    Nov 10, 2015
    Posts:
    79
    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.
     
    isidro02139 likes this.
  9. Zif

    Zif

    Joined:
    Mar 12, 2013
    Posts:
    1
    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.
     
    Chom1czek likes this.
  10. PhilSA

    PhilSA

    Joined:
    Jul 11, 2013
    Posts:
    434
    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
     
    IAMBATMAN, nonom, rikey and 2 others like this.
  11. isidro02139

    isidro02139

    Joined:
    Jul 31, 2012
    Posts:
    63
    @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
     
    rikey likes this.
  12. Apparaten_

    Apparaten_

    Joined:
    Jul 9, 2013
    Posts:
    44
    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)
     
  13. DRRosen3

    DRRosen3

    Joined:
    Jan 30, 2014
    Posts:
    625
    I'm not quite sure what you're trying to say here...
     
  14. Apparaten_

    Apparaten_

    Joined:
    Jul 9, 2013
    Posts:
    44
    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...
     
  15. DRRosen3

    DRRosen3

    Joined:
    Jan 30, 2014
    Posts:
    625
    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.
     
    Chom1czek likes this.
  16. iileychen

    iileychen

    Joined:
    Oct 13, 2015
    Posts:
    51
    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?
     
  17. bobmaxine

    bobmaxine

    Joined:
    Dec 27, 2015
    Posts:
    13

    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!
     
  18. moco2k

    moco2k

    Joined:
    Apr 29, 2015
    Posts:
    251
    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.
     
  19. larus

    larus

    Unity Technologies

    Joined:
    Oct 12, 2007
    Posts:
    246
    A little update from the multiplayer team.

    The last few months the biggest tasks we've been working towards is improved stability and documentation. There have been bugfixes going into 5.3 until the entry to that became higher, now we'll be focusing on stability in 5.4.x and onwards. For 5.4.0 the fixes stopped when neared release and was locked down but now we'll be bringing them to 5.4 patch releases going forward (they went to trunk/5.5). Not everything can go into patch release though, only the less intrusive fixes. There have also been changes on the backend, to ensure stability with higher loads. Traffic has been increasing steadily since GDC in march and we've been making sure things stay smooth.

    Some improvements and features we've been working are:
    • Reworking network transport for performance and usability. Issues with configuration parameters and bandwidth have been addressed. It also has usability improvements for better bandwidth monitoring, debugging, troubleshooting and so on. We've submitted a session proposal for Unite where we would go over these changes (if accepted).
    • Dashboard improvements. Live mode will be easier to use in the future and we'll try to gradually make it possible to auto-manage everything (CCUs/bandwidth limits). Statistics/Bandwidth graphs will be added so you can easily monitor your traffic usage there. We'll be integrating with new billing solutions internally so we can remove the need for being subscribed before using live mode (getting payment details without Plus/Pro subscriptions).
    • Host migration support for relays.
    • Full websocket support on all platforms, also over relay (this also bring WebGL closer to feature parity with other platforms)
    • NAT punchthrough support. This should be usable with network transport or high level API and can hopefully be added to existing projects. Eventually the idea is to integrate this with the relay server connectivity so it will only fallback on that when direct connect and NAT punchthrough connect fail.
    • Server DLL. This feature has been in alpha but is getting closer to beta status. This is a C# DLL with just the Unity Multiplayer protocol support for barebone dedicated servers (non-Unity) or utility tasks.
    @moco2k: the dashboard and transport improvements should address what you asked for (except does not integrate with the Analytics service).

    We should spend more time on the forums, I know. Sorry about that, and we'll try harder to make time for it.
     
  20. Zullar

    Zullar

    Joined:
    May 21, 2013
    Posts:
    462
    Thanks for the update.
     
    isidro02139 likes this.
  21. vis2k

    vis2k

    Joined:
    Sep 4, 2015
    Posts:
    1,845
    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.
     
    Last edited: Aug 17, 2016
  22. moco2k

    moco2k

    Joined:
    Apr 29, 2015
    Posts:
    251
    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.
     
    Last edited: Aug 18, 2016
    isidro02139 likes this.
  23. lucasmontec

    lucasmontec

    Joined:
    Apr 7, 2015
    Posts:
    59
    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.
     
  24. isidro02139

    isidro02139

    Joined:
    Jul 31, 2012
    Posts:
    63
    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
     
  25. lucasmontec

    lucasmontec

    Joined:
    Apr 7, 2015
    Posts:
    59
    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!
     
    Last edited: Aug 23, 2016
    isidro02139 likes this.
  26. TobiasW

    TobiasW

    Joined:
    Jun 18, 2011
    Posts:
    45
    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.)
     
  27. PhilSA

    PhilSA

    Joined:
    Jul 11, 2013
    Posts:
    434
    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
     
    Last edited: Aug 23, 2016
  28. thegreatzebadiah

    thegreatzebadiah

    Joined:
    Nov 22, 2012
    Posts:
    532
    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..
     
    Stormy102 likes this.
  29. TobiasW

    TobiasW

    Joined:
    Jun 18, 2011
    Posts:
    45
    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.
     
    Last edited: Aug 25, 2016
  30. PhilSA

    PhilSA

    Joined:
    Jul 11, 2013
    Posts:
    434
    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
     
    Last edited: Aug 31, 2016
    akuno, iCode, Alturis2 and 12 others like this.
  31. PeterB

    PeterB

    Joined:
    Nov 3, 2010
    Posts:
    255
    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.
     
  32. Zullar

    Zullar

    Joined:
    May 21, 2013
    Posts:
    462
    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.
     
    Stormy102, PhilSA, g-hoot and 4 others like this.
  33. emrys90

    emrys90

    Joined:
    Oct 14, 2013
    Posts:
    400
    @larus When can we expect the network transport improvements/fixes? Any chance that'll be released in 5.5?
     
  34. lucasmontec

    lucasmontec

    Joined:
    Apr 7, 2015
    Posts:
    59
    THIS! THIS IS WHAT UNITY NEEDS.
    It really seems they do not use their own engine! Many obvious features missing!
     
  35. Artaani

    Artaani

    Joined:
    Aug 5, 2012
    Posts:
    212
    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! : )
     
  36. PhilSA

    PhilSA

    Joined:
    Jul 11, 2013
    Posts:
    434
    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
     
    Last edited: Sep 12, 2016
    SuperNeon, moco2k and vis2k like this.
  37. Aruaca

    Aruaca

    Joined:
    Oct 27, 2014
    Posts:
    9
    @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.
     
  38. zacharyl

    zacharyl

    Joined:
    Sep 5, 2016
    Posts:
    9
    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
     
  39. PhilSA

    PhilSA

    Joined:
    Jul 11, 2013
    Posts:
    434
    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
     
    Last edited: Sep 12, 2016
    IAMBATMAN likes this.
  40. Zullar

    Zullar

    Joined:
    May 21, 2013
    Posts:
    462
    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.
     
    Last edited: Sep 14, 2016
  41. Vedrit

    Vedrit

    Joined:
    Feb 8, 2013
    Posts:
    487
    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.
     
  42. Zullar

    Zullar

    Joined:
    May 21, 2013
    Posts:
    462
    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.
     
  43. PhilSA

    PhilSA

    Joined:
    Jul 11, 2013
    Posts:
    434
    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
     
    Last edited: Sep 15, 2016
    Zullar likes this.
  44. Zullar

    Zullar

    Joined:
    May 21, 2013
    Posts:
    462
    I agree with all that.
     
    isidro02139 likes this.
  45. shadiradio

    shadiradio

    Joined:
    Jun 22, 2013
    Posts:
    60
    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).
     
    Stormy102 and moco2k like this.
  46. Zullar

    Zullar

    Joined:
    May 21, 2013
    Posts:
    462
    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.
     
    darthbator and isidro02139 like this.
  47. isidro02139

    isidro02139

    Joined:
    Jul 31, 2012
    Posts:
    63
    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 :cool:

    Arun
     
    Zullar likes this.
  48. darthbator

    darthbator

    Joined:
    Jan 21, 2012
    Posts:
    132
    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".
     
    Last edited: Sep 23, 2016
    isidro02139 and PhilSA like this.
  49. uWHATMATE

    uWHATMATE

    Joined:
    Jul 19, 2016
    Posts:
    2
    @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.
     
    Last edited: Oct 3, 2016
  50. l3fty

    l3fty

    Joined:
    Mar 23, 2013
    Posts:
    72
    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.