How exactly can players cheat when there is no dedicated server?

Please don’t understand this as someone asking how to cheat, I’m genuinely interested in learning more about it as a developer so I have a better grasp of the actual risk and can better protect against it (or at least can make a better decision when to use a dedicated server).

One thing I keep hearing over and over when it comes to Listening Server vs Dedicated Server is that the Listening server is not as secure, because a player controls the data and could cheat. But there is never an explanation given how exactly that would happen. Would someone have to decompile, modify and build the game? Or can it even be done kinda like reading the data that is being sent out and modify it there before passing it on the clients?

In both cases I kinda don’t see why exactly a dedicated server would stop a client from sending in bogus data. I’ve watched pretty much every tutorial about Netcode out there, and it only gets mentioned like ‘the server checks the validity of the connection’.

Would be awesome if someone could point me to some resources that go more in depth and are relevant to Netcode/Unity. I’m new to networking but somehow it’s very addictive :slight_smile:

Thank you

Listen server => this is usually called the “host”, meaning a server that also has a client playing the game locally in the same instance.

You are correct, a dedicated server is not an automatically secure solution. Even a game with a dedicated server can be easy to cheat on if certain actions are client-authoritative.

Authority means who decides which player actions are valid and allowed to synchronize the player’s state to other clients. You can program server and client side authority separately within the same app for any given action, such as movement, shooting, chatting, etc.

In case of movement and with server authority, the client would normally transmit his input action to the server such as “i wish to move forward with speed x” or even “I am holding down the move forward button”. The server then performs the action on behalf of the client and finds the player blocked by a wall half-way, then sends the client its new location. The client will be at the location the server tells it to be it. The client could theoretically cheat to move his player to some other place in the game, however this will not be synchronized with other clients and the cheating client cannot just backstab someone after clipping through walls.

This “rubberbanding” effect of a player moving but then returning back to a previous position can be observed when the latency to the server is very high. To make the game feel responsive, many player actions and almost always movement will be executed locally right away assuming that the server will allow the movement and correct the player’s local position if it goes out of sync with the server’s game state.

The client might still be able to see behind walls however, if only momentarily or by hacking the “reconcile” method that would normally put the player back to its server-side position. Some games actively fight this way of gaining an unfair advantage by purposefully disabling the rendering and position updates of all other clients the player would not be able to see based on visibility checks performed by the server. Now the player might still clip through walls, and might even turn rendering of obstructed enemies back on, but they would be at out-of-date positions - still an unfair advantage but one with much less usefulness.

Now if you move the authority for movement to the client, the client can do anything he wants to. He could write a script that teleports his player close to an enemy player, in his back, and backstab that player. Since the client has position authority, anything the client does is synchronized with all other clients. This makes it practically impossible to prevent cheating. Therefore, hosting or listen server or peer-to-peer networking is only recommendable for non-competitive games (coop) and games where you can trust each individual client (play with friends).

Still, even with a dedicated server, if anyone can host a dedicated server instance then the admin(s) of that server could still cheat and use their own server to troll or take advantage of any participating clients. The same goes for hosting a game, where the hosting client has an unfair advantage to begin with. Ping for his own actions is practically 0, and latency of other client’s actions is about 50% the latency any other client would experience because to get an action from client A to B it requires sending the action packet from A to the hosting client (host sees client A’s action performed at this instance in time) and from there to client B. Let’s say ping of A is 30 ms and of B is 70 ms then A’s action would run on the host after 30 ms while client B will see it happen only after 30+70 = 100ms latency.

Anyhow, I agree network programming is very addictive. I hope this helps you grasp the basics of cheating over a networked game. But don’t worry too much about it, before you get to a point where cheating players ruin your game it first needs to be published (99% of projects don’t get to that point) and attract so much attention that players are going through the trouble of trying to come up with cheats. By this point you should welcome it, because you have found success! :slight_smile:

2 Likes

Thanks a lot for that long reply! I see how much you like networking too :slight_smile:

About the last part of players not cheating, I’ve published about a dozen games and my experience was that if there is a way to cheat, players will do it. They weren’t even multiplayer games, but they had highscore lists and sadly that was enough for some people to figure out how to hack my games.