Ah, yeah it is. I didn’t even think about that. I don’t think it’d even be possible (for me) to obtain a sublicensable license from microsoft for all users of MatchmakingService.
See this reddit post.
My module has a different name and is based on this open-license implementation which uses different math.
If I don’t care about the ratings or SBMM system, can I just not initialize MatchmakingService on the game server? I’m asking if doing that will break any systems in the matchmaking (e.g. it was expecting a match result).
You can safely not call UpdateRatings()
and it’ll keep everyone at the same rating effectively meaning everyone is always at the same level. This is more clearly stated in the new docs I’m working on. However you should still initialize the service and call RemoveGame()
and StartGame()
at their appropriate times.
I will add though that roblox has still not replied to my bug report… So this service is still a little broken
Is there a reason I need to use RemoveGame()
and StartGame()
? I’m in a weird situation here.
There can be up to 2 players normally in a server, but at certain points during a co-op experience parties will “intersect” if they are at the same point in the story; so they will come together in a single 4 player server for a period of time. If you’ve heard of resident evil 6’s intersection system, it’s basically that.
Also, is there a way to modify the function when a “match” is found? I need to set a datastore with the new servers’ reserve code for teleport data such as what checkpoint they are at in the story.
If you don’t use RemoveGame()
the game will exist in memory until it times out which is bad for the overall performance of the memory store (and more importantly, right now it’s a big problem, see current solutions bug report for why). There is no real reason to use StartGame()
other than to mark it as started. Currently there isn’t a way to modify match found, but I can add that functionality in the future
Edit: I accidentally reset the solution, sorry to anyone that was notified!
So roblox made an update…
Instead of fixing the bug they went ahead and capped the size of sorted maps to 1kb. Which is just wonderful. I don’t know if there will be any good way to fix this.
It’s super unfortunate that it has come to this, but I’m not sure of any scalable way to make this service work with this limitation. For anyone wondering this is what the docs said before:
It’s just incredibly upsetting and I really don’t know what to do about it so I’ll detail some options and why they won’t work:
Switch to memory queues - While I would love to switch to memory queues, it’s not feasible. Memory queues are is a terrible position right now. One you add an item to the queue it will exist there until it times out or is read. This isn’t always a problem, but it means that there’s no way to dequeue players if they leave or want to get out of the queue. It’s honestly a joke how badly implemented memory queues are in their current state with pretty much no control over them.
Break the running games up when the limit is reached - This is not scalable and will exponentially increase the number of calls to the memory store, eating up your quota.
I only see one option and it’s what I’ll be working towards for the foreseeable future:
Save ids to the games in a single array in the memory queue and save games to their own map - This seems like it will be the only option. The problem is, with small-medium sized games the 1kb limit will still be an issue. Here’s why: 1KB is 1024 bytes. Each character is 1 byte in size. The id to identify the game is ~55 characters in length. 1024/55
= 18.6
. This means that at any given time, you will only able to have 18 running games before the service starts to error. It’s just not scalable. I can switch to smaller unique ids (which I will, something like youtube’s base64 system) but even then, memory size is scarce and even if I could make a 1 character unique id you’d still only get up to 1000 games, which if your game has even 10000 players is still not enough. Honestly going back to MessagingService-based matchmaking systems might just be the only real solution, but those aren’t even scalable either because of the limits. There’s no good solution and this service has its back against the wall while roblox rips it apart.
It’s really upsetting to see them add this service (memory stores) that seems so good and new and a breath of life into possibilities… just to then impose limitations that make it useless. 1KB is nothing. The Xerox Alto, a PC from 1973 had 96x the amount of memory.
Anyways, rant over, I’ll see if any solutions are viable. If it’s not worth my time and effort to maintain and find a scalable solution then I may have to discontinue this project which would be really disheartening to me because of the work I put into it. And it would make me feel bad for anyone that currently uses it because it won’t work if their game ever gets to an even small-medium size. I’ll continue to ponder solutions, if you have any ideas don’t hesitate to share them with me.
Edit with some afterthought:
It may be possible to have multiple running games sorted maps with a counter of how many there are so we can loop over them. The main problem is that for each new sorted map you make, if you want to iterate over all games you’ve added an extra call to the memory store, which isn’t too bad and might be the solution to this. An additional call to it isn’t the best solution, but it’s a solution. And with the request quota giving you 100 requests per user per minute I don’t think it should impose any real downside (other than multiple calls to memory) and the quota should still be fine. I’ll look into implementing this asap.
How would I go about teleporting the players back to the lobby place? Would I use normal teleport service or is there a function?
Just use teleport service. Once you teleport all players out the game will close. Just make sure you have this in BindToClose:
game:BindToClose(function()
MatchmakingService:RemoveGame(gameId)
end)
where gameId is the actual game id passed through teleport data
Well I am giving the players the option to leave the game after it is over. For example a /hub command.
Version 3.3.0-beta is finally out after a week or so of testing (and even more for coming up with a decent way to do it… I haven’t seen any issues so far). This patch includes a long awaited fix for issue #4. This fix is still being monitored and if you notice any issues still with it let me know asap!
Version 3.3.0-beta
Changes (breaking):
- None
Changes (non-breaking):
- [Change] Players are now removed from queue automatically upon leaving, if they are in the queue.
Fixes:
- [Fix] Broke up the memory stores to bypass the arbitrary 1kb limit on a single key in the memory store map. This fix is being monitored.
I did a testing for this with around 700 people(not the new version this was about 1-2 week(s) ago) and here is what I found. The main issue I had was that the profile service did not load sometimes so people would get kicked/errored. Another issue is the issue #4 which I believe you said above. Another thing for me is I have absolutely no need for the rating part so if you could make an option to like disable that or a different version without it(since most of the issues stemmed from there I believe). Other than that it was fine but with those 2 issues in large servers it wasn’t really able to work for me but I am quite excited to see where it goes in the future.
I have plans to be able to disable the rating system entirely via an option when using GetSingleton
. As for the issue with #4, the update I made should’ve been able to get around that. Could you update me on if you’re still having the same issue on 3.3.0-beta
? Would love to talk more in detail if you want to dm or add me on discord
Sure, I would love to talk to you on discord. You can add me at SkeletorAngel#7886
awesome i was making one too but your is better for internal use
a cool feature will be like SetPlayerRange per Rating type and PlaceId too
Multiple places and rating types for each places is planned, but it will take a small rewrite of some of the base code so I haven’t gotten to it yet. I’m still working on the new docs.
I changed your code but I don’t know if it will be optimized
QueueSettings = {[“ranked”] = {range = NumberRange(), Placid = :number}}
At line 375…
Service.PlayerRange = NumberRange.new(QueueSettings[mem.ratingType].Range.Max,…)
And I change placed in the code loops
If you wish to have your code changes implemented into the service, please fork the project on github and open a pull request GitHub - steven4547466/MatchmakingService. This makes version control and rollback easier.
I’ve released an update that allows you to disable the rating system entirely!
Version 3.4.0-beta
Changes (breaking):
- None
Changes (non-breaking):
- [Addition] Added an
options
table toGetSingleton
. Right now the only accepted option isDisableRatingSystem
which will disable the rating system, disable profile service, and everyone will be in the same queue pool.
Fixes:
- None
To disable the rating system, when you call GetSingleton
, add {["DisableRatingSystem"]=true}
into the parameters so it looks like this: GetSingleton({["DisableRatingSystem"]=true})
. Make sure you do this on any place where you use GetSingleton
in hub servers and game servers
Editing in a small patch:
Version 3.4.1-beta
Changes (breaking):
- None
Changes (non-breaking):
- None
Fixes:
- [Fix] Fixed an issue where you would get an error while queueing a player or party with the rating system disabled.
EDIT: So I’m pretty busy right now, but I’m doing a big change to this service that will improve everything for everyone. This will include:
- Removing ProfileService entirely and just using datastores directly (this will completely get rid of wait time exceeded issue)
- Switching from glicko-2 (which has a few issues with farming volatility) to OpenSkill.
- Multi-place support
- A data folder of some sort that will replicate after teleporting to the game server.
That is amazing, thank you so much for everything you’re doing for the community. We really appreciate all the hard work!