How Does Cheating Work When Modifying Values In This Circumstance

Good day everyone, trying to understand cheating better to write better replicated code. I was trying to avoid having to much code running on Server, but I think In my circumstance I made it easily viable to cheating. Based on the photos, where would cheating take place?

  1. Can someone just change the output values of the break replicated structure even though its replicated?
  2. Can someone change the value of the input for the RemoveIDFromArray interface message?
  3. Can the value be changed for the input of the ServerPrintValues on the first line of Blueprintcode?
  4. I am guessing that they can at least change the output values of the EventRemoveIDFromArray, correct?

Hi,

I cannot point out the exact spot where cheating could occur, but basically if the client can call that change value function then cheating is possible.

It is almost impossible to prevent all cheating, but the general idea is to never trust the client (player). For example if a client says they want to heal, the server should check is the client on cooldown and any other checks before healing the client.

This isn’t fully related, but as we are talking about replication I have to mention the network compendium, which is a great resource to learn about replication.

1 Like

The server should control relevant gameplay actions/events.

I want to pick up/drop something… client sends a request to the server to do so.
I want to heal… client sends a request to the server to do so.

Server request! Server validates the request and scrutinizes the action. Can I do X,Y,Z? If so, do it.

Modern cheats can modify game memory directly (read/write). For the cheat to work as intended all they need is for the developer to allow the client to apply game relevant changes.

Change Value should pipe directly to Server Remove Item.

Server should attempt to make the change, then RPC back (owning client) the results if any. Then client updates itself with server data.

Ok, I thought I watched a tutorial that showed a replicated bool value set on the server. Then later when the player pressed “P” for example, the replicated bool value was sent to a branch without passing through a Server event at all to check if it was valid. Then it called a server event for the action they wanted. But you’re saying a branch check should be called on the server as well in this case?

The best way I can explain it is like this:

The client cannot be trusted, as the user can use some software to edit their memory. However the server can always be trusted, so whenever something critical like for example damage is dealt the client should only be able to “ask” the server if that damage can be dealt. Now you can do the damage on the client pre-emptively and show some hit indicators, but the server should only replicate that damage out if it deems that the damage can actually be dealt.

For your question there isn’t an answer that is always correct as when trying to prevent cheating you must think about everything on a case by case basis. This is why it very difficult to make a game where cheating is not easily possible. For example if this bool was “ready” then the player should be able to set that themselves as only they know if they are ready to start, but if this bool is “is on ground” then the server should be in charge of that variable.

The server should do validation on ALL game play relevant events and actions.

You should have an interaction system implemented in your game if you intend for the player to “interact” with the game world. e.g. open/close doors, pick up items etc.

So when the player wants to interact with a door/item the interaction system attempts locally. If successful it executes an rpc which tells the server to interact. If successful on the server, the result of interaction is executed. e.g. door opens, or item is picked up.

Here’s a tutorial series I produced to create an interaction system and networked doors. It should be enough to put you on the right path and how to think about multiplayer event structuring.

1 Like