Best way to store models (skins) ? ReplicatedStorage VS Roblox Servers

[Keile54]

Hey, I’m currently developping a game where players will unlock a lot of collectibles to wear (skins, pets, animations, etc.).

At first, I was storing all the models inside of ReplicatedStorage, and making a clone of the model inside the character once the skin was “equipped”. However, I found that uploading the models to roblox, and retrieving them from their IDs, was way more practical (especially to retrieve the equipped models when the players will switch places). But now I’m wondering if it really is a better way from the game’s performances POV.

So, what are the pros/cons of each methods ? Is there a clearly superior method for performances ?

Thanks

[samlovesmath]

i agree, it might actually be a bit more beneficial to you to use ReplicatedStorage. here’s a list of pros and cons ive gotten from using both methods over time, BUT there’s one cool thing i found at the end:

ReplicatedStorage

Pros:

1. ReplicatedStorage is great for essentials for loading. it duplicates everything inside to both the server and the client, usually at start-up.

2. any changes you make to objects loaded in replicated storage are client-side only.
   for example, if you want to load up a unique color for each player, the server can replicate the base code to the client. then, the client’s code can change that color in the replicated storage just for their end. any :Clone()s from the replicated storage will then be that client’s custom color. good for customization in themes and such.

3. because ReplicatedStorage is basically client/server clones, it works well with modules that want to communicate between the two and/or do the same thing no matter if in client/server.

Cons:

1. you can’t dictate the order things load in ReplicatedStorage. that means while some things may load, other things you want to load first instead won’t finish for a bit. (ex. meshes, images… those take more time)

2. you can’t load certain scripts (ex. local) straight away with this way. youll have to look for them and clone them to somewhere else for it to work, since it’s just “storage”, literally. module scripts work there because theyre just a storage of code to be copied to other scripts.

Load by ID / List with IDs

Pros:

1. perfect for on-demand requests. any ids called and used within meshes, objects, etc. will make the client immediately request to load it. since only one object is requested by roblox this way, it means its obviously faster than waiting for the queue of all assets in ReplicatedStorage. this also means you can load it even after client join.

2. useful for non-included asset requests. this also means that any content your game has no connection with / no reference of (ex. custom images found on the creator marketplace for spray paints) will be downloaded to the client/server as needed.

Cons:

1. if not everything is loaded at the start, it may make the game seem “unpolished”. if a player wants to look at a very complex model, the game has to wait quite a bit to be able to download it in that moment before the player can see it. with models, it gives this clunky loading look, where you have the grey, low-quality meshes grow into the final product. for images, this means theres a delay where the image isn’t there yet but pops in shortly after.
   sometimes this may be necessary, though, if you have many of these models and storing them would be too memory-heavy. roblox relies on memory since it’s an online game. but light assets should load almost instantly on good internet!

2. trying to store a list of IDs for these kinds of things may be troublesome. i’ve had quite some frustrating moments with roblox and the marketplace, especially when trying to upload models or update them. spoiler alert: at the time that i was using roblox a lot, you couldn’t update or delete images/meshes!! and i still can’t figure out how to do that (can you even? probably not!). that means you’ll have a long list of number-jumbled ids to keep track of, and if you want an updated version, good luck figuring which id replaces the new one.

3. loading things in the middle of a game may cause a performance issue, if it’s too many objects–probably a bit more frustrating than waiting at the beginning. i’d imagine it would be frustrating to suddenly lag in the middle of a shooter game if roblox is trying to use my internet to download another asset!

now, i recently got back into roblox coding for the first time in a while, and lemme tell ya, i stumbled upon something GODLY as i was trying to figure this kind of stuff out. you might already know about it, or you might not, but this made things 100% easier as i was deciding against ReplicatedStorage and IDs:

PACKAGE LINKS !!

(apparently roblox still considers this new? but its been out for several months now!)

package links allow you to export your groups models out to roblox the same as usual, BUT it comes with a good twist. each linked Model object comes with a PackageLink child. what does this link do? it allows you to:

1. upload the package to groups as IDs (idk if it can for personal inventory, but i have a private/personal group i use for my games for close friends/family!)

2. UPDATE THE MODEL TO THE SAME ID!!! (head exploding pow pow)

3. it has an important “link” part… where you can have ALL COPIES of the same linked model UPDATE TOGETHER!!! (explosion pow pow boom booooom)

the only downside was making sure all of the models would automatically update by going to the PackageLink and making sure AutoUpdate was enabled… but most of the important commands are easily embedded into the right click menu of the PackageLink!!

i was so overjoyed when i figured it out because i was feeling doomed at the start having to go and reupload copy after copy of model fixes (because i have trouble getting things imported into roblox right…). one of the few amazing features added from roblox. whichever developers made it, youre amazing.

so this means you can use package links for BOTH Replicated Storage and IDs, easily. it takes away the con in IDs about needing to have a long list of everything, and replacing it for each version. you can just have one long list without worrying about changing it, or put it in replicated storage (or another storage) but also have access to the ID, since it’s a property in PackageLink. (perhaps you can keep it server-storage only, and then fire a request to the server to return the id? ;D)

Conclusion

ive learned over time that its best to keep the required assets under ReplicatedStorage, and then ID the rest if you want your experience to load quickly. if your game needs to load everything at the start, though (ex. everyone already has a bunch of pets out in the game–what already exists from server to server is different), then you mine as well put everything in replicated storage, and perhaps create a script alongside replicated storage that shows the player that things are loading (loading screen!).

most games do it that way, and i think its less frustrating to have all of the big things loaded first instead of having to wait minuscule moments for everything else to load. though, i do think it’ll make debugging a little more challenging! can’t tell you how many times i have to click the play button to make sure something worked, hehe!

good luck with your game!

[GE_0E]

using replicated storage will make it faster to load models but will increase the clients memory
roblox servers will make it slower to load models while making the client memory low

if your skins need big storage(alot of memory) then use roblox servers
if your skins need low storage(low memory) then just use replicated storage for faster loading