We provide the player with the serverlist. They get to choose which server to join. For examples, look to games like CSGO community serverlist, or TF2 community serverlist, or Dayz serverlist, or Rust Serverlist. This is the type of system we have built out. We have “static” servers, in a list, and let the player join any server from the list. This is so that the state of the server is always the same as they left it.
I do not think simply having a GetCrossplayEnabled function would suffice, because of the issue differentiating between XBOX and Playstation servers. If we only know they have crossplay disabled, then we cannot serve the player a serverlist for only their platform.
This seems like the best approach for us. These three settings would cover all cases for us to adequately serve the players the correct serverlist for them to choose from.
The player object is convenient, yes. Even if it is locked to server-only, as the server is the one serving the player with the serverlist.
In your specific case of the static server list, how would you be using the matchmaking context identifier? Would you filter out servers that the player can’t join, prevent them from teleporting to the server, or something else?
When a client wishes to view the serverlist, he makes a request to the server. The server gathers a list of servers that client has access to view, and sends it back.
Today, we use our hacky workaround to try to figure out which players are Xbox/PS5 players, and whether or not crossplay is enabled. These factors are then used when filtering the serverlist.
With the proposed API you mentioned, I would simply replace my hacky detections with the matchmaking context identifier, so that I can serve Xbox (crossplay disabled) players with only their servers, and same with PS5, etc.
After looking into the code some more, it seems that this matchmaking context id lives on the server-side config and isn’t currently a part of the current player config. What do you think of adding the matchmaking context id to the datamodel of the server, gotten with game.MatchmakingContextId instead of the Player object? Does it solve your problem still?
So long as every player in the server is bound to the same matchmaking context, then I think it does not make a difference to me.
If a server is marked as a “Crossplay enabled” server, then I would expect all players to be crossplay enabled players, and as such only able to join crossplay enabled servers. In which case, I can serve everyone in the server the same in-game serverlist.
You will see a new Enum called MatchmakingType with three values: Default, XboxOnly, and PlayStationOnly, and the value will exist on the server DataModel via game.MatchmakingType.
More details to come once I am able to get code working, tested, approved, etc.
I’ve made some changes which seem to work, but I honestly have no idea whether it will work in the larger scope of matchmaking. I need some more feedback from the engine folks that understand how the server & matchmaking logic works before I can be sure of my solution. That said, I really can’t imagine this change being that hard to make, so I’m hoping this’ll be available by the end of this quarter.
Hey all, as I’ve just been linked, this change was made into release 662. Please let me know if you can see the new value in Studio.
Edit: I’m going to run this through QA first to double check its validity before enabling it on production (targeting next Monday), but you should be able to see the new value in Studio now. Enabling it on production would just mean its value is reflected correctly if you’re in a game that is XboxOnly or PlayStationOnly. Right now, it will always be Default.
I am planning to add console support for a game that utilizes reserved servers and absolutely needs to know which players will be put into the non crossplay servers, it seems like the only way to do this will be to check the current lobby server’s .MatchmakingType.
Is it really not possible to disable non crossplay in your game completely? Just imagine how many players out 1000 will have crossplay disabled… Even now, sometimes creating a match takes longer than 30 seconds.
I don’t think you can prevent a non-crossplay player from spinning up a server and joining your game because Matchmaking would have to create an API that lets you block a player from joining before they even create a server for the player. If that’s what you need, it’s probably a feature request for Matchmaking, as that would be server-side.
However, can’t you kick a player out of your server with a message if they have cross-play disabled? e.g. pseudocode like this:
-- server script
when a player connects:
if game.MatchmakingType ~= Enum.MatchmakingType.Default then
kickPlayer(player, "This experience does not support cross-play disabled players. Please enable cross-play in order to play.")
end
That would result in an instant dislike by the player that was kicked. It would be better if it was possible to disable the play button for those players.
In that case, I think we would probably need some collaboration with Discovery to check the user’s cross-play setting against the game’s crossplay setting (which might not exist, so we would need to add that field to game settings somewhere). I agree it would probably be the best experience for a cross-play disabled player to not be able to join in the first place, so feel free to make a feature request. As you said yourself though, not a lot of players have cross-play disabled so it shouldn’t be a huge loss to your like ratio.
If I had to take a guess at this, I would think that this is beyond Roblox itself. Microsoft and Sony most likely have requirements that all apps on their stores must adhere to. Respecting crossplay is most likely one of them.
Hi everyone, I turned on the change for production yesterday and was able to confirm the value was set correctly to PlayStationOnly on my cross-play disabled PS5 devkit.
In the above we can see that Xbox players have a unique serverlist that is different from PS5 users and from Crossplay Enabled users.
Sorry for the low quality screenshot
