My Goal:
I want to be able to get a random player who played my game, even if they aren’t currently playing.
My Ideas:
My first idea when I thought to do this was to just use a datastore and every time a player joins who isn’t already in the datastore, will be inserted into said datastore.
I didn’t try this, although I think it will work. I honestly don’t know if it’s a good idea as datastores aren’t always reliable (despite me never having problems with them).
Another idea I had was to use a badge, but I don’t know if it’s possible to get a random person who has the badge (hence why I’m on dev forum, looking for solutions). I do think that if it were possible, that it’d be a much better solution than a datastore.
If there are any other possible solutions, please suggest them, you don’t even have to go in depth, I just want ideas that I could research and test.
If you have errors with that, you can create a table that when a player joins it added on the table, later do a while loop with long time (like 5 minutes) and update data store with table
In case a save request fails, you can repeat attempting to save data 60 times in a 1-person server upon that player leaving. Personally, my record for failed save requests is 5 in a row, so you should be fine.
If for some astronomically unlikely scenario in which data fails to save on that server 60 times, as a last resort, you can quickly transfer that player’s ID or username or whatever to another open server using MessagingService, and then try saving the ID or username on whatever server you sent it to.
What I plan on doing requires me to insert their userId into a datastore once they first join ever. I’m not too worried about it failing, I’m just worried that the datastore may get too full or something. Idk how many people will end up playing my game, but I’d rather prepare for the best case scenario of a lot of players playing
They aren’t reliable at saving tables since it can become corrupted. They are fine with any other value type as long as you save correctly before the player leaves.
The only issue with a datastore is that they’re really slow to query, though it sure is the better option in this case, since users can delete badges.
Only choose doing a badge if you are worried about data deletion requests.
Also, there isn’t a DataStore limit you will realistically reach if you’re trying to save playerIDs. You can store an almost unlimited amount of keys in ROBLOX datastores as long as each key is 50 characters long or less.
This means that, in order to reach the DataStore limit, you’d have to store the PlayerIds of ten quindecillion different accounts, which is more than 1,0000000000,0000000000,0000000000,0000000000 times the total amount of people on earth right now.
So, I think it’s safe to say that you have probably have nothing to worry about.
Won’t Roblox additionally allocate you more storage if you were to have a larger player count?
Additionally, the datastore limit is 4MB, but it really isn’t big enough for my need of 1GB with my AI trainer.
It isn’t actually the best. The server might be shut down during gameplay or the player might unexpectedly disconnect. An autosave feature should be working every 5 minutes for certain uses.
To answer OP’s question, I think a datastore would be the best option.
Check this out! Player | Roblox Creator Documentation You actually are able to check when a player leaves the game, similar to when they join with game.Players.PlayerAdded etc
How about instead of saving all users to a single key, save multiple users to their own key? Then you can use DataStore:ListKeysAsync to get a random item from it?
Well, you did say a random player. Not a random player from a pool of every player that has ever played your game. Something that keep a rather small list wouldn’t take much and even if it was lost could replace itself quickly. Could even refresh itself once in a while when players are on and the outcome would be the same to you.