I’ve been programming off and on for a couple of years now but I’ve never understood the uses of local scripts versus server scripts. I understand that local scripts only run on the client where server scripts run on the server, but when should I use local scripts with RemoteEvents/RemoteFunctions rather than server scripts? If I can do everything I need via a server script should I skip local scripts to prevent exploiters? I know how to use RemoteEvents/RemoteFunctions, just not when to use them.
5 Likes
You can’t do everything on the server–and you shouldn’t. Specific properties can only be read from the client, and you should always – or at least almost always – do things such GUI interaction on the client.
A lot of things such as streaming your game map from the client, creating UI effects, etc. can also be less network intensive and result in a much better player experience,.
2 Likes
Well, Local script are scripts that only the player can see. For example lets say you created a script that creates a part. Only the player can see the part while all the players can’t see the part. Server scripts are so all the players can see the part.
3 Likes
I know some properties can only be read from the client, but what if I don’t need anything from the client? Should I just use server scripts? If I don’t need to use anything like input service via client, shouldn’t server scripts work fine? And thanks for the extra advice with GUIs and UI effects!
1 Like
I understand that local scripts only run on the client where server scripts run on the server, but when should I use local scripts with RemoteEvents/RemoteFunctions rather than server scripts?
I’m aware of what server scripts do. I just don’t know what to do locally rather than server sided.
You should use local scripts when you need local scripts.
You should use server scripts (also called scripts) when you need server scripts.
There is nothing more to it. If you have no reason to animate some functionality on the client–then don’t do it. If you do–then do it.
Don’t waste your time fretting over what type of script something should be just because you could use both in the situation. Use what is easiest.
So the main game runs on the server, and all players are connected to it through their own client.
Each client runs on their home computer, with their mouse and keyboard (or mobile touchscreen, etc). So if you want to know if a player is pressing a key on the keyboard, or clicking a button, you will have to detect it on the client in a localscript.
Similarly, if you are steering a car using the keyboard, you could send a message to the server: the messages about which buttons you press would take a while (latency) to travel to the server, change the steering of the car, and for the result to travel back to the client so they can see it on their screen.
Therefore, you could consider making the steering of the car local. That way the controls are smooth. But now the changes in steering won’t propagate to the server, and other players won’t be able to see it. Everything has upsides and downsides, and ways in-between.
So you want smooth responsiveness sometimes, and the keyboard and screen are on the client. That’s reasons to do something in a localscript. On the other hand, people may be able to cheat on their client, by opening the game’s software running on their computer, or pretending to be the client by using another program.
That’s why you can do things like keeping score on the server. That way, you are sure people cannot just give themselves points. Only the server can communicate with datastores, HTTPservice, marketplace, etc. So there are a lot of reasons for doing things on the server as well.
Generally there is some optimal solution for each problem. Generally visuals, animations, etc, even ones using physics, are best offloaded to the client. It would take a lot of streaming bandwidth and slow down your server. Game mechanics are best handled on the server, for security. Control of physics such as a car usually has to find a way in-between, balancing security and responsiveness.
Hope this gives you a better idea of why the separation is made. Many parts of the library are only available in either local scripts or server scripts. But there is always a reason/philosophy behind it.
Best of luck!
7 Likes
This was an issue I faced when I first started off scripting, and I always found it difficult to explain what I meant by “I didn’t know when to use server and local scripts.”
What helped me was always thinking about what can be exploited. So obviously as you already know, local scripts all happen on the client, and things that you want to be replicated (serverscripts) should be done on the server. If you code something on the client, always think about how it can be abused, “NEVER give the client power,” is a phrase you’ll hear a lot from developers. You used to be able to code everything through a script, and it’d automatically replicate but you aren’t able to do that anymore because it was abused.
A common example is the use of RemoteEvents. If you want to get when a player activates a tool through the built-in Tool.Activated event, fire a remote once its activated Remote:FireServer().
Then with a serverscript you will name the fired remote with .OnServerEvent and connect it to a function.
"Remote.OnServerEvent:Connect(function()"
Since most remotes are replicated, they can be viewed by everyone and fired even if the tool is never activated/clicked in. Typically with Tool.Activated cases, its never an issue with the use of debounces, but developers will put in checks to counter-act simple exploits like that.
Right now I’d recommend just practicing with tools as they’re very easy to grasp server and local script uses. To get started; try making the server print anything you want when you activate a tool.
Continue learning!
3 Likes
“NEVER give the client power,”
This is a great way to think about it. What I’ve gathered from the very helpful responses I’ve gotten is that clients shouldn’t have power over anything other than the client itself. Thank you so much I’ll get to work on experimenting with remote events!
2 Likes
Thanks for the response! I still have a lot to learn but this helps a lot!
2 Likes