Every time I try to find a way to do this, people talk about the amount of players in the server, or the concurrent players of the universe.
NO I’M NOT TRYNIG TO FIND THIS:
NOR AM I TRYING TO FIND THIS:
#game.Players:GetChildren()
I know to get the concurrent players of the universe I can use JSONDecode, Maybe is there a place version for the universe code?:
local data = game.HttpService:GetAsync("https://games.roproxy.com/v1/games?universeIds=4705987484")
local body = game:GetService("HttpService"):JSONDecode(data) --res would be the response from the server
local playerCount = body.data[1].playing
print(playerCount) -- universe player count
I’m assuming that you’re using teleportservice for the different places, and if that’s the case then just use fetch the active players of those places. Summary: Make different games for different modes and fetch the active players throughout the different modes.
HttpService is exactly what you’re looking for if that’s the case. I highly recommend to watch videos about HttpService to get a better understanding. (Read this doc aswell)
Last update: You cannot request roblox game data with external servers unless you make your own website to track the data of your game with the help of GCP or AWS.
Assuming the code runs from within the game itself, you can use MessagingService:
local MessagingService = game:GetService("MessagingService")
local function getServerPlayers(): number
return #game.Players:GetPlayers()
end
--Only bind this once
MessagingService:SubscribeAsync("GetPlayers", function(message)
local data = message.Data
if data[2] == game.JobId then return end
if data[1] ~= game.PlaceId then return end
MessagingService:PublishAsync("ReceivePlayers", getServerPlayers(), data[3])
end)
local function getPlayersOfPlace(placeId: number, waitTime: number?): number
local players = 0
local guid = game.HttpService:GenerateGUID(false)
local connection: RBXScriptConnection
connection = MessagingService:SubscribeAsync("ReceivePlayers", function(message)
local data = message.Data
if data[2] ~= guid then return end --the just in case check
players += data[1]
end)
MessagingService:PublishAsync("GetPlayers", placeId, game.JobId, guid)
task.wait(waitTime or 5) --default delay is 5 seconds
connection:Disconnect()
return players+getServerPlayers()
end
local targetPlaceId = 0 --replace with your place id
local concurrent = getPlayersOfPlace(targetPlaceId) --this yields/has delay
print(concurrent)
Basically what’s happening above is that a server(for example your game lobby) asks all the other servers currently running for their current in-game players, and if the place id happens to match, they’re added in the total. In the example above we give 5 seconds to all the pinged servers to send back a response. If you want quicker refreshing times you can try decreasing the delay, although for this you don’t really need anything less than 2 seconds.
While MessagingService does provide a good method, there is the off-chance that SubscribeAsync can fail, as shown on the documentation. So, a server could be missed out, undetected.
for anyone wondering, I didn’t only say SubscribeAsync could fail because it ends in Async. That’s not why…
They can add pcalls and retry logic on top of this so this wont happen. I usually avoid adding pcalls in my responses so I don’t overcomplicate them, except the very obvious cases, for example datastores.
Additionally if they know in advance which place ids they care for(within that universe), they can only subscribe the game servers that are in any of those place ids. So if for example they don’t care about knowing how many concurrent players the lobby place has, they can not subscribe the GetPlayers topic for the lobby servers(since we know in advance they wont be pinged). Lastly if you want to reduce traffic even more, you can add the place ids in the topics themselves(assuming they aren’t a lot, for example more than 100). That way if you do something like GetPlayers-{placeId} it will only ask the servers of placeId and thus reduce traffic(because only those servers will have subscribed to that event).
Yeah, they can add pcalls, but there’s still that tiny, incredibly unlikely but still existent chance of a fail. I would presume a separate place would have been used for the lobby instead of game servers under the same place, but if not, MessagingService would be better, yes. As for adding place IDs, the OP asked how to retrieve the CCU for one place, not many. For many place IDs, maybe even something like a memory store could work. Or, Roblox could just update the multiget-place-details endpoint… sigh…
If the error chance for this specific problem is really small, why bother? It’s not a datastore entry that will be impacted, just the numbers being very slightly off once in a while. I can just use the Ostrich Algorithm and call it a day.
I derived that they may need it for many due to the image they shared, it shows two images/game modes, so I assumed they may be under different places.
My point is that there’s much less room for error with a proxy and the Roblox API. You’ve got the chance of an error from HttpService, a chance of an error from the proxy’s HTTP request, and the chance of an error from the proxy returning the data back to the HttpService. Where as with MessagingService, you’ve got the chance of an error from broadcasting the message, and each server has a chance of an error publishing the message back. Not to mention there will be a lot more traffic through the MessagingService despite the optimisation tactics you mentioned before. Adding more for other places, the chances of error are still much less using 2 HTTP requests.
