I’m not too sure where to post this - I don’t have access to create a new topic in #discussion, and it’s definitely more scripting related than anything else.
While developing my game, I’ve noticed that I have a tendency to try an handle EVERYTHING from the server, including systems that I’ve been advised not to such as UI. I was wondering what your takes are on what is and isn’t good to leave to the client.
There is a collision brick that triggers a UI using a .Touched event. Normally, I’d use a RemoteEvent to fire to the client in order to handle UI controls. However, through some digging, I noticed an old forum topic in which someone mentioned that it’s entirely unnecessary, opting to handle everything client-side instead. In my head, this baffles me.
- Wouldn’t this make it easier for the client to spoof their position, allowing bad actors to access the shop from anywhere?
- How important is server performance in terms of this?
I have a shop, that utilizes ViewportFrames to display items available. My old method was to, on server initialization, clone the UI elements, then parent them to the player as they join the game. I used this approach initially due to wanting to use the same set of items for both the player’s inventory and the shop (removing the functionality of the ViewportFrame models), but from what I’ve been told this is again unnecessary and I should just handle this on the client as well.
My alternative approach to example 2 is to simply have non-functional items within ReplicatedStorage, with the actual “function” items in ServerStorage once they are purchased/acquired by the player. When the client loads in, the ViewportFrame would simply populate/clone from there instead of having a pre-generated shop cloned to the player.
Thanks for any advice!