Four Tips for Solving Technical Challenges When Running a Real-Time Multiplayer Game

Real-time multiplayer games have made some vast technological advances in recent years. PC and console titles like Overwatch and Total War have had millions hooked, and now even mobile has come into its own in the past few years. As devices have become more powerful, enabling more immersive gameplay, players demand quality experiences, as standard.



Over 7million people played Blizzards Overwatch within its first week on sale


However, with great technical advances come greater complications. Getting a real-time multiplayer game up and running successfully can present added complexity to developers.


In between working out how to set up matches between hundreds of players in a fraction of a second, developers still have to overcome the challenges of running a real-time multiplayer service. Making sure that your game is stable, runs lag-free and keeps players’ competitive side satisfied is not an easy task, regardless of your team’s size.


How can developers stay ahead of these potentially significant problems? We’ve come up with four tips for game developers looking to create real-time multiplayer games on how to overcome these issues (and more).


1) Design to solve problems


Every real-time multiplayer game will face challenges. Creating an effective matchmaking system that satisfies players, fighting back against the spectre of lag and preparing for dropped connections will challenge every real-time multiplayer game developer, regardless of their chosen platform.


However, each genre of game has characteristic problems which can be anticipated.


For example, if a developer is creating an MMO, it’s obvious that the maintenance of a stable connection to the game’s server is essential, even if the player is physically on the move. But if a developer is creating a MOBA that is intended for highly competitive play, it’s not unreasonable for the developer to expect dedicated players to maintain a stable Wi-Fi connection – allowing resources to be devoted elsewhere.


In practice, this means that developers creating real-time multiplayer games should be looking at game design as the first opportunity to anticipate, and solve, problems that might occur in a game.


An excellent example of this is Clash Royale’s deployment system. By allowing players to play a card, and then handing responsibility for movement to the game’s AI, the game mitigates for problems commonly seen on mobile devices, such as a brief drop in connection, keeping the player in the game.



King’s Clash Royale Gameplay


So before you start turning to the general challenges of running a real-time multiplayer game, first think about the problems your specific game’s genre might have. This will help you to prioritise your time and efforts into areas where you will see the biggest benefits.


2) Create an effective matchmaking system


A multiplayer game is only as good as the people you play against, meaning that it is essential to create a matchmaking system that is capable of delivering the gaming goods.


At a basic level, understanding how an effective matchmaking system works is relatively straightforward. A player should, if things go smoothly, make a request to join a multiplayer match, be placed in a holding pattern until appropriate opponents are found and then enter a game.


However, executing that effectively when running a service-based multiplayer game can be challenging. What happens if it’s a quieter time of day and a beginner wants to find a match against similarly levelled players? Do you want to allow a game to start if you’ve not managed to reach the number of players you’d consider ideal? And if a session is short of players, how much are you willing to compromise the ideal experience of a competitive multiplayer game by allowing lower, or higher level, players into a match?


To answer these questions effectively, you need to think carefully about what criteria you consider essential for a multiplayer match and which you are willing to compromise. There will be different approaches for different games, but in general, the main criteria for every game will be:


  • What are the minimum and the maximum number of players your game needs to run effectively? For head-to-head games, such as a digital version of chess, the answer will be 2 to both. But for a team-based battle that goes up to 16 players, the minimum figure might be 8 or above.
  • How much difference will you accept in skill between players? In the GameSparks multiplayer suite, we offer options for absolute matching (player skill levels fit within specified minimum and maximum values), relative matching (player skill levels fit within a range of values relative to each other) and percentage matching (player skill levels are within a percentage range of one another). But it’s important to decide how close your matching needs to be and, importantly, whether you would be willing to compromise after a period of time (e.g. after 15 seconds of trying to find an absolute match, the system switches to relative matching) to record a result.
  • How long will you wait for a match connection to be made? Players who are looking for a match might be willing to wait for a minute or so to find a rival. You need to consider when will you bring up a message that the attempt to find a match has failed, allowing them to retry.
  • What custom criteria do you wish to allow matches by? When running a matchmaking system, you can add additional information to participant data to influence the matchmaking system. For example, your game could have the option to host games. If that’s the case, you would need to make sure that you add data to players who host to enable guests to find and join their games.
  • Do you allow players to join once a match has already begun? In games like Team Fortress 2 players are constantly leaving and joining casual games mid-round. You can leverage a Drop-In/Drop-Out system to allow this behaviour, but you need to consider how this affects player experience and behaviour. For example, do you still award XP to players who drop out of a match mid-round?


Once you’ve determined your criteria, it’s then time to set up your matchmaking system. If you’re using GameSparks matchmaking tools, you can read the full advice on how to use them here. But the main steps you’ll have to take, regardless of the approach will be:


  • Ensuring that you have a system in place that records essential matching criteria from the player (such as skill level) against your in-house checklist (such as the acceptable range of skill levels for matching players).
  • Allow players to request that a MatchMaking session is started. Once that’s done, they will be placed in a holding pattern with one or more other players who meets the criteria until either a) enough players are found to start a game or b) the request times out.
  • Make sure that multiple holding patterns exist to allow a range of players to find games. For example, if Player A, B and C are low-rank, mid-rank and high-rank, respectively, then it is advantageous if they can match to players in holding patterns corresponding to those difficulty levels.
  • Once a match is found, and a game begins, make sure that you abandon the holding pattern to allow the game to run and potentially prevent other players from joining. You’ll then also have to consider running a Drop-In/Drop-Out system that will automatically boot players whose connection drops for more than a certain period of time and allow them to be replaced with bots or other players.


Building a matchmaking system that fits your game is essential for making sure that players find fair and worthy opponents. But matchmaking can also play a role in combating another problem for real-time multiplayer games – lag.


3) Combat lag


Lag can be simply described as the perceived gap in time between a player’s input, and the game’s response. There are many causes of in-game lag; distance between players and server, breaks in connection, etc. In an ideal world, players would be equidistant to the same server and will see their in-game data (such as the registering of a shot in an FPS game) register simultaneously on each device.


However, that ideal situation isn’t always possible. A player logging into a server late at night in Europe might end up being matched against a player in the US. And if they end up connected to a server in the US, there’s a chance that they will suffer high latency – seeing lag as a result.


This can be a source of particular frustration to players. Returning to an example of an FPS, imagine that you’re playing a session and spot a chance to hit an enemy player. You watch them crouching into cover, spot that they’re going to pop up out of cover at the end of your rifle and prepare to fire.


In a situation without lag, the servers should recognise in a fraction of a second that the opponent moves from cover, that you register a shot, that it hits their hit box and records damage. But if you’re suffering from high latency, it’s possible that the player you thought was moving out of cover has already passed the wall – meaning your shot is wasted and they are in a much better position to attack you.


For any game developer creating a real-time multiplayer game, minimising lag is an essential pre-condition for running a successful game. And there are many ways that this can be done.


The first is ensuring that players connect to a server that is as close to being an equal distance between the players in game. To do this, you’ll need to calculate the coordinates where the majority of your players are located, create a vector between them all, use that to calculate a mid-point and then find a server as near to that as possible.


It’s important to do this calculation using a system that accounts for the spherical shape and continuous nature of the Earth’s surface.


For example, taking the average longitude of players at 1 degree and 359 degrees East would result in an average of 180 degrees East, which is actually about as far away from both players as it is possible to get.


3D vector maths can account for these problems easily, and avoid finding an “average” location that is equidistant, but far away from all players. Locating a server at the North pole would not usually be a sensible choice, considering the low quality of data signal on the polar ice caps.


There is a second way to reduce the distance between players and servers if you’re being vexed by vectors. Using the GameSparks matchmaking system, it’s possible to ensure players are efficiently grouped closer together.


To do this, you’ll need to find out where your players are based (usually during sign up) and then add this either to your matchmaking algorithm, or the user matchmaking options. Doing so will undoubtedly make it simpler to bring latency down, but remember that it will decrease the number of potential matches that can be made and potentially bring matchmaking time up.


Finally, as mentioned at the start, it’s also worth considering if you can reduce the amount of data sent to and from the servers within the game. You can have players in the same room as the servers, but without efficient communication between clients, it won’t matter – lag will be obvious.


If we return again to the example of the FPS, the more players that are connected to any game, the more data points the server has to handle. So while it’s possible to have a 16 vs. 16 FPS game running without lag, a game with an 8 vs. 8 player cap will typically have a greater chance of avoiding latency problems than its rivals.


Just working out how to reduce lag isn’t enough though. Developers need to think about how they handle connection issues when they occur. Even the best systems suffer from downtime and error. For example, if you have a player whose Internet connection drops out for a few seconds, what do you do? Pausing the game for all involved would end up resulting in a horrible experience. But there are some options to hide lag:


  • AI takeover – in many cases, such as a player on the move, tunnels in the real world tend to interfere with a constant connection. The GameSparks platform enables developers to let AI temporarily takeover while the players connection is down. The trick here is to make it seem as natural for everyone. For example, if the player was about to be shot, the game shouldn’t suddenly move them out of the way, in an unnatural way. It also probably shouldn’t go rogue and kill other people on your team.
  • Player tag team – this is really linked to the AI takeover, but if you are in a big battle and someone on your team needs to drop out, having the option to let other members of the team take over that player, with AI controlling their player, can help to hide lag, while also being honest that it is happening.
  • Lower game requirements – this can be an option if the device detects that the Internet connection is not especially strong or stable. By reducing some of the graphic requirements, or limiting players to certain games that are able to cope with varying connectivity conditions, it is possible to still deliver a good experience.


4) Test extensively


Lastly, and perhaps most importantly, it’s essential to make sure that you test extensively to avoid as many problems as you can, ahead of the release of your game or new features.


Replicating the day-to-day problems of running a real-time multiplayer game can, of course, be difficult. Once a game has launched and has had to deal with the stresses of a 24-hour service, you will have much more data about when or where you’re having problems matching opponents, or delivering (or, indeed, not delivering) a consistent connection.


However, adapting when the game is already on the road will be of little comfort to early adopters. Although players increasingly accept that patches, server downtime and maintenance windows are necessary for running an online gaming service, it’s poor form and potentially damaging to long-term retention to hang early adopters out to dry.


There will, therefore, be three things that you will want to do to make sure that your game is as extensively tested as possible before launch:


  • The first is to ensure that every system works as it should do. While this is, of course, standard game development practice, testing what happens if eight different devices from across the continent (with different player profiles) try to match make for a four player game isn’t as easy as testing a single player social game. It’s, therefore, important to use software such as the GameSparks Test Harness to make sure everything is plumbed in together.
  • The second is to attempt to replicate as many practical scenarios that will push your service to the max as possible. As well as testing what happens to individual devices in a variety of contexts – such as a long distance between it and a server, what happens when a data connection drops or shifts from Wi-Fi to mobile data – it’s also important to anticipate what the breaking point will be for your servers. After all, if your game is becoming a breakout or slow burning hit and your servers couldn’t deal with it, that could prove to be a missed opportunity.
  • Third and finally, make sure that you test what happens in real conditions by heading out for a soft launch or beta. By using back-end analytics tools, crash reporting and even app review analysis to see how your app performs in the market, you can identify problems and fix them before you take the final plunge into the market.




Running a successful real-time multiplayer game involves providing a consistent and stable service. From a technical perspective, that means designing a fun game that will consistently connect players to people on their gaming level – all while avoiding lag, crashing and disconnection.


Make sure that your game is best placed to succeed by keeping a careful high-level overview of what you want to achieve. By knowing what technical problems your game needs to prepare for and designing a sophisticated safety net to be positioned underneath it, it’s possible to create a real-time multiplayer game that hits all the right notes.

Who uses GameSparks?