I keep wanting to make cool games and then trashing the idea because there’s no way to match my players. Without matchmaking new players will be matched with veterans and everyone will have a bad experience. That sucks.
A good API would be:
- DefineQueue(name, rankThreshold, targetPlaceId, canJoinGamesInProgress)
- PutPlayersIntoQueue(players, queueName, playerRanks, timeout)
- RemovePlayersFromQueue(player,s queueName)
- PlayerQueueStatusChanged(players, queueStatus, reservedServerId)
Roblox would automatically sort players into matches when they’re in the same queue, then once the match is sorted roblox will make a reserved server and tell the developer the id so that they can transition and teleport the players.
I would be hesitant to add an API at this high of a level. If you add too many features, it’ll be confusing and hard to use. If you add too few, people will need to code their own.
Would DataStores be viable at a low level to solve this? If not, what changes would they need?
They seem sufficient, but I haven’t ever tried doing a matchmaking system, so I don’t know for sure.
They would if you only have 200 players. Past that the limits hit you pretty hard.
please vote for me
(this one’s going to take a lot of “want” to get done)
Too slow and I’m using those requests for other things. I could foreseeably make a custom solution using http requests but I don’t think anyone on roblox knows how to do that - it would be a huge project in itself.
You guys need to make a button that leads to this trello board on here or the ROBLOX website, because I always forget to visit it as it’s hardly shown anywhere. So users will know it’s official and you will get more feedback as well as an increased regularity of feedback.
Alexnewtron’s Robot Blox did exactly that I believe and it seemed to work pretty well. I can relate on scrapping ideas from this though; it’s as if the only feasible thing to do is have your games have a single-server round loop.
I like the idea of matchmaking. There are a lot of issues that need to be considered.
Is latency considered?
Are friends considered?
Is reputation considered?
Are parties considered? If so, how is party elo determined?
This could cause some players to never be able to play, or only play the same people.
(Ideally, there would be a way to get fixed teams for clan battles. This can already be done without this system.)
Matching by skill also has issues. It means good players can’t play casually without losing ranking and new players can’t learn by playing against good players. It can also mean the best players always play against an exploiter. It also means players will quit tactically or attempt to crash the game server in order to avoid loss.
It will increase scamming as well, as some users will let good players “borrow” their accounts in order to increase rank, if rank is skill based.
We should get matchmaking though, we should just take these problems into consideration.
We should be able to store arbitrary data and operate on that to determine match making.
In my opinion, it should be up to us to run our own matchmaking server, that way it fits the game that we’re making it for. The only problem with it at the moment, is that we need to spam http requests to our servers. Instead, I suggested websockets, but that was rejected, not sure if they knew I was referring to client-side protocol vs server-side. We just need a way for our own servers to communicate with the roblox servers, like a TCP connection for example. Because personally, I would keep a connection open, keep my server up to date with where players are, and then my server would tell the roblox game servers to place certain players into certain games, etc.
But this is just my opinion, I am sure most people would rather roblox run it, but I wouldn’t for customization.
No idea if this is a good or terrible idea, but what about a script you put somewhere special(maybe in the game’s edit page) and it lets you handle all the server matchmaking. Every server chooses what data to post to this script(all the players involved and their relevant data, the map/roundtime/etc), and also this script is told relevant data about players trying to join. It seems less user friendly, but I think it’ll also be more powerful for those that are not new to scripting
I also was wondering about this as a long-term idea. The ability to have an arbiter instance that would know about all running instances and the players, but not have players itself.
Really I think we at least need a list any server can pull down that contains a list of every server, their jobId/reserveserver key, and any data we choose to put in. Because datastores don’t cut it when you have 1k player highs. You cant update a single datastore too much, so everyone updating the same datastore is out of the question. You can try 5-10 per server, but it’s tough to determine how many servers are connected to each datastore(serverTable1, serverTable2, etc), but that’s still not good because 3 servers updating simultaenously can be a problem, and it still doesnt help if you have 200 servers running. Cant download all 200 frequently enough in a lobby server.
The limiting factor seems to be data store update speed. What if there was some form of data store that trades data for speed? That is, data is more limited and/or temporary, but updates are nearly instant.
The other issue is the inability to efficiently manipulate rows of data. OrderedDataStores do not solve this problem because their values can only be numbers.