The Problem
Currently, there is no easy way to isolate players into separate matchmaking pools.
We can adjust the signals for matchmaking through the Custom Matchmaking system and API’s, but there is no hard cutoff for whether a player should be able to join a specific server. The matchmaking system prioritises servers based on desired signals, but doesn’t have a veto for if a server is truly not suitable for the players joining.
As a developer, you might want to have separate matchmaking pools for team sizes. For example, you shouldn’t be put into a pool of solo players if you’re running a duo, and vice versa. Either you throw 2 solos together into an impromptu duo, or you crowd out the server with loads of players who can’t even get put into a match together.
This is just one example, as there’s quite a few cases where you might want to have separate pools of matchmaking:
- Casual/Ranked lobbies, ELO-gated lobbies, different rulesets, etc.
- Passphrase-locked matchmaking pools, community servers, private servers. Unlike the existing reserved approach, you could have multiple servers available for a community this way, so you aren’t all forced to play on the same region.
Roblox already has a feature like this for cross-play disabled console players: DataModel.MatchmakingType. These players are placed into their own matchmaking pool and won’t interact with players in different pools. If the functionality is already covered by Roblox infrastructure, why not open up a custom solution?
Existing Solutions
One way we solve this currently is by creating multiple copies of the place:
They’re all identical and have the same source code, so have to individually be updated every time a change is made.
Developers expanding the offering of your gamemodes by introducing new pools in this way end up having to shoulder a mountain of tech debt that’d make Atlas go weak in the knees.
You can automate this, but this requires an amount of organisation and infrastructure that isn’t accessible to most developers.
You could also use MemoryStores and handle all of the matchmaking yourselves through Reserved servers… But then you don’t get to use any of the Custom Matchmaking signals, with latency being a signal that you can’t fetch with MemoryStores.
Proposed Solution
I’m not on the matchmaking team so I won’t pitch a solution like I am, but here’s an idea of what might fill the gap:
This could be done by extending TeleportOptions to have a ‘Pool’ property. Simple!
How does this feature request differ from those already out there?
This feature request differs from similar existing requests (e.g. Option to Prioritize New Server Creation through Custom Matchmaking) as it is not concerned with just server creation but also with barriers to entry. A combination of existing systems and those proposed would cover most needs.
Thanks for reading!