I’m working to upgrade my game to use the save system suggested by Berezaa a few months ago.
Quick rundown:
Save timestamps to an orderdatastore
Save data to a regular datastore with those timestamps as the key
Whenever you want to load data, get the most recent key from the orderdatastore and load that key+value from the regular datastore
My main concern is the fact that this would be created many multitudes more saved files for each player. If I’m auto-saving every 60 seconds, that means there would be a new key+value in each data store every 60 seconds with a large chunk of data. This does mean that data loss is essentially impossible, but I feel like this would be stressful on the Roblox servers. Is this practice looked down upon? If you use it, have you noticed any irregularities due to it?
Does every time you save create a new key, or do you save on a wider basis?
I was wondering if it would be better to only generate one new file per day as opposed to one new file every time the game saves. That would, of course, increase the possibility of data loss (although it would only be limited to a day of playtime).
Gotcha. I actually already read through DataStore2’s source code while working on my own variation. I would use your system, but I also like the experience of trying to do it myself
I wouldn’t say that they would take down your game because of this. However, in general, I would say that Roblox does look down on this practice due to just the sheer amount of data.
Now that I think about it, Roblox did add a RemoveAsync function a while back. I wonder if you could also set up a system to automatically remove older versions after they pass a certain amount in the OrderedDataStore. (ie: after 50 keys, the last key gets removed every time a new one gets added)
you surely could. I also use a bit other method of saving. Similiar, but other. Instead of timestamps i save play time so always the most progressful one are loaded (ensures than no older will be loaded).
I would get fired from my job if I tried to save data like this.
If you want to prevent data loss, you could just swap between two different keys. If one is corrupt, use the older one.
As a developer, it is your responsibility to manage the data appropriately. Exploiting the fact that there is no data limit is no excuse for treating DataStores as infinite backup data storage.
Being able to roll back saves isn’t the primary benefit from using the method. You’d just be limiting yourself to the extremely restrictive OrderedDataStore limits for it.
First off, you shouldn’t be auto-saving every 60 seconds. Saving when the player leaves, when the server shuts down (game.OnClose or bind to close), every ~3-5 minutes and whenever the player makes a robux purchase should be more than enough.
It’s also not stressful on the servers at all. It just costs Roblox extra money for the data storage, but the amount a single game saves is pretty much negligible in the grand scheme of things. Considering Roblox takes the vast majority of game income, this seems pretty fair to me.
Roblox doesn’t impose any limits on how much total data you can have saved, and I doubt they ever will because such a limit wouldn’t be very scalable.
I was only light-heartily joking when I said “Roblox hates me” for the way I save data. You shouldn’t run into any issues doing it like I do.
Additionally, consider keeping a per-player flag that gets set whenever an online player makes a change that requires a datastore update. There’s no point using disk space or datastore bandwidth to write multiple copies of unchanged data every 3-5 minutes. Especially if you’re going to keep only the last N saves, then it benefits you for them to be the last N unique datasets.
