I have created a data save library for a game I have been working on. The goal of the library is to be developer-friendly while also providing a powerful player save framework. You can see it here as a free developer item
It functions by using a DataModel stored in ServerStorage. Within the DataModel folder, Player save data can be structured, like so:
This setup (assuming DMOP is in ServerScriptService, and Kills is an IntValue) is all a developer would need to do to setup leaderboard stat persistence.
Data is saved using the DataStoreService in a DataStore called PlayerData.
Any Value object who’s property can be saved with DataStore is supported. Folders are considered to be tables by default, and the name of items is their key in the table.
DMOP also comes with advanced functionality, such as declaring indexed arrays:
This structure declares that PlayerData[PlayerTags] is an array, and items in that array get their value from the folder name in PlayerTags
DMOP supports keyed arrays as well, which are very similar but also have exclusive functionality:
This structure declares that PlayerData[PlayerTags] is an array, and items in that array get their key from the folder name in PlayerTags. In the example pictured above, the value of these items in memory is an empty table (which is the exclusive functionality)
This is where the power of DMOP starts to shine, if you use a Keyed Array, you can further define the structure of the keyed array:
This structure declares that PlayerData[PlayerItems] is a keyed array. I have specified that items in that array have an indexed table called ItemTags, as well as an integer value called Count.
After specifying this, data can be added to a Player[PlayerItems] instance following the structure, and it will be saved when they leave or the server shuts down. The Interface:TableToModel() function can be used to instantiate keyed Instances using Lua tables following the structure you have specified:
local model = DataModel.PlayerItems.key -- the structure to follow
Interface:TableToModel(params, model, id).Parent = plr.PlayerItems
here, params is the lua table used for instancing, and id is the id to give the keyed table item you are instancing.
Let me know your thoughts or if you have questions! Don’t be afraid to tell me that this is just bad either.
Example using the most recent structure pictured
Player first joins
Instancing script:
local model = game:GetService("ServerStorage").DataModel.PlayerItems.key
local params = {
Count = 1,
ItemTags = {
"Heavy",
"Sturdy"
}
}
Interface:TableToModel(params, model, "Rock").Parent = plr.PlayerItems
Player after instancing
This is just a one-item example, but you can have as many of these items with unique IDs as you want. The only data saved will be data that follows the structure you have defined