Job Title: Sarcastic Architect
Hobbies: Thinking Aloud, Arguing with Managers, Annoying HRs,
Calling a Spade a Spade, Keeping Tongue in Cheek
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
No4 5
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 Goodies
6
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
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”]]
Acknowledgement
Cartoons by Sergey GordeevIRL from Gordeev Animation Graphics, Prague.