The real solution? Send only information players are supposed to see. Sacrifice some speed for true cheat proof games.
Then instead you have a FPS with multiple weapons and it takes several seconds to switch between them. One has a high rate of fire but is useless against players with armor, another is the opposite. Cheaters don't know if the opponent is wearing armor (or what kind) because the server doesn't tell them that until they're in the same room, by which point it's too late.
Make certain weapons better against certain defenses, so it's a matter of predicting what your opponent will do and being ready for it. Make the humans do the things that humans are still better at, instead of trying to prevent a computer from beating them at things computers are better at.
Many of the very popular games now require good aim. Some people spend countless hundreds/thousands of hours just practicing their aim and muscle memory. It's part of the fun for them. CS:GO is a notable example.
The problem isn't really that it's impossible to ban such cheating. ESEA do it pretty well in CS:GO - their anti-cheat is practically a RAT.
It's that banning cheaters and making a bulletproof anticheat has two issues:
1) To do it properly you need to basically code a RAT, which has some privacy issues. If Valve do it, it could hurt activity, platform support, and be controversial. ESEA have done it since day one, but their player base is much smaller and more competitive. ESEA is also limited to Windows.
2) It's not profitable. That's the honest truth. They ban obvious public cheats and the cheaters will buy another account and come back, probably use another cheat again, get banned again, repeat. Some games don't have awful cheat protection because the company can't make a good one, they have awful cheat protection because it's not profitable to alienate all the cheaters in the game away from the platform (and their many purchases per person; legitimate players only buy once).
If only one game has working anti-cheat, it may not be worth the cheater's time to break it because it's only one game, and they can go cheat in a different game. If all the games had it then more people would try to break it and more would succeed. And once they have a working method, it can be employed against any other game that uses the same kind of anti-cheating, even if it's not the same vendor's, as long as the mechanism is similar.
But having all the vendors get together to pool resources and design one good anti-cheating software makes it even worse, because then it might be a little harder to defeat, but the prize for defeating it is being able to cheat in every game without even having to translate the cheating method to each new game.
So you get small victories or nothing. There is no winning at scale because increasing scale only increases the number of adversaries and the gains from finding an effective way to cheat.
It's basically the same problem as keeping the latest Hollywood releases off of pirate sites. They count success as occasionally having a week before a new release is on the pirate sites instead of being there the same day, and even that doesn't happen very often.
It turns out it's more effective to make it so it doesn't matter. In their case by making it so easy and cheap to watch Netflix on your TV that it's not worth most peoples' time to figure out how to use BitTorrent even if it has 100% of their content. In this case by making more games that humans are better at than computers, so you can't use a computer to cheat.
I feel like the concept of "ban waves" ought to help a lot here. Wait a couple weeks between banning people, and then randomly don't ban some people during the wave. Should make it pretty hard to test your anti-anti-cheat.
It's a thing that enables cheaters to not get caught. They may not need it if they have some other way to not get caught, but you can expect to see it if it is or becomes the easiest thing that works.
In your game design not only is it dull because you have a 50:50 chance of having the right gun equipped to take advantage of a situation even if no one is cheating. But it’s still very amenable to cheating both because the cheat would be able to switch weapon the instant the client was informed of the state of the opponent, beating a human where it actually matters and would still be able to have a mechanically perfect aim.
Most videogames actually have the sort of human reaction prediction you are talking about and that’s why people cheat because they are bad at it. So make it up by exploiting information sent but not displayed or through mechanical assistance. The interesting case there is that mechanically good players that have a good read can beat cheaters.
Stuff like the DeepMind successes playing Chess, Go and Starcraft ultimately show that even with an environment where things are fairly level that computers have the edge in games albeit with an unattainable for cheat makers level of technology.
Except that it's not random, because you can try to figure it out. You know what's in the map. If you go to where a particular weapon is and it's not there, now you can expect the opponent to have it, so you start looking for defenses against it etc. Or you know that you're playing against Bob and Bob always goes for the same weapon like a chump because he doesn't know what to do with any of the others. Or you get a weapon and then go around collecting every defense against it on the map so the opponent can't get them.
> But it’s still very amenable to cheating both because the cheat would be able to switch weapon the instant the client was informed of the state of the opponent, beating a human where it actually matters and would still be able to have a mechanically perfect aim.
Which is why it's not about switching faster, it's about making the right choice to begin with. The whole idea is if you have to switch at all you're probably already dead and switching a half second faster isn't going to save you.
probably family friendly.
should make it.
There can still be strategy in it without leaving any easy way to cheat.
I wonder if anyone had ever designed a completely external aimbot. A camera, a computer vision system and a hardware mouse or gamepad multiplexer/proxy that mixes real controls with the adjusting movements.
That won't be fun to use (except, maybe, for PvE, if manual dexterity is just a irritating mechanical hurdle - there are games like that, too), but surely fun to hack.
Heh. Sometimes I regret that I won't live long enough to see all the drama around cyborgs in sports and gaming...
war thunder does it and it works well enough. it still has other problems, like p2w vehicles, but the system is solid
This problem is as old as competitive multiplayer itself, and various approaches have all been tried.
Transparent walls, for example, can be done via the graphics driver (or by replacing your graphics driver).
Pre-rendering the scenes on the server and then sending those is just not really possible today due to latency -- even google can't get it right with Stadia so far.
But, if the game engine/server just crunched the line-of-sight numbers and didn't even send location data for rendering enemies that were out of LOS, then that would work and while it is heavier than doing nothing, it isn't really that heavy.
That wouldn't stop an aimbot, but it would prevent some classes of exploits.
Of course, people would then gyrate back and forth across zone/room thresholds as a way of protecting themselves, which seems obnoxious, but also seems like a very easy behavior for the server to detect and punish.
Ah, but Stadia (and Playstation Now, and Geforce Now) are trying to solve a different problem: moving all the compute to the cloud, so that the game console can be wimpy (or of a different/incompatible architecture, in PSNow's case.)
If you remove that requirement—or rather, impose the requirement that the client hardware must be just as powerful as if it were running a full game—then you can do something clever by splitting the game not into "renderer on the server, frame buffer on the client" but rather into "game and projection matrix on the server; display-list renderer on the client."
In other words, the server (or per-client server-side agent) would be responsible for doing all the evaluation of local physics (e.g. soft-body dynamics, constraint-resolution during rigging, etc.), lighting calculation, and all the other stuff that currently requires the client to "know stuff" about the world; and then it'd output to the client, on each tick, just a display-list—a bunch of loaded-model references, their positions in space and the positions of their rigged limbs, and the reflected-light amount on each of their polys; any temporary particles that exist for that frame, and their positions; etc. This would all be culled down to a virtual viewport.
The job of the client would then just be to receive this display-list, each frame, and draw it. It would also perhaps be responsible for doing client-side visual lerps between server ticks. (Probably each rigged limb would be annotated with linear+angular velocity properties.)
In other words, this would be a recapitulation of the X11 protocol, but where the primitives are 3D objects rather than 2D ones. (It'd kind of look like the protocol between games and OS display drivers, but at the same time higher-level in some ways and lower-level in others.)
This would be highly bandwidth-efficient (and jitter-tolerant!) compared to what Stadia is doing. You'd probably be able to play a decent game through this on 3G, even. But you'd need a computer that could do the final rendering passes.
And even then it wouldn't stop cheating. Bots would just look for triangles drawn with enemy uniform textures (very easy if you have the display lists) and aim at them.
I think you missed the "viewport culling" step in the above description. The server would only be sending the client enough information to draw what's going to be on the client's screen (since that's the only information that's naturally left after that step of the rendering pipeline!) So, on any frame where another player is obscured by a wall, data about that player wouldn't be in the display-list sent to the client, any more than it would be in the image Stadia sends.
This is ignoring things like player shadows which are rendered separately and need polygons which are not in the visible fulcrum.
Also we are both ignoring audio. Sounds like gunshots come from a specific place in the world.
Well, yes, but I'd categorize that as "acts indistinguishable from theoretically-optimal human performance", rather than cheating per se. Or would you ban The Flash for cheating?
> This is ignoring things like player shadows which are rendered separately and need polygons which are not in the visible fulcrum.
No, not really; a shadow mesh is generated on the server, as part of the lighting step. The client then receives the shadow mesh, potentially disconnected from whatever's casting the shadow if the thing casting the shadow was culled. Just like what happens inside your GPU.
> Sounds like gunshots come from a specific place in the world.
In a paradigm like this, audio-cue triggers would essentially be "scripted particles" in the scene. If you can't see them, they're not rendered, so you can't hear them, either.
I'm not trying to describe something here that's a lossless approximation of how the game would work if run locally. I'm describing something with real effects on gameplay balance, but potentially good ones.
Mind you, I'm less picturing FPS games as the best use of this, and more picturing RTS games. Take the "fog of war" of a game like Starcraft, and implement it server-side, such that it's not the client not-rendering unexplored stuff, but the server.
Shadow meshes are often generated by rendering the scenes from the viewpoint of the light sources. This would have to be done on the server, so the server is already doing some rendering.
Sounds certainly need to be rendered, even for non-visible players. Otherwise you couldn't hear someone shooting behind you.
You ideas would work much better with a RTS. But so do solutions like Stadia.