Quality of Service
Quality of service (QoS) service helps to dynamically determine the available regions where a client would expect to get the best connection for their online session.
Matchmaker allows game clients to provide QoS results information for each player in a matchmaking ticket. The QoS results contain information about the connection quality from the clients to the QoS servers that reside near the game servers that could potentially host a game. The Qos results are defined by region and contain the latency and packet loss ratio values. Matchmaker uses these results to match players together in regions where the connection quality satisfies the requirements of a game.
Note: The QoS results contain server IPs. These IPs are not game server IPs, but QoS server IPs.
QoS rules
QoS rules use the QoS results on a ticket to define what a good connection quality for their match should be.
Consider the following example where the latency of all the players in the match must be under 100:
"MatchRules": [
{
"Name": "QoS",
"Type": "LessThanEqual",
"Source": "Players.QosResults.Latency",
"Reference": 100,
"Not": false,
"EnableRule": true
}
]
Relaxations
When using QoS rules, it is important to apply some relaxation to allow matchmaking to happen even if the player population in a region is low.
Consider the following example to relax the latency rule after 30 seconds:
"MatchRules": [
{
"Name": "QoS",
"Type": "LessThanEqual",
"Source": "Players.QosResults.Latency",
"Reference": 100,
"Not": false,
"EnableRule": true,
"Relaxations": [
{
"Type": "ReferenceControl.Replace",
"AgeType": "Oldest",
"Value": 150,
"AtSeconds": 30
}
]
}
]
Using Unity QoS SDK
Unity provides an SDK that makes the QoS calculation easier for a fleet. The following code snippets shows how to retrieve QoS results from a game client.
If a Matchmaker for a project supports multiple fleets, then the QoS results on the ticket should only include the QoS from the fleet that is allocated.
HttpClient client = new HttpClient();
client.DefaultRequestHeaders.Authorization =
new AuthenticationHeaderValue("Bearer", AuthenticationService.Instance.AccessToken);
var fleetId = "Multiplay fleet id"; // Replace this with the fleet Id;
// Fetch QoS result for the fleet
var qosResult = await GetSortedMultiplayQosResultsAsync(new List<string>{fleetId});
QoS considerations
Party matchmaking and QoS
For parties where more than one player is on a ticket, several strategies are possible to provide QoS information.
- Have the different clients of the party provide their QoS results and then add those values to the ticket.
- Have the different clients of the party provide their QoS results, make an average of the QoS results and then add those values to the ticket.
- Provide the QoS results of the party leader.
Determine acceptable QoS limits
Most real-time games have thresholds for latency and packet loss above which gameplay quality is considered degraded (when gameplay quality is reduced, but is still technically playable) or impossible (when players are unable to maintain connection or the game logic does not function properly). Using QoS results in matchmaking prevents players from playing in regions where QoS is poor.
When determining these limits, remember to consider both the experience of the player with a poor connection and the experience of other players when playing in a game alongside a player that has a poor connection. For example, some game engines provide a reasonably good experience for a player with high latency or packet loss, but to other players, that player might appear to teleport to a degree that makes gameplay with that player impossible. In practice, this means that you have to process the per-region QoS results that are gathered by the client and then filter out the regions that are unacceptable or impossible for them to play in.
- If a player's best available QoS result is outside of the acceptable latency or loss range for your title, but is still technically possible, you might want to consider filtering out all results except for the player's best result. This allows the player to at least find a match even if it is not a match with a good quality connection. In these scenarios, providing a connection quality warning to the player can help to set expectations that there might be gameplay issues.
- If a player's best available QoS result exceeds your impossible threshold, it is recommended that you provide appropriate error messaging and prevent the player from playing.
QoS best practices
Consider the following best practices when you work with the Multiplay Hosting QoS protocol.
- The latency and packet loss values per region that are included in a ticket should generally be an average or flattening of all responses for each QoS server that is contacted within that region. A weighted average of results that gives more weight to the most recent results might be a more accurate depiction of the current network quality.
- Review your packet loss versus latency ratio. For example, for real-time games, a very low latency connection that would normally result in a standard game session could be impacted by even minimal packet loss.