How would you make a *secure* hunger/thirst system?

I have seen posts and videos to see what people were doing but I noticed nobody was actually making it secure, for example the handling of increasing and decreasing wasn’t serversided, most of them were only local scripts that used a value in the character and relied on what its current value was, etc.

Here’s how I thought about handling the system so far:

A server script assigns each player that joins a hunger value. Each player also has a local script in StarterCharacterScripts, that fires a remote event every ex amount of time.

The server script listens for that remote event and grabs the hunger value that specific player was assigned and lowers it by ex amount, then fires the value back at their local script, the local script takes that value and adjusts its internal value to scale the hunger GUI accordingly.

The local script would also handle telling the server whether it has to increase or decrease the values of hunger as an argument likely, so I would need to make sure the player couldn’t exploit that through the remote event or script somehow?

I made this post to ask if this system has any flaws or oversights, also, I am curious if we could use a datastore like profileservice to save the hunger values, maybe instead of assigning the values to the player as they join, instead just grab their values from profile service, adjust them when needed and send the local script the new value?

This is going to be my second attempt at creating a system like this too so I am not too familiar with the stuff related to this, I just learnt profileservice like 4 days ago as well.

This is too much event handling. When the player joins, a value should be assigned to them, which will be the hunger value. The value will slowly decrease using a while loop. On the client, it should check when that value updates and will update the label. There was no need for events.

The more the client handles in the game, the more it is controlled by the player instead of the server which will not let the server and client cooperate very well

1 Like

I’d use attributes that are controlled by the server. Client can listen to attributes and update UI. Client makes action requests to server, such as “eat” which the server does the logic, maybe sends events to the client about actions being taken, but the server also updates the attributes that the client is listening to changes to.

1 Like

So the only event that would be firing is from the server → the client, and nothing from the client to the server? if that’s the case, how would the client tell the server that it’s say doing an action that should increase hunger without an event? or would I use an event for that?

Yeah, you’d use the event to communicate from the client it’s requests, but the server processes all logic, and sends updates on events that take place.

1 Like

I’ll look into attributes later and see if that will work.

Attributes are great for arbitrary state like this. You can have the server set the state easily, and have the client listen for changes.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.