States that you can do " * Skill-based matchmaking queues : Save user information such as skill level in a shared queue among servers, and use lobby servers to run matchmaking periodically."
Seems like this service was the perfect solution to my problem. After reading all the documentation I have become very confused.
Problem number 1
“ReadAsync” allows you to specify a count. Okay this is good. I can read multiple items in case the first item in the queue isn’t of the right skill level.
Lets pretend that the 2nd player in the queue is the right skill level.
“RemoveAsync()” requires a ID that is returned from “ReadAsync”. The documentation, to my understanding, says that it will remove all the players that were returned.
I only want to remove the 2nd player, leaving the 1st player at his position on the queue.
I can’t read just the 2nd alone, then remove it. The count parameter is only an int64 and will read all items starting from position 1 to count.
What if the 100th player in the queue is the right skill level. 99 other players need to restart their position in the queue as they get removed?
Problem 2
Okay, lets say we got lucky.
The player in position number 1 was the correct skill level.
The server that found the player in the queue will teleport the searching player to the desired place.
Now how do I get the player found in the queue (who is in a completely different server) to join the first players private server so they can have their evenly skilled 1v1.
I feel like I’m misunderstanding the entire system and I need to look at it from a different perspective. If anybody has any tips or system designs, I’d love to hear them!
For this issue, the best solution would be to send out a message using MessagingService, with the players UserId and the target servers JobId. Then you can listen to the topic and check if the playerId is the player in your server, if so teleport them to the server with the JobId you passed.
I’m currently in the process of building a matchmaking system. At first I was going to use memory store queues like you, and it seemed like an awesome candidate to avoid having a central server to do all the matchmaking. It became apparent that this wouldn’t be a suitable option for a few reasons.
You are not able to remove a player from the queue once they’ve entered it.
I came to terms with this, and decided that I would just read multiple items from the queue and validate a unique “queueId” that would be stored in a MemoryStore Map. If the queueId wasn’t in the memory store map, it would mean that the player wasn’t in the queue anymore. Here comes the second problem.
ReadAsync only returns a single id.
The reason this is a problem, ex: if I’m trying to match a team of 4 people, I would read 6 people from the queue as a precaution. This way, if any players weren’t in the queue anymore I could still make a team out of 4 people. However, if all 4 people were still in the queue I have no way to just remove those 4 people. I would have to remove all 6 people and then perform two more MemoryStore calls to add those players back into the queue with a high priority.
I would love to make a feature request to change the way ReadAsync() works. To make matchmaking with MemoryStore queues feasible, ReadAsync should return a removalId for each element read from the queue. Then you can pass a list of removalIds to RemoveAsync() and it would remove the items from the queue. I’m not sure how things work behind the scenes or if it’s even possible to implement this but it’d be nice to see.
I’m still in the process of deciding how I want to implement my matchmaking system in a scalable manner. Having a single server do all the matchmaking processes isn’t feasible for a popular game. I might make my own implementation of a linked list using MemoryStore maps. I might just scrap using Roblox Api and move to a third party server with some REST api, although that comes with added costs.