Matchmaker In-Depth
Last updated
Was this helpful?
Last updated
Was this helpful?
Learn more about Edgegap’s no-code matchmaker concepts in-depth and customize to your needs.
Edgegap Matchmaker is a managed service using your own rules to find the optimal group of teammates and opponents in seconds. Get started in 5 minutes and test the entire feature set for free. Upgrade when you're ready to a private dedicated cluster with enhanced security. Native integration with Edgegap Deployments delivers best-in-class ping no matter where your players are located.
Our matchmaking philosophy is driven by player perspective, with core principles of matchmaking:
social integration (such as friends and lobbies),
balance between match speed (time to play) and match quality (balanced player attributes),
high availability, process observability, and user-friendly error handling.
To deliver on our core principles, we prioritize first and foremost:
usability - ease of learning, integration, and use,
real world examples and troubleshooting guidelines,
modularity of features with holistic, design-driven approach,
full automation of DevOps and maintenance tasks.
Testing Matchmaker is entirely free, no credit card required. Free Tier allows up to 3 hours of runtime on our shared test cluster, after each restart. After releasing your game, your matchmaker will need to run 24/7 to ensure players across the world can join servers.
There are three essential concepts to each Matchmaker:
☁️ Hosting Cluster - underlying server infrastructure, fully managed and operated by Edgegap.
📏 Configuration - set of rules and settings that define how the matchmaker will operate.
🌐 Service Instance - the 24/7 live matchmaking service running on the Cluster, using Configuration to match players together and produce deployment (server) assignments.
To take advantage of new features and bug fixes, you’ll need to update your matchmaker version.
To make things easy, we host and manage matchmaking entirely for you 24/7. You can use our
Free Cluster (shared) to test all features and explore synergies with your design,
matchmakers on free cluster shut down after 3 hours automatically, requiring restart,
Private Cluster to ensure stable and dedicated environment for your production needs.
Upgrading to a private cluster only takes one click. Changing Private Cluster Tiers after launch, without any player downtime, is also possible with Rolling Updates & AB Tests. Managed clusters provide you high-availability service hosting maintained by Edgegap.
Prepare for success and optimize after launch, so you don’t block your players on release day.
Our clusters use cloud machines featuring AMD/Intel CPUs with clock speed 2.4 - 3.2 GHz.
Every matchmaker is based on JSON configuration. Config is validated automatically during restarts.
See Getting Started for our SDKs and detailed example scenarios.
Editing a running matchmaker will trigger a quick reload, deleting all tickets and causing short downtime.
Profiles represent entirely separated matchmaking queues, only sharing the same matchmaker version. You can configure any number of profiles for your matchmakers, though splitting up your player base will result in longer queue times for your players.
Some game modes may require more vCPU / RAM, especially if they support a higher number of players. A single matchmaker may include multiple profiles, each linked to an app version with adjusted resources.
Each matchmaker profile points to Apps and Versions in your Edgegap organization. Separating development and production environments with separate matchmaker may help prevent accidentally releasing a version which is not production ready.
Every ticket joins matchmaking queue based on initial rules defined for their chosen profile.
Rules
Each entry in profile at path .rules.initial represents a rule, where:
key is a string value to name the rule however you prefer; e.g. match_size , and
value is an object defining the type and attributes of the rule, adhering to our standard ruleset.
Operators player_count and latencies may only be used once per profile.
Operators (rule type)
To demonstrate various operators, we will refer to our example configuration:
All rules have to be met simultaneously to initiate assignment. You may match using operators:
player_count is a special rule defining how many players need to match to initiate assignment,
example defaults to 1 team (no team split), see Matchmaking Teams for more details,
player_count rule is required and may only be defined once in your initial configuration rules.
string_equality matches players with the exact same string value, case sensitively, e.g.:
example selected_game_mode rule:
Erin (”Capture The Flag”) and Frank (”capture the flag”) will not match; A≠B.
Charlie (”Capture The Flag”) and Dave (”Free For All”) will not match; A≠B,
Alice (”Free For All”) and Bob (”Free For All”) will match; A=B,
number_difference matches players within the absolute numerical difference from each other:
example elo_rating rule above with "max_difference": 50 initially:
Alice (42) and Bob (90) will match; | A-B |=48 elo_rating points,
Charlie (40) and Dave (91) will not match; | C-D |=51 elo_rating points.
intersection matches players with one or more overlapping string values, case sensitively:
example selected_region rule above with "overlap": 1 :
Alice [”NA”,”EU”] and Bob [”EU”,”APAC”] will match; A ∩ B = {“EU”},
Charlie [”NA”] and Dave [”EU”] will not match; C ∩ D = {}.
latencies is a special rule matching players within a specific difference range in ping values:
this presents a “soft” solution to splitting your player base, enabling matching with neighboring regions, especially improving match speed for less populated regions,
max_latency should be specified to discard locations above a given threshold,
example beacons rule above with "difference": 50, "max_latency": 250 initially:
Alice and Bob will match, since Beijing is discarded (>250) and the rest is within | A-B | < 50:
Alice {Montreal: 12.3, Newark: 45.6, Dallas: 59.9, Beijing: 264.4}; and
Bob {Montreal: 27.3, Newark: 32.4, Dallas: 23.1, Beijing: 252.2}.
Charlie and Dave will not match, since | C-D | > 50 for Dallas Beacon:
Alice {Montreal: 5.7 Newark: 44.2, Dallas: 59.5, Beijing: 263.2}; and
Bob {Montreal: 57.8, Newark: 32.0, Dallas: 24.2, Beijing: 272.3}.
See Ping Beacons and Latencies Attributes for details on player ticket integration.
Latencies rule is optional and may only be defined once in your initial configuration rules.
An openAPI specification will be generated based on your config once you create your matchmaker.
Optionally, expansions can be defined to modify each rule’s attributes at time intervals since ticket creation, effectively expanding the pool of players which can be matched, speeding up queue times.
In the example above, we expand the queue by modifying attributes after:
5 seconds spent in queue:
elo_rating difference of 100 points is now accepted,
10 seconds spent in queue:
elo_rating difference of 200 points is now accepted,
latency difference of 100 points is now accepted,
latency maximum of 250 points is now accepted,
20 seconds spent in queue:
match_size of 3 players is now accepted,
30 seconds spent in queue:
match_size of 2 players is now accepted,
60 seconds spent in queue:
match_size of 1 players is now accepted
the match starts automatically.
Updates of the same rule’s attribute will overwrite previous values during rule expansion.
To support multiple teams, increase team_count value. Get total number of players by multiplying team size and team count:
for "team_count": 2 and "team_size": 5, a total of 10 players is required for a match,
for cooperative and free-for-all game modes, set "team_count": 1 .
Team IDs will be assigned to 🎫 Player Tickets (accessible by game clients), and injected in deployments as Injected Environment Variables (accessible by dedicated servers).
When used with Join as Group, groups will match in teams with sufficient slots without overfilling. Teams are balanced using average (mean) of attributes. Interested in alternatives? Let us know!
Each player creates tickets to join the matchmaking queue. Tickets are compared and if criteria defined in the 📏 Configuration is met, a deployment will be assigned, and players may establish connection with game server.
See Getting Started for detailed example scenarios and tickets.
The matchmaking process can be summarized in a few steps:
Player creates a ticket status="SEARCHING" ,
Player repeatedly reads their ticket every second; looking for matches:
Team has been found status="TEAM_FOUND" (see Matchmaking Teams and Join as Group),
Optionally team disbanded status="SEARCHING" , shuffling groups.
Optionally team disbanded status="SEARCHING" , teammate abandoned.
Optionally group disbanded status="CANCELLED" , group member abandoned.
Match has been found status="MATCH_FOUND" ,
Deployment started, waiting while Assignment is null,
Host has been assigned status="HOST_ASSIGNED" ,
Deployment is Ready, server process starts initializing,
Players read the assignment (URL & external port) from their tickets,
Players retry connection to game server until ready.
Matchmaking may stop before "MATCH_FOUND" due to either:
Player abandoning (deleting) their ticket,
Ticket is immediately deleted and reading it will return 404 Not Found.
Ticket expiration period reached status="CANCELLED" ,
Ticket can be read until removal period is reached, then it’s deleted (returns 404).
Maximum deployment retries exhausted status="CANCELLED" ,
Ticket can be read until removal period is reached, then it’s deleted (returns 404).
If players experience any issues, or a long queue time, they may attempt deleting their current ticket and restarting the process by creating a new ticket.
If the player has been matched and assigned a game server, their ticket will be deleted automatically. Players who abandon queue after HOST_ASSIGNED may be replaced with server Backfill.
For best experience, provide status updates to players using in-game UI. Once players connect, start a loading scene to perform synchronization steps (e.g. selecting and loading a map/scene/level).
To provide best possible latency, 🎫 Player Tickets may include game clients’ latency for one or more Ping Beacons. Once clients perform a “best effort” measurement, they construct an object with all beacon-specific latency values:
Beacon latency values are used to prevent matching with players in a vastly different region.
Joining matchmaking with your friends relies on a third party identity system. Most games will use Epic Online Services, Nakama, Steamworks, brainCloud, Lootlocker, Playfab, Apple Identity, Google Play, or others… These systems usually expose a platform-dependent friend system and a lobby/party system which can be used to communicate across the group.
See our Epic Online Services group implementation example for “join as group” inspiration.
To join matchmaking with a group, once the group is assembled:
Group leader requests ticket attributes from other members,
Group members provide requested information to leader,
Group leader creates a Group Ticket using our SDKs or the API,
upon receiving assignments, Group leader sends each member one assignment,
Group members follow regular Matchmaking Process as if they joined alone.
In case a group member decides to abandon their ticket prior to HOST_ASSIGNED, all tickets of group members immediately update to status="CANCELLED" pending removal after the configured period. Afterwards, this matchmaking process may be repeated from scratch with a new group ticket, disregarding the previous tickets.
If a group member decides to abandon match after HOST_ASSIGNED , game server is responsible for waiting for a pre-defined period of time and finally issuing new Backfill tickets to replace the player.
If a group member’s game client crashes, they may reconnect as long as they have saved their assignment ID persistently (on drive) between game restarts.
See Getting Started and our SDKs with automated reconnect and more.
Optionally, some games may have special matchmaking needs, such as:
allow new players to join games in progress (friends or strangers),
replace players who leave (leavers) after game starts to avoid restarting match,
allow spectators to join and observe tournament or friends’ matches (e-sports),
centralize players in larger servers to provide more social interactions (MMOs),
let players choose a server to join through a server browser (custom).
Backfill is a server-controlled matchmaking feature enabling all of these use cases and more. Once Matchmaking Process and game server initialization concludes, your server should continually:
Start idle disconnect countdown for each new player (recommend up to 3 min):
Start a loading scene/level while players connect - a full fledged 3D scene, a lobby-like social UI, or a loading screen with a progress bar, to indicate initialization is progressing.
Trigger loading for new players on server initialization.
Trigger loading for players replacing leavers (joining via Backfills).
Keep track of new player connections or existing players leaving over time:
Read Injected Environment Variables for initial players' ticket data.
Listen to custom client RPCs containing new player ticket IDs (initial or backfilled), to pair tickets to netcode entities/actors.
Read and verify matchmaking data of players using Endpoint /backfills assignment.
Create new Backfills for unused player capacity (leavers) or to renew expired Backfills.
See Mirror Seat Management and FishNet Seat Management for player connection monitoring.
Use Backfill to replace Seat/Match sessions. Matchmaker only supports Default session type.
See Getting Started for genre-specific scenarios and examples.
This feature is in development, scheduled for late 2025, stay tuned for updates! 🚀
Some games may want to let players join servers with open capacity. We're working on additional matchmaking features allowing this in addition or as a replacement of classic matchmaking.
Clients and servers may call API directly or via SDK methods, see also Getting Started.
Game clients and Servers authenticate with Matchmaker using an Authorization HTTP header containing your secret token (Auth Token). If you’re using our SDKs, an input is provided to paste your matchmaker-specific Auth Token.
This token may be included in your game client safely, as it doesn't grant access to Edgegap API.
Keep your tokens secret and safe! Edgegap staff will never ask you for your tokens.
To restrict access to certain functions, authenticate players using a third party identity store (such as Epic Online Services, Steamworks, brainCloud, Nakama, Lootlocker, Apple Identity, Google Play Account, or others…) you may integrate an additional authorization service of your own using Server to Server Integration.
If creating tickets for players using your own backend service, make sure to add an additional HTTP header X-Player-Ip with the player’s public IP address (or include parameter player_ip in ticket create API request) so Matchmaker can perform telemetry and ensure lowest possible latency.
IP addresses of players using a VPN will be masked. Game clients may use ipify.org free service to find their real public IPs.
These endpoints can be used directly by game clients or your Server to Server Integration.
Monitoring endpoint provides a convenient way to verify uptime of your Matchmaker Service from game clients or backend services, so you can reach out for assistance in case of urgent issues. You may integrate redundant (multiple) monitoring systems checking this endpoint for your own visibility.
Ping Beacons provide a simple yet effective way to approximate connection quality to major networking nodes and prevent high latency matches. See Latencies Attributes for more.
Create Ticket (POST) - pick a matchmaking profile & submit ticket attributes.
Read a Ticket (GET) - check on matchmaking progress and host assignment.
Delete a Ticket (DELETE) - abandon matchmaking immediately.
Unity/Android - consider using raw string interpolation to prevent code stripping of hardcoded JSONs.
Join as Group endpoints allows matching deployments as a group/party/lobby:
Create Group Ticket (POST) - submit yours and your group members' tickets.
Your designated group host/leader is responsible to collect ticket attributes from players through a third party of your choice, and to distribute assignment IDs to individual group members to allow managing individual Matchmaking Process.
See Join as Group for details and Getting Started for genre-specific scenarios.
For webGL games hosted on third party distribution platforms (e.g. itch.io), sending any requests to Matchmaker from game client may result in Cross-Origin Resource Sharing policy violations. Most modern web browsers send a pre-flight request to verify that a backend service (the Matchmaker) understands and accepts communication from your game client.
Failing pre-flight check (default for security reasons) can result in one of several possible CORS-related errors, most commonly CORS header 'Access-Control-Allow-Origin' missing .
To resolve this error, add allowed_cors_origin parameter to your configuration to either:
whitelist your exact client hosting domains:
or whitelist a wildcard domain (including all subdomains):
No credentials are required for Matchmaker pre-flight requests, if domains are configured correctly.
These endpoints are used by the dedicated game server or your game backend.
Backfill allows your game server or your backend service to manage player capacity of servers:
Create a Backfill (POST) - submit current player tickets along with matchmaking profile.
Read a Backfill (GET) - retrieve ticket information about the filled player.
Delete a Backfill (DELETE) - stop backfill depending on game server logic and design.
See Backfill for details and Getting Started for genre-specific scenarios.
Inspect API lets developers understand and debug possible matchmaking flows:
Inspect Tickets (GET) - list current player tickets, their status, and assignment (if available).
Inspect Matches (GET) - list current matches and resolved Matchmaking Rules values.
To pass information to game servers and provide operational insights, we provide additional features.
Map players to tickets - players should send ticket ID via an RPC to game server server when they connect.
Environment variables are stored as stringified JSONs, parse them using an SDK or a custom method.
Keeping track of compatibility between server and client versions can get confusing. Follow our tips for reliable releases, updates, and preventing downtime or compatibility issues.
Your Matchmaker URL will always remain the same after restarting.
Create separate matchmakers for dev & production environments to safeguard against human error.
Follow these steps to run AB tests, then disable underperforming variants, and keep the 🏆 winner version.
To prepare for zero-downtime updates we recommend creating at least 3x copies of your matchmaking profile ahead of time, for example green, blue and orange. Each game client version will create tickets for one of these, rotating after each update.
Multiple app versions can serve as aliases for the same server image tag, removing the need to restart your matchmaker when rolling out a new server version. Simply update the tag of your app version.
We recommend the blue/green strategy for update releases.
This section assumes you’ve completed 🟠 Before Going Live. Let’s assume that live game clients (c1) are currently connecting to profile green, pointing to app version green linked with image tag v1.1.0. We also assume you’ve previously created profile blue pointing to app version blue linked with an older image tag which is no longer used (e.g. v1.0.2).
In order to release game client + server updates, you may:
Prepare new server app version (v1.2.0) on Edgegap:
push a new image tag to your container registry (v1.2.0),
create new app version (v1.2.0),
optionally enable caching for new app version (v1.2.0) in preparation,
wait for cache percentage to get to 80% or higher,
Perform any dev tests by deploying your new app version (v1.2.0):
connect your game engine’s Editor to the provided URL + external port,
Update unused profile blue to link to your new image tag (v1.2.0),
Update your new game client (c2) to use the new profile (blue) when creating tickets:
change the base URL and Authorization token to production matchmaker values,
Perform QA tests and final verifications of your new game client (c2):
if you find and resolve any issues, repeat process from the beginning,
Release your new game client update (c2) on distribution platforms,
Allow time for new game client (c2) to distribute to player devices (typically up to 3-7 days):
monitor outdated game clients (c1) by filtering deployments with app version (green),
Perform cleanup of unused resources in your Edgegap account:
delete app version v1.2.0 as it’s no longer used for dev tests,
delete image tag v1.1.0 to free up Container Registry capacity since update is completed.
For your next update, increase version numbers and swap green and blue keywords in the guide.
This section assumes you’ve completed 🟠 Before Going Live. Let’s assume that live game clients (c1) are currently connecting to profile green, pointing to app version green linked with image tag v1.1.0.
To release a server patch without requiring a game client update, you may:
Prepare new server app version (v1.2.0) on Edgegap:
push a new image tag to your container registry (v1.2.0),
create new app version (v1.2.0),
optionally enable caching for new app version (v1.2.0) in preparation,
wait for cache percentage to get to 80% or higher,
Perform tests and verifications by deploying your new app version (v1.2.0):
connect your game engine’s Editor to the provided URL + external port,
if you find and resolve any issues, repeat process from step 1,
Update currently used profile green to link to your new image tag (v1.2.0),
new matches will automatically initiate assignment with the updated tag (v1.2.0),
Perform cleanup of unused resources in your Edgegap account:
delete app version v1.2.0 as it’s no longer used for dev tests,
delete image tag v1.1.0 to free up Container Registry capacity since update is completed.
Display ticket IDs and deployment IDs in client match history UI to trace players when troubleshooting.
Instances use CPU and memory to perform matchmaking and assignments, associating a hosting cost with each private matchmaker. See resources and prices associated with each tier on our pricing page.
Always use private clusters for stress testing. Free matchmakers are limited for testing at small scale only.
The resource requirements for your instance will depend on factors:
number of players - more players make more tickets,
number of requests - polling for status more often creates more load on matchmaker,
configuration complexity - number of profiles, rules, and expansions,
average match duration - shorter duration means more matches, tickets, and higher load,
ticket expiration and removal periods - keeping stale tickets for longer consumes more memory,
client retry fallback logic - retrying with short jittered backoff helps spread traffic burst peaks.
If a matchmaker is experiencing high load:
if CPU is throttling, matchmaking could be slowed down,
if matchmaker runs out of memory, it will restart without losing ticket information, hoping that clients will implement exponential backoff and the burst is retried over longer period of time.
Matchmaker offers a vast set of capabilities, adding complexity to the matchmaking process. The changes you make to your configuration and the impact on your players will be more predictable if you run tests on your matchmaker, using our Inspect API:
List all tickets to understand and reset state quickly and reliably anytime.
List match proposals for live tickets to fine tune your ruleset and gain more control.
Coming Soon: pause and resume matchmaking at specific ticket stages.
This feature is in development, scheduled for 2025, stay tuned for updates! 🚀
To improve user experience we plan to expose additional user-facing statistics through our SDKs and API. Additionally, some studios may want to optimize and monitor their Matchmakers. To address both needs, we plan to expose metrics such as:
load monitoring over time (create, read, delete, expire),
match speed and expansions per profile,
groups and teams attribute balance,
bucketing based on attributes and rules (min, max, avg over time),
event data export for your custom analysis needs.
Your success is our priority. If you'd like to send custom requests, ask for missing critical features , or express any thoughts, please reach out in our Community Discord.
Our matchmaker uses official Semantic Versioning guidelines. Each configuration JSON is tied to a specific version of the matchmaker. Matchmaker version dictates which rules and settings are available in your configuration and API. Once a version is released, it will never change.
Your configuration file will be validated depending on matchmaker version used, make sure your rules are matching the matchmaker version’s capabilities.
The latest version of matchmaker is 2.1.0. All examples on this page are up to date. Keep an eye out for end of support notices for your matchmaker version. See also Rolling Updates & AB Tests.
This is the latest matchmaker service version, recommended for production use.
⚠️ Breaking changes:
Separated game profile and expansion stage information in the Injected Environment Variables:
MM_MATCH_PROFILE will now only include the profile name as it appears in the configuration.
Introduced MM_EXPANSION_STAGE which will contain the expansion stage as a string (e.g. "initial", "15", "30").
Ticket assignments now include the group ID when Endpoint /tickets. Group ID is also included as an Injected Environment Variables, as a mapping of group ID to a list of the group's player IDs.
Ticket assignments now include the team ID when Endpoint /tickets. The team ID is also included in every ticket data Injected Environment Variables.
Endpoint /tickets now returns 409 Conflict HTTP code instead of 204 No Content to indicate the ticket can't be deleted since the deployment is starting. To replace leavers, use a Backfill issued by the server after a pre-specified timeout period.
Endpoint /backfills request body parameter attributes.deployment_request_id has been moved to attributes.assignment.request_id.
Endpoint /backfills request body now requires full assignment details as part of attributes parameter in addition to the request_id.
🩹 Bugfixes:
Resolved intersection rule values are now Injected Environment Variables in the MM_INTERSECTION environment variable.
Quick restart feature now reliably regenerates API endpoints and openAPI specification when configuration is changed.
Fixed several bugs during matchmaker (re)start causing prolonged startup time or getting matchmaker stuck.
✨ Improvements and new features:
Increased rate limits and scalability of all API endpoints, across all matchmaker tiers.
When assigning a player to a Backfill, the new player's ticket ID will be added as a tag to the Backfill's Deployments.
Added swagger UI authentication feature to test API directly in web UI without needing postman.
Improved openAPI examples to reflect realistic requests and responses more closely.
Added new Inspect API meant for development and debugging purposes.
Allows listing all current player tickets in a paginated list.
Allows listing all current matches in a paginated list.
Backfill: Upon (popular) request, we’re adding backfill with automated ticket assignment, which allows you to reuse server seats when players leave the session.
Ideal for filling empty player seats after a match has begun, or for replacing players that have left during a match.
Join as Group: We’re adding the ability to join as a group to the already available ability to fill multiple teams with players.
Ideal for joining up in a matchmaking queue with a group of friends or coming from a common lobby.
To make integration easier, we’re now offering Software Development Kits for the most popular game engines.
Fixed a bug where the Latencies Attributes was not applied correctly.
Tickets will now be automatically canceled after a Matchmaking Process if they haven't been assigned to a deployment.
You can now Endpoint /tickets to enhance the flow of your matchmaking process.
Deployments made by the matchmaker are now tagged with ticket IDs.
You can now edit your configuration while the matchmaker is running. This triggers a quick reload of your configuration without requiring a full on/off cycle for your matchmaker. Note: This feature is not recommended for production environments, as it deletes all current tickets and temporarily makes the API unresponsive.
Fixed Injected Environment Variables to use the correct primitive types instead of arrays.
Fixed Injected Environment Variables JSON values, which previously contained escaped characters.
Fixed a bug where certain headers were not accepted by the matchmaker when requests were made from a WebGL application (CORS policies).
Fixed issue with TLS/SSL certificate validation preventing matchmaker from launching.
Fixed a bug causing the beacons endpoint to return a 500 error.
Basic authentication is now mandatory for all endpoints.
Added the ability to configure the number of retries on server assignment failure.
Team-based matchmaking is now the default for all matchmaking configurations.
Both application and version are now required fields in all profiles.
Introduced a new endpoint to monitor the matchmaker's status.
Updated the format of the tickets environment variable in the deployment.
Added a configuration option to allow hosts to communicate with the matchmaker.
The debug API is now only available when explicitly enabled in the configuration (it is currently disabled for rework).
The game_profile key in the GET ticket response has been replaced by profile.
Deployment may be retried several times ,
Delete any leftover Backfills once the .
To Backfill a group of players, or invite a friend to an existing game, add Matchmaking Profiles with a string_equality operator following the example, sharing the same app version. Current player tickets will be matched using the chosen profile to new player tickets. Any profile can be used for Backfill as long as attributes of backfill are valid.
If you need a server browser feature urgently, consider using our API to .
🎫 Player Tickets provide a simple interface for players to match together, see Matchmaking Process and .
Your server might need to know details about it’s players. Ticket attributes, resolved rule values, and other values are injected to your deployment, in addition to default .
If your players experience any issues, tracing their path to server logs can be helpful. Each Matchmaker deployment will be tagged with assigned player ticket IDs so you can easily and find to help you troubleshoot.
See to learn about deployment troubleshooting.
Use or implement exponential jittered backoff to recover from high load.
and matchmaking SDKs:
We currently offer to cater to everybody’s needs:
Best Suited For
enthusiasts, solo developers
commercial releases
high-traffic launches
Resources
1 vCPU + 2GB RAM
6 vCPU + 12GB RAM
18 vCPU + 48GB RAM
Redundancy
1x virtual node
3x virtual nodes
3x virtual nodes
Price (hourly)
$0.0312
$0.146
$0.548
Price (30 days)
$22.464
$105.12
$394.56
Swagger Web UI: deploying a matchmaker will generate an openAPI specification and a convenient web UI. Open the URL in your browser to view and test all API endpoints, and to review payload examples.
🎈 Social Game Example