I’m stuck on a dilemma that keeps slowing me down…
I’m working on a way to replicate a player’s data to them. The data contains their game settings and their purchased items. The data can be altered and read by anything on the server, and read + requested for change by the player (e.g purchasing a new weapon or changing a setting).
Now, I have 2 methods for that in mind:
Automatic Instance Replication
I can set attributes on instances and have them automatically replicated to the player. Pros: No need to make a custom system, accessible in studio. Cons: Waste of resources by replicating the data to every single player, no solid type checking (having to use :WaitForChild()/:FindFirstChild()).
Custom Module Replication
I can make server + client modules that pass data to each other via remote events/functions. Pros: Supports type checking, doesn’t replicate to other players. Cons: Requires more synchronization, less accessible in studio.
I’m leaning more towards the module method because type checking feels safer. I’m really against using abstract instance functions to find their children, it just doesn’t guarantee a bug-free system. I know I’m probably overthinking, but I just want to be safe and go with a long-term plan.
What option would you go with, if any at all?
Thanks for reading
In my experience using Instances and attributes for replication has been a huge help when making complicated data structures, as it allowed me to use the GetAttributeChangedSignals which helps a lot, whereas with module idk where you would begin to setup all those custom signals
Other than that and it being a little easier to debug seem to be the only real benefits to using it over modules.
I also know that manually changing the values in attributes is really annoying, especially when doing math. So I would also just like use a table on the server side, then anytime you need to replicate the data make some code that goes through the table and make all the instances with the correct attributes, then on the client make it so you can translate the instances back to a table.
Idk if thats a good way to go about it, but its worked really well for imo.
With a module or any form of script would allow you to store the data that way you dont have to send a request to the server for said information every time you need it. Using a module allows you to have a central location to store data, and handle anything regarding it that you might need to do for replication.
You wouldnt have to use a module if only one script needs this data, but depending on how your game is structured you might need other modules to have access to it, or other scripts, therefore it would probably be better to just store it in one place.
Use some sort of server → client communication via Scripts for data replication. Attributes can be used for some player data, sure, but they do not allow the same flexibility and control. Being able to choose when/what data is replicated, especially when the data gets updated, is far better than using attributes. Inventories are typically stored like so:
local Data = {
Inventory = {"Item1", "Item2"} -- Obviously can be even more complex, depending on the gamae
}
– which would be a nightmare to deal with using attributes as the inventory expands.
I actually have a module for this exact reason, it combines both of best worlds
you can watch my video to understand the basics, but the actual system itself is alot more than just what the video shows, but its a god save for replicating data without the hassel of worrying about setting attributes manually
