Organization

[surreal ledge]

Does game assets go in replicated storage or server storage? For example models, reusable module code.

[radiant heron]

It depends on the type of asset.

If the client needs access to something, like shared code or effects, put it in ReplicatedStorage

If the client doesn't need access, like a datastore module, put it in ServerStorage

[surreal ledge]

Wdym by the client needing access

[radiant heron]

If the client needs to use it. Like if you have a module thats required from both the client and the server, the client needs it and the server needs it

[tiny ginkgo]

serverstorage can only be accessed using serverscripts, and replicatefstorage can be accessed by both server and client

during a roblix studio playtest you may have noticed that in explorer you can see childs of replicatedstorage but not serverstorage

[surreal ledge]

cant I just put everything in replicated storage then?

[radiant heron]

Yes, technically you can

I would avoid putting things that the client won't ever need to access, like if you use ProfileStore, theres no need for the client to load that entire large module when it won't ever require it

[tiny ginkgo]

(recommended to check) i think that since client scripts have access, exploiters have access too (since exploits are scripts ran on a client) so if you have core gameplay or just stuff that you don't want to risk, such as player values, put it on serverstorage, as it is safe against exploiters

[surreal ledge]

true. For like a rng/gacha system would it be in replicated storage? cause isnt it dangerous and exploiters can just exploit client side? for the spins?

(im thinking of an rng module script in replicated)

[radiant heron]

An exploiter has 100% control over everything that happens on the client

If you put code (ex, rng module) in replicated storage, that code will be sent to the client when they join, and they will have access to that code if any local scripts need to require it. Since the module is on the client, the exploiter can also change the contents however they want (but only the version that exists on their client, not the original version on the server!)

It would be perfectly safe to require a module thats in replicated storage from a server script because the module that gets required is the copy that the server owns and that couldn't have been modified by the client.

[radiant heron]

You don't want the client to be doing rng gatcha logic because the client could pick whatever result they wanted. You'd want to handle that logic on the server, were the server does the random decision

[surreal ledge]

true. then can local scripts even have anything? since exploiters can just manipulate it.

[radiant heron]

Yes, a lot of stuff should still be done on the client. The primary reason is latency, if you handle something like UI on the server, every time the player clicks a button, they have to wait for the server to respond which can sometimes be a very annoying and noticeable delay. Plus, an exploiter exploiting ui interactions (usually) gives them no advantage anyway.

Player characters are owned by the client, meaning exploiters change their speed, fly, and teleport very easily. Moving the character to the server however is not a good idea, since the input latency would make playing the game suck*.
-# *There are ways to simulate the character on the server, ex a server authoritative character with client prediction and rollback. Roblox is implementing something like this in the future, you can implement it yourself but its advanced and can be difficult.

So some things, even if they are exploitable, should be handled on the client because its the best of two bad options.

In the example of characters, there are ways to mitigate the problem while keeping the character owned by the client.
For example, on the server, checking if the character moves further than it should be able to over a duration of time. If the server detects that, it teleports the character back. If you've ever experienced "rubber banding" in a game, thats often why

[surreal ledge]

so js lots of character stuff should be client sided with sanity checks

[tiny ginkgo]

if the client doesn't need to access to something, then prevent it from accessing it, best tip i have to tell about that.

an example if for a game that has multiple maps for a round system. serverstorage is the best place for that as exploiters don't have any control over it.

[radiant heron]

I think this is slightly inaccurate, placing the maps in replicated storage wouldn't give exploiters any control over it per say (like, they could change stuff, but it wouldn't change for anybody else) but it would increase load times and allow exploiters to instantly steal all your maps without having to wait for each round to load

[radiant heron]

Character stuff is one example, there are a lot of things. Visual & sound effects, shooting*, etc
-# *this can be complicated and done in a lot of ways, but generally do it on the client and then have the server verify the results itself

[tiny ginkgo]

mayne my example was abit weird, but that just prevents them from simoly breaking the game yk

[surreal ledge]

i see like other games they usually put vfx and animations in replicated. wouldnt exploiters exploit that

[tiny ginkgo]

i think that since its only visual and only their client is affected, putting this in serverstorage wouldnt change a lot

[surreal ledge]

oh im kinda of confused on that part. When is a vfx serversided so that everyone sees the same thing and when is it client side only one person sees the change. like How do I implement one or the other? idk how it works