Global Matchmaking

Hello, I am trying to make global matchmaking for a game. Players can match with other ones on any server, then they are teleported to a new place or anything like that… The important part (or issue) is how to match the players around the game, these are ideas I had so far:

MessagingService: Have a list on each server of players searching match, listen for a “Matchmaking” topic and response with a player on our local queue (probably there are some details to cleanup), this is perfect because limits scale up with players
Problem: MessagingService is still in beta

Firebase: Adding a user to the realtime database so another player can search it (of course on server-side) and edit the entry to contain the generated place id or whatever we are doing, while the first player is listening for changes
Problem: Firebase limits are 100 concurrent connections at the “Spark Plan”, so you wouldn’t be able to have more than 100 roblox servers running (having a connection per server)
Problem 2 (Common Problem): There can be also concurrency problems: two players finding the same one, idk if firebase has some kind of locking but otherwise is a common problem in most of the methods

Google Sheets: A long time ago I saw this video https://www.youtube.com/watch?v=vISRn5qFrkM I don’t really know how this can work on our context but maybe we can see it like a normal mysql db, quotas are based on size so there is no real problem since all the data is just temporal.
Problem: It seems very nice and simple but it does really works that well? Also we have the concurrency problem, and probably we would need to shift all the rows when deleting an entry

An HTTP server that has redis or something like that would be great handling concurrency (as long as you do it) but I don’t think we all can host a server that supports the massive amount of players that roblox has.

So what do you think about these ideas, do you have any other better? I hope we can do a bit of brainstorming on this!

6 Likes

I feel like MessagingService will be the best option out of those options for the long run because it is an official Roblox feature, whereas the other options use 3rd party websites or applications.

Assuming the MessagingService comes out of Beta smoothly, then I would expect it to be available to everyone by the time you even finish the matchmaking system, and you can sign up to use Beta features early so you could be working on the Matchmaking System before it is officially released.

Of course, this would be much easier if we had some kind of unique UniverseScript that ran across every server instead of duplicating to each one. Looking at the Official 2019 Roadmap we can see that Universe Script & Game Services (New type of scripts that can run at a universe level to allow for matchmaking, leaderboards, etc.) seem to be on-track for the 4th quarter of 2019, or October-December.

So, I think for the time being the easiest option would be MessagingService if you aren’t familiar with using external databases. But, if the project isn’t expected to finished in the next couple of months, perhaps make a temporary system using MessagingService or an external database, and hopefully you will be able to use UniverseScripts before the end of the year!

Good luck with the project :smiley:

6 Likes

The main issue with external databases is that Roblox’s HttpService cannot listen for requests, it can only spam GET requests, meaning that for a real time database you’d be sending hundreds of requests per minute across however many servers you have.
What I’d recommend loosely:

  • Create a universe, with your lobby as the starting place
  • Set the server to prioritise filling (to reduce server count)
  • Use the MessagingService to choose a server (probably the oldest) as the “Master” server. This is where the other servers will send their matchmaking data, and will be the server that replies telling the “Slave” servers where to send players
  • Have a lifetime on the “Master” server so it doesn’t get too old and slow and gross
  • Wait for Universe Scripts to come out and make this like, a hundred times easier. It’s hopefully only a few months away!
4 Likes

MessagingService is what I would do, even though it’s in beta still. Google Sheets is not meant for that. And other third-party tools are going to cost you money. Unless you’re hosting your own server that can scale really well and doesn’t cost much, I would stick with MessagingService.

7 Likes

Awesome to hear that you are thinking about how to achieve global matchmaking! This is one of the main reasons we created MessagingService. The more details you can provide about your use case, the better we can help. So feel free to post a description of how you think your system will work.

Also we’re going to be opening up MessagingService to all devs in the next week or two, so stay tuned!

8 Likes

Instead of working this summer, I’ve dedicated my time to https://rbxmod.com , a service which allows you to upload Lua code and run it in the cloud. Once you’ve uploaded your code, you can start an instance of it and connect to it from as many games as you would like. Right now the service is free, but in the future I’ll ask for some compensation for server resources. I’m working with some developers right now to bring matchmaking to their game and I’d be happy to work with you as well.

RBXMod is however in very active development. I’d be happy to slow down that development and switch to high availability mode if you decide to use it. I actually use Redis right now for session management and have considered opening it up for RBXMod use.

RBXMod is built in the AWS EC2 cloud. The EC2 instances that support it scale from the current 1 vCPU and 1 GB of RAM to 96 vCPUs, 768 GB RAM, virtually unlimited SSD storage, and a 25 Gb connection. While a normal LuaJIT application wouldn’t be able to utilize all of that, you can either start multiple RBXMod instances in that or use compiled libraries that can. If that isn’t enough, I’m building RBXMods so that it you can start instances on multiple servers. It can handle your needs.

The concept behind RBXMod is simple: give developers the freedom and power to create the game that they want. It does this by allowing Roblox games to use resources from outside Roblox’s restricted environment. If compiled libraries are required by one developer, they can be added and everyone will benefit. Need more computing power? Start up multiple RBXMod instances and you have a multi-process, multi-node cloud network to support you.

Send me a message if you would like more information or would like me to work with you to build a custom solution.

5 Likes

At first what I think about is like a global “list” channel where servers can publish a list of their players searching match among with a server uuid so if another server is interested on matching we can message via “negotiation-{uuid shown on list}” channel telling our uuid and that our player wants to match (probably also give some feedback to the player telling that matching with another), at this point both players are locked, they can’t appear on list nor be negotiated (if they receive a new request is declined) and now the only thing left is that the receiver server of the negotiation creates the place and responses to the “negotiation-{sender’s uuid}” channel telling the place id or that we decline the match if the player is locked.

I didn’t test this but it seems a pretty straightforward protocol, also I doesn’t have concurrency problems (as long as I can see) that was one of my main concerns.

Also thanks for those news, I don’t have to worry anymore about MessagingService release being out of my schedule!

1 Like

Nice I didn’t know about Universe Script & Game Services being planned on the roadmap!
I used a lot of external databases but I feel more secure of using a feature like MessagingService since I don’t have to worry to much about scalability.
The nice staff there told it will be like next week or two that I think matches perfectly with our schedule.

Thanks to everyone for the comments, I will be sharing with you the working thing once its finished!

2 Likes

I wrote this when MessagingService was first released. If you mess around with it a bit you should be able to do cross server matchmaking just fine. Cross-Server Matchmaking Module

1 Like

I think the best option at the moment would be a 3rd party option using HttpService. Although it could get a bit complicated as you would need to set up a MySql database and some php scripts. It is doable though i have done it myself. You might want to wait for messaging service or Iniverse scripts though if you want an easier option

1 Like