How Much Control SHOULD the Client Have?

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.

Example:
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?

Another Example:
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!

2 Likes

When it comes to what should be on the client, and what should be on the server, I personally try to keep the load off of the server as much as possible. Of course, I give exceptions for things like security, however when it comes to things like User Inteface, Tweens, and other antimations/effects, It’s usually good practice to handle it on the client to ensure that the server doesn’t lag.

Remember to utilize RemoteFunctions, RemoteEvents, and to never trust the client!

Helpful links:
https://developer.roblox.com/en-us/articles/Roblox-Client-Server-Model
https://developer.roblox.com/en-us/articles/Remote-Functions-and-Events

Hope this helped!

3 Likes

Thanks, I appreciate the advice! I definitely keep animations and tweens on the client side, but I’m a bit more picky around UI for some reason. I suppose having one client being laggy would be less game-breaking than having one server being laggy for player experience.

Yeah, specifically when it comes to UI, you should be handling the front end of the UI, like making things appear, tweening ,etc all on the client. However when doing things like checking if they have access to a team, or checking anything important, it should be handled on the server. This can be done with a RemoteFunction or RemoteEvent.