In this article we\u2019re going to take a deep look at the\u00a0available solutions for multiplayer action games, explore different architectures and examine the multiplayer side of engines such as Unity.<\/p>\n
For each method we\u2019ll discuss the pros and cons and finally we\u2019ll propose an integration with SmartFoxServer 2X that we think provides the best of both worlds.<\/p>\n
\u00bb Intro<\/b><\/h2>\n
Depending on the\u00a0type of action game being developed\u00a0different techniques have been devised over the last decades to deal with the multiplayer side:<\/p>\n
- \n
- Peer-to-peer lockstep<\/b>: not very popular these days, it\u2019s a p2p technique used in the original Doom (which at the time was designed for LAN only) and still employed in some RTS games. It requires the game to be fully deterministic and it works by exchanging commands among all peers before the next frame is executed. Among other\u00a0issues this method\u00a0lacks\u00a0efficiency over the internet\u00a0since the game pacing is dictated by the most lagged client.<\/li>\n<\/ul>\n
- \n
- Terminal client: <\/b>this is a client-server approach where the world state is simulated on the server side. Every client acts purely as a terminal, sending their input to the server and receiving world updates that are then rendered. This method was employed in the first Quake and it suffered from substantial input latency as every key press must be sent to the server and processed\u00a0before anything happens on the client.<\/li>\n<\/ul>\n
- \n
- Predictive client: <\/b>also a client-server approach where the client tries to hide the latency by predicting the next player state, before the server update. In other words this system runs a server side simulation (as in Terminal client) and an additional local simulation on the client, to conceal the network\u00a0lag.\u00a0 <\/span>When the server sends new position updates the client side can correct what was predicted earlier and use \u201csmoothing\u201d animations to avoid too much jumpiness.<\/li>\n<\/ul>\n
These days the predictive client technique is by far the most popular and it\u2019s found everywhere from AAA twitchy FPS (Battlefield, PUBG\u2026) to smaller indie titles or mobile games.<\/p>\n
\u00bb All roads lead to an authoritative server<\/b><\/h2>\n
Besides the corner cases such as the lockstep<\/em> approach for some games, the vast majority of action titles require an authoritative server to keep a central state, applying user\u2019s input validation and preventing cheating.<\/p>\n
To implement this solution there are a couple of different approaches:<\/p>\n
- \n
- the classic one is to run multiple dedicated servers<\/strong> in one or more data centers that can deal with large amounts of CCUs, simulating the physics and interactions among thousands of players. This is the method employed by many successful AAA titles but it\u2019s less accessible for smaller studios and independent developers as the costs for maintaining a large infrastructure can be significant.<\/li>\n
- An alternative approach is to ditch the big central servers and instead\u00a0run many small ones via the player\u2019s own devices. This modality is also referred to as client hosted server<\/strong>\u00a0and it is one way in which the likes of Unity, Unreal and other similar engines have tried to solve this issue.<\/li>\n<\/ul>\n
By running the game server on one of the player’s device\u00a0(PC, console or phone) it is possible to\u00a0 host a small group of players over a non dedicated connection and get a decent performance most of the times.<\/p>\n
Whether it’s a large data center or a client hosted server,\u00a0the client-server model is still the best approach for\u00a0a large majority of multiplayer games<\/strong>, offering\u00a0ample flexibility for different\u00a0projects and multiple ways\u00a0of implementation.<\/p>\n
\u00bb Large scale vs small scale<\/h2>\n
We are now going to take a closer look at the two main\u00a0strategies just described and\u00a0analyze their\u00a0strengths and weaknesses.<\/p>\n
Large scale, dedicated hosting<\/h3>\n
![\"\"](\"http:\/\/smartfoxserver.com\/blog\/wp-content\/uploads\/2018\/05\/dedicated-hosting.png\")
<\/p>\nThe dedicated\u00a0hosting approach allows to run multiple servers (game, web, database) in\u00a0the same environment, with minimized latency and high performance.<\/p>\n
It has\u00a0multiple advantages:<\/p>\n
- \n
- runs in an optimized environment with plenty of dedicated resources, bandwidth and options for scaling the service<\/li>\n
- integrates with other services such as storage, databases and security<\/li>\n
- reduces\u00a0downtimes to a minimum<\/li>\n
- can be expanded to higher levels of scalability by\u00a0adding\u00a0new servers (provided the system is bottleneck free, of course)<\/li>\n<\/ul>\n
and also several\u00a0downsides:<\/p>\n
- \n
- infrastructure costs can be\u00a0significant<\/li>\n
- requires admins to maintain the system<\/li>\n
- requires higher expertise to\u00a0implement correctly<\/li>\n<\/ul>\n
Small\u00a0scale,\u00a0client hosted server<\/h3>\n
The client-hosted server model instead (i.e. running the server on one player\u2019s device) looks more convenient:<\/p>\n
![\"\"](\"http:\/\/smartfoxserver.com\/blog\/wp-content\/uploads\/2018\/05\/client-hosted-server2.png\")
<\/p>\n- \n
- relatively easy to implement<\/li>\n
- removes the costs of a large server infrastructure<\/li>\n
- does not require a high level of expertise, especially when using rich engines such as Unity\/Unreal<\/li>\n<\/ul>\n
… but it comes with some significant built-in issues:<\/p>\n
- \n
- relies on client bandwidth which can be slow, inconsistent or laggy<\/li>\n
- depends on\u00a0external services for matchmaking, message relaying and NAT punchthrough<\/li>\n
- doesn\u2019t offer good security and anti-cheating mechanisms<\/li>\n
- the client hosting the server can be at an advantage\u00a0because\u00a0it doesn’t incur in\u00a0network lag<\/li>\n
- there are restrictions on the number of players per game, dictated by the limited resources of the host<\/li>\n
- mobile network stability and performance can hinder the quality of games<\/li>\n
- no HTML5 support\u00a0since WebGL doesn’t allow clients to receive incoming connections<\/li>\n
- requires\u00a0 NAT punchthrough<\/a> to establish a connection to hosts behind a router<\/li>\n
- NAT punchthrough is not\u00a0100% reliable. When it fails an external server is needed, usually referred to as a Relay server<\/a>.\u00a0This acts\u00a0as a middle man to send traffic between clients and at the cost of\u00a0additional latency<\/li>\n
- if storage\/database is needed developers will have to either integrate a third party service or\u00a0setup a custom\u00a0solution<\/li>\n<\/ul>\n
Even if the list of downsides is substantial this technique can provide\u00a0good results as long as the number of players per game is kept to a reasonable value. For instance most devices these days are perfectly able to host 4-8 players while dealing with the 2D\/3D rendering, networking and physics simulation.<\/p>\n
It’s also important to\u00a0underline\u00a0that the client hosted server\u00a0model cannot get rid of dedicated servers entirely<\/strong>. As outlined in the diagram above a central match-making\u00a0service is always required for players\u00a0to search or start new\u00a0games.\u00a0Also the NAT punchthrough and relay services are\u00a0highly recommended to improve the reliability of connections among players.<\/p>\n
All these services are\u00a0usually provided by third parties (such as Unity) for a monthly fee so developers don’t need to worry about the complexity of setting them up.<\/p>\n
\u00bb The best of both worlds<\/h2>\n
Now it’s time to get back to\u00a0the title of this article and\u00a0take a look\u00a0at an hybrid system that\u00a0combines\u00a0both Unity and SmartFoxServer on the server side to get the best of both\u00a0worlds:<\/p>\n
- \n
- what Unity<\/strong> does best is simulating the 2D\/3D world created by developers,\u00a0calculating physics, collisions and synchronizing\u00a0game objects<\/li>\n
- what SmartFoxServer<\/strong> does best is providing User and Room management, server side logic, storage, security, match making, chats, buddy lists, web services and tons more<\/li>\n<\/ul>\n
The core idea of this solution is to run multiple headless (i.e. with no rendering) Unity servers with SFS2X as the orchestrator.<\/p>\n
![\"\"](\"http:\/\/smartfoxserver.com\/blog\/wp-content\/uploads\/2018\/05\/sfs2x-unity-combo.png\")
<\/p>\nEssentially clients connect and login with SFS2X and from there they can join\u00a0one or multiple lobbies, perform the match making and finally join a Unity server to play their favorite game.<\/p>\n
The advantages are\u00a0numerous:<\/p>\n
- \n
- core game logic can be developed\u00a0directly in Unity, taking full advantage of the engine’s features<\/li>\n
- integration\u00a0with SmartFoxServer Extensions gives unlimited backend possibilities (account management, custom profiles, leaderboards etc.)<\/li>\n
- custom Room\/User\/Buddy management via SFS2X API<\/li>\n
- matchmaking, invitations, chats are all managed via\u00a0the SFS2X API and are fully customizable<\/li>\n
- Unity servers can run anywhere: on the same physical machine where SFS2X runs, on a dedicated server, on cloud hosted micro instances<\/li>\n
- integrated web services allow to serve extra content, host the website portion of the game, manage uploadable content etc.<\/li>\n<\/ul>\n
This approach avoids the main pitfalls of client hosted servers<\/strong> (especially the connectivity and performance issues, not to mention the lack of anti-cheating) and\u00a0offers an architecture that is\u00a0simple\u00a0to implement and can be scaled to accomodate thousands of users without major investments from the start.<\/p>\n
\u00bb Who do we recommend this to?<\/h3>\n
The\u00a0hybrid SFS2X\/Unity architecture is suitable for all kinds of projects, in particular if your game is a fast, realtime and physics-based one<\/strong>.<\/p>\n
With the help of a cloud hosting\u00a0this solution can be implemented on a small\u00a0scale\u00a0at\u00a0an affordable price, and can be scaled up\u00a0as popularity and traffic grows.<\/p>\n
For example, a single AWS t2.small instance (which is ~$17\/mo) is enough to\u00a0handle thousands of clients with SFS2X and a second instance can be dedicated to running multiple Unity servers for game Rooms.<\/p>\n
\u00bb Who do we NOT recommend this to?<\/h3>\n
If you have little expertise with the basics of server management and\u00a0don’t want to deal with extra\u00a0services yourself (matchmaking, database, web services etc.) then this solution is probably not for you.<\/p>\n
In this case we’d recommend sticking with the client hosted server model and acquiring the extra services from third party providers.<\/p>\n
If you’re still on the fence about which way to choose we’d recommend to investigate the monthly fees of the third party services you plan to acquire and see how they compare with a cloud based hosting. If you have a minimum of experience in setting up your own servers (which in the cloud is\u00a0pretty simple) it can pay off in terms of extra flexibility and reduction of\u00a0third party costs.<\/p>\n
\u00bb Conclusions and next steps<\/h2>\n
In this introduction we have taken a top-down look at\u00a0different\u00a0strategies\u00a0to\u00a0implement\u00a0multiplayer action games,\u00a0highlighting their pros and cons. In the next installment of this series we are going to work on actual implementation of the SFS2X\/Unity server model and see in details how it works.<\/p>\n","protected":false},"excerpt":{"rendered":"
Realtime multiplayer games have been around for over four decades, even though their popularity is a\u00a0much more recent phenomenon, and they remain one of the trickiest type\u00a0of games\u00a0 to develop. Delivering a smooth and responsive action for the players while hiding the latency and limitations of the network\u00a0is still a major source of coding pain. […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[23],"tags":[98,97,96,7,42],"_links":{"self":[{"href":"https:\/\/smartfoxserver.com\/blog\/wp-json\/wp\/v2\/posts\/901"}],"collection":[{"href":"https:\/\/smartfoxserver.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/smartfoxserver.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/smartfoxserver.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/smartfoxserver.com\/blog\/wp-json\/wp\/v2\/comments?post=901"}],"version-history":[{"count":18,"href":"https:\/\/smartfoxserver.com\/blog\/wp-json\/wp\/v2\/posts\/901\/revisions"}],"predecessor-version":[{"id":923,"href":"https:\/\/smartfoxserver.com\/blog\/wp-json\/wp\/v2\/posts\/901\/revisions\/923"}],"wp:attachment":[{"href":"https:\/\/smartfoxserver.com\/blog\/wp-json\/wp\/v2\/media?parent=901"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/smartfoxserver.com\/blog\/wp-json\/wp\/v2\/categories?post=901"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/smartfoxserver.com\/blog\/wp-json\/wp\/v2\/tags?post=901"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- what SmartFoxServer<\/strong> does best is providing User and Room management, server side logic, storage, security, match making, chats, buddy lists, web services and tons more<\/li>\n<\/ul>\n
- NAT punchthrough is not\u00a0100% reliable. When it fails an external server is needed, usually referred to as a Relay server<\/a>.\u00a0This acts\u00a0as a middle man to send traffic between clients and at the cost of\u00a0additional latency<\/li>\n
- An alternative approach is to ditch the big central servers and instead\u00a0run many small ones via the player\u2019s own devices. This modality is also referred to as client hosted server<\/strong>\u00a0and it is one way in which the likes of Unity, Unreal and other similar engines have tried to solve this issue.<\/li>\n<\/ul>\n
- the classic one is to run multiple dedicated servers<\/strong> in one or more data centers that can deal with large amounts of CCUs, simulating the physics and interactions among thousands of players. This is the method employed by many successful AAA titles but it\u2019s less accessible for smaller studios and independent developers as the costs for maintaining a large infrastructure can be significant.<\/li>\n
- Predictive client: <\/b>also a client-server approach where the client tries to hide the latency by predicting the next player state, before the server update. In other words this system runs a server side simulation (as in Terminal client) and an additional local simulation on the client, to conceal the network\u00a0lag.\u00a0 <\/span>When the server sends new position updates the client side can correct what was predicted earlier and use \u201csmoothing\u201d animations to avoid too much jumpiness.<\/li>\n<\/ul>\n
- Terminal client: <\/b>this is a client-server approach where the world state is simulated on the server side. Every client acts purely as a terminal, sending their input to the server and receiving world updates that are then rendered. This method was employed in the first Quake and it suffered from substantial input latency as every key press must be sent to the server and processed\u00a0before anything happens on the client.<\/li>\n<\/ul>\n