Unity 5 vs UE4 vs Photon vs DIY for MMO

 
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 VIII 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 IX, “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.

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). “

    • "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).

  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.

    • "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!

    • "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 :-(.

    • "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.

      • 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/

  3. 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.

    • "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 :-).

Leave a Reply

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