IT Hare on Soft.ware

Unity 5 vs UE4 vs Photon vs DIY for MMO

posted by , translated by Sergey IgnatchenkoIRL

 
Author:  Follow: TwitterFacebook
Job Title:Sarcastic Architect
Hobbies:Thinking Aloud, Arguing with Managers, Annoying HRs,
Calling a Spade a Spade, Keeping Tongue in Cheek
 
 

Pages: 1 2

Jump to a  Huge Table comparing 40+ different network-related parameters of Unity 5, UE4, and Photon
Three-way shootout: Unity vs UE vs Photon

[rabbit_ddmog vol=”2″ chap=”Chapter 7 from “beta” Volume II”]

By this point, we’ve discussed all the major parts of Modular MMOG Architecture. Now we are in a good position to take a look at some of the popular game engines and their support for MMOG, aiming to find out how they support those features which we’ve described for Modular Architecture.

DIY Do it yourself, also known as DIY, is the method of building, modifying, or repairing something without the direct aid of experts or professionals— Wikipedia —There are lots of game engines out there, so we’ll consider only the most popular ones: Unity 5, Unreal Engine 4, and Photon Server (which is not a game engine in a traditional sense, but does provide MMOG support on top of the existing game engines). Note that comparing graphics advantages and disadvantages of Unity vs UE, as well as performance comparisons, pricing, etc. are out of scope; if you want to find discussion on these issues, Google “Unity 5 vs UE4”, you will easily find a ton of comparisons of their non-network-related features. We, however, are more interested in network-related things, and these comparisons are not that easy to find (to put it mildly). So,

Let the comparison begin!

Unity 5

Unity 5 is a very popular (arguably the most popular) 3D/2D game engine. It supports tons of different platforms (HTML5 support via IL2CPP+emscripten included, though I have no idea how practical it is), uses .NET CLI/CLR as a runtime, and supports C#/JS/Boo (whatever the last one is) as a programming language. One thing about Unity is that it targets a very wide range of games, from first-person shooters to social games (i.e. “pretty much anything out there”).

Surprised hare:“As usual, support of CLI on non-MS platforms requires Mono which is not exactly 100% compatible with CLR, but from what I've heard, most of the time it worksAs usual, support of CLI on non-MS platforms requires Mono which is not exactly 100% compatible with CLR, but from what I’ve heard, most of the time it works (that is, as long as you adhere to the “write once – test everywhere” paradigm).

Another thing to keep in mind when dealing with Unity is that CLR (as a pretty much any garbage-collected VM, see discussion in Chapter VI) suffers from certain potential issues. These issues include infamous “stop-the-world”; for slower games it doesn’t really matter, but for really fast ones (think MMOFPS) you’ll need to make sure to read about mitigation tricks which were mentioned in Chapter VI.

Event-driven Programming/FSMs

Unity is event-driven by design. Normally the game loop is hidden from sight, but it does exist “behind the scenes”, so everything basically happens in the same thread,1 so you don’t need to care about inter-thread synchronisation, phew. From our point of view, Unity is an ad-hoc FSM as defined in Chapter V.

In addition, Unity encourages co-routines. They (as co-routines should) are executed within the same thread, so no inter-thread synchronisation is necessary. For more discussion on co-routines and their relation to other asynchronous handling mechanisms, see Chapter VI. [[TODO! – add discussion on co-routines there]]

One thing Unity event-driven programs are missing (compared to our ad-hoc FSMs discussed in Chapter V) is an ability to serialise the program state; it implies that Unity (as it is written now) can’t support such FSM goodies discussed in Chapter V as production post-mortem, server fault tolerance, replay-based testing, and so on. While not fatal, this is a serious disadvantage, especially when it comes to debugging of distributed systems (see “Distributed Systems: Debugging Nightmare” section in Chapter V for relevant discussion).

1 or at least “as if” it happens in the same thread

 

Unity for MMOG

When using Unity for MMOG, you will notice that it deals with one single Game World, and that separation between Client and Server is quite rudimentary. In “Engine-Centric Development Flow” section below we’ll see that this might be either a blessing (if your game is more on “Client-Driven Development Flow” side) or a curse (for “Server-Driven Development Flows”). On the other hand, in any case it is not a show-stopper.

Communications: HLAPI

Communication support in Unity 5 (known as UNet) is split into two separate API levels: High-Level API (HLAPI), and Transport-Level API (LLAPI). Let’s take a look at HLAPI first.

Hare thumb down:“You SHOULD NOT use Command requests to allow the client to modify state of the PC on the server directlyOne potential source of confusion when using HLAPI, is an HLAPI term “Local Authority” as used in [UNet]. When the game runs, HLAPI says that usually a client has an “authority” over the corresponding PC. It might sound as a bad case of violating the “authoritative server” principle (that we need to avoid cheating, see Chapter III), but in fact it isn’t. In HLAPI-speak, “client authority” just means that the client can send [Command] requests to the server (more on [Command]s below), that’s pretty much it, so it doesn’t necessarily give any authority to the client, phew.

On the other hand, you SHOULD NOT use [Command] requests to allow the client to modify state of the PC on the server directly; doing this will violate server authority, widely opening a door for cheating. For example, if you’re allowing a Client to send a [Command] which sets PC’s coordinates directly and without any server-side checks, you’re basically inviting a trivial attack when a PC controlled by a hacked client can easily teleport from one place to another one. To avoid it,

instead of making decisions on the client-side and sending coordinates resulting from player’s inputs, you should send the player’s inputs to the server, and let the (authoritative) server simulate the world and decide where the player goes as a result of those inputs

State Synchronization

In HLAPI, basically you have two major mechanisms – “state synchronization” and RPCs.

State synchronization is a Unity 5’s incarnation of Server State -> Publishable State -> Client State process which we’ve discussed in Chapter VII. In Unity 5, state synchronization can be done via simple adding of [SyncVar] tag to a variable [UNetSync], it is as simple as that.

Importantly, Unity does provide support for both distance-based and custom interest management. Distance-based interest management is implemented via NetworkProximityChecker, and custom one – via RebuildObservers() (with related OnCheckObservers()/OnRebuildObservers()).

For quite a few games, you will need to implement Interest Management. Not only it helps to reduce traffic, it is also necessary to deal with “see through walls” and “lifting fog of war” cheats2

On top of [SyncVars], you may need to implement some (or all) of the Client-Side stuff discussed in Chapter VII (up to and including Client-Side Prediction); one implementation of Client-Side Prediction for Unity is described in [UnityClientPrediction].

Surprised hare:“While Unity does use per-field delta compression (or a reasonable facsimile), it cannot possibly implement most of the compression which we've discussed in 'Compression' section of Chapter VII.So far so good, but the real problems will start later. In short – such synchronization is usually quite inefficient traffic-wise. While Unity seems to use per-field delta compression (or a reasonable facsimile), it cannot possibly implement most of the compression which we’ve discussed in “Compression” section of Chapter VII. In particular, restricting precision of Publishable State is not possible (which in turn makes bitwise streams pretty much useless), dead reckoning is out of question, etc. Of course, you can create a separate set of variables just for synchronization purposes (effectively creating a Publishable State separate from your normal Client State), but even in this case (which BTW will require quite an effort, as well as being a departure from HLAPI philosophy, even if you’re formally staying within HLAPI) you won’t be able to implement many of the traffic compression techniques which we’ve discussed in Chapter VII.

These problems do not signal the end of the world for HLAPI-based development, but keep in mind that at a certain stage you may need to re-implement state sync on top of LLAPI; more on it in “HLAPI Summary” subsection below.

2 see Chapter VII for discussion on Interest Management

 

RPCs (a.k.a. “Remote Actions”)

In Unity 5, RPCs were renamed into “Remote Actions”. However, not much has changed in reality (except that now there is a [Command] tag for Client-to-Server RPC, and [ClientRpc] tag for Server-to-Client RPC). In any case, Unity RPCs still MUST be void. As it was discussed in Chapter VII, this implies quite a few complications when you’re writing your code. For example, if you need to query a server to get some value, then you need to have an RPC call going from client to server ([Command] in Unity), and then you’ll need to use something like Networking.NetworkConnection.Send() to send the reply back (not to mention that all the matching between requests and responses needs to be done manually). In my books3 it qualifies as “damn inconvenient” (though you certainly can do things this way).

In addition, Unity HLAPI seems to ignore server-to-server communications completely.[[PLEASE CORRECT ME IF I’M WRONG HERE]]

3 pun intended

 

HLAPI summary

Hare pointing out:“You can still use HLAPI despite its shortcomingsAs noted above, for quite a few simulation games, HLAPI’s [SyncVar] won’t provide “good enough” traffic optimization. But does it make HLAPI hopeless? IMHO the answer is “no, you can still use HLAPI despite its shortcomings”. HLAPI’s [SyncVar] will work reasonably good for early stages of development (that includes testing, and probably even over-the-Internet small-scale testing), speeding development up. And then, when/if your game is almost-ready to launch (and if you’re not satisfied with your traffic measurements), you will be able to rewrite [SyncVars] into something more efficient using LLAPI. It is not going to be a picnic, and you’ll need to allocate enough time for this task, but it can be done.

As for RPCs calls (and network events) – due to their only-void nature, they’re not exactly convenient to use (to put it mildly), but if you have nothing better (and you won’t as long as you’re staying within Unity’s network model) – you’ll have to deal with it yourself, and will be able to do it too.[[IF YOU KNOW SOME WORKABLE LIBRARIES PROVIDING non-void RPCs in Unity, PLEASE LET ME KNOW]]

In addition, I need to note that the absence of support for Server-to-Server communications is very limiting for quite a few games out there. Having your server side split into some kind of micro-services (or even better, Node.js-style nodes) is a must for any sizeable server-side development, and having your network/game engine to support interactions between these nodes/micro-services is extremely important. While manual workarounds to implement Server-to-Server communications in Unity are possible, doing it is a headache, and integrating it with game logic is a headache even more 🙁 . This is probably one of the Biggest Issues you will face when using Unity for a serious MMOG development.

Communications: LLAPI

Inquisitive hare:“Just as advertised, Unity Transport Layer API (a.k.a. LLAPI), is an extremely thin layer on top of UDP.Just as advertised, Unity Transport Layer API (also known as LLAPI4), is an extremely thin layer on top of UDP. There is no RPC support, no authentication, no even IDL or marshalling (for this purpose you can use .NET BinaryFormatter, Google Protocol Buffers, or write something yourself).

For me, the biggest problem with LLAPI lies with its IP:Port addressing model. Having to keep track at application level all those IP/port numbers is a significant headache, especially as they can (and will) change. Other issues include lack of IDL (which means manual marshalling for any not-so-trivial case, and discrepancies between marshalling of different communication parties tend to cause a lot of unnecessary trouble), lack of explicit support for state synchronization, and lack of RPCs (even void RPCs are better than nothing from development speed point of view).

On the positive side, LLAPI provides you with all capabilities in the world – that is, as long as you do it yourself. Still, it is that cumbersome that I’d normally suggest to avoid it at earlier stages of development, and introduce only when/if you have problems with HLAPI.

4 don’t ask why it is named LLAPI and not TLAPI

 

Unity 5/UNet Summary

Assertive hare:“All-in-all, Unity 5/UNet does a decent job if you want to try converting your existing single-player game into a low-player-number multi-player one.All-in-all, Unity 5/UNet does a decent job if you want to try converting your existing single-player game into a low-player-number multi-player one. On the other hand, if you’re into serious MMO development (with thousands of simultaneous players), you’re going to face quite a few significant issues; while not show-stoppers, they’re going to take a lot of your time to deal with (and if you don’t understand what they’re about, you can easily bring your whole game to the knees).

If going Unity way, I would suggest to start with HLAPI to get your game running as a MMO. Most likely, when using HLAPI for a serious MMOG, you’ll face traffic problems with replicated states (and/or cheating) when number of players goes up, but to have your prototype running HLAPI is pretty good. At this stage you’ll probably need to rewrite the handling of your Publishable State, most likely on top of LLAPI. This rewrite can include all those optimizations we’ve spoke about, and is going to be quite an effort. On the positive side, it can usually be done without affecting the essence of your game logic, so with some luck and experience, it is not going to be too bad.

Additionally, you’ll also have issues with server-to-server communications (which are necessary to split your servers into manageable portions). You can either implement these on top of LLAPI, or to use good old TCP sockets, but in any case you will stay even without RPCs, just with bare messages. While I’ve seen such message-based architectures to work for quite large projects, they are a substantial headache in practice 🙁 .

At this point you might think that your problems are over, but actually the next problem you’re going to face, is likely to be at least as bad as the previous ones. As soon as a number of your players goes above a few hundred, you’ll almost certainly need to deal with load balancing (see Chapter VI for discussion on different ways of dealing with load balancing). And Unity as such won’t help you for this task, so you’ll need to do it yourself. Once again, it is doable, but load balancing is going to take a lot of efforts to do it right 🙁 .

Unreal Engine 4

Arguing hare:“Unreal Engine is more oriented towards first-person games, and (arguably) does it better.Unreal Engine 4 is a direct competitor of Unity, though it has somewhat different positioning. Unlike Unity (which tries to be a jack of all trades), Unreal Engine is more oriented towards first-person games, and (arguably) does it better. Just as Unity, UE also supports a wide range of platforms (with differences from Unity being of marginal nature), and does have support for HTML (also using emscripten, and once again I have no idea whether it really works5).

As of UE4, supported programming languages are C++ and UE’s own Blueprints. At some point, Mono team has tried to add support for C# to UE4, but dropped the effort shortly afterwards 🙁 .

It should be noted that UE4’s variation of C++ has its own garbage collector (see, for example, [UnrealGC]). Honestly, I don’t really like hybrid systems which are intermixing manual memory management with GC (they introduce too many concepts which need to be taken care of, and tend to be rather fragile as a result), but Unreal’s one is reported to work pretty well.

5 as of beginning of 2016, support for HTML5 in UE4 is tagged Experimental

 

Event-driven Programming/FSMs

Unreal Engine is event-driven by design. As with Unity, normally game loop is hidden from sight, but you can override and extend it if necessary. And exactly as with Unity or our FSMs, everything happens within the same thread, so (unless you’re creating threads explicitly) there is no need for thread synchronization.

On the negative side of things, and also same as Unity, UE’s event-driven programs don’t have an ability to serialize the program state, and (same as with Unity), it rules out certain FSM goodies.

UE for MMOG

Just like Unity, UE doesn’t really provide a way to implement a clean separation between the client and the server code (while there is a WITH_SERVER macro for C++ code, it is far from being really cleanly separated). More on advantages and disadvantages of such “single-Game-World” approach in “Engine-Centric Development Flow” section below.

UE Communications: very close to Unity 5 HLAPI

Femida hare:“There is not much to discuss here, as both replication and RPCs are very close to Unity counterparts which were discussed above.Just like Unity, UE4 has two primary communication mechanisms: state synchronization (“Replication” in UE-speak), and RPCs. There is not much to discuss here, as both replication and RPCs are very close to Unity counterparts which were discussed above.

In particular, replication in UE4 is very similar to Unity’s [SyncVars] (with a different syntax of UPROPERTY(Replicated) and DOREPLIFETIME()). UE4’s RPCs (again having a different syntax of UFUNCTION(Client)/UFUNCTION(Server)) are again very similar to that of Unity HLAPI (with the only-void restriction, no support for addressing and for server-to-server communications, and so on).

Interest management in UE4 is based on the concept of being “network relevant” and is dealt with via AActor::NetCullDistanceSquared() and AActor::IsNetRelevantFor() functions (ideologically similar to Unity’s NetworkProximityChecker and RebuildObservers respectively).

Being so close to Unity 5 means that UE4 also shares all the drawbacks described for Unity HLAPI above; it includes sub-optimal traffic optimization for replicated variables, void-only RPCs, and lack of support for server-to-server communications; see “HLAPI summary” section above for further discussion.

On the minus side compared to Unity 5, UE4 doesn’t provide LLAPI, so bypassing these drawbacks as it was suggested for Unity, is more difficult. On the other hand, UE4 does provide classes to work directly over sockets (look for FTcpSocketBuilder/FUdpSocketBuilder), and implementing a (very thin) analogue of LLAPI is not that much of a headache. So, even in this regard the engines are very close to each other. As a result, for UE4 MMO development I still suggest about-the-same development path as discussed in “Unity 5/UNet Summary” section for Unity, starting from Replication-based game, and moving towards manually controlled replication (implemented over plain sockets) when/if the need arises.

Photon Server

Thinking hare:“Photon Server is quite a different beast from Unity and Unreal EnginePhoton Server is quite a different beast from Unity and Unreal Engine: unlike Unity/UE, Photon isn’t an engine by itself, but is rather a way to extend a game developed using an existing engine (such as Unity or Unreal) into an MMO. It is positioned as an “independent network engine”, and does as advertised – adds its own network layer to Unity or to Unreal. As a result, it doesn’t need to care about graphics etc., and can spend more effort of MMO-specific tasks such as load balancing and matchmaking service.

As Photon is always used on top of existing game engine,6 it is bound to inherit quite a few of its properties; this includes using game engine graphics and most of scripting. One restriction of Photon Server is that server-side always runs on top of Windows .NET and APIs are written with C# in mind (I have no idea how it feels to use other .NET languages with Photon, and whether Photon will run reasonably good on top of Mono). For the client-side, however, Photon supports pretty much every platform you may want, so as long as you’re ok with your servers being Windows/.NET – you should generally be fine.

Functionally, Photon Server is all about simulated worlds consisting of multiple rooms; while it can be considered a restriction, this is actually how most of MMOs out there are built anyway, so this is not as limiting as it may sound. In short – as we’ve discussed it briefly in Chapter VII [[TODO! – add discussion on Big Fat World there]], if your MMO needs to have one Big Fat World, you’ll need to split it into multiple zones anyway to be able to cope with the load.

Within Photon Server, there are two quite different flavours for networked game development: Photon Server SDK and Photon Cloud / PUN.7

6 or should I rather say underneath existing game engine?
7 Exit Games also provide Photon/Realtime and Photon/Turnbased cloud products, but I know too little about them to cover them here [[TODO! – try to learn more about them]]

 

Photon Server SDK: Communications

IMPORTANT: Photon Server SDK is not to be confused with Photon Cloud/PUN, which will be discussed below.

Unfortunately, personally I didn’t see any real-world projects implemented over Photon Server SDK, and documentation on Photon Server SDK is much less obvious than on Photon Cloud and PUN, so I can be missing a few things here and there, but I will try my best to describe it. [[PLEASE CORRECT ME IF I’M MISSING SOMETHING HERE]]

Hare thumb down:“Photon Server SDK doesn't explicitly support a concept of synchronized stateFirst of all, let’s note that Photon Server SDK doesn’t explicitly support a concept of synchronized state. Instead, you can BroadcastEvent() to all connected peers, and handle this broadcast on all the clients to implement state synchronization. While BroadcastEvent() can be used to implement synchronized state, there is substantial amount of work involved in making your synchronization work reliably (I would estimate the amount of work required to be of the same order of magnitude as implementing synchronised states on top of Unity’s LLAPI). In addition, keep in mind that when relying on BroadcastEvent(), quite a few traffic optimizations won’t work, so you may need to send events to individual clients (via SendEvent()).

From RPC point of view, Photon Server does have kinda-RPC. Actually, while it is named Photon.SocketServer.Rpc, it is more like message-based request-response than really a remote procedure call as we usually understand it. In other words, within Photon Server (I’m not speaking about PUN now) I didn’t find a way to declare a function as an RPC, and then to call it, with all the stubs being automagically generated for you. Instead, you need to create a peer, to send an operation request over the peer-to-peer connection, and while you’re at it, to register an operation handler to manage operation response.

This approach is more or less functionally equivalent to Take 1 from “Take 1. Naïve Approach: Plain Events (will work, but is Plain Ugly)” section of Chapter VI; as such, it inherits all the inconveniences of Take 1 listed there. In addition, I have my concerns about Peer.SetCurrentOperationHandler() function, which seems to restrict us to one outstanding RPC request per peer, which creates additional (and IMHO unnecessary) hassles.

Hare thumb up:“On the positive side (and unlike all the network engines described before), Photon Server does support such features as Server-to-Server communication and Load Balancing.On the positive side (and unlike all the network engines described before), Photon Server does support such all-important-for-any-serious-MMO-development features as Server-to-Server communication and Load Balancing.

Photon Cloud / PUN: Communications

IMPORTANT: Photon Cloud / PUN is not to be confused with Photon Server SDK, which is discussed above.

The second flavour of Photon-based development is Photon Cloud with Photon Unity Networking (PUN). While Photon Cloud/PUN is implemented on top of Photon Server which was discussed above, the way Photon Server is deployed for Photon Cloud/PUN, is very different from the way you would develop your own game on top of Photon Server SDK 🙁 .

The key problem with Photon Cloud is that basically you’re not allowed to run your own code on the server. While there is an exception for so-called “Photon Plugins”, they’re relatively limited in their abilities, and what’s even even worse, they require an “Enterprise Plan” for your Photon Cloud (which as of beginning of 2016 doesn’t even have pricing published saying “contact us” instead, ouch).

And as long as you’re not allowed to run your own code on the server-side, you cannot make your server authoritative, which makes dealing with cheaters next-to-impossible. That’s the reason why I cannot recommend PUN for any serious MMO development, at least until you (a) realize how to deal with cheaters given limited functionality of Photon Plugins, and (b) get a firm quote from Exit Games regarding their “Enterprise Plan” (as noted above, lack of publicly available quote is usually a pretty bad sign of it being damn expensive 🙁 ).8

This restriction is a pity, as the rest of PUN is quite easy to use (more or less in the same range as Unity HLAPI, but with manual serialization of synchronization states, what is IMHO more of a blessing rather than a curse, as it allows for more optimizations than [SyncVars]). Still, unless you managed to figure out how to implement an authoritative server over PUN (and how to pay for it too), I’d rather stay away from it, because any game without an authoritative server carries too much risk of becoming a cheaterfest.

8 BTW, I do sympathize Chris Wegmann in this regard and do realize that allowing foreign code on servers opens more than just one can of worms, but still having an authoritative server is that important, that I cannot really recommend Photon Cloud for any serious MMO

 

Assertive hare:“I want YOU to read page 2!

 

 

 

Keep reading for a  Huge Table comparing 40+ different network-related parameters of Unity 5, UE4, and Photon

Related posts

MMOG. RTT, Input Lag, and How to Mitigate Them MMOG: World States and Reducing Traffic IDL: Encodings, Mappings, and Backward Compatibility MMOG. Point-to-Point Communications and non-blocking RPCs Client-Side. On Debugging Distributed Systems, Deterministic Logic, and Finite State Machines
Join our mailing list:

Comments

  1. Kevin says

    “In the simplest form, [interest management] can be sending only information of those characters which are currently within certain radius from the target player (or even “send updates only to players within the same “zone”).”

    I’m not expert, but I think that means UE4 has this simplest form of interest management then?

    From https://wiki.unrealengine.com/Replication#When_Is_An_Actor_Replicated.3F

    “An Actor is replicated to a client when it is considered to be “network relevant”. There are a number of ways to control this. By default Unreal replicates an Actor when it is within range of a client (AActor::NetCullDistanceSquared controls the culling distance). “

    Reply

    • "No Bugs" Hare says

      You’re right, THANK YOU! I’ve added it to UE4’s description, please correct me if I got something wrong there).

      Reply

  2. Jesper Nielsen says

    Something that strikes me here is that you seem to imply that the Client game engine will also be used as a basis for the server.
    This isn’t exactly a given – I can’t answer for UE but Unity is mostly a client-side technology, and using it as a server is of course possible, but it will be a bit of a hack.
    Also – Unity is single threaded. Nothing stops you from starting threads in Unity (Except if you’re building for WebGL) but only one thread can access game objects. Of course you can work around it by only having 1 Game World FSM per process, but it complicates things a bit, forcing you to use RPC or similar to communicate between FSMs.
    I’m using Unity for my multiplayer game (MORPG – not really counting on “massive” numbers of players, but a lot of your points are still very relevant for me).
    The server is pure .Net, and communication is done via TCP / BinaryWriter (Be careful with BinaryFormatter/BinaryWriter btw – it is LittleEndian, as opposed to many network protocols).
    I’m not totally escaping the engine-centric approach on server side though – all of the zones must be created in Unity – with custom Editor scripts used to export the data relevant for the server.

    Reply

    • "No Bugs" Hare says

      > Something that strikes me here is that you seem to imply that the Client game engine will also be used as a basis for the server.
      > This isn’t exactly a given – I can’t answer for UE but Unity is mostly a client-side technology, and using it as a server is of course possible, but it will be a bit of a hack.

      Of course, and personally I wouldn’t do Server via Unity either, BUT – Unity is pushing their network stuff in a strong way, and I know people who went the way described in the Chapter above. AND – it is working too (with some quirks etc.). But “your” way (dropping HLAPI etc. altogether and doing your own marshalling with your own server) is perfectly viable too (and as I’ve said above – being a DIY person I would do it this way too ;-)), so I will add a section about using-DIY-server-with-Unity to the final version of the book. THANK YOU!

      Reply

    • "No Bugs" Hare says

      THANKS, I’ve made necessary clarifications, please let me know if you feel that it is not 100% correct. About UE4 and TCP – yes, I’ve mentioned FTcpSocketBuilder before, but as far as I know it cannot be easily integrated to support high-level stuff such as UPROPERTY :-(.

      Reply

    • "No Bugs" Hare says

      THANKS for the link, I’ve heard about DarkRift and uLink, but didn’t hear of Forge. Will probably add a paragraph or two about them to the “2nd beta” version of the book.

      Reply

      • says

        Thanks and good to hear you will address them. I’ve tried uLink back in 2013 but there hasn’t been any releases since early 2014 so not sure if it’s still in active development.

        DarkRift is very developer/plugin friendly and Forge provides you with all source code upon purchase. They both allow for custom de/serialisation which nicely ties into your topic on http://ithare.com/marshalling-and-encodings/

        Reply

  5. Ian Smith says

    [[TODO! – add discussion on co-routines there]] – If you haven’t written something, I could write something and you can edit it extensively, use as is or throw it away. I’d focus a bit on threads = cores vs coroutines = light weight timing manager. “Walk and chew bubble gum” I’d put in a coroutine example, vs “walk and use cell phone” as a multithreading example.
    “as of beginning of 2016, support for HTML5 in UE4 is tagged Experimental” – I haven’t done this lately, but I had issues with libraries and calls June 2015. I can try again if you’re interested.
    “or should I rather say underneath existing game engine?” – I strongly vote “below the existing game engine” especially for people who have English as a second language.
    “This approach is more or less functionally equivalent to Take 1 from “Take 1. Naïve Approach: Plain Events (will work, but is Plain Ugly)” section of Chapter VI; as Take 1 is not the most convenient thing to use (this it to put it very mildly), it will become quite a hassle to work with it directly. In addition, I have my concerns about Peer.SetCurrentOperationHandler() function, which seems to restrict us to one outstanding RPC request per peer, which creates additional (and IMHO unnecessary) hassles.” – Please note how cumbersome this paragraph is to essentially say: “Using the PhotonSDK’s implementation of RPC creates all of the same problems as the Naïve Approach: Plain Events (will work, but is Plain Ugly)” section of Chapter VI. I have my concerns about Peer.SetCurrentOperationHandler() function, which seems to restrict us to one outstanding RPC request per peer requiring a locking and queue mechanism to avoid missed messages.” Too much self reference loses context, citing author sourced slang or titles leads to client confusion. People are bad at new vocabulary already.

    Reply

    • "No Bugs" Hare says

      > If you haven’t written something, I could write something and you can edit it extensively, use as is or throw it away.

      Thanks for the offer :-). There is actually quite a bit of discussion of co-routines in general (and .NET async/await, though not “Unity co-routines”) within Chapter V of “beta 2”; overall, I DO like ANYTHING which saves me from explicit multithreading sync (such as mutexes/atomics) at the game/business level, so co-routines will do just fine :-). That being said, can you say whether it is possible to use Unity co-routines in a manner similar to .NET async/await (to introduce non-blocking processing with results triggered by, say, results of RPC call arriving, not just to wait for some time with WaitForSeconds())?

      > “as of beginning of 2016, support for HTML5 in UE4 is tagged Experimental” – I haven’t done this lately, but I had issues with libraries and calls June 2015. I can try again if you’re interested.

      Sure, any information like this would be potentially VERY useful :-).

      > Please note how cumbersome this paragraph is…

      Indeed; that’s one of the reasons I’m planning to hire a professional editor to fix this kind of stuff for the book. For the time being, I’ve fixed it a little bit (I hope), so at least it is a bit shorter now, but for the publishable version of the book this paragraph – and all such cumbersome things which I am so prone of 😉 – will be hopefully fixed by the editor :-).

      Reply

  8. Bulat Shamsutdinov says

    Hi! I’m more than just excited reading your book and articles!

    One proposal for an addition to the current chapter:

    You probably should list at least one “open source” engine, that is not UE4) Even as brief notice.

    A good example would be Urho3D. It is free, C++, open source engine, with networking, pathfinding, and etc, capable of running as a simulation server.

    A reason why – it might be a good middle ground for indies that want an option to tinker with a low-level stuff without been overwhelmed by the beast like UE or Unity (even if they can get source license).

    Reply

    • "No Bugs" Hare says

      You’re right – I do need to mention an open source engine (THANKS!) – and probably Urho3D is the one to discuss. As for their networking – do you by any chance happen to know what is the current status of their migration to RakNet (I’ve run into https://github.com/urho3d/Urho3D/issues/1810 – and it SEEMS that they’re migrating from kNet to RakNet, which is IMO a Good Thing(tm))?

      Reply

      • Bulat Shamsutdinov says

        I’m not currently informed. But it was a pretty hot debate due to RakNet been (as well as kNet) in a pretty much limbo-like state with no updates for quite a long time. With reasons that RakNet is much more battle-tested, yet kNet is leaner and so easier to maintain by Urho community itself.

        Reply

        • "No Bugs" Hare says

          > RakNet been (as well as kNet) in a pretty much limbo-like state with no updates for quite a long time

          Right. BTW, IMO the best one would be libyohimbo by a network guru Glenn Fiedler (with a trick or two of crypto suggested by me :-)) – and it is currently in an active state of development.

          Reply

          • Bulat Shamsutdinov says

            That is very interesting! Thank you for noting that one, will take a close look!

          • Bulat Shamsutdinov says

            Quote from the description: “It is designed around the networking requirements of competitive realtime multiplayer games such as first person shooters and action games. As such it provides the absolute fastest, most time critical networking layer over UDP, with a client/server architecture supporting up to 64 players per-dedicated server instance.”

            That “up to 64 players per dedicated server” is a bummer.

            Glenn replied to a question about the limit with:

            “You are free to increase MaxClients above 64. I don’t support it, because you will become more and more I/O bound and this starts moving into MMO territory, but it does work. Increasing above 1024 players also requires changes to const int MaxEncryptionMappings = 1024 and const int MaxContextMappings = 1024, which should really be some (generous) multiple of MaxClients. I’m going to fix this shortly, but right now these constants have to be manually adjusted above 1024 clients.

            To answer your other question, this library is designed for first person shooters and other action games, with [2,64] player counts. For example, Battlefield 1 was just released and it supports a maximum of 64 players. These sort of games.

            cheers Glenn”

            That takes libyohimbo MMO usage into “not supported” territory wich is not a good of a sign(

          • Bulat Shamsutdinov says

            Finally got to this part in a Beta book.

            First of all – great job! It was a fantastic read! Any estimates on vol 2 Beta?

            Second – libuv seems so interesting (competitors might too, didn’t check yet) it is even a pity you discuss it so shortly.

            Third – libyohimbo is very interesting in several regards (out of the box encryption is a big one of them), but Glenn mentions that he has no expertise in MMO realm and so he doesn’t consider its needs while developing libyohimbo.
            That makes me ask a question on your thoughts on libyohimbo in that regard – would you consider using libyohimbo for MMO development in its current state?

  9. Anon says

    “In addition, Unity HLAPI seems to ignore server-to-server communications completely.[[PLEASE CORRECT ME IF I’M WRONG HERE]]”

    Well, i’m not sure if this is relevant and maybe a bit hacky, but I think you can create custom connections with methods like NetworkServer.AddExternalConnection.

    Also, this is not really server to server but maybe it can give someone some ideas :
    – I used a custom httplistener from C# to manage interactions between my master server and a bash console. So c# udp/tcp listeners are probably available to send server/server messages.
    – If your architecture allows it, you can also treat a server as a client of another server. My hosts are using both NetworkServer (to interact with players) and NetworkClient (to interact with the master) at the same time.

    I’m a noob so maybe not the best practices but for now it just works and i’m happy 😀

    Thanks for all these excellent articles. I learned so much.

    Reply

  10. Lluis says

    Hello,

    Thank you very much for this blog, it is awesome.

    I’m creating a MMOG with Unity and I’m now a bit confused as I would like my game to run in a dedicated server where all the clients can connect in a match that is running in that server (if it is full then create another match) and there are no clients acting as a host(handling the game as a server).

    So I’m very confused in terms of networking about Unity vs UE.

    I’m not sure if this is something that is new implemented in Unreal but I just found this link in their documentation that make me thing that they has all the network management more focused to have a dedicated server than Unity who I think has the network management focused on using one client as a server.

    https://docs.unrealengine.com/en-us/Gameplay/Networking/Server
    https://docs.unrealengine.com/en-us/Gameplay/Networking/Overview

    It says that UE is designed as a client-server model and if I’m not wrong the Unity HLAPI is designed as a client-host model.
    So, does it means that the UE is better designed to run as a dedicated server? so all the game happens in the server and the client just have a copy of his own player, simulating the real position that is running on the server.
    In the other hand, Unity is designed to have a client acting as a server? so it is easier to cheat as this client(host) has authority over the other clients and also if the client(host) disconnects the match is over. About the player, the clients here has their own player and send the position to the server to replicate it to the other clients instead of receive their own position from the server.

    Is that right?

    Could you help me clarify my doubts?,
    Reading your post it seems that is pretty much the same what te UE does and what the Unity does, so does that mean that I can continue developing the game with Unity and I will be able to create a dedicated server with full authority from unity?

    Thank you very much.

    Reply

    • "No Bugs" Hare says

      > Thank you very much for this blog, it is awesome.

      Thanks for kind words, it is always nice to know that people appreciate what I am doing :-).

      > Could you help me clarify my doubts?,

      Overall, in spite of different terminology, the difference between networking in UE4 and Unity 5 is not THAT big (actually, it is quite small). While you MAY run Unity as a Server-hosted-on-Client, but if you don’t want to – you MAY run it as a dedicated server too. Sure, it is generally better to deal with people who realize the importance of Authoritative Servers – but in fact, when choosing between UE4 and U5 the difference is small enough (so that usually networking shouldn’t be the reason to choose UE4 vs U5 or vice versa).

      > I can continue developing the game with Unity and I will be able to create a dedicated server with full authority from unity?

      Yes, you can – BUT you should start developing your network code ASAP (I like to name it “continuous conversion” from single-player code into multiplayer one). This conversion is quite an elaborated topic (just one example – there are at least two severely different approaches to this “continuous conversion” of the Client-centered game to become MOG with an Authoritative Server – engine-provided server vs standalone server). While on this blog there ARE some bits and pieces about it, there is a significantly more elaborated description in Vol. II (more specifically, Chapter 7) of my book – and there is also quite an updated analysis of UE-vs-U5-from-network perspective there too. The book is available at https://leanpub.com/b/development-and-deployment-of-multiplayer-online-games-part-arch ; current version of Vol. II is text-complete and is merely awaiting formatting, and you’ll get all the future updates too (if you have problems paying for it – LMK, I will send you a copy of Chapter 7 for free).

      Reply

        • Lluis says

          Hi,

          I would like to ask you one more question.
          Would you recommend then to use Unity with a dedicated server and for example AWS for hosting the server game? Amazon EC2 is ok or should we use Amazon GameLift?
          I’m a little confused here, Can I still have the game with the HLAPI to manage all the rpc and commands and just use the amazon sdk to connect to the server and do the matchmaking, start server, etc…?
          Is the choice to use a dedicated server with AWS a good choice? or It should be ok just using UNET with a server hosted on client?

          Thank you very much.

          Reply

          • "No Bugs" Hare says

            > Would you recommend then to use Unity with a dedicated server and for example AWS for hosting the server game? Amazon EC2 is ok or should we use Amazon GameLift?

            Unity with dedicated server is certainly one of the options. However, keep in mind that using cloud services (AWS or otherwise) is expensive (compared to dedicated stuff, cloud computing power tends to cost 4x more, and cloud traffic – 10+x more!, though for load spikes cloud is still more efficient, which leads to “hybrid” deployments). For a rather detailed discussion of it – see http://ithare.com/preparing-to-deploy-your-game-to-cloud-or-not-to-cloud/ .

            As for EC2-vs-Gamelift – IF your cost calculations show that you’re ok with 100% cloud deployments (and moreover, ok with paying EC2 prices which aren’t bad for cloud – but aren’t too good either, especially for traffic) – you can try GameLift, technically I don’t see much problems with it (except for locking you up to EC2).

            > I’m a little confused here, Can I still have the game with the HLAPI to manage all the rpc and commands and just use the amazon sdk to connect to the server and do the matchmaking, start server, etc…?

            You can, but often you shouldn’t. HLAPI has two big issues. First, depending on your game, it can easily happen that with HLAPI your game will eat too much traffic (one thing to try in this regard is to develop your game with HLAPI first – and measure its traffic-while-you’re-playing in LAN. If it is higher than ~200kbit/second – or higher than you can afford given your monetization expectations, whichever is lower, bye-bye HLAPI). The second problem is that HLAPI doesn’t seem to support encryption out of the box, and adding encryption later on top of HLAPI, while possible, is a Big Headache :-(. This, in turn, means that with unencrypted HLAPI, you are _badly_ exposed to cheaters (using virtually-undetectable proxy bots); whether it is important for your game is your call, but certainly a thing to keep in mind.

            > Is the choice to use a dedicated server with AWS a good choice? or It should be ok just using UNET with a server hosted on client?

            It is a very complicated question, which depends on several factors; here are just a few of them from the top of my head:

            1. how are you going to monetize your game? If it is going to be free forever-and-ever – you won’t have money to pay for dedicated servers, so the choice becomes clear, however if you have some monetization in mind, then keep in mind that dedicated servers tend to allow for simpler/better monetization.

            2. cheating. How bad your game will be hit if everybody starts to cheat? Servers-on-Client are Badly Vulnerable to cheating, while centralized servers give a

            2a. how many players you’re targeting? In smaller communities (like “up to 1000 players”) cheating is usually not THAT much of a problem, but as soon as you’re going into millions – they will CERTAINLY find a reason to cheat even for the most innocently-looking game, which can easily break the whole game ecosystem (nobody wants to play a game where cheating is rampant).

            And so on and so forth. In general, for a serious commercial game I certainly suggest to go with centralized dedicated server (starting with rented servers such as “dedicated servers” by Leaseweb, and adding cloud later if necessary) – this way it is easier to monetize, AND you get a fighting chance against bots; however, if your game is more as a smaller/hobby project – YMMV.

  11. kfng says

    Any thoughts on Amazon’s Lumberyard engine? Seems interesting from what i’m reading on the documentation, but i’m a newb 🙂
    Apparently they have a team working on developing an MMO using the engine so I guess there will be some focus on their part on improving things related to that.

    Reply

    • "No Bugs" Hare says

      It is covered in some detail in upcoming Vol. II of my book, but a very brief summary goes as follows:
      – technically, it is more or less on par with the alternatives; graphics is provided by AAA-class CryEngine, network-wise it is very close to alternatives, sometimes a tiny bit better (in particular, built-in encryption is nice).
      – license-wise, for commercial development it is IMO risky. Last time I checked, it was either (a) you can run it EXCLUSIVELY on the AWS (which is going to be expensive – more on cloud costs in http://ithare.com/preparing-to-deploy-your-game-to-cloud-or-not-to-cloud/ ), or (b) you can run it on your own servers (it SEEMS that colo servers are ok, but rented are probably not, and in any case you’d better ask Amazon for clarification before trying). ALL OTHER DEPLOYMENTS ARE EXPRESSLY PROHIBITED BY LUMBERYARD LICENSE!

      Reply

  12. Dan says

    Hello,

    You mention Unity 5 networking, but unity’s UNET is being deprecated and replaced by a more robust system, I think this could impact this part of the book greatly.

    https://blogs.unity3d.com/2019/06/13/navigating-unitys-multiplayer-netcode-transition/

    Unity is providing a lower level transport package, along with a dots-networking coming before the end of the year (preview). These systems technically speaking put it on par with high-end fast paced Multiplayer systems such as in quake, and source.

    Reply

  13. Karsten Pedersen says

    I am not sure how relevant this is but when dealing with an MMORPG game, these things generally need to work for a long time. Therefore lifespan of a development tool is extremely important. UE4 is not open-source but it is “source access” allowing your company to personally maintain a specific version if you must. Unity as a prosumer product does not provide access to the source (they say that they are open to licensing the source but in our experience this is not entirely true on their behalf). Unity also has extremely amateur backwards and forwards compatibility making it unsuitable for professional work over a number of years.

    Therefore, just as with Adobe Flash, I doubt the lifespan of Unity.

    Don’t get me wrong, Unreal has its flaws. It is far too large for a smaller independent company to personally maintain. However it *is* possible given enough resources (and you stay away from their domain specific scripting languages such as UnrealScript, Kismet 1, 2, 3 (Blueprint). Those are effectively dead on arrival in terms of lifespan.)

    Also should the server not be a different decision to the client? Standalone middleware is important or just standard C/C++. Unity has very weak support for this; it barely supports Linux servers.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Copyright © 2014-2016 ITHare.com