Storing Data for Multiple Save Slots

Hello,

The title refers to having a save slot system for player data, where a player can have multiple different save slots.

Should I store all the slots under the same user ID index, or should I use different indexes for each slot (userId + slotId for example)? If either is preferable over the other please explain why, and if neither are preferable over the other, please also state that and why.

Image below to provide clarity.

dookie scripter here:

i would put the slots under the same user ID. my reason is just for the clean organization.

i’m interested in this question now too… hopefully some bigbrains come into the thread :flexed_biceps::brain:

1 Like

If the slots are going to be small in size, then you can store them under the same id, and it’ll work just fine. But if the slot size can reach a large size, then storing each slot under it’s own key will be preferable, as then each slot will have a maximum size of 4mb (instead of that limit being for every slot)

The second method isn’t all that hard to implement. You could save the slots in their own datastore, and the key can be a random GUID string. Then, in the user’s data, you can store the guids of the different slots the user has. When loading, the user’s data is loaded first, then the user selects the slot (metadata for the slots should also be stored alongside the key), then the selected slot is retreive from the datastore and loaded. How hard it is to implement could depend on the datastore system you are using, if it’s your own, or if it’s a library

Something like this

local UserData = {
  DataAboutTheUser = [SomeValue],
  
  Slots = {
    {
      Name = "Slot 1"
      Created = [Unix timestamp],
      LastPlayed = [Unix timestamp],
      Size = [Size of the slot in bytes],
      Key = [GUID],
    },
    {
      Name = "Slot 2"
      Created = [Unix timestamp],
      LastPlayed = [Unix timestamp],
      Size = [Size of the slot in bytes],
      Key = [GUID],
    }
  }
}

the second method could also give more granularity, ie, transferring slot data from one user to another only requires modification of the table of keys in the user’s data, a slot could be available to more than one user, … (but then, make sure two users don’t have the slot open at the same time). Though, are these benefits actually useful, probably not

3 Likes

Thank you for sharing, I will say this wasn’t how I saw my second method, but it seems to be leagues better than what I had in mind, incorporating the pros from the first method.

It could always come in handy. Maybe.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.