1. Enter the Microsoft Developer Challenge for a chance to win prizes. Read more about it here.
  2. Enter the Google Play Indie Games Contest in Europe. Read more about it here.
  3. Unity 5.5 is now released.
  4. Become a closed-alpha partner on the new Facebook games platform. Read more about it here.
  5. Get early access to our Google Daydream Technical preview. Click here for more details!

Experience with Unity Networking, Photon, and uLink / UnityPark Suite for My Giants

Discussion in 'Multiplayer Networking' started by theBrandonWu, Nov 26, 2011.

  1. theBrandonWu


    Sep 3, 2009
    We posted a write-up of our experience with Unity Networking, ExitGame's Photon, and MuchDifferent's uLink (UnityPark Suite) on http://www.pepwuper.com/unity3d-mul...unity-networking-photon-and-ulink-comparison/ (link to blog). Of course each solution has its own pro's and con's, and this post is specifically about the solution we need for our specific game, but I thought I'd share it here as well for people who are looking into different solutions for multiplayer games.



    Creating multiplayer game logic for My Giants turned out to be a very challenging task. There are many concepts and different layers of complexity that need to be addressed in order to get good results. For us, the major decision was which kind of server logic we want to build: non-authoritative, authoritative or semi-authoritative.

    A non-authoritative server exists only as a kind of proxy between all the connected clients. The server relays messages sent by clients and doesn’t know anything or very little about the game logic. All of the game logic is implemented on a client. Such setup is prone to hacking and cheating, since it is possible to change the original game logic on the client. Hacking software even exists that can automatically search and modify important game variables like lives, score, etc… On the other hand, since all the logic is on the client side, the server requires much less cpu and memory resources than an authoritative server.

    Authoritative servers are the most secure in terms of cheating because all game logic runs on the server. The server contains proper game state at any moment and it can detect and override possible client’s attempts to cheat. For example, on the client side character speed is hacked in order to gain advantage over the other players. However, this does not make any difference for other players, because the server calculates the movement of the hacked player and only the server result is relevant.

    Semi-authoritative server is a blend between the two aforementioned approaches, giving some authority to the client over certain aspects of game logic. For example, in semi-authoritative setup, client reports to the server when an opponent is hit and should receive damage, and the server keeps track of a player’s health status and decreases it accordingly.

    In the course of a few months our networking game logic went through many iterations of improvement and experimenting, trying three networking technologies:

    • Unity Networking,
    • Photon by ExitGames,
    • and finally uLink by MuchDifferent
    I’ll try to give an overview of our experience with the three technologies, some of the difficulties we had and a few core differences. Our networking logic is still in development and there will probably be other observations as we progress, but this is as good time as any, to share some of the things we picked up along the way.

    Unity Networking

    With almost no prior experience with multiplayer games, we started using Unity built-in networking as it seemed the easiest approach. Unity Networking is nicely integrated into Unity and works very well for rapid development. Network Views are components that make game object network-aware. Through Network Views, using State Synchronization and Remote Procedure Calls, any kind of multiplayer game logic can be implemented.

    Our intention was to create a working prototype in a fairly short amount of time. There are a lot of examples and nice tutorials to learn about Unity networking (i.e. M2H Tutorials), which helped us a lot in the beginning. We had basic movement and animation synchronization done in a matter of days. At that point, we only used peer to peer connection and we didn’t even think about the idea of having a headless server running on a cloud or VPS. P2P connection gave us a lot of headache during tests, because the servers were behind the router and the NAT punch-through functionality didn’t work as expected. These initial problems paired with a general opinion in the Unity community that built-in networking is not suitable for real-world games, made us think about a different solution. Although My Giants is envisioned as a game with 10 to 20 players per session, which Unity Networking could probably handle, we didn’t want to lock ourselves to a solution that, supposedly, has limitations with a fairly low number of players. True or not, we started considering other solutions and decided to try out Photon Network Engine.

    Unity Networking:


    When we started working on MyGiants networking, we soon found out that the semi-authoritative setup was the only way to go at that point. We didn’t want to have a non-authoritative server because we wanted to keep a level of control over cheating, and if we wanted to have fully authoritative server, we would have to use Unity built-in networking, which has it’s own problems in regards to scalability and performance.

    There are a lot of 3rd party server solutions available and after spending some time on evaluation we chose Photon from ExitGames, a very powerful network engine with optimized socket communication, reliable and non-reliable protocol built on top of UDP, encryption and many other nice features. The only thing we had to give up was the idea of a fully authoritative server. Photon server application is not aware of Unity geometry, physics and the collision system, which means we would need to recreate all those parts on the server side. This is a difficult task and what’s more important, prevents us from re-using Unity’s built-in features. That is why we used the semi-authoritative approach.

    We were able to implement networking logic relatively fast. That includes: player movement and animation states, throwing items, damage and health, NPC movement.

    Synchronizing NPCs gave us a bit of a headache. When synchronizing players, it is clear who is the owner. The player is the owner and the player is responsible for updating its own position. With NPCs, the server should be the owner, but Photon server can’t be the owner because it doesn’t know how to move NPCs. Photon server is not aware of Unity geometry and collisions. Thus, we need to move NPC ownership to one of the players. The server assigns ownership to one of the players who becomes a master client. This also requires logic for shifting ownership to another player in case the master client loses connection, which brings all kinds of synchronization problems.

    When comparing Photon and Unity Networking, Unity Networking makes it simple to write networking code that is more object oriented because each Game Object has Network View which is added to the object as Unity Component. For example, code for moving a character can be put into a script “PlayerController.cs”. The script is added to Unity Game Object – Character. This object also has Network View, and the PlayerController script uses that Network View both on the client and the server. The code is encapsulated and easy to maintain.

    With Photon, it is a bit more difficult. More work and knowledge is required to achieve this kind of abstraction, both on the client and server side. We were beginners with Photon and after some time we ended up with a very centralized networking code with 1000+ lines of networking code in one script, a lot of switch and if-else cases used just to relay messages between the server to the client and then to proper game objects. The code soon became unmanagable and needed refactoring. Aside from that, working with Photon is a pleasant experience. The framework is very good, there are basic applications which can be extended with own custom server logic and there is plenty of documentation and examples. Server logic is written in C# and is very convenient for us, because we mostly use C# for Unity scripts also.


    uLink (UnityPark Suite)

    During evaluation of different server solutions for multiplayer games, we noticed uLink as one option that was not that famous and was not talked about that much on the forums. It’s probably because the price for the product is very high and it seems like it’s aimed at already established, large studios. Because of the price we soon forgot about it but came back to it at the time we started refactoring our Photon code. uLink was recently made available to indies at a very popular price and we decided to try it out.

    uLink is more similar to Unity Networking than to Photon. It is also fully integrated into Unity and has Network View components, State Synchronization and Remote Procedure Calls. In fact, it is possible to automatically replace Unity Networking with uLink using uLink converter – that’s how similar the two technologies are. So, what’s the difference?

    uLink is supposed to be much more scalable and optimized than Unity Networking.
    certain built in concepts make multiplayer development easier, for example:
    in uLink settings there is a checkbox “Authoritative server”. If the checkbox is clicked, uLink refuses to execute RPCs or sync states between the clients. Clients can only call RPCs on the server and only the server can sync object states to the clients.

    Game Objects can be instantiated on all clients and on the server with a single call, but different prefabs can be used depending on where the object is instantiated. For example: when NPC is instantiated, the server is creator and it instantiates an object with prefab “NPCServer” which contains the whole AI logic for moving, attacking etc… while on the clients another prefab “NPCClient” is used, which is a lightweight version of “NPCServer”. “NPCClient” contains animations and simple logic to update character position, according to updates recevied by “NPCServer”. This is a very powerful concept and when paired with C# subclassing, produces clean and maintainable code.

    powerful test tool uTsung which can be used to generate many connections on the server and test how the game behaves under different conditions.
    uCollab, a Unity plugin that enables the developer to open two Unity editors, load a master project and a client project which is synced with the master project. That way, a developer can have a client scene loaded in one editor, server scene in another and debug both scenes, during multiplayer game testing. This boosts productivity significantly.
    In the end, we were able to port most of our Photon server and client side code in a week and a half, improving the overall code architecture, making it easier to add multiplayer features in the future and what’s most important, we moved from semi-authoritative to fully authoritative server.

    The main difference between Photon and uLink is that when using uLink, game server logic is developed in Unity. The server knows about the scene geometry, physics and collisions which makes development easier. In case of our own game My Giants, every match game is one game server instance, running on a cloud server. Game server instances are automatically started or stopped, depending on the number of concurrent players.

    Photon server application is not aware of Unity geometry, so in our opinion it is best suited for the type of games that don’t need this kind of information. For some games it is easy to write custom collision system, some games require the scene to be divided into movement areas (rectangle, hexagonal)… In this case, Photon is just as attractive a solution as uLink, so it comes down to choosing the best tool for the job. Inadvertently, we got to know three different networking technologies, and although we spent some extra time on it, it’s always good to have an extra weapon in a developers’ arsenal.

    uLink Server:

    uCollab Client + Server (VIDEO):
    Last edited: May 27, 2012
    beppim likes this.
  2. Gaski


    Jul 25, 2011
    Hi Brandon,

    Thanks for taking the time to share you experiences with us and the detailed write up. I too have just started using uLInk for my project and find it the perfect fit for my project. I too nearly overlooked this option entirely due to its currently somewhat lower profile than the other solutions.

    I am curious with regards how you are managing automated server instance startup within your cloud. I know that MuchDifferent will be releasing uZone next year which is described as an instance manager among other things. How are you currently implementing the automatic startup of server instances? Are you using a custom master server or something similar? Also, which cloud service are you currently using (or is this your own private cloud)? I have tried some cloud services in the past and found them to be very prone to frequent lag spikes in high paced games. If you have found one where this is not the case I would love to know,

    Thanks again
  3. killroy


    Nov 8, 2011
    Hi Gaski,

    I'm working with Brandon on My Giants project, so maybe I can help with some of the technical questions.

    Regarding the automated server instance startup, we don't yet have the stable solution that can be used for production, but since My Giants is in relatively early stage of development, we only need a setup for testing. We're also eagerly waiting for uZone and other product included into UnityPark Suite and we'll probably use uZone. But for now, we basically have a simple backend on the same cloud where we run our game server instances. The backend consists of SQL Server express and a simple ASP.NET handler (http://www.dotnetperls.com/ashx) which processes http requests from Unity Servers. This can be, of course, replaced with any other combination (PHP-MySQL, etc...)

    Then in our server instance we use something like :
    WWW www = new WWW("http://localhost/ServerHandler/?serverId=serverId&serverEvent=event");
    uLink_OnPlayerConnected(uLink.NetworkPlayer player) and
    uLink_OnPlayerDisconnected(uLink.NetworkPlayer player)

    to report to the backend via http request that the number of connected players has changed. The backend writes down the information to the database and depending on the number of current players spawns another unity server instance or shuts down existing. For example, we have 2vs2 match games, so if initially two server instances are running and the number of players increases to 6, another instance is spawned. Then when number of players increases to 10 another is spawned. This of course needs a better handling logic for production, like some logic for matchmaking the players of the similar rank and so on..but we're not at that stage yet :)

    For the cloud service, we're currently using www.airvm.com
    I can't really say if it's good for production, because we have been using it only for a relatively small number of players, but this service has been recommended by one of the Photon team members. Initially we wanted to go with Amazon EC2, but they mentioned it's not good because of lag.

    Which ones did you try?

  4. Meltdown


    Oct 13, 2010
    Some good info, thanks guys.

    uLink is currently offering cloud based hosting from 55 Euros a month in a partnership with http://www.game-hosting.eu/ who have servers all over the world, and based on the reviews they get they sound like the real deal with some serious hardware.
  5. hjupter


    Dec 23, 2011
    I heard they will offer their own cloud based hosting, but thats the price? $73? is not that too expensive? well unless it's a good server capable of handling a good amount of players, I would like to know whats the CCU for this price
    Last edited: Feb 23, 2012
  6. Meltdown


    Oct 13, 2010
    I'm busy chatting to uLink and game-hosting.eu at the moment over email.
    Once I've found out a bit more I'll share the responses here.
  7. pixelsteam


    May 1, 2009
    Looking forward to the info you get back.

    Thank you Plinan for writing up this great report. Please keep us in the hoop on any new developments. Much appreciated.
  8. theBrandonWu


    Sep 3, 2009
    Actually our awesome programmer Killroy wrote this one up, so all credit goes to him! :) Thanks!!
  9. Meltdown


    Oct 13, 2010
    In case you missed, it, this thread I started has some good discussion and findings on the best options to host in US and Europe along with some other good advice from a few people.
  10. theBrandonWu


    Sep 3, 2009
    Great. Just posted there what we are using. :)
  11. dreammakersgroupAdmin


    Feb 13, 2012
    Thanks for sharing your information.
  12. bpears


    Aug 23, 2012
    This thread is getting a bit old, but good info here, still very relevant I think.

    One thing I'd like to know is if fully authoritative uLink Server instances would be a expensive approach for a bigger game?

    You mentioned that you needed a server instance per match, that seems like it would cost a lot from the server company, compared to a nonauthoritative cloud? I assume you did this because the server side needs to do all the thinking, but I'm still interested in cost difference from the server renting standpoint. I'm not really sure how many server instances you could run per actual sever(say dualcore), for a game like Saints Row or something.

    Anyway, thanks for the info thus far, really helpful.
    Last edited: Dec 29, 2013
  13. P_Hansson


    Jul 4, 2012
    There's some overhead with each server process. To avoid this overhead you can run multiple game sessions on the same server with some trickery with network groups feature of uLink, but it's easier to do it the way he mentions. It's not that much of a deal to run several server processes on the same physical machine - it's something that's desirable anyway to exploit multiple cores.

    At the end of the day it's going to take a certain amount of time executing your server side logic regardless of what solution you pick. How much? You'll have to measure it. There's nothing magical about it. Or you can offload calculations to clients at which point you make cheating much easier and complicate logic due to there not being a single authority.
    Last edited: Dec 29, 2013
  14. theBrandonWu


    Sep 3, 2009
    Like @P_Hansson has mentioned, it really comes down to how you implement your server-side client-side logic. uZone (http://www.muchdifferent.com/?page=game-unitypark-products-uzone) can help you control your server instances, but the balancing between cost vs benefits of running things on the server-side is up to your game. You probably want to open up a spreadsheet and make some assumptions as to how many concurrent players you expect, how many instances you'll need to run the game, how many games can each instance support... There's more discussion on uLink's forum (http://forum.muchdifferent.com/unitypark/).

    In summary, a non-authoritative setup is likely to be cheaper than an authoritative setup. There are things you can do to minimize the server cost if you have an authoritative setup. This is a great article on multiplayer server setup that, although not Unity specific, can provide more insight on the topic: http://www.gamasutra.com/view/feature/3094/1500_archers_on_a_288_network_.php