Best of both worlds: SFS2X + server side Unity for realtime games (p1)

Realtime multiplayer games have been around for over four decades, even though their popularity is a much more recent phenomenon, and they remain one of the trickiest type of games  to develop. Delivering a smooth and responsive action for the players while hiding the latency and limitations of the network is still a major source of coding pain.

Also many games heavily rely on physics to add extra realism and interesting mechanics which in turn adds more complexity to make sure that all players are accurately in synch with each other.

With the emergence of powerful 3D engines such as Unreal and Unity these complex features have been integrated with the visual and rendering systems, hiding the intricacies of physics simulations and networking, and making it more accessible to all developers.

In this article we’re going to take a deep look at the available solutions for multiplayer action games, explore different architectures and examine the multiplayer side of engines such as Unity.

For each method we’ll discuss the pros and cons and finally we’ll propose an integration with SmartFoxServer 2X that we think provides the best of both worlds.

» Intro

Depending on the type of action game being developed different techniques have been devised over the last decades to deal with the multiplayer side:

  • Peer-to-peer lockstep: not very popular these days, it’s 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 issues this method lacks efficiency over the internet since the game pacing is dictated by the most lagged client.
  • Terminal client: 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 before anything happens on the client.
  • Predictive client: 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 lag.  When the server sends new position updates the client side can correct what was predicted earlier and use “smoothing” animations to avoid too much jumpiness.

These days the predictive client technique is by far the most popular and it’s found everywhere from AAA twitchy FPS (Battlefield, PUBG…) to smaller indie titles or mobile games.

» All roads lead to an authoritative server

Besides the corner cases such as the lockstep approach for some games, the vast majority of action titles require an authoritative server to keep a central state, applying user’s input validation and preventing cheating.

To implement this solution there are a couple of different approaches:

  • the classic one is to run multiple dedicated servers 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’s less accessible for smaller studios and independent developers as the costs for maintaining a large infrastructure can be significant.
  • An alternative approach is to ditch the big central servers and instead run many small ones via the player’s own devices. This modality is also referred to as client hosted server and it is one way in which the likes of Unity, Unreal and other similar engines have tried to solve this issue.

By running the game server on one of the player’s device (PC, console or phone) it is possible to  host a small group of players over a non dedicated connection and get a decent performance most of the times.

Whether it’s a large data center or a client hosted server, the client-server model is still the best approach for a large majority of multiplayer games, offering ample flexibility for different projects and multiple ways of implementation.

» Large scale vs small scale

We are now going to take a closer look at the two main strategies just described and analyze their strengths and weaknesses.

Large scale, dedicated hosting

The dedicated hosting approach allows to run multiple servers (game, web, database) in the same environment, with minimized latency and high performance.

It has multiple advantages:

  • runs in an optimized environment with plenty of dedicated resources, bandwidth and options for scaling the service
  • integrates with other services such as storage, databases and security
  • reduces downtimes to a minimum
  • can be expanded to higher levels of scalability by adding new servers (provided the system is bottleneck free, of course)

and also several downsides:

  • infrastructure costs can be significant
  • requires admins to maintain the system
  • requires higher expertise to implement correctly

Small scale, client hosted server

The client-hosted server model instead (i.e. running the server on one player’s device) looks more convenient:

  • relatively easy to implement
  • removes the costs of a large server infrastructure
  • does not require a high level of expertise, especially when using rich engines such as Unity/Unreal

… but it comes with some significant built-in issues:

  • relies on client bandwidth which can be slow, inconsistent or laggy
  • depends on external services for matchmaking, message relaying and NAT punchthrough
  • doesn’t offer good security and anti-cheating mechanisms
  • the client hosting the server can be at an advantage because it doesn’t incur in network lag
  • there are restrictions on the number of players per game, dictated by the limited resources of the host
  • mobile network stability and performance can hinder the quality of games
  • no HTML5 support since WebGL doesn’t allow clients to receive incoming connections
  • requires  NAT punchthrough to establish a connection to hosts behind a router
  • NAT punchthrough is not 100% reliable. When it fails an external server is needed, usually referred to as a Relay server. This acts as a middle man to send traffic between clients and at the cost of additional latency
  • if storage/database is needed developers will have to either integrate a third party service or setup a custom solution

Even if the list of downsides is substantial this technique can provide good 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.

It’s also important to underline that the client hosted server model cannot get rid of dedicated servers entirely. As outlined in the diagram above a central match-making service is always required for players to search or start new games. Also the NAT punchthrough and relay services are highly recommended to improve the reliability of connections among players.

All these services are usually 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.

» The best of both worlds

Now it’s time to get back to the title of this article and take a look at an hybrid system that combines both Unity and SmartFoxServer on the server side to get the best of both worlds:

  • what Unity does best is simulating the 2D/3D world created by developers, calculating physics, collisions and synchronizing game objects
  • what SmartFoxServer does best is providing User and Room management, server side logic, storage, security, match making, chats, buddy lists, web services and tons more

The core idea of this solution is to run multiple headless (i.e. with no rendering) Unity servers with SFS2X as the orchestrator.

Essentially clients connect and login with SFS2X and from there they can join one or multiple lobbies, perform the match making and finally join a Unity server to play their favorite game.

The advantages are numerous:

  • core game logic can be developed directly in Unity, taking full advantage of the engine’s features
  • integration with SmartFoxServer Extensions gives unlimited backend possibilities (account management, custom profiles, leaderboards etc.)
  • custom Room/User/Buddy management via SFS2X API
  • matchmaking, invitations, chats are all managed via the SFS2X API and are fully customizable
  • Unity servers can run anywhere: on the same physical machine where SFS2X runs, on a dedicated server, on cloud hosted micro instances
  • integrated web services allow to serve extra content, host the website portion of the game, manage uploadable content etc.

This approach avoids the main pitfalls of client hosted servers (especially the connectivity and performance issues, not to mention the lack of anti-cheating) and offers an architecture that is simple to implement and can be scaled to accomodate thousands of users without major investments from the start.

» Who do we recommend this to?

The hybrid SFS2X/Unity architecture is suitable for all kinds of projects, in particular if your game is a fast, realtime and physics-based one.

With the help of a cloud hosting this solution can be implemented on a small scale at an affordable price, and can be scaled up as popularity and traffic grows.

For example, a single AWS t2.small instance (which is ~$17/mo) is enough to handle thousands of clients with SFS2X and a second instance can be dedicated to running multiple Unity servers for game Rooms.

» Who do we NOT recommend this to?

If you have little expertise with the basics of server management and don’t want to deal with extra services yourself (matchmaking, database, web services etc.) then this solution is probably not for you.

In this case we’d recommend sticking with the client hosted server model and acquiring the extra services from third party providers.

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 pretty simple) it can pay off in terms of extra flexibility and reduction of third party costs.

» Conclusions and next steps

In this introduction we have taken a top-down look at different strategies to implement multiplayer action games, highlighting 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.