Which is better? Or are they equally good?
Caching data every time it changes, and then when a player leaves, just save everything in the cache (What I do right now)
Only get all the data at the time a player leaves and then save that
I’m considering doing the second one because I’m reworking my game structure with a framework, and I have to cache a lot of things a lot of different times a player’s data could potentially change, so the second would be easier than the first
Side question, but
is this really what caching is, I think everyone does that. A lot of people make it seem like some super hard thing, but if this is caching then it’s pretty easy to implement.
Also if this is caching I think caching isn’t good for real time cross server systems.
Now to answer your question:
Actually I think both of your ideas have cons. Saving one time can lead to data loss, such as SetAsync failing at player leaving. For your second idea one you’ll hit the datastore limit super quickly.
Instead, pedoritic auto saving either a constant like every 3 minutes or after every game roud (for minigames) is a much better way.
BUT IMMEDIATELY PERFORM A DATASTORE SAVE WHEN A PAID PRODUCT IS PURCHASED.
This isn’t what I meant by caching. I meant caching with tables inside of scripts, (so that the DataStores wont throttle), and then saving whatever’s in the cache when a player leaves. Both options are only one datastore save, just that what they’re saving is different
By caching do you mean storing data in a table and whenever a purchase ect is made the stats inside the table are updated, and when the player leaves the table is set to the datastore. For example sword is purchased with cash subtract the cash inside the playerdata table.
Isn’t that what I meant though, i’m confused how the second option would work though.
Yes, whenever anything is changed like money or inventory the change is sent to a script to be cached. Each player has their own cache. So basically, when they leave, whatever’s in that cache is saved and then cleared, which should be the latest things. But, I’m starting to hate this cause I have to create so many bindables.
The second option is literally just normal data saving, like how you would see in tutorials on YouTube where they just save values only on PlayerRemoving
Are you discussing something similar to the code provided on the developer wiki here? Have a look.
No. I don’t need a tutorial on how to save, I’m just asking which one is better to practice
I know. I’m asking if what you mean by “caching” is similar to the code in that tutorial, as the responders seem to have mixed definitions on what you’re describing.
To answer your question, I would prefer caching (if it’s what you mean by whats on that developer page.)
I don’t why you need so many bindables just save all the data in a module all scripts will share one reference of the table returned from a module.
This allows any script to access/change the data inside the module.
Yes, actually. But I have a main cache and a backup cache
Yeah, I realized that, which is why I’m rewriting my game and making a framework
Isn’t this similar to the cache since your storing all your data in a table? And only setting the datastore once the player leaves. If not could you explain more how this would work?
PlayerRemoving fires right before the player leaves the game and has the player as the parameter, so you still have access to the player object when you connect functions to it. Say you were using values for data inside of the player. When the player leaves, since you still have access to their player object, you can save the values inside of the player since you still have access to them.
Honestly that seems similar to caching to me except this time your using value objects which handle replication for you. Caching doesn’t only have to be implemented using tables, storing object values could also be considered like that since you can consider them as indexes of a table and in object terms it would be called ‘Folder’.
Player.DataFolder.Coins.Value+=1
I would considering this caching if you only saved it once in the datastore when the player left.
However I do see one problem with value objects, you have to first convert them into a table to savable by roblox datastores.
We’re storing this data where we have quick acess to. getting the value object isn’t really that expensive such as an API call, so I would consider this caching because it is quick access data.
Most likely tables would be more efficient though, however value objects would be better for data replication.
Yeah. The values were just an example, I don’t use them. Tables are way better