Search Unity

  1. Unity 2018.3 is now released.
    Dismiss Notice
  2. The Unity Pro & Visual Studio Professional Bundle gives you the tools you need to develop faster & collaborate more efficiently. Learn more.
    Dismiss Notice
  3. Want more efficiency in your development work? Sign up to receive weekly tech and creative know-how from Unity experts.
    Dismiss Notice
  4. Build games and experiences that can load instantly and without install. Explore the Project Tiny Preview today!
    Dismiss Notice
  5. Want to provide direct feedback to the Unity team? Join the Unity Advisory Panel.
    Dismiss Notice
  6. Improve your Unity skills with a certified instructor in a private, interactive classroom. Watch the overview now.
    Dismiss Notice

Unity Multiplayer Mirror - Networking for Unity (aka HLAPI Community Edition)

Discussion in 'Connected Games' started by vis2k, Aug 11, 2016.

  1. vis2k

    vis2k

    Joined:
    Sep 4, 2015
    Posts:
    2,718
    mirror_icon_500x128.png
    (Asset Store) (Github) (Discord) (Donations)
    Mirror is a high level Networking API for Unity, built on top of the low level Telepathy library.


    Mirror is built and tested for MMO Scale Networking by the developers of uMMORPG, uSurvival and Cubica (@goldbug).

    Mirror is optimized for ease of use and probability of success. Projects that use Mirror are small, concise and maintainable. uMMORPG was possible with <6000 lines of code. We needed a networking library that allows us to launch our games, period.

    With Mirror, the Server & Client are ONE project (hence the name). Instead of having one code base for the server and one for the client, we simply use the same code for both of them.

    • [Server] / [Client] tags can be used for the server-only and client-only parts.
    • [Command] are used for Client->Server, and [ClientRpc] / [TargetRpc] for Server->Client communication.
    • [SyncVar]s and SyncLists are used to automatically synchronize state.
    What previously required 10.000 lines of code, now takes 1.000 lines of code. Therein lies the magic of Mirror.

    Mirror is based on Unity's abandoned UNET Networking system. We fixed it up and pushed it to MMO Scale. If you are looking for a UNET replacement or the old HLAPI Community Edition, then this is the right place. Mirror is a simple drop-in solution, without any more DLL replacements.

    Documentation

    We are still working on the documentation, but Mirror is still similar enough to UNET that you can use the UNET Manual for now.

    The only difference is that you have to use using Mirror; instead of using UnityEngine.Networking; at the top of your scripts.

    Oh, and you won't have to worry about channels, low level networking, packet loss, lack of support or bugs ever again. Mirror just works.

    Usage Guide
    Mirror can be downloaded on the Asset Store, ready to be used without any extra configurations.

    Migration Guide for UNET / HLAPI CE
    If you are still using UNET and want to switch to Mirror, you should check out our Migration Guide. Don't panic, it's very easy and won't take more than 5 minutes.

    We also created a script that does the migration automatically.

    Here is how we updated uMMORPG to Mirror, it will be similar in most projects:


    If you need the old HLAPI_CE download: 2017.4 Version.

    Example Projects
    We are building several easy to understand example projects that we will add here soon.

    For a fully polished complete project example, consider uMMORPG or uSurvival.

    Donations
    Mirror is developed by volunteers. If you like what we are doing, consider leaving a small donation.

    Benchmarks




    Differences to UNET
    We fixed and improved an endless amount of things since forking UNET's HLAPI.

    Here is a rough and incomplete overview:
    • Increased the [SyncVar] limit from 32 to 64
      • Problem: one MonoBehaviour could only have 32 SyncVars+SyncLists combined. This is fine until you have a big Player script and no option to use more, leaving you to ugly workarounds.
      • Solution: increased the SyncVar dirty mask size from 4 to 8 byte, allowing 64 SyncVars+SyncLists. Sending around 4 more bytes is definitely worth our sanity.
    • OnSerialize/OnDeserialize safely
      • Problem: the reader/writer is passed through all components. If one messes up, all other components will get strange errors like ReadString/ReadByte out of range
      • Solution: data length is included for each component, buffer copies are passed to each component so that it's impossible to touch any other component's serialization data.
    • OnSerialize/OnDeserialize detailed error logging
      • Problem: errors in OnSerialize/OnDeserialize are never shown. If we are lucky, we see ReadString/ReadByte out of range errors, but sometimes just corrupt data.
      • Solution: errors are caught properly before calling OnSerialize/OnDeserialize and log messages give detailed info about the object's name, component's type, sceneId, expected data size, and known causes.
      • Example: 2017-08-01_ondeserialize error log.png
    • Nondeterministic SceneID bug fixed (most critical HLAPI bug, exists in all HLAPI Projects)
      • Problem: OnPostProcessScene assigned SceneIDs based on the order of FindObjectsOfType<NetworkIdentity>(). The order is not guaranteed, which resulted in different SceneIDs each time the Editor restarts. Reconnecting to a build after restarting the Editor would then cause bugs where UNET tried to serialize the wrong objects, often causing 'ReadString out of range' errors etc.
      • Solution: FindObjectsOfType is sorted by the sibling index path in the Hierarchy. This doesn't change after restarting, only when manually changing the Hierarchy.
      • Note: Unity attempt to fix this bug in 2018.1, but they didn't actually fix it.
    • Fixed Client Scene Switching/Loading
      • Problem: switching a scene would sometimes cause random object spawning errors and 'target not found' messages due to corrupted state.
      • Solution: I analyzed the Client<->Server handshake to find out at which point the client state got messed up. If the server sends a scene change message to the client, then there is no guarantee that this message arrives before the rest of the initialization (like object spawning). If the message arrives during initialization, then the scene will be loaded asynchronously and after the scene was loaded, all the state data like spawned objects are nulled. HLAPI Pro uses a new pausing mechanism that delays all message handling while a scene is loaded, making sure that all the spawning works perfectly fine even if spawn messages are received during a scene load.
      • View attachment 244190
    • NetworkServer made static and removed NetworkServerSimple
      • Unity added NetworkServerSimple a while after someone requested server parts to be replaceable at runtime. A good idea in theory, but the amount of complexity this caused is completely insane and no one seemed to be using it anyway.
      • NetworkServer is meant as a static class, but Unity used the singleton pattern. The code always expects exactly one server, so making it static makes perfect sense and simplifies the code a lot.
      • Improves performance a bit since all those .instance getter logic/checks are gone.
      • Less state == good.
    • NetworkCRC removed
      • NetworkCRC sent all NetworkBehaviour script names over the network, only to compare their channelIds with those on the server. This used a lot of bandwidth for virtually no benefit. Why would anyone build the server, then modify a script's channel for no reason, then build the client? A real CRC for the whole project might have been useful, but only comparing channelIds is not worth the bandwidth and code complexity at all.
    • ChannelBuffer/ChannelPacket removed
      • NetworkConnection had a list of ChannelBuffers, each of them had a ChannelPacket. This was implemented to provide reliable messages, message fragmentation and send delay buffering before NetworkTransport implemented those features. NetworkTransport does implement those features now, so it's enough if we send all messages directly to NetworkTransport.
        • => Significantly reduces memory consumption and GC for each packet
        • => Reduces computations needed to buffer and fragment packets
        • => Reduces latency because HLAPI and LLAPI don't both have a SendDelay anymore, only LLAPI
    • NetworkLobbyManager removed
      • NetworkLobbyManager was just one specific NetworkManager implementation that inherited from NetworkManager and added some lobby functionality. People used Unity's 'NetworkLobby' asset for this anyway. It's good that a NetworkLobbyManager example script exists, but it shouldn't be hard coded into HLAPI. People should be able to change it and we shouldn't have to maintain it. This library should provide the basics, not all different possible NetworkManager implementations.
    • Matchmaking / Relay removed
      • Unity pretty much abandoned the Matchmaking and Relaying services, as evident by complete lack of support on the forum here.
      • Matchmaking is a useful feature, but Unity already announced a new Matchmaking solution on Google Cloud anyway.
      • Relaying is useful when hosting games on people's computers, like in Dota1. But this never works well for anyone except the person that hosts the game. Latency to some random person's computer is already high, relaying it through Unity's services makes it even higher. Besides, people can still open ports in their firewall if they want to host on their own computer.
      • There is also no reason why we should maintain Unity's services in the HLAPI Community Edition. People that need those features badly can still use the 'fixes' version. The 'improvements' version is supposed to be lightweight and stable.
    • NetworkServiceInitialize removed
      • NetworkServiceInitialize was used for internal Editor analytics.
    • NetworkIdentity.UNetUpdate serialization Bandwidth overkill fixed
      • Problem: NetworkIdentity.UNetUpdate serialized all components for each channel if any component for the channel was dirty. This caused at least twice the unnecessary bandwidth, usually even more:
        • Most UNET projects use at least two channels: Unreliable and Reliable. So all of the components would be serialized once for Unreliable and then once again for Reliable and then sent over the Network, doubling the necessary bandwidth just about all the time. If a project uses 5 channels, then it would be 5x the unnecessary bandwidth. This is completely insane.
        • If one component was dirty then all components would be synced and sent over the network again. For example, if the player moves and the component gets dirty, then not just the movement, but also all other components like Health, NetworkTime, etc. would be serialized. If the player has 10 components and only one of them is dirty, then all 10 would be serialized. This again causes unnecessary bandwidth depending on the amount of your components, so it can easily cause 10x the required bandwidth. This too is completely insane.
        • Additionally, the SendInterval setting was almost entirely ignored because OnSerialize would be called if another component's sendInterval was elapsed.
      • Solution: a dirtyComponents bit mask is included in each serialization. Only the dirty components for a given channel are serialized.
    • SendToTransport failed error isn't shown anymore if someone disconnects
      • People disconnect all the time, no need to log an error each time.
    • Message Header size reduced:
      • Messages used to have a 4 byte header consisting of content size (2 bytes) and message type (2 bytes)
      • We now use varint which results in a 2 byte header almost all the time (except for large messages)
      • This effectively reduces bandwidth by about 10%, assuming an average message size of 20 bytes (it's usually even shorter than that)
    • Switched Low Level Networking to Telepathy
    • Making Mirror a drop-in allows us to finally use Unity Cloud Build too
    Donators:
    Special thanks to everyone who supports Mirror development by donating on Patreon.
    @doctorpangloss @yellinglionstudio
     

    Attached Files:

    Last edited: Oct 30, 2018
  2. iileychen

    iileychen

    Joined:
    Oct 13, 2015
    Posts:
    63
    If it contains a better designed and stable and documented LLAPI to use, i would like to pay.
    Also, Websocket support is needed.
     
    nonom likes this.
  3. voltage

    voltage

    Joined:
    Nov 11, 2011
    Posts:
    488
    I would buy a NetworkTransform fix alone. 5 bucks USD sounds fair, maybe 10 if it's smooth as butter. I want it to be virtually identical to the current one, only it works properly. My only request really.
     
  4. vis2k

    vis2k

    Joined:
    Sep 4, 2015
    Posts:
    2,718
    I don't intend to modify the LLAPI, only the HLAPI. The LLAPI is closed source anyway.

    Thanks for your feedback.
     
  5. PhilSA

    PhilSA

    Joined:
    Jul 11, 2013
    Posts:
    906
    I'd definitely be interested in paying for that. Especially if I can see the stress test results, which would reassure me that this would be a good and dependable option for my projects

    PS: if you do manage to successfully communicate with the rare unicorns working on UNET, can you please try to drag them back here in the forums and make them read/comment on this thread?: http://forum.unity3d.com/threads/official-multiplayer-improvements.390823/
     
  6. vis2k

    vis2k

    Joined:
    Sep 4, 2015
    Posts:
    2,718
    Good to hear.

    That reminds me, I also have a lot of SyncListStruct examples (including hooks) that would probably be interesting for a lot of people too.

    I am sure they do read the forums every now and then.
     
    Chom1czek likes this.
  7. Quis

    Quis

    Joined:
    May 16, 2014
    Posts:
    14
    Paying for it wouldnt be an issue, although if it was free but based on for example donations/patreon/etc then more people could adapt it to their projects.
     
  8. vis2k

    vis2k

    Joined:
    Sep 4, 2015
    Posts:
    2,718
    Patreon is a good idea too. Will add this option to the first post.
     
  9. Xaon

    Xaon

    Joined:
    Feb 28, 2013
    Posts:
    52
    I'm most interest in premium support or complex examples as those provided by Unity are oversimplied for me and don't cover many typical use-cases. While I am a programmer, programming network stuff is still a bit of magic for me and I would gladly pay to learn some more of this magic ;)
    More features are secondary for me, at least for now.

    P.S.
    NetworkTransform with Rigidbody synchronization works good enough for me (as it does movement interpolation) so I don't quite understand why is this issue mentioned so often.
     
  10. moco2k

    moco2k

    Joined:
    Apr 29, 2015
    Posts:
    289
    There is no question about the current UNET flaws and the urgent need for further improvements. So any kind of initiative is more than welcome.

    I have one concern though. If you go that route with custom HLAPI, in the end, we have both native UNET HLAPI and HLAPI_fixed. That means we have 2 different HLAPIs which are developed independently by different people. This has some potential for confusion and I guess also for problems. For example, what happens if official UNET implements significant updates to the original HLAPI but I am now using HLAPI_fixed and it is not updated as well? Also, support could become an issue.

    Maybe this is a good idea still. But before going this way, I would strongly recommend to first get in direct contact with the UNET devs and try to establish some kind of official collaboration. So that you can directly work together with the UNET team to get your improvements in the official branch. Maybe even something like freelance UNET improvement task force. Then, we would have both a faster improvement progress and official support and maintenance. And above all, a single stable and feature-rich HLAPI that everyone can use, with a single documentation and community. If this way does not work out, okay, then you could still take the custom route.
     
    Last edited: Aug 17, 2016
    Artaani likes this.
  11. vis2k

    vis2k

    Joined:
    Sep 4, 2015
    Posts:
    2,718
    NetworkTransform is laggy for most people when trying it over the network.

    Valid concerns.

    If enough people end up being interested in this project, then I will contact Unity first of course. For legal reasons, etc.

    I definitely don't want to reinvent the wheel. Phase 1-3 are very important and can be developed without messing with the HLAPI core (NetworkManager etc.) at all. Component based development allows us to replace NetworkTransform, NetworkProximityChecker, etc. easily. Allowing us to replace and create our own components seems to be one goal of UNET anyway.

    Phase 4 would be more difficult, if we decide to replace more critical components like NetworkManager. Don't get me wrong, I really don't want to do that. This would be a nightmare to deal with. Keeping it up to date with the latest official HLAPI code would be hard. Just like anyone else here, I am really only interested in launching my own online game. If UNET would have the same quality like other Unity components, then we wouldn't have this discussion in the first place. Sooner or later, many of us will launch their games though. If critical bugs in core components are found, then they will have to be fixed. Let's hope we don't get to that point though.
     
    Last edited: Aug 13, 2016
  12. jjobby

    jjobby

    Joined:
    Nov 28, 2009
    Posts:
    112
    We are currently developing MMORPG for our client and the lack of update in Unity network is really becoming our main concern. It would be nice if you can get the collaboration from UNET developers. I fully support your plan and I am willing to pay for your effort.
     
  13. larus

    larus

    Unity Technologies

    Joined:
    Oct 12, 2007
    Posts:
    255
    Just to be clear on legal matters: Anyone can freely modify, use, re-distribute (for free or for a fee) or do anything they want with the high level API source we published on bitbucket (as explained in the LICENSE file in the repo). Nothing to worry about there.

    You can work on the project, and do fixes/modifications/improvements, and it's up to you if you want to make them public and available for us to integrate if that is suitable or to keep them private (or publish on asset store with a price tag). It should be easy to switch out components (like NetworkTransform) and exchange with modified or customised versions. Of course if the core is changed too much it will be harder to integrate patches from us but that's up to you.

    We'll have an update soon on our immediate roadmap so you can see what changes are incoming in future releases.
     
  14. iCode

    iCode

    Joined:
    May 25, 2013
    Posts:
    32
    To answer your question I would be willing to pay.

    Do to personal issues i have been away from the Unity scene. I recently started up again with the idea of using UNET. I had no idea it was in such a bad state with no signs of improvement. Although i think it is great you are willing to take on this challenge. It is unfortunate that Unity has let it come to this.
     
  15. vis2k

    vis2k

    Joined:
    Sep 4, 2015
    Posts:
    2,718
    Thanks for the info.

    By the way @larus, it looks like you are trying to create your own GetComponentsInChildren function in NetworkProximityChecker:
    Code (CSharp):
    1.         // called hiding and showing objects on the host
    2.         public override void OnSetLocalVisibility(bool vis)
    3.         {
    4.             SetVis(gameObject, vis);
    5.         }
    6.  
    7.         static void SetVis(GameObject go, bool vis)
    8.         {
    9.             foreach (var r in go.GetComponents<Renderer>())
    10.             {
    11.                 r.enabled = vis;
    12.             }
    13.             for (int i = 0; i < go.transform.childCount; i++)
    14.             {
    15.                 var t = go.transform.GetChild(i);
    16.                 SetVis(t.gameObject, vis);
    17.             }
    18.         }
    Even though it already exists and can be used like this:
    Code (CSharp):
    1.         // called hiding and showing objects on the host
    2.         public override void OnSetLocalVisibility(bool vis)
    3.         {
    4.             foreach (var r in GetComponentsInChildren<Renderer>())
    5.                 r.enabled = vis;
    6.         }
     
    Last edited: Sep 27, 2016
  16. vis2k

    vis2k

    Joined:
    Sep 4, 2015
    Posts:
    2,718
    Update: HLAPI Pro V1.0 released for Unity 2017.1.

    After reading @aabramychev 's post about how no one created a better HLAPI , I figured I should finally do it.
    Please read the top post for all the details. V1.0 already has the fix for the ReadString out of Range bug that happens randomly in every single UNET project.

    Please reply if you tested it, if you like it, if you have questions or suggestions. Please tell me what you want to see in the future. Source code access and license info will come soon.

    Let's fix UNET!
     
    Last edited: Aug 1, 2017
  17. moco2k

    moco2k

    Joined:
    Apr 29, 2015
    Posts:
    289
    Thanks for your efforts! I'm looking forward to test it.

    One suggestion: I would appreciate to have more transparency and information on bandwidth consumptions when using particular HLAPI methods. I know that this is more a matter of documentation, but maybe you decide to add some additional documentation as well (ofc only where it is needed).
     
    Last edited: Aug 1, 2017
    vis2k likes this.
  18. vis2k

    vis2k

    Joined:
    Sep 4, 2015
    Posts:
    2,718
    Which methods in particular? Do you mean 'how many bytes a Rpc uses' or do you mean 'how many bytes a SyncVar uses per second' etc.?
     
  19. moco2k

    moco2k

    Joined:
    Apr 29, 2015
    Posts:
    289
    I think both. It would be helpful to have clear information right from the start, e.g. about header bandwidth consumptions or for magic stuff that is going on under the hood. Especially for the relevant methods such as SyncVars, Commands, RPCs, SyncLists, etc. I have once started a thread about this here. I think such information should be part of the official UNET docs but it's not there yet. So, it might be a beneficial option for additional docs.
     
    Last edited: Aug 1, 2017
  20. Possum1

    Possum1

    Joined:
    May 19, 2017
    Posts:
    3
    Great work. A fix for the readstring bug is huge on its own. Thanks for your work.
     
    vis2k likes this.
  21. vis2k

    vis2k

    Joined:
    Sep 4, 2015
    Posts:
    2,718
    I see. I will look into the code and see if I can find anything.
     
  22. nonom

    nonom

    Joined:
    May 1, 2014
    Posts:
    12
    Good luck and have fun ;)
     
  23. Vancete

    Vancete

    Joined:
    May 3, 2010
    Posts:
    163
    Thanks for your work! (just posting here for checking it later at home)
     
    vis2k likes this.
  24. vis2k

    vis2k

    Joined:
    Sep 4, 2015
    Posts:
    2,718
    Download will be available again soon, looking into a potential issue first

    Wasn't much work yet, but thanks.

    Please keep me all posted on wether or not it works in your project and remember to rebuild all clients/servers first.
     
    Last edited: Aug 1, 2017
  25. TwoTen

    TwoTen

    Joined:
    May 25, 2016
    Posts:
    1,011
    I know that post is old. But no he isn't reinventing GetComponentsInChildren. GetComponentsInChildren goes down the whole hierachry. He just checks the direct children of this object.
     
  26. vis2k

    vis2k

    Joined:
    Sep 4, 2015
    Posts:
    2,718
    And then calls SetVis again on each child. Recursion is used there.
     
    ferretnt likes this.
  27. TwoTen

    TwoTen

    Joined:
    May 25, 2016
    Posts:
    1,011
    Oh, did not spot that! My apologies.
     
  28. TwoTen

    TwoTen

    Joined:
    May 25, 2016
    Posts:
    1,011
    Are you planning to add support for the Unet LLAPI timestamp feature? Don't think that's in the HLAPI
     
  29. vis2k

    vis2k

    Joined:
    Sep 4, 2015
    Posts:
    2,718
    Update: new version uploaded, download link is in the first post.
    • ProximityChecker GetComponentsInChildren replacement
    • NetworkManager.Awake HLAPI-Pro welcome message for easy check
    • Temporarily removed my ReadString out of range fix while I am researching another occurence at one of my customer's projects
    Maybe later. I am more interested in bugfixes and code improvements first.
     
    Last edited: Aug 1, 2017
    TwoTen likes this.
  30. nxrighthere

    nxrighthere

    Joined:
    Mar 2, 2014
    Posts:
    382
    Link to the source code repository please. :rolleyes:
     
  31. wobes

    wobes

    Joined:
    Mar 9, 2013
    Posts:
    502
    Hey, could you implement some authorization system on HLAPI, with a some byte[] array for example client.Connect(ip, port, data); an the server won't connect the player to the server if the credentials are wrong, thanks.
     
  32. vis2k

    vis2k

    Joined:
    Sep 4, 2015
    Posts:
    2,718
    Update: next version was uploaded.
    • [2017-08-01] OnSerialize/OnDeserialize safely
      • Problem: the reader/writer is passed through all components. If one messes up, all other components will get strange errors like ReadString/ReadByte out of range
      • Solution: data length is included for each component, buffer copies are passed to each component so that it's impossible to touch any other component's serialization data.
    • [2017-08-01] OnSerialize/OnDeserialize detailed error logging
      • Problem: errors in OnSerialize/OnDeserialize are never shown. If we are lucky, we see ReadString/ReadByte out of range errors, but sometimes just corrupt data.
      • Solution: errors are caught properly before calling OnSerialize/OnDeserialize and log messages give detailed info about the object's name, component's type, sceneId, expected data size, and known causes.
    Here is a screenshot of the detailed error logging:
    2017-08-01_ondeserialize error log.png
    There will be no more randomness in OnSerialize/OnDeserialize errors. They will be easy to debug.


    Coming soon

    You should do that in your custom NetworkManager, just send the account info along when connecting. I do that in uMMORPG too.
     
    Last edited: Aug 1, 2017
    nxrighthere likes this.
  33. vis2k

    vis2k

    Joined:
    Sep 4, 2015
    Posts:
    2,718
    Progress: repository link added to the first post.
     
  34. mons00n

    mons00n

    Joined:
    Sep 18, 2013
    Posts:
    212
    This is a great idea! If we could fix up the NetworkTransform so people don't have to write their own and get rid of massive per frame memory allocs in the NetworkAnimator then I'd be a happy camper.
     
  35. nhold

    nhold

    Joined:
    May 2, 2017
    Posts:
    48
    Maybe it's a good idea to work with Unity and get these accepted as PRs (Minus the SyncVar limit increase, that can be kept out).

    Unfortunately it seems Unity hasn't merged any PRs for the HLAPI, they should really think about it.

    I also don't think you should change NetworkTransform, just have a NetworkTranformInterpolated.
     
    Last edited: Aug 2, 2017
  36. VergilUa

    VergilUa

    Joined:
    Dec 22, 2014
    Posts:
    885
    Wow, this is HUGE. How did I missed this earlier?

    I hope this would became a part of actual HLAPI library. Not that I wouldn't pay for it, just to keep my sanity.

    If you'd fix that sceneId bug, that would be really, really goood.
     
    Last edited: Aug 2, 2017
  37. vis2k

    vis2k

    Joined:
    Sep 4, 2015
    Posts:
    2,718
    Good morning everyone. Glad to see so much positive feedback here. Next wave of improvements coming soon.

    That would be nice yes.

    Will see about that yes

    SceneId bug is my highest priority. I have a fix that works, except when you build the game with a scene file that you never opened before. Need to figure out how to set and save a sceneid in a scene that isn't open first.
     
    VergilUa likes this.
  38. vis2k

    vis2k

    Joined:
    Sep 4, 2015
    Posts:
    2,718
    Update: added a new Experimental version to the first post:
    • [2017-08-02] assetId uses a prefab's m_localIdentifierInFile instead of a complicated NetworkHash128 workaround
      • Problem: Networkhash128 was used to uniquely identify a prefab based on it's path. This is unnecessarily complicated and uses 128 bytes of data and wasn't resistant to renaming.
      • Solution: Unity's built in m_localIdentifierInFile is a persistent unique id for prefabs, so we might as well use it. It fits into a long value, so we save 64 bytes each time we send it over the network.
    This bothered me for a long time.

    Now that the asset id is a simple struct wrapped around an 'ulong', NetworkAssetId, NetworkSceneId and NetworkInstanceId are just simple wrappers around built in types. Might be possible to make them even simpler too.
     
    Last edited: Aug 2, 2017
    nhold, VergilUa and camta005 like this.
  39. TheWesselGames

    TheWesselGames

    Joined:
    Aug 31, 2016
    Posts:
    30
    Seems really promising. Looking forward to the updates!
     
    vis2k likes this.
  40. vis2k

    vis2k

    Joined:
    Sep 4, 2015
    Posts:
    2,718
    Thanks. Playing around with NetworkTransform right now..
     
  41. vis2k

    vis2k

    Joined:
    Sep 4, 2015
    Posts:
    2,718
    Progress: turns out that NetworkTransform is a giant mess, 2144 lines of code for all the relevant components. It even has package handling hooks in the NetworkServer code.

    That's way beyond fixing, so I decided to rewrite NetworkTransform from scratch.

    Position interpolation is already ultra smooth, here is a uMMORPG test: https://gyazo.com/0519736c3794fa64f5c3dbf2f0287ae1
     
    Last edited: Aug 2, 2017
    mons00n and PartyBoat like this.
  42. PartyBoat

    PartyBoat

    Joined:
    Oct 21, 2012
    Posts:
    60
    That link is one of the most pathetic things I have ever read. I'm sure aabramychev and the rest of the networking team are just doing their best, but Unity Technologies has a valuation of over one BILLION dollars and has over 1500 employees. The fact that they thought it was okay to leave something as important as networking to be written by the community almost makes me want to give up on Unity altogether. It blows my mind how many games released today are multiplayer and yet a company as massive as this treats their networking solution like a second class citizen. Now we rely on a single unpaid member of the community to fix something that a company with plenty of cash and staff to throw around should be working on.

    Anyway, thanks for your effort vis2k! It's very generous of you to do Unity's work for them and release it for free. I will always be a big supporter of anyone who decides to create an open source project to help the community. Best of luck!
     
    Last edited: Aug 3, 2017
    nickonmir, PeterB, Thanathos and 2 others like this.
  43. vis2k

    vis2k

    Joined:
    Sep 4, 2015
    Posts:
    2,718
    Thanks. I guess it's like he said, HLAPI was just an example on how to use LLAPI. The LLAPI is UNET. And that works impressively well and is far from easy to do.

    HLAPI is just one way to do a high level architecture, there's value in not being tied to any. I think this architecture with SyncVars/Commands/Rpcs is really good though, it just needs some cleaning up.
     
    nickonmir, angusmf and TwoTen like this.
  44. TwoTen

    TwoTen

    Joined:
    May 25, 2016
    Posts:
    1,011
    Alex is the LLAPI guy. And how do you know they have 1500+ employees? I am not saying you are wrong. Just wondering about your sources? Only one I can find is Wikipedia. But there is no source on that number. So it could be made up.
     
  45. PartyBoat

    PartyBoat

    Joined:
    Oct 21, 2012
    Posts:
    60
    You're right about Alex, I'll edit my post.

    Actually the valuation is even higher than I had seen previously. This is the most recent interview I could find (May 2017). About halfway through the Q and A John Riccitiello says:

    "We’re hiring 10 or 15 people a week, so yeah, that number changes. But every company like ours has some attrition. We’re at a low attrition number. We’ll probably finish the year with 1,500 to 1,600. We’re not hiring like we were two years ago, building up the company to do all the stuff we’re able to do now. But we’re still growing. Revenue is growing even faster."​

    The article is actually pretty interesting if you want a sense of Unity as a company and where they are heading.

    Fair enough, I mostly felt like ranting a little bit. Although I maintain there is no reason why Unity couldn't create a fully-featured, non-example, robust high level architecture for the most popular use cases, or at least they could improve the old one. It would be a huge feature win for the engine.

    I don't want to derail your thread though so I'll leave it at that. :p
    Can't wait to see your work progress!
     
    Last edited: Aug 2, 2017
    VergilUa and TwoTen like this.
  46. mons00n

    mons00n

    Joined:
    Sep 18, 2013
    Posts:
    212
    How frequently are you sending position updates and via what QoS?
     
  47. robochase

    robochase

    Joined:
    Mar 1, 2014
    Posts:
    211
    if i could chime in about the HLAPI and a possible direction of this library - what I would really like out of the HLAPI is more dependency-injection-esque patterns. for example, the HLAPI already has ways for you to supply your own NetworkConnection class to use instead of the built in one. more stuff like this would be very helpful.

    the thing about the HLAPI that really sucks is that if you don't like one part of it, you have to change the source code, generate DLLs, and shove them into your unity application folder. this is tedious to maintain, especially if you have multiple HLAPI unity projects on your computer. ideally, it should be a cinch to inject changes into the HLAPI at the project level and not the system level so that all your different projects can play nicely with each other. it would also make upgrading unity versions a lot less painful
     
    TwoTen and camta005 like this.
  48. vis2k

    vis2k

    Joined:
    Sep 4, 2015
    Posts:
    2,718
    It uses the DefaultUnreliable channel like the original one. There's another issue with default channels that I want to work on too. So right now the code always assumes that DefaultUnreliable is channel 0 in your NetworkManager. But if you reorder them it might wind up using Reliable, StateUpdate or whatever other channel there is in the first slot. Unless I am missing something. Will have to do more research there soon.

    Frequency can be selected by the user via 'Send Interval' in seconds. So a smaller send interval means more updates. The video uses 0.1s. I just tested 0.5s and that works just as well.
    upload_2017-8-3_10-28-40.png

    The original NetworkTransform sets the position in OnDeserialize immeditately without any interpolation, so any interval should look smoother than before.

    Would be best if we can put the Scripts in the editor directly. Right now this is not possible because parts of NetworkTransport are internal. I mentioned this to Alex.
     
    VergilUa likes this.
  49. TwoTen

    TwoTen

    Joined:
    May 25, 2016
    Posts:
    1,011
    I suggest using the Unreliable Ordered. Otherwise this might happend:
    We get an update. And move them there.
    We then get an older update. So we move them back!?
    We then get an even newer update. So we move them really far ahead
     
    vis2k and nxrighthere like this.
  50. vis2k

    vis2k

    Joined:
    Sep 4, 2015
    Posts:
    2,718
    True. My current interpolation method keeps a history with timestamp anyway, so packets arriving out of order won't be a problem.