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

Summary

The discussion above (with some subtle details added too) is summarized in the table below.

In this table, the rightmost column represents what I would like to see from my own DIY game network engine. In this case, while the network engine itself is DIY, there is a big advantage of pushing all these things into the network engine and to separate them from the game logic. The more things are separated via well-defined interfaces, the less cluttered your game logic code becomes, and the more time you have for really important things such as gameplay; in the extreme case, this difference can even mean the difference between life and death of your project. Also keep in mind that if going a DIY route, for any given game you won’t need to implement all the stuff in the table; think what is important for your game, and concentrate only on those features which you really need. For example, UDP support and dead reckoning are not likely to be important for a non-simulation game, and HTTP polling isn’t likely to work for an MMOFPS.

[[PLEASE CORRECT ME IF SOMETHING LOOKS WRONG HERE!]]

Features (those IMO most important ones are in bold) Unity 5 (HLAPI) Unity 5 (LLAPI) Unreal Engine 4 Photon Server SDK Photon Cloud / PUN My ideal DIY network engine (along the lines of this book)
 Platforms
Desktop Win / MacOS / SteamOS Win / MacOS / SteamOS Win / MacOS Whatever tickles your fancy
Consoles PS / Xbox / Wii PS / XBox PS / Xbox / Wii Whatever floats your boat
Mobile IOS / Android / WinPhone iOS / Android iOS / Android / WinPhone Whatever butters your biscuit
HTML 5 Yes / Websockets Experimental Yes / Websockets Yes
Server Windows / Linux Windows / Linux Windows Only Windows / Linux
 Languages
C/C++ Sort Of1 Yes2 Client Only3 Yes
Garbage-Collected C#/CLI No45 C#/CLI C#/Any, Java/Any, etc.
Scripting JS/CLI, Boo/CLI “Blueprints” Client Only JS/Any (incl JS/V8 and Node.js), Python/Any, etc.
Unity 5 (HLAPI) Unity 5 (LLAPI) Unreal Engine 4 Photon Server SDK Photon Cloud / PUN My ideal DIY
 Programming
Event-driven Yes Yes Yes Yes Yes Yes
Deterministic Goodies6 No No No No No Yes7
void non-blocking RPCs Yes No Yes No Yes Yes
non-void non-blocking RPCs No No No No No Yes
Futures for RPCs No No No No No Yes8
Co-routines Yes Yes No Yes Yes Yes9
Clear Client-Server Separation No (favors Client-Driven Development Flow) No (favors Client-Driven Development Flow) No (favors Client-Driven Development Flow) Yes (favors Server-Driven Development Flow) No (favors Client-Driven Development Flow) Whatever you prefer
 Graphics 10
3D Yes Yes External: Unity, Unreal Engine External11
2D Yes Yes External: Cocos2X External12
Model-View-Controller DIY DIY DIY No Yes
2D+3D Views on the same game No No DIY No Yes
Unity 5 (HLAPI) Unity 5 (LLAPI) Unreal Engine 4 Photon Server SDK Photon Cloud / PUN My ideal DIY
 Networking – General
Support for Authoritative Server Yes Yes Yes Yes No13 Yes
 Networking – Marshalling/IDL
IDL In-Language No In-Language No In-Language14 External
State Synchronization Yes DIY Yes DIY DIY Yes
Clear Server-State – Publishable State – Client State separation No15 N/A No15 N/A No15 Yes
Cross-language IDL No N/A No No N/A Yes
IDL Encodings No N/A No No N/A Yes
IDL Mappings No N/A No No N/A Yes
Interest Management Yes DIY Yes DIY DIY Yes
Client-Side Interpolation DIY DIY DIY DIY DIY DIY
Client-Side Extrapolation DIY DIY DIY DIY DIY DIY
Client-Side Prediction DIY DIY DIY DIY DIY DIY
Delta Compression (whole fields) Automatic DIY Automatic DIY DIY Controlled
Delta Compression (field increments) No DIY No DIY DIY Yes
Variable Ranges, Rounding-when-Transferring, and Bit-Oriented Encodings No DIY No DIY DIY Yes
Dead Reckoning No DIY No DIY DIY Yes
Revision-Based Large Objects Sync [[TODO! Add to Chapter VII]] No DIY No DIY DIY Yes
VLQ No DIY No DIY DIY Yes
Huffman coding No DIY No DIY DIY Yes
IDL Backward Compatibility Support No N/A No No N/A Yes
Unity 5 (HLAPI) Unity 5 (LLAPI) Unreal Engine 4 Photon Server SDK Photon Cloud / PUN My ideal DIY
 Networking – Addressing/Authentication
Addressing Model “Client” / ”Server”16 IP:Port17 “Client” / ”Server”16 IP:Port17 “Client” / ”Server”16 By server name for servers, player ID / “connected client” for players
Player Authentication DIY DIY DIY DIY DIY Yes
Server-to-Server Communications No DIY No Yes No Yes
 Networking – Supported Protocols
UDP Yes Yes Yes Yes Yes Yes
TCP No18 No18 Low-level Only19 Yes Yes Yes
WebSockets Yes (only for WebGL apps?) ? Yes Yes Yes
HTTP No No No Yes Yes Yes
 Scalability/Deployment Features
Load Balancing No No No Inter-World Only [[TODO!: describe inter-world / intra-world balancing in Chapter VI]] Inter-World Only [[TODO!: describe inter-world / intra-world balancing in Chapter VI]] Both Inter-world and Intra-world
Front-End Servers No No No No No Optional
1 Unmanaged code is possible, but cumbersome
2 actually, UE4 is using a somewhat-garbage-collected dialect of C++
3 on server side unmanaged C++ may work
4 Mono tried to add support for C#, but this effort looks abandoned
5 as noted above, UE4 has their own garbage collection for C++
6 replay testing, production post-mortem, server failure handling
7 to enable deterministic goodies while using either futures or co-routines, a source pre-processor will be necessary
8 to use futures with deterministic goodies enabled, a source pre-processor will be necessary
9 to use co-routines with deterministic goodies enabled, or for a language which doesn’t support them explicitly, a source pre-processor will be necessary
10 yes, graphics comparison is intentionally VERY sketchy here
11 in particular, can use Unity or Unreal Engine for rendering
12 in particular, can use Cocos2X or a homegrown 2D library for rendering
13 Photon Plugins MAY allow for a way out, but this needs separate analysis
14 Last time I’ve checked, Photon has had only RPC part as declarative IDL; Publishable State was via manual serialization
15 it is possible to separate them, but it requires efforts
16 i.e. there is no way to address anything except for “Client” on Server, and “Server” on Client; this addressing model is too restrictive, and effectively excludes server-to-server communication
17 quite cumbersome in practice
18 support reportedly planned
19 while there are classes like FTcpSocketBuilder, they are more like Unity’s LLAPI, without an easy way to integrate into UPROPERTY etc.

 

Engine-Centric Development Flow

Ok, so we’ve got that nice table with lots of different things to compare. Still, the Big Question of “What should I use for my game?” remains unanswered. And to answer it, we’ll need to speak a bit about different development flows (which are not to be confused with data flows(!)).

In general, for a pretty much any game being developed, there are two possible development scenarios which heavily depend on the nature of your MMO game.

Server-Driven Development Flow

Dreaming hare:“The first development scenario occurs when the logic of your MMOG does not require access to game assets.The first development scenario occurs when the logic of your MMOG does not require access to game assets. In other words, it happens when the gameplay is defined by some internal rules, and not by object geometry or levels. Examples of such games include stock exchanges, social games, casino-like games, some of simpler simulators (maybe snooker simulator), and so on.

What is important for us in this case, is that you can easily write your game logic (for your authoritative server) without any 3D models, and without any involvement of graphics artist folks. It means that for such development server-side has no dependencies whatsoever, and that server-side becomes a main driver of the things, plain and simple. And all the graphical stuff acts as a mere rendering of the server world, without any ability to affect it.20

In this kind of Server-Driven development workflow game designers are working on server logic, and can express their ideas without referring to essentially-3D or essentially-graphical things such as game levels, character geometry, or similar.

If your game allows it, Server-Driven development is a Good Thing(tm). It is generally simpler and more straightforward than a Client-Driven one. Developing, say, a social game the other way around is usually a Pretty Bad Idea. However, not all the MMOGs are suitable for such Server-Driven development, and quite a few require a different development workflow.

20 as discussed above in Chapter VII, from data flow point of view it will happen anyway when the game is running, but from game designer point of view it might be different, see “Client-Driven Development” section below

 

Server-Driven Development Flow: Personal Suggestions

Hare pointing out:“From what I've seen and heard, if you're using a 3rd-party game engine, and your game is suitable for Server-Driven Development Flow, starting with Unity 5 HLAPI is probably your best bet.From what I’ve seen and heard, if you’re using one of the engines above (and not your own one), and your game is suitable for Server-Driven Development Flow, starting with Unity 5 HLAPI (and rewriting necessary portions into LLAPI when/if it becomes necessary) is probably your best bet. UE4, as it is even more simulation-world-oriented, is less likely to be suitable for the games which fit Server-Driven Development Flow, but if it is – you can do it with UE4 too.

Photon Server SDK might work for Server-Driven development flow too, though you IMO should stay away from Photon Cloud and PUN at least until you realize how Photon Plugins will help to deal with cheaters, and figure out Photon Cloud Enterprise pricing (as noted above, Enterprise plan is necessary to run Photon Plugins).

And of course, a DIY engine can really shine for such development scenarios (using some game engine or 2D/3D engine for client-side rendering purposes).

Client-Driven Development Flow

For those games where your game designers are not only laying out the game rules, but are also involved in developing graphical things such as game levels, Server-Driven development flow described above, tends to fall apart fairly quickly. The problem here lies with the fact that game designers shouldn’t (and usually couldn’t) think in terms of servers and clients. When thinking in terms of “whenever character comes to city X and doesn’t have level 19, he is struck into his face”, there is no way to map this kind of the world picture into servers and clients. In such cases, from Game Designer perspective there is usually a single Game World which “lives” its own life, and introducing separation between client and server into the picture will make their job so much more difficult that their performance will be affected badly, quite often beyond any repair 🙁 .

Surprised hare:“Games which almost universally won't work well with Server-Driven development flow and will require a Client-Driven approach described below, are MMORPGs and MMOFPS.Games which almost universally won’t work well with Server-Driven development flow and will require a Client-Driven approach described below, are MMORPGs and MMOFPS.

For such games, the following approach is used pretty often (with varying degrees of success):

  • develop a game using existing game engine “as if” it is a single-player game.
    • There is only one Game World, and both game designers and 3D artists who can work within a familiar environment, are able to test things right away, and so on
    • at this stage there is no need to deal with network at all: there is no [SyncVars], no RPCs, nothing
  • at certain point (when the engine as such is more or less stable), start a project to separate server from the client. This may include one or more of the following:
    • dropping all the textures from the server side
    • using much less detailed meshes for the server side; in the extreme cases, your PCs/NPCs can become prisms or even rectangular boxes/parallelepipeds.
    • taking existing Game World State as a Client-State, figuring out how it can be reduced to get Server-State
    • working on further reducing Server-State for transfer purposes, obtaining Published-State
      • this process is likely to involve certain visually observable trade-offs and degradations, and is going to take a while
    • at the same time, work of game designers on high-level scripts etc., and of 3D artists on further improvements, may continue

[[TODO! – vigilance]]

While this Client-Driven development process is not a picnic, it is IMHO the best you can do for such games given the tools currently available. Most importantly, it allows game designers to avoid thinking too much about complexities related to state synchronization; while certain network-related issues such as “what should happen with a player when she got disconnected” will still appear in the game designer space, it is still much better than making them think about clients and servers all the time.

Client-Driven Development Flow: Personal Suggestions

Hare thumb up:“If you're using one of the engines above (and not your own one), and your game requires Client-Driven Development Flow, you may want to start with a single-player Unity 5, or with a single-player UE4.If you’re using one of the engines above (and not your own one), and your game requires Client-Driven Development Flow, you may want to start with a single-player Unity 5, or with a single-player UE4. Then (as a part of “client-server separation project” described above), you will be able to proceed either to Unity 5 HLAPI, or to UE4 Replication/RPCs. And as a further step, as discussed above, you may need to rewrite state sync into LLAPI or on top of plain sockets respectively.

While Photon Server SDK might work for Client-Driven Development too, I expect it to be too cumbersome here. As for Photon Cloud and PUN – just as with Server-Driven Development workflow, you IMO still should keep away from them at least until you realize how Photon Plugins will help to deal with cheaters, and figure out Photon Cloud Enterprise pricing.

As for DIY network engine, you can certainly use it for “client-server separation” too (and that’s what I would personally suggest if you have reasonably good network developers).

Important Clarification: Development Flow vs Data Flow

One important thing to note that regardless of game development flow being Server-Driven or Client-Driven, from the technical point of view the completed game will always be server-driven: as our server needs to be authoritative, all decisions are always made by the server and are propagated to the clients, which merely render things as prescribed by the server (see more discussion on data flows in Chapter VII). What we’re speaking about here, is only Development Flow (and yes, having development flow different from program data flow is a major source of confusion among multi-player game developers).

[[To Be Continued…

Tired hare:This concludes beta Chapter 7 from the upcoming book “Development and Deployment of Massively Multiplayer Games (from social games to MMOFPS, with social games in between)”. Stay tuned for beta Chapter 11, “Pre-Development Checklist: Things everybody hates but everybody needs too”]]

Don't like this post? Comment↯ below. You do?! Please share: ...on LinkedIn...on Reddit...on Twitter...on Facebook

Acknowledgement

Cartoons by Sergey GordeevIRL from Gordeev Animation Graphics, Prague.

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