Continuing on our quest to find a workable networking solution for our HoloLens application, we gathered information about various networking solutions and their use with the HoloLens. Since we want to make an efficient working environment for sharing holograms on the HoloLens, a good networking solution and a fair amount of code are needed. This week, we investigated different networking solutions based on 3 criteria – their ability for networking, simplicity of use, and compatibility with the HoloLens. Our solution requires sharing Holograms with multiple users, and allowing manipulations of the hologram to be available to all users in the group. It needs to be able to work on LAN or P2P networks, as our client is not in an area with good internet. Finally, it needs to be simple enough to use so that programmers with little networking experience can make it work with a little research and not require excessive work to get simple features and networking implemented correctly.
Researching and testing all of the networking solutions was fairly time consuming due to the compatibility errors that are a nuisance for most of the solutions when building a windows app for the HoloLens, which uses the UWP rather than .Net framework. However, if you are using Unity 5.6 or higher, you can go to the player settings, windows section and alter your scripting backend to IL2CPP and your API compatibility to .Net 4.6, which will fix many compiler errors from common namespaces. Note that this might not work for Photon and possibly others, who seem to work with the default .Net backend and .Net 2.0 subset API. There is also difficulty in understanding networking itself, which requires a bit of research to understand all the parts, especially if you choose a solution with less starting features like we did with UNET.
Here are the main networking solutions that we looked at:
Photon networking by Hello Labs is one of the more well-known networking solutions for Unity. Photon is easy to start development for, but reportedly can be hard to deal with in the later stages. When I made my example it was fairly easy to start a networked lobby with the scripts that come with Photon. However, Photon has the structure of client ownership, so if you want to control objects from different clients you need to pass ownership over to that client for any changes. This isn’t necessarily difficult, and there are other options like using ClientRpc functions to send information to all clients. Photon may make much more work when dealing with AI controlled characters who will likely be placed under a single master client rather than being controlled by the server, or objects that might change ownership under specific conditions.
Photon is hosted on the server so it doesn’t matter if a client leaves the match, the host will not be dropped. It uses built in encryptions which would prevent or reduce information leakage and possible tampering. It also has built in punch-through to connect to programs behind firewalls, as well as room, lobby and matchmaking creation with some simple code. If, for some reason you must use an older version of Unity than 5.6, Photon is one of the few buildable solutions that will work on 2.0 .Net subset.
Some demerits or difficulties with Photon are that there is no ability to make custom server code when on Photon’s server, and everything must be run from the client side, with the server only relaying messages. The application also needs to be connected to the internet to send information through Photon’s server. Both these issues can be worked around by hosting a custom server, which can be done through UNET or built from scratch, though the latter isn’t recommended for those faint of heart or short on time.
Cost: Photon can be tested and developed for free, but you only get 20 concurrent users (CCU) on their server and will need to purchase more when releasing the product, which costs approximately $100 per 500 CCU monthly. More info here: photonengine.com/en-US/Realtime/Pricing#plan-20
Unviable Network Solutions
There are several solutions that are simply not able to work with the HoloLens at the moment but may be decent networking solutions under different circumstances…but these solutions may come up in searches frequently, so I would like to cover a few of these solutions to save you the time of trying them.
First is UnityPark’s uLink, a networking solution that is robust and quite extensive, with several other tools to test and add features to networking. That is, if it were still 2014, when the last update for uLink was released. Unity’s default networking solution, UNET came out just after this, and much of their code used the older version of unity networking which is no longer supported. I tried to build it for the HoloLens as a test, but it failed to build. The issues are too extensive to bother. The design allowed for some clean code, but for the HoloLens we needed to look elsewhere.
Second is Bearded Man Studios’ Forge networking which was recently remastered with a few new features. This uses the concept of network objects, and a menu to create all the networked variables. When something is changed on a client object you can get its network object and change the same variable on that, which will then change the object on other clients. It is designed for unity and handles sending data in the background. It also comes with multithreading and TCP which in this case is also its main detriment. When building this for the HoloLens, there are many build errors that aren’t solved by using IL2CPP and 4.6 API, and it appears that unity is at fault in this case. Some functions in the System.Threading namespace and possibly the TCP namespace as well, have not yet been implemented by unity and this solution will not work for the HoloLens until they are implemented.
Lastly Created by Heroic labs, Nakama is a relatively unknown networking solution, and very few opinions on it can be found. It seems mostly geared to social games, with many features for that purpose, but we aren’t creating a social game. That’s not to say that this couldn’t be used, but it has an odd behavior when building for the HoloLens where some System.Threading namespace functions in the basic HoloLens packages are causing compile time errors. These same files are used in several other projects and build just fine, but this solution wasn’t ideal for us.
uLink Cost: free to download, license is $550 for an indie license, though I’m not sure if this is still going
Forge Cost: open source or $75 (on the asset store)
Nakama Cost: free (on the asset store)
Finally, the default unity networking solution UNET is not a bad choice. The API/Namespace and compatibility issues from other namespaces don’t pop up in this solution, and nothing is more integrated with unity. However, in comparison with the other solutions, UNET is lacking in many basic features and is a little difficult to start making custom lobbies and messages. It lacks the built in punch through to connect even through firewalls, so in initial testing we didn’t immediately realize that was the reason we were having connection failures. There are several options for sending information over the network, and we are still deciding on which method to use. RPC functions, syncvars and default components like NetworkTransform all can work, but using the messaging system is our current method. You can use the default network message sender, and make any custom class that derives from MessageBase which will handle serialization/deserialization internally. Alternatively, it requires a bit of research, you can build your own serializer/deserializer (the answer over here: goo.gl/1Bw9Q9 has been invaluable), and set up any custom class that derives from NetworkMessage and send that to the server or clients that are listening for it. Currently this is our networking solution, and appears to be the go to for many HoloLens developers.
Cost: Unity personal will get you 20 CCU, but if you want more than that a Unity plus account is needed (though exceptions can be made for personal) and cost is only traffic that is used, currently $0.49/GB. More information here: unity3d.com/unity/features/multiplayer
Many solutions are not viable for our project and several of them still are not fully compatible with the HoloLens. Photon and UNET are currently our best options, but for flexibility and easier LAN networking we have chosen to work with UNET. Though we are having difficulties with the way to send messages over the network efficiently and some other areas, we are making progress.