I made a fake health system that doesn’t use the default humanoid health unless its for killing the player. I’ve been reading about game security on the forum, and how I shouldn’t trust the client for important stuff, like handling in-game purchases.
Currently, the health system is handled all by the client. Updating the gui, initializing the health value, and regenerating it. What parts of this system should stay in the client? What should be on the server? How can I use remotes effectively and safely?
the client, in my opinion, should only be trusted with handling the gui. If you allow the client to handle things like updating health, setting health, etc… Exploiters will be able to manipulate their health to be unbeatable in the game.
So the way that you want to think about things is let the client be a reasonable representation of the data of the server.
There are many times you can make safe assumptions in most cases that it will be right. For example if you want updates to health to not be effected by lag, you can track the same health effecting events on the server and the client, and when it happens on the client you can go ahead and deduct the health. And the server will reconisile it later
– A common trick is why games most the time use that whole “delayed” health bar where a portion drops and then a faded version slowly drops behind it.
_—> Basically this gives time for the server to certify the health and any discrepinsees on its next time to fire an event back it cna resolve those slight adjustments. This can help smooth out lag artifacting.
EASIEST ways to keep things simple
—> MAKE ALL YOUR LOGIC “Deterministic” !!!
Outside of Values, any event sending is order certified. So as long as the end result of whatever the player sees/server sees ect that teh same inputs result in the same result, you can safly make lots of assumptions that can better mask lag.
Remember there is no CURE for LAG. Just many many tricks to HIDE it. And you need to be careful how you hide it because you can accrue “Lag debt” if you don’t properly handle and resolve your hiding techniques properly.
Make a ReplicatedHealth folder or something of the like inside of ReplicatedStorage so that changes are replicated to the client.
When a player joins/leaves, create/delete their respective IntConstrainedValue.
Have the client listen to a .Changed event on their respective health value.
Whenever the server makes a change on their health value, they will be able to use all the relevant data returned from the .Changed event to tween their health bar, etc.
All meaningful changes are server-authoritative, while cosmetic/visual effects are managed by the client.
So, the server should handle most of the changes, while the client updates the gui to present those changes. There will be lag during communication, but it can be masked with some neat effects.
However, I have a question.
Since the RepStorage can be accessed from the client and the server, won’t that mean exploiters can see the scripts inside of it? Or am I missing something?
They can see the scripts that are stored inside of it, yes. However, if you have well-made game architecture, the scripts that are able to be seen won’t have a drastic impact on the game should they be compromised/leaked. Additionally, changes that the client makes to ReplicatedStorage won’t be replicated to the server and to other clients.