Should I reduce dependence on local scripts?

Help and Feedback Scripting Support
#1

I’ve been making good progress on my first game so far.
I have been using a local script for anything that remotely involves GUIs. While this has allowed me to use a single script to code entire physical sections of the game, it brings up some concerns.

Fore example, I connect a function to a Touched event for a block. I then proceed to code the GUI stuff, which involves teleporting the player across the map when they press the confirm button. Fast forward to when they touch another block, the script teleports them back and then gives them exp for whatever they did.

My problem is, I feel like using one local script located in Starter GUI for this entire process leaves the game vulnerable to exploiters messing with the client. I have no knowledge about how exploiting works, or what I can do against it, but it feels insecure, even if it is efficient.

So, should I add in server scripts and remote events where possible, such as with the Touched events? Or is my way of coding with local scripts secure enough?

#2

Having this logic in the client does not make your game more vulnerable as an exploiter can just do that anyway. If you’re concerned about teleport or speed hacking, you should add sanity checks on the server.

Edit: you should not be able give out exp on the client, instead you should have some event on the server

2 Likes
#3

Sorry for the late response, but are sanity checks like validation checks, or are they something different?

#4

Something like having a

while wait(1) do
  --check if they moved more than the normal walkspeed could in that time
end
#5

So what would I do if the check detects something dodgy?

#6

That choice is up to you, you can either teleport them back, or kick them.

You could also have it keep track of how many times it happens, and if it happens 3 or more, kick them otherwise jut teleport back. Or if you know that it’s impossible to move that far, or you don’t teleport in your game you could just kick right away.

1 Like
#7

You’re pretty much spot on.
A “sanity check” will eliminate any “insane values” that a client passes to any event.

Scenario 1:

Say you have a system where players can click on coins to claim them. The player sends the coin they want to claim through a RemoteEvent so you can have the server verify their request.

An “insane value” would be;

  • A coin that is way too far away from the player
  • Them possibly passing nil
  • Them passing a table of some sort to mimic an instance ({Position = Vector3.new(x, y, z)} and similar)

On the server, you would check the “sanity” of these values.

  • Does the “coin” exist?
  • Is the “coin” parameter an Instance?
  • Is the “coin” close enough to the player?

You always have to assume the client has sent some kind of tampered data, and whatnot.

As for the original post, exploiters can mess with the client even if you have multiple scripts or just one. Just remember to have sanity checks if you plan to migrate some features to RemoteEvents, and don’t let the client control the server.

2 Likes
#8

Another example is vehicles. In order to have smooth, performant physics and responsive controls the vehicle’s physics must be handled on the client via network ownership. This is where you need to check for unexpected behaviour and respond appropriately. For example, if there is extreme change in position you could teleport the client back to their last recorded position. Or if the player is too high from the ground for too long they could be teleported to the ground. Fixes unexpected physics glitches as well. There will always be false positives so you should not kick players.

1 Like