Daily news, dev blogs, and stories from Game Developer straight to your inbox
Sponsored By
Experts from the Amazon GameLift team take an informative deep-dive into the architecture of cross-platform multiplayer games.
April 12, 2018
12 Min Read
Sponsored by Amazon GameLift
Author: by Bruce Brown, Peter Chapman
Presented by Amazon GameLift. Learn more about cross-platform game development during our live webinar. Register today!
Development of multiplayer games has reached an inflection point: game developers have started supporting cross-platform play across all devices. This is a significant shift that can create better player experiences while introducing new challenges for game developers. What makes this new development in cross-platform play so significant is that it challenges some long held beliefs and assumptions in multiplayer games:
Players value competitive fairness of matches over being able to play with friends
Mobile games can’t meet the same performance expectations as PC and console games
Certain genres – like shooters – don’t translate directly to mobile
Players only want to commit to playing a game on one gaming device
Why should you consider supporting cross-platform play for your game?
It’s all about the players. Players can now play with their friends who are on other platforms without having to buy another copy of a game or invest in an entirely new gaming device. They can engage more frequently with a game across a number of screens throughout the day: on the bus with a phone, at lunch on a laptop, at home on a PC or console, etc.
Wait times go down and the competitiveness of matches go up. Combining all players into a single large pool allows matchmaking logic to handle where players intersect across gaming devices. Players willing to opt-in across multiple gaming devices will find matches more easily, and with a larger pool of players to choose from, the likelihood of finding matches with similarly skilled players increases.
Build and manage a single community of players. Cross-platform play eliminates the inherently fractional nature of isolated gaming devices and brings all players together to play, creating stronger and more loyal communities for game developers. And you'll likely increase MAU and profit.
Simplify your backend infrastructure. With the right architecture, cross-platform play can simplify the backend services infrastructure around getting players matched and into games.
This last point is what we are going to address in the remainder of this post by walking through an example using Amazon Web Services (AWS) and Amazon GameLift, the dedicated game server hosting and matchmaking solution.
How to design and support cross-platform play
Requirements for designing cross-platform play architecture
To get into the specifics of how your game can support cross-platform play on AWS, let’s explore the requirements of an end-to-end solution:
Accept game requests from desired gaming devices such as Xbox, PlayStation, Nintendo, PC, Mac and mobile devices.
Capture the device that the player is playing on
Allow players to opt-in to or out of cross-platform play
Capture player data for matchmaking such as skill and desired role
Match players into games based on your defined rules
Route player groups to a suitable game server for play
Figure 1 (below) shows a multiplayer back end architecture that supports cross-platform play.
3 steps to implement a cross-platform play solution:
Process requests from multiple gaming devices
Match players across devices
Place players onto game servers
Let’s take a closer look at how to achieve these three steps.
1. Process requests from multiple gaming devices
First, you need to accept game requests from players on any gaming device the game supports and use the data from those requests to generate matchmaking requests.
In our multiplayer backend service architecture, we have a game service that acts as a front door to game clients. The game service is a custom part of the end-to-end process, and there are many options for implementing this service. One solution is to use Amazon API Gateway with AWS Lambda, but you may already have your own service that interacts with clients which can be extended.
This game service provides a means to:
Parse inbound game requests from clients
Handle any necessary player authentication
Perform any game specific logic for your game such as granting players permission to access a game mode or to check if a player is banned, for example
Integrate with Amazon GameLift FlexMatch to process matchmaking requests and place players on game servers
Cross-platform play data is specifically provided in the matchmaking request to FlexMatch, so let’s dive into that integration next.
Integrate with Amazon GameLift SDK
The game service will be the point of integration with FlexMatch. This integration will enable the game service to create new matchmaking requests and have them processed. The integration can be implemented via the AWS SDK, and most popular languages are supported, including C++, C# and JavaScript.
Create StartMatchmaking Requests
Now that integration between your game service and FlexMatch is complete, your game service can create StartMatchmaking requests for FlexMatch. The information Amazon GameLift FlexMatch will need for your cross-platform solution includes:
A unique matchmaking ticket ID
A unique player ID
The player’s current gaming device
A list of gaming devices the player has opted-in to playing with
Latency data to allow FlexMatch to determine where to place the match
Any other game-specific data the matchmaker should consider about the player like skill, maps, etc.
The StartMatchmaking request gets a MatchmakingTicket in response. This ticket includes the information that was part of the original request, including Ticket ID and a status of “SEARCHING”. For more information about integrating a game service with Amazon GameLift FlexMatch please see this guide.
2. Match players across gaming devices
Now that you have integrated with FlexMatch and are successfully making matchmaking requests, you now need to configure FlexMatch to use the request data to match players across gaming devices. Configuring FlexMatch is done via the rule set. Here is an example of a simple rule set that configures FlexMatch to match across gaming devices, considering latency as well:
{ "ruleLanguageVersion": "1.0", "name": "Cross platform matching with latency and expansions", "playerAttributes": [{ "name": "acceptablePlatforms", "type": "string_list" }, { "name": "myPlatform", "type": "string_list" }], "teams": [{ "name": "red", "minPlayers": 2, "maxPlayers": 2 }, { "name": "blue", "minPlayers": 2, "maxPlayers": 2 }], "rules": [{ "description": "Find the common set of platforms among players in the match”, "name": "PlatformMatch", "type": "collection", "operation": "reference_intersection_count", "measurements": [ "flatten(teams[*].players.attributes[myPlatform])" ], "referenceValue": "set_intersection(flatten(teams[*].players.attributes[acceptablePlatforms]))", "minCount":1 }, { "name": "FastConnection", "description": "Prefer matches with fast player connections first", "type": "latency", "maxLatency": 50 }], "expansions": [{ "target": "rules[FastConnection].maxLatency", "steps": [{ "waitTimeSeconds": 10, "value": 100 }, { "waitTimeSeconds": 20, "value": 150 }] }] }
Let’s look at each section of the rule set.
This first section is a bit of booking that includes the name of the rule set and the rule set language:
"ruleLanguageVersion": "1.0", "name": "Cross platform matching with latency and expansions",
Next, you tell the rule set what player attributes to expect. Latency is actually a special attribute that is passed directly from the matchmaking request to the rules engine that evaluates rule sets, so you only need to include the platform data in the playerAttributes.
"playerAttributes": [{ "name": "acceptablePlatforms", "type": "string_list" }, { "name": "myPlatform", "type": "string_list" }],
acceptablePlatforms is a string list of the platforms that the player has opted-in to playing with others on, and myPlatform is the platform of the player.
Next, you define the teams for the match. In this case, there are two teams – a “red” team and a “blue” team – with two players required for each team (minPlayers and maxPlayers are equal):
"teams": [{ "name": "red", "minPlayers": 2, "maxPlayers": 2 }, { "name": "blue", "minPlayers": 2, "maxPlayers": 2 }],
After that, you define the rules used to match players with the passed in player data. The rules sections is where the core part of the cross-platform play evaluation happens:
"rules": [{ "description": "Find the common set of platforms among players in the match”, "name": "PlatformMatch", "type": "collection", "operation": "reference_intersection_count", "measurements": [ "flatten(teams[*].players.attributes[myPlatform])" ], "referenceValue": "set_intersection(flatten(teams[*].players.attributes[acceptablePlatforms]))", "minCount":1 }, { "name": "FastConnection", "description": "Prefer matches with fast player connections first", "type": "latency", "maxLatency": 50 }],
In this case, we have defined two rules:
The PlatformMatch rule does a reference_intersection_count operation between the acceptablePlatforms of the players in the match and the myPlatform value to determine if the platform of the current player being evaluated by the rules engine intersects with the rest of the players in the match. If the values intersect, then the current player is added to the match.
The FastConnection rule indicates that only players that have 50 milliseconds of latency or less can be added to the match.
Finally, you can also tune the rules to relax their constraints over time to find the sweet spot in balancing matchmaking for your players by utilizing the expansions section of the rule set:
"expansions": [{ "target": "rules[FastConnection].maxLatency", "steps": [{ "waitTimeSeconds": 10, "value": 100 }, { "waitTimeSeconds": 20, "value": 150 }]
This section indicates that if a match has not been found after evaluating the current set of players for 10 seconds, relax the rules[FastConnection].maxLatency requirement from the original 50 milliseconds defined in the FastConnection rule to 100 milliseconds. If no match has been found after 20 seconds, relax that constraint again to 150 milliseconds.
3. Place players onto game servers
Now that you are processing requests from multiple gaming devices and matching players across them, you need to connect the players in those matches to game servers.
Once FlexMatch has found a group of players that meet your matchmaking rule set requirements, it will create a game session placement request and place this in to a queue to find the lowest latency game server for the match. FlexMatch is wired up to Amazon GameLift Queues to automate the process of efficiently allocating new game sessions onto game servers.
Queues are configurable and allow you to determine several options that are used when Amazon GameLift places a session onto a game server:
Queue Timeout
Member Fleets
Fleet Priority
Latency policies
Your rule set used player latency data to match players that had a similar latency value to one another. You can then use that same latency data to find an Amazon GameLift Fleet in your Queue with the lowest average latency value for the match. To do this, you set a latency policy.
Like the expansions section of the rule set, latency policies define how long you want the Queue to spend trying to meet a specific latency target for the match of players, and policies can be made up of one or more rules.
Once the Queue has determined the best Fleet for the game session to be placed in, Amazon GameLift will request that a server in that Fleet reserve sessions for our group of players.
Fleets in Amazon GameLift represent the deployed state of your game server. They enable you to define how your build should be hosted within Amazon GameLift including:
Instance Type
Region
Scaling Policies
Capacity Limits
Number of processes per instance
Now that Amazon GameLift has a game session for the players to connect to on a game server, it associates the server ip address and port number of the game server with the players in the MatchmakingTicket. This data is ready to be retrieved by the game service either through polling or via an SNS notification once the session has been placed.
Once the game clients have the server ip address and port, they can connect directly to the game server using that information. As a result, Amazon GameLift adds no latency between your game clients and the dedicated server when playing a game.
Start building a stronger community with cross-platform play
The design explored here allows you to start with a cross-platform configuration that works for you and evolve it over time with minimal overhead and impact. If you would like to learn more about supporting cross-platform play for your multiplayer game, join AWS and Gamasutra on April 24th at 2 PM EST (11 AM PST) for a live webinar. We’ll explain design patterns and backend architecture that allow you to accept game requests from multiple gaming devices, match players into games, and route player groups to suitable game servers. Register here >>
About the Authors
Bruce Brown is the Software Development Manager of the Amazon GameLift Player Experience team responsible for building the FlexMatch matchmaking service. He has been in the software industry for 12 years including time spent at Microsoft on the Xbox Live Cloud Compute and Xbox Multiplayer teams and at Riot Games working on the League of Legends Live Gameplay and Personalization teams. Currently, he is playing Zelda: Breath of the Wild with his 6 year old son, and he enjoys designing games with his wife in his free time.
Peter Chapman is a Solutions Architect in the Amazon GameLift and Lumberyard teams. He has over 13 years of software development and architecture experience. He has designed solutions in many industry sectors including Retail, Healthcare, and Gaming. Currently, he is having a great time playing Axiom Verge on his Switch.
Learn more about cross-platform game development during our live webinar. Register today!
Read more about:
Sponsor Resource CenterYou May Also Like
