[v2.1.0] MatchmakingService - ON HOLD

Hello, is there a way to be sure that 2 players won’t be in the same queue like having a call back function that check if the player can join a game

Hey Steven, I am considering to continue developing this with added features and bug fixes, if you do not wish for me to publish the modification then let me know otherwise I will be posting it on the DevForum under my user and of course I would put you in the credits.

1 Like

Please do, this module seems to have been abandoned despite the recent changes related to MMS budgets, and has been running into increasingly more issues as of lately.

How could I detect when a new private server created by the service is ready, and players are in the process of teleporting to it?

There is no event like that but there is a print(« Added game ») and it does print when a game is created. This isn’t print when a player join a game.Z game is created when the player range.Min not playererange.Max

1 Like

If you are able to, can you make an pull request on github with the fix so that you can be properly credited? If not, that’s fine, I’ll update it myself, but I do want you to be credited for the fix.

Also, my extended LOA from roblox may end soon, so I’ll look into some of the issues posted here since my last update and see what I can do about fixing them.

That’s unfortunate that the budget changed, I’ll have to check the changes to the API and see what I can do about improving this.

The end goal was to switch to a memory queue which is much more efficient for this task, but the lack of API revolving around it makes it nearly impossible to implement into this service effectively without ending up with much more API calls due to people leaving the queue, rejoining, parties, etc.

1 Like

I’ve added a license to the github. I must’ve forgot when I originally created. I have no issues with someone forking this project and maintaining it separately. The license I set was Apache 2.0, which is a generally permissive license.

I am going to be updating this soon to hopefully lessen the errors with the new budgeting. But feel free to fork, maintain, make pull requests, etc.

I’ve released 2.1.0 with some minor fixes before I fix the bigger problems with the new memory store budgets.

Version 2.1.0

Changes (breaking):

  • None

Changes (non-breaking):

  • [Change] GetRunningGame’s argument code is now optional. If not provided, the code will be the current code of the server, if it’s a game server.

Fixes:

  • [Fix] Updated MessagingService implementation to reflect Roblox’s updates to how data is sent and fixes from user misternicekai. I did make this change on my end many months ago, but I unfortunately seemed to have forgotten to commit it.

  • [Fix] Fixed issue #22.

1 Like

Hey steven nice to see you are back to update your service !

This is a warning that the next update to this service will contain breaking changes regarding how games are stored in memory in an attempt to drastically reduce rate limit usage.

Along with this, multiple values will be cached on game servers, such as their id and game data.

What does this mean right now?

I’m not sure. I’m still working on the update. Currently I made SetJoinable(..., false) remove the game from memory. This means that games that are non-joinable will essentially become anonymous. This comes with the unfortunate side effect that non-joinable games will no longer be able to be viewed by you, the developer, if you are making a running games board.

This may or may not remain the case. I’m most likely going to add a secondary running games map that contains non-joinable games, or split the existing map into two categories indexed by “joinable” and “notJoinable.” This would retain the ability for you to get running games regardless of their joinable status, and allow me to not return non-joinable games in the matchmaking loop which only take up an extra rate limit unit. This means that all of your non-joinable games will basically become invisible to the matchmaking loop, which is currently not the case, potentially freeing up many rate limit units.

Currently that’s the only change I’ve made as I write this, but there is going to be more.

This update will come with many optimizations to how memory is utilized, and although I don’t personally agree with roblox’s changes, I understand them, and they are forcing me to make the service better for everyone that uses it.

This was always just a passion project of mine. I don’t play roblox anymore, I don’t really use this service at all, but I love making open source resources available to everyone. I realize now that I should’ve put more thought into it, though. These optimizations are coming, in my opinion, too late. I should’ve made them sooner and frankly speaking they should’ve been in the first release of the service.

I recommend, if you are requiring by id, to make sure to denote the v2 in your GetSingleton’s MajorVersion option. I upload breaking versions under different scripts, but the main module must change as well. If you specify GetSingleton({["MajorVersion"]="v2"}), you will always get version 2.x.x, even when v3 is released. This gives you time to update and not break your games when v3 releases.

I’m not sure when this will release, but when it does, it will probably contain new bugs which I am unable to test myself, so I will be paying close attention to both the github and to the replies to this topic, and please do report any bugs that you find. This version will come with a beta so that I can iron out the bugs of the major version so I don’t need to make two major version changes in a row.

3 Likes

The first beta release for v3 has been added to the roblox marketplace. You can find it here: MatchmakingService v3 - Roblox

require(13533090734) to get it in script, or put it in manually. This has not been added to the main module yet.

This is a beta version and may contain bugs.

Version 3.0.0-beta.1

Changes (breaking):

  • [Removal] Removed GetRunningGames().

  • [Change] SetJoinable() will now move a running game from the joinable memory to the non-joinable memory to preserve rate limit while matchmaking.

  • [Change] StartGame() will move games from joinable to non-joinable memory if joinable is false.

  • [Optimization] The matchmaking loop will now only get joinable games, ignoring all non-joinable games to free up rate limit units.

Changes (non-breaking):

  • [Addition] Added GetJoinableGames().

  • [Addition] Added GetNonJoinableGames().

  • [Addition] Added GetJoinableGamesFiltered()

  • [Addition] Added GetNonJoinableGamesFiltered()

  • [Change] GetAllRunningGames() will return both joinable and non-joinable games.

  • [Change] StartGame()'s gameId parameter is now optional. If nil, it will default to the current game id.

  • [Optimization] Players queued will be given the MMS_QUEUED attribute. If true, MatchmakingService will check their data to see if they’ve joined a game.

  • [Optimization] Rather than getting the data from memory in every loop, teleport game data is cached outside the loop.

  • [Optimization] GetCurrentGameCode() now caches its value so it only gets it from memory once rather than every call.

Fixes:

  • [Fix] Fixed both ApplyCustomTeleportData’s and ApplyGeneralTeleportData’s game data argument.

  • [Fix] Fixed the return value on many methods that would always return true regardless of errors.

  • [Fix] requireing the script with a MajorVersion option will now set the singleton to the one returned from that version’s GetSingleton properly.

TODO:

  • Docs
  • Update autocomplete
5 Likes

This is going to be added in 3.0.0-beta.2

Suggestion :
I know it will change a lot of your current code but for the v3 a great thing would be a way to control the queue and pools.
I will take the example of Dead By Daylight :
In dead by daylight you have 2 teams : killer and survivors and you choose before the game start in which team you want to be in and then the matchmaking create game with 1 killer and 4 survivor…
A way to control player « role »would be really cool…
(Sorry for my English if you need better explanation just ask me)

I’ll see what I can do, that does add a lot of complications.

1 Like

Yeah i do understand but it will open this module to a larger community I think…
I think should add extra parameter on QueuePlayer and QueueParty

It would be, but it also requires the way maps are added to be changed, and how the matchmaking loop works.

My current idea for that which was what initially popped into my head would require something like this:

MatchmakingService:SetMapRoles(map, roles) (like SetPlayerRange, and AddGamePlace)

where roles is (dbd example):

{
  {
    ["RoleName"]="Survivor";
    ["Minimum"]=1; -- Minimum of this role for a game to be made
    ["Maximum"]=4; -- Maximum of this role allowed in the game
  },
  {
    ["RoleName"]="Killer";
    ["Minimum"]=1; -- Minimum of this role for a game to be made
    ["Maximum"]=1; -- Maximum of this role allowed in the game
  }
}

And in this case the game would be made with 1 killer and 1 survivor, but you’d be able to control when it starts so that the full 4 survivors can join. Like how in dbd, you’re on the menu waiting for other survivors to join.

This would override SetPlayerRange, which is basically the same thing, but only one role.

Then QueuePlayer would have a new argument added role. This will require a lot of internal changes to support, but it is a good idea, so I’ll look into it and see if I can make it happen

1 Like

Yes that would be really great , hope you can make it even if it’s hard and need to change a lot of how your service works

Version 3.0.0-beta.2
Changes (breaking):

  • [Addition] Added a new role system to allow developers to assign players roles while in queue. This would allow them to queue on different teams. For example, in dead by daylight, you can queue as killer or survivor. This new system allows you to mimic that.
  • [Addition] SetMapRoles(). Allows you to set the map roles to a table with this format (example):
{
  ["Killer"] = { -- Key is the role name
    Min=1;
    Max=1;
  };
  ["Survivor"] = {
    Min=1;
    Max=4;
  };
}
    • SetPlayerRange is unchanged, but is now only applicable if the role parameter is not used when queuing
  • [Change] QueuePlayerId, QueuePlayer, QueuePartyId, QueueParty, AddPlayerToGame, AddPlayerToGameId, AddPlayersToGame, and AddPlayersToGameId now accept a role parameter. If not provided, then it will use the old system without roles, but the backend adds a role called MMS_NO_ROLE for the sake of convenience in the queue.
  • [Change] GetQueueCounts structure has changed to {map: {ratingType: {role: count}}}.

Changes (non-breaking):

  • [Addition] Added signal GameCreated(gameData, serverId, reservedCode) which is fired when a server for a game is reserved. This only works in the game which is currently handling the matchmaking loop (otherwise known as the main job).
  • [Addition] Added the RunningGamesJoinable property with the corresponding method SetRunningGamesJoinable(). Defaults to true, if false, the matchmaking loop will skip running games and not use any memory queue rate limit units on them. This means that when a game is created by the serivce, it will never be joinable to the service, even if you manually set it to joinable. If you use this, it is recommended to set the minimum and maximum players to the same value so that only full games will be made since they are no longer able to be joined afterwards.

Fixes:

  • None
5 Likes

Great update Steven you added that feature so fast didn’t expect it to be real…It will save so much times for me
Edit : for the queue party it should be a table that contain role no or instead you can make a call back function