3 ms·

Imagine a multi-player first person shooter game. There are complaints that some players are cheating to win matches. Many of these complaints include a common

Imagine a multi-player first person shooter game. There are complaints that some players are cheating to win matches. Many of these complaints include a common description in the experience: the alleged cheaters seem to "know" where the other players are, even when not within direct line of sight. In this hypothetical game, there is a feature where, in specific circumstance, one player can in fact see on a map where the enemy players are located. Maybe this feature occurs when enemies are within a specific distance and shooting a weapon. Or maybe it occurs for a limited time when somebody on one team activates a drone and then that team can see the positions of everyone on the enemy team. Regardless, there exists some function called "DisplayPlayersEnemy" that provides this feature. It's only supposed to be running in specific circumstances and otherwise is not active. Unless, of course, some players figured out how to always have Function "DisplayPlayersEnemy" constantly running. This gives those players an obvious advantage. So the developers decide to quietly release an update to the game to test this theory. They create an alternative function called "DisplayEnemyPlayers". It does the same thing as the older "DisplayPlayersEnemy". And all the processes that had previously initiated the old function now initiate the new function instead. So the game continues to function just the same as it did before. The developers keep the old function in the game, even though there's no longer any legitimate way to initiate it. It will still do all the things it did before, so if the function is initiated, it will seem to work as it did before. Except that the developers added a process to that function to identify when and by whom the function was initiated. The developers release the update and then wait. From the players' perspectives nothing has changed. Except that the cheaters are now about to fall into a trap. Some players did in fact modify their game with additional code that caused the old function to initiate when it wasn't supposed to. Since the old function is still in the game, their modifications have continued to work. Many of the cheaters did not notice that the old function had been modified and that a new function had been added. So these cheaters did not know to update their modifications to use the new function. But since there's no legitimate way for the old function to initiate after the update, and since the old function now reports data to the developer, the developer knows who modified their game to cheat.

DanHulton 4y ago
That also sounds like a classic mistake on the behalf of the developers: never trust the client. The client should never be able to call a "DisplayEnemyPlayers" function, like _ever._ That should be calculated entirely server-side. The client should only ever know what the player could possibly know, and the inputs limited, checked, and sanitized to ensure that they're valid inputs based on the server's known player state, not the client's reported player state. Of course, there's limited situations where the client can still do cheaty things despite your best intentions, like refusing to display smoke particles that should partially obscure another player and make it difficult to hit them (if they fully obscured the other player, the client should not receive updates about that other player), but aside from that and other "partial knowledge" problems, what you describe is a completely solved problem.
- dleslie 4y ago
  Often the design of the gameplay requires trusting the client. Ie, foliage that partially obscures an enemy. There's no way to have this as a feature that doesn't require trusting the client to render the foliage properly.
  - jamesfinlayson 4y ago
    Yeah I thought the client got a lot of this extra information for performance reasons more than anything e.g. only play enemy shooting sounds if the enemy is nearby - do all the processing on the client so that the server doesn't need to work out a matrix of who can hear who and send the appropriate message to each client.

DanHulton 4y ago

That also sounds like a classic mistake on the behalf of the developers: never trust the client. The client should never be able to call a "DisplayEnemyPlayers" function, like _ever._ That should be calculated entirely server-side. The client should only ever know what the player could possibly know, and the inputs limited, checked, and sanitized to ensure that they're valid inputs based on the server's known player state, not the client's reported player state. Of course, there's limited situations where the client can still do cheaty things despite your best intentions, like refusing to display smoke particles that should partially obscure another player and make it difficult to hit them (if they fully obscured the other player, the client should not receive updates about that other player), but aside from that and other "partial knowledge" problems, what you describe is a completely solved problem.

dleslie 4y ago
Often the design of the gameplay requires trusting the client. Ie, foliage that partially obscures an enemy. There's no way to have this as a feature that doesn't require trusting the client to render the foliage properly.
- jamesfinlayson 4y ago
  Yeah I thought the client got a lot of this extra information for performance reasons more than anything e.g. only play enemy shooting sounds if the enemy is nearby - do all the processing on the client so that the server doesn't need to work out a matrix of who can hear who and send the appropriate message to each client.