For anyone hoping to play Delta Force on Desktop Linux, the developer Team Jade has given a pretty clear no. That's despite it working on Steam Deck due to the anti-cheat they've used.
You can run an entirely-untrusted client, but that creates very substantial limitations. I’d go so far as to say that doing so rigorously makes most genres of multiplayer games impractical. Some examples:
If the client has no information about visibility of non-visible enemy players in a first-person shooter, it creates delay due to latency in an enemy becoming visible, collision detection issues, and so forth.
If all random number generation needs to happen server side, then the client not only can’t be trusted to generate any important random numbers (probably avoided today for many games) but also cannot run an RNG with the same internal state as the server (else a client could “peek ahead” to see the future). As a result, every action that involves randomness requires a server round trip and a sluggish response until a player can see the outcome.
On any network without guaranteed minimum bandwidth and guaranteed maximum latency (which is generally not the case for the Internet today), a client can not send packets and pretend that the network just dropped them. There, either one has to seriously restrict predictive movement or one can pull stunts like briefly disabling packet transmission and “teleporting” across dangerous areas, preventing an enemy from taking a shot at one.
All hidden information in a game that a client could expose to a player must be exposed to maintain a level playing field. Even stuff that isn’t even specially available to only a client. So, say players figure out that Monster X in an MMO has a respawn timer that causes it to respawn at time T, and someone can modify the client to indicate the remaining time with a timer. For a level playing field, that feature has to be built into the base client for all players, immersion-breaking or no.
Any large amount of state on the client probably has to also be exposed to the player, because transmitting it over the network in real time isn’t practical due to bandwidth constraints. So players have to all have minimaps with no obscured terrain, because their client has map files with the geometry. They need to be able to see at least terrain through walls, because their client has that information. Maybe you could try to hide map data in encrypted chunks the very first time through, but that’s going to lead to performance issues and also the next issue if maps are the same across multiple players (almost certainly yes):
Any information that another player’s client has should also be available, as players can have clients that collude. So if any other player can see an enemy player, then since their client could tell you about them, the vanilla client must have a wallhack showing any enemy visible to any other player to keep level footing.
Almost all simple mechanical operations (e.g. responding quickly to counter an enemy action) must be automated or removed from the game, because otherwise someone could modify their client to do this instantly in response to an enemy action and gain an edge. Dodging needs to be totally automated or gone, for example. The only player actions that can remain are those that require human-level reasoning, where the client can’t play better in some respect than the human using “bot”-like code. Relying on reflexes or having a player managing load from having to deal with many simple things at once can’t be in the game. Aimbots have to be in the base client for first-person shooters.
For something like turn-based card games, yeah, it’s possible to create games where the client is completely nontrusted. There are no real time constraints, and you can deal with the client (or server) gaming the RNG via mental poker techniques. Keep in mind that even there, the client might be doing things like running probability calculations and telling a player the mathematically-optimal card to play in many cases. Poker would basically be reduced to trying to detect player tells, because playing poker optimally outside of that was solved by von Neumann, and the client could probably tabulate data on other players, like speed of response, to try to help a player identify tells.
But for most real-time games, providing an experience comparable to the current one is probably going to require some level of client trust. Maybe one can achieve the lesser goal of reducing one’s trust a bit, make it harder to cheat, but a true zero-trust real-time game has to have a great many very serious limitations placed on it.
I do think some of these limitations can be resolved. But it indeed poses a big challenge. You can go to big lenghts with server occlusion checking to prevent wall hacks but under zero trust any game with directional sound already has build in wallhacks.
I mostly speak from experience with my developing my own game which is not an FPS. Previously the client would send “i build on this position”. Which could very easily be abused. Which I then changed to “i build with this angle and this distance from the previous node” the client would then already show the newly constructed “ghost” node while the server would check if that construction is valid and then send the real position to all clients. The only thing a player would notice is that with high ping the constructed node would move slightly as it got the definitive position from the server. While being significantly more cheater proof.
I suppose im biased towards this kind of thinking since im not working on a FPS game, what for me might be a simple change is a massive undertaking for other genres.
You can run an entirely-untrusted client, but that creates very substantial limitations. I’d go so far as to say that doing so rigorously makes most genres of multiplayer games impractical. Some examples:
If the client has no information about visibility of non-visible enemy players in a first-person shooter, it creates delay due to latency in an enemy becoming visible, collision detection issues, and so forth.
If all random number generation needs to happen server side, then the client not only can’t be trusted to generate any important random numbers (probably avoided today for many games) but also cannot run an RNG with the same internal state as the server (else a client could “peek ahead” to see the future). As a result, every action that involves randomness requires a server round trip and a sluggish response until a player can see the outcome.
On any network without guaranteed minimum bandwidth and guaranteed maximum latency (which is generally not the case for the Internet today), a client can not send packets and pretend that the network just dropped them. There, either one has to seriously restrict predictive movement or one can pull stunts like briefly disabling packet transmission and “teleporting” across dangerous areas, preventing an enemy from taking a shot at one.
All hidden information in a game that a client could expose to a player must be exposed to maintain a level playing field. Even stuff that isn’t even specially available to only a client. So, say players figure out that Monster X in an MMO has a respawn timer that causes it to respawn at time T, and someone can modify the client to indicate the remaining time with a timer. For a level playing field, that feature has to be built into the base client for all players, immersion-breaking or no.
Any large amount of state on the client probably has to also be exposed to the player, because transmitting it over the network in real time isn’t practical due to bandwidth constraints. So players have to all have minimaps with no obscured terrain, because their client has map files with the geometry. They need to be able to see at least terrain through walls, because their client has that information. Maybe you could try to hide map data in encrypted chunks the very first time through, but that’s going to lead to performance issues and also the next issue if maps are the same across multiple players (almost certainly yes):
Any information that another player’s client has should also be available, as players can have clients that collude. So if any other player can see an enemy player, then since their client could tell you about them, the vanilla client must have a wallhack showing any enemy visible to any other player to keep level footing.
Almost all simple mechanical operations (e.g. responding quickly to counter an enemy action) must be automated or removed from the game, because otherwise someone could modify their client to do this instantly in response to an enemy action and gain an edge. Dodging needs to be totally automated or gone, for example. The only player actions that can remain are those that require human-level reasoning, where the client can’t play better in some respect than the human using “bot”-like code. Relying on reflexes or having a player managing load from having to deal with many simple things at once can’t be in the game. Aimbots have to be in the base client for first-person shooters.
For something like turn-based card games, yeah, it’s possible to create games where the client is completely nontrusted. There are no real time constraints, and you can deal with the client (or server) gaming the RNG via mental poker techniques. Keep in mind that even there, the client might be doing things like running probability calculations and telling a player the mathematically-optimal card to play in many cases. Poker would basically be reduced to trying to detect player tells, because playing poker optimally outside of that was solved by von Neumann, and the client could probably tabulate data on other players, like speed of response, to try to help a player identify tells.
But for most real-time games, providing an experience comparable to the current one is probably going to require some level of client trust. Maybe one can achieve the lesser goal of reducing one’s trust a bit, make it harder to cheat, but a true zero-trust real-time game has to have a great many very serious limitations placed on it.
I do think some of these limitations can be resolved. But it indeed poses a big challenge. You can go to big lenghts with server occlusion checking to prevent wall hacks but under zero trust any game with directional sound already has build in wallhacks.
I mostly speak from experience with my developing my own game which is not an FPS. Previously the client would send “i build on this position”. Which could very easily be abused. Which I then changed to “i build with this angle and this distance from the previous node” the client would then already show the newly constructed “ghost” node while the server would check if that construction is valid and then send the real position to all clients. The only thing a player would notice is that with high ping the constructed node would move slightly as it got the definitive position from the server. While being significantly more cheater proof.
I suppose im biased towards this kind of thinking since im not working on a FPS game, what for me might be a simple change is a massive undertaking for other genres.