Are local scripts a good way to optimize your game?

I have always been a scripter that tends to be poor at optimizing my scripts when it comes to what should be local and what should be on a server script, I tend to do everything on the server I don’t know how much that effects lag.

Do local scripts help a lot with lag? Or does it not really make a difference? If they do help a lot with lag, what types of things should I put into local scripts and what type things should I avoid putting on local scripts?

4 Likes

Local Scripts should be used to only handle instances the server should not need or do not have access to handle. (For Example, Gui Functioning or RunService) In a way, it is essential to have LocalScripts in a game.

LocalScripts can be used to help focus something on the client, instead on putting the workload on the server. So in a way, yeah, LocalScripts are pretty useful to help make code run smoother and more effectively.

5 Likes

There’s a good question here, one where most people will probably respond to the title.

Using a LocalScript doesn’t automatically make something more optimized - of course not, but performing computation client-side instead of offloading it to the server can be beneficial when possible. This can make a big difference!

If you’re doing everything on the server it’s likely you have a separate problem in that you’re not giving clients immediate visual feedback, which is very important for most effects.

Alternatively, are you talking about network latency in your original post, or do you mean a computational performance problem?

3 Likes

Local scripts run entirely client-side. Server scripts, aka “scripts”, run entirely server-side. Server scripts should be used to manage the state of the game and all the players. The server is one single machine that controls what happens for everyone. Anything the client does that other clients may see must be validated server-side, as it’s the only machine you can actually trust. There is no performance to be gained from switching over to local scripts. Anything that the client visually sees, aside from objects in workspace, should be controlled via local script. Anything the client should not be able to modify without requesting modification from the server should be run via server script.

To add on to what @Avigant said, computing on the client rather than offloading all the work to the server will definitely improve server performance. Most clients’ machines are more than powerful enough to perform their own computation, but if we just offload it to the server, the server then needs to compute for itself and every other client. Essentially, if we have 10 players in the game, the server would be using more than 10x the resources a single client’s machine would be using if it computed a result on its own, as the server would need to compute 10 different results based on data from 10 different clients.

For more information on the client/server model, see here.

8 Likes

I was sort of referring mostly to latency issues.

Yeah, switching over to local scripts will definitely remove any and all latency where it’s actually needed. Anything the server doesn’t need to validate, that only that specific client can see, should be controlled on that client to allow for instant feedback.

1 Like

What sort of latency are you dealing with? Localscripts certainly help prevent latency but the topic changes entirely based on use-case.

1 Like

I’m not sure what you mean by “sort of latency”.

Where do you see noticeable latency…or maybe this question more broad game design?

It was more a broad game design question, I’m working on a new game and was wondering how I should go about doing that.

It’s key to do almost everything visual immediately on the client. When they click to fire a gun, fire it immediately client-side before waiting on the server. The server can, for example, do its own raycasting purely for hit detection, and tell all other clients that the gun was fired, so that every other client can draw their own effects.

1 Like