The most memory efficient and performant ways to store data for server that change and can easily be access by the Client

I’m working on a looter game and I want to store datas of my item somewhere so it can easily be access by client but also performant and memory efficient. Currently using folders and value instances inside RepStorage but I think it might not be memory efficient to store that way.

ModuleScripts and remotes is your best friend.

So I use modulescript and a server script to handle the changes in data and remote event for client to access that module?

ModuleScripts allow scripts to access it, perfect for storing data and accessing it somewhere else.

Remotes handles replication by sending and/or receiving data, not directly access the ModuleScript. It is both a one way and two way communication.

1 Like

I’m gonna ask an extra question. Is storing tables as strings in Stringvalue is better than storing it in a module script and do what you said?

Use ProfileService because it handles everything for you, you can also use attributes to access data on client. Say something like GetAttributeChangedSignal(“Cash”) which you can save to the profileStore.

ProfileService handles datas for cross-server data storing, I’m looking for store data in a server.

What do you mean? Like converting tables to a string and storing it with Json encoding/decoding? Don’t, as some things cannot serialize, you lose intellisense, and is much more expensive.

If you mean using Instances for data, albeit technically slower, it’s easier. It’s all up to your preference.

1 Like

Ok thank you for your replies.

You can use module scripts. Module scripts are better in everyway because:

This creates a lot of instances and could be bad performance wise.

This welcomes Object Oriented Programming, also know as OOP.

Some quick examples of what you can do:

–Module script:

local Data = {}
Data.__index

function Data.Create(Player)
    local self = setmetatable({}, Data)
    self.Items = {}
    self.Guns = {}
    
    Data[Player.Name.." Data Store"] = self
   --This up here sets the key to the players name and data store.
   --In your instance your data store would be: "vipkute0057 Data Sore"
    --this also creates the table and inserts your player data to the table called "Data" above

    return self
end)

--if you were to print "Data with  2 people in your game it would be:"

["YourUser Data Store"] >
Items = {}
Guns = {}
["OtherUser Data Store"]
Items = {}
Guns = {}
function Data:Load(DataStore)
    --should be easy to do if you know data stores and self is already defined
end)

function Data:Remove()
     setmetatable(self, nil)
     self = nil
end)

return Data

Forgot to mention, require and connect the functions with the proper events. for example when the player joins you want to connect Data.Create and Data.Load and when the player leaves you woud first save the data by accessing the key [“YourName Data Store”] then connect Data.Remove()

Reason i did Data[Player.Name.." Data Store"] = self was so you can refer to the object later without creating a new one

now in a server script combine all these functions and you can add extra like: add items, remove item, etc. And you can store whatever you want with table.insert.

if you dont know OOP you can easily do the same thing, OOP just makes it more organized and i would prefer you to use it if you dont know OOP


local Data = {}

function Data.Create(Player)
      local PlayerData = {}
      PlayerData.Items = {}
      PlayerData.Guns = {}

     Data[Player.Name.." Data Store"]
     return Data
end)

function Data.Load(Player)
      local PlayerData = Data[Player.Name.." Data Store"]

     --See how i didnt use "self?" because know your not using Meta Tables
     --And self isnt automatically defined now


    --Load data with data stores etc
end)

--More functions to your liking.

return Data

I always use this as it is very versatile and the limit is up to you. It has the same effect as instances without actually using them and it can be accessed by other scripts.

If you have any confusion let me know and ill resolve it

1 Like

It can seem a little confusing at first but when you require a module script it would be like this:

local Data = require(--location to where the module script is located

not this data is a table and with the functions i mentioned above it adds player tables like these:

to the table.

1 Like

Question, Ive always seen Json encoding/decoding used for data stores but why? Ive always used regular data stores and they worked fine. also what is intellise?

You don’t ever need to encode or decode to and from a DataStore - they automatically do that for you. It is just a waste of resources and running it through an external DataStore editor might not work as expected. I don’t know where the idea comes from where you NEED to do this, and some people even believe you cannot save tables to the DataStore.

Intellisense is just the autocompletion feature for Roblox. It is especially useful when it comes to creating custom modules.

Ohhh i get it its like the little side text. Are there any drawbacks to losing intellisense?

Intellisense allows for faster, more efficient code writing. You are not going to remember every single function or property.

It even tells you what type of values are to be expected, and on strict mode, script analysis will warn you beforehand that you are doing something wrong, catching value related bugs before you even finish your code.

Say you wanted to create a table with certain properties, you can do so by declaring your type and intellisense will help you with the autofill.

type Point = {x: number, y: number, z: number}

-- autocomplete will show you that you x, y, and z as if they were properties,
-- and on strict mode, it will tell you that y is invalid and z is missing.
local myPoint: Point = {x = 7, y = true}

You can learn a lot and improve your coding skills even more if you have time to read this website in it’s entireity: https://luau-lang.org/

2 Likes

Definitely will read it already took a little look at it. Thanks!

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