For many games, latency (the time taken from making a request to receiving a response) is, or should be, a major consideration.
Latency can have many contributing factors, but generally can be classified into two main categories: computer latency and network latency.
At GameSparks, we understand these concerns and our service is architected from the ground up to reduce latency as far as possible.
Computer latency is relatively simple to understand – a request arrives at the server, is processed, and a response is sent back to the client. The time taken to perform this processing is the computer latency. To minimize computer latency, we monitor and dynamically scale our server clusters, ensuring that they never become too busy. We also monitor the speed of various automated tests to ensure that we have not inadvertently introduced any performance-impacting changes in our releases.
Network latency is the time taken to transmit data from client to server (and back again). One major factor that typically affects this is the physical distance between client and server. Even with modern network infrastructure and broadband fiber-optic cables, there is a measurable time taken to transmit even a single packet of data across the network. Network latency between the USA and Europe, for example, is typically 200-300ms.
This network latency becomes compounded if multiple trips are required during communication. For example, opening a standard HTTPS socket involves several round-trips as part of the protocol handshake.
To minimize the effect of network latency, we use secure WebSockets rather than RESTful services for standard requests. This reduces the overhead of HTTPS connections (eliminating handshakes for every request, and reducing the amount of bytes sent backwards and forwards “over the wire”). This allows us to provide significantly faster request/response times than competitors using more traditional RESTful services.
Providing our services from numerous datacenters around the world allows us to minimize the physical distance between our customers’ players and the GameSparks servers, reducing the network latency further. All of this means that for games using GameSparks, latency is usually not an issue – the service works seamlessly.
But there is one genre of game where latency (or reducing it) is absolutely vital. RealTime Multiplayer games require that the latency be as low as possible – if it is too high, data cannot be transmitted quickly enough between players, and there is a noticeable “lag” when playing the game.
A second consideration is not just the latency for each individual player, but that the majority of players have similar latency to each other. Otherwise, players with the lowest latency have an inherent advantage over players with higher latency, since they will receive data more frequently – this can result in “slower” players always seeing the “faster” player in an out-of-date position. It makes it pretty hard to shoot someone in a “versus” match, if you always see where they were rather than where they are.
With the recent addition of RealTime services to the GameSparks feature set, this was an important issue for us to address.
To start a typical RealTime Multiplayer game, the process usually begins by deciding which players will take part against each other. This can be done using GameSparks’ Matchmaking features. With this, a group of players can be found with similar skill levels to ensure the most competitive, and engaging game – no new player really enjoys being constantly beaten by more experienced players after all! Ensuring that players compete against players of similar skill improves the experience, and ultimately helps player retention rates for your game.
Ultimately however, if your matched players are scattered all over the globe, the latency for at least some of these players will never be particularly great. That’s why for RealTime matches, players are preferentially matched by location. For example, if you’re in Europe looking for a head-to-head match with another player, GameSparks will match you with the geographically closest available player (whilst still ensuring that the skill and match group rules defined in the match configuration are obeyed). So if two players were available to be matched, one in Europe and one in the USA, both of whom match your skill and have the same match group, we will match you to the player closest – in this example, the player in Europe.
Additionally, you can use the match group to limit matches by any arbitrary factor you choose. You might decide that you only want players in the same countries to match each other – no problem! Just set the match group to be the player’s country code for every Matchmaking request, and only players in the same country will be matched. Of course, this isn’t just limited to countries – you can feel free to rely on the in-built process for RealTime matching to find the closest players. You can use the match group feature to limit your matches by demographic factors such as age group, or indeed by any other factor you require.
Once a suitable group of players are matched, the game can begin, facilitated by a GameSparks RealTime server. We provide these servers at various locations all over the world, and to ensure the best possible gaming experience, it is important to choose the most appropriate server.
This process is not as trivial as it might first appear. For example, if you only have two players, it is fairly obvious you want to pick a server somewhere in the middle of the two. But what about larger groups? If the majority are in the USA, with maybe one player in Europe, which server do you pick? Picking the geographical center of these 2 locations might ensure average latency is similar for all players, but would artificially increase the latency for the majority of players (in this example, those in the USA) leading to reduced playability for most players.
What is really needed is a “weighted average” location – in effect, a best attempt to keep the average latency fairly consistent, but not at the expense of introducing a higher latency for most, just to accommodate a few players.
So how do we achieve this? Consider the simplest case of just two players. You know the latitude and longitude for each, so to calculate the “middle” surely just taking an average would work? Sadly, life isn’t so simple. Consider two players at longitudes of 5E and 5W degrees respectively (i.e. +5 and -5 degrees). The simple average of these values is 0 degrees. Perfect!
However, now consider values of 175E and 175W (i.e. +175 and -175). These also average to 0 degrees. In this case, although the result is technically still the “middle” (i.e. on a 3-dimensional globe, it is equidistant from both players) it is also sadly on the exact opposite side of the globe to the location we really want to find (which is 180 degrees).
The problem is that this simple algorithm is effectively using a 2D solution to solve a 3D problem. The answer is therefore to use a solution that accounts for the spherical nature of the globe.
Consider the simple example below, with only two players (represented by the red dots) on the surface of the Earth. The vector for each of these locations is shown as a yellow arrow (with the origin at the center of the Earth):
Now if we perform simple vector addition for these two locations:
The green vector shows the sum of the two original vectors. Normalizing this resultant vector (i.e. resizing it without changing it’s direction, so it finishes on the Earth’s surface again) gives us the center of the two original positions:
For this example, only 2D vectors were used, but it is trivial to perform the same technique with 3D vectors. As more players are added, we simply add more vectors together, normalize the result, and we will have found the center of the players.
Additionally, this gives us the weighted average we wanted – if the majority of players are located close together, with one player in another location on the globe, the result will be naturally “weighted” towards the area with most players:
Now we know the (three-dimensional) center of the player’s locations, it becomes trivial to choose the closest RealTime server to that point. This provides a best effort to minimize the overall latency, whilst attempting to keep the average latency similar for the majority of players. Ultimately, this results in a more enjoyable game for more players, and helps to maximize player engagement and retention.