This has been done before in both 1.6 as well as Source. I helped with some of these implementations back in the late-2000s when I was playing professionally and I even tried to kickstart an anti-cheat hardware solution about a decade ago[1].. spent way too much time working on some of these problems. The main issue with occlusion was slightly increased latency, visual jitter because of interpolation (especially around corners), and a few other more technical problems[2]. It's good enough for public servers, but not tenable in serious competition.
Cheating has always been a problem in FPSs, and it likely won't go away. That's why premier competitions have always been on LAN.
[2] Hard to fully obfuscate audio sources, hard to obfuscate hitboxes since you still need them for collision checking (e.g. if a grenade bounces off an enemy player behind a wall—the server does not do all physics for all clients), and this is on top of the engine itself sometimes requiring actual entities, so you're stuck with these dummy entities in memory, and so on.
I wonder why similar methods haven't been employed in MMO servers to help curb botting/cheating there. The impact of jitter and loss of smoothness in a tab-target game like WoW would be minimal (even in PvP), because it's always had a noticable level of artifacts like rubberbanding.
WoW has a lot of mechanics involving line of sight (eg a spell you begin casting when the target was in LOS will fail when the casting time finishes if the target moves out of LOS) and positioning (AOE spells, spell ranges, NPCs/objects you can interact with only within a certain range, among many others)
Because what do you think matters more in an online game:
A. Smooth and consistent client experience, where bullets hit what you aim at (client-side prediction) where aimbots and wallhacks work.
B. Jittery/laggy client experience, where aimbots still work, but wallhacks are disabled?
You can only choose one option.
Generally, everyone agrees "A" is the best option and cheaters will be dealt with at game time. It's annoying, but that's the cost of online video games.
Also even if it worked perfectly, there'd still be other practical ways to cheat. In a way it's better to detect cheats than prevent them, because you waste a lot more of their time sticking them into a pool of cheaters and can also undo it. Though afaik Counterstrike tells you when you're low-trust.
The many tradeoffs involved are not trivial, this can only feasibly work well on LAN.
This is the reason why Valorant is the least playable among all competitive shooters if your internet is anything lesser than Google campus fiber, ironically in spite of having even-slower-than-CS movement physics on its side to mask the problem.
Riot conveniently cherry picks the best case scenario and handwaves the actual technical tradeoffs in their smug "we solved peeker's advantage!" engineering blog posts that are really just barely-disguised monorail Gish gallop.
I was on the other side of this in League of Legends. They used to have packets leak information to the client about player position. The classic examples are for stuff like particle emission or spell usage. Well at some point they decided that they had enough and did a pretty major rework of their netcode to only send player positions when you were supposed to have vision on them (plus a tiny extra radius). That absolutely wrecked the determinism of the game, as small jitters would cause skill shots to hit you before they even drew in your game, players would become invisible as the packets arrived out of order. Particle emitters would bug out.
This stuff i way harder than people imagine. I think League eventually got it somewhat figured out, but it took a couple of years from what i recall.
Valve also implemented this on CS:GO back in 2015 [0], and enabled by default in competitive servers, so I would consider it absolutely tenable (FACEIT, the platform used by competitive variants, had their own hand-rolled SMAC implementation, before using the 1st party solution, albei,t that solution was buggy). Why Valve didn't port this over to CS2, I will never know.
Always confuses me why people speak so authoritatively on topics they aren't versed in. PVS culling is not even remotely comparable to occlusion culling, mainly because wallhacks are not relevant accross the map; in fact they are only useful when opponents are always well into your PVS range.
FYI: there are also some clever ways to get around PVS culling (mostly by inferring opponent position based on other indicators, like gunfire).
PVS-based culling is very different from the kind of fog of war system in discussion here. The cases that these FoW systems purports to deal with would all be "pass" cases for PVS culling.
PVS culling solves the informational/strategic advantage aspect provided by wallhacks, but not the pre-aiming reaction-time advantage in a peeker vs holder scenario.
I wonder how often wall hacks are actually used in high-level competitive play by cheaters vs ESP. ESP seems like the better route to avoid manual review flagging suspicious activity. Audible cues (which this currently does not mitigate, and I'm not sure it can) are things that can genuinely separate players by skill and you'd think someone running such a cheat just has very good hearing.
>CS2FOW uses static baked map geometry. Dynamic occluders such as doors, breakables, props, smokes, particles, and projectiles are intentionally out of scope for now.
Market window on Mirage just became more powerful on these servers :)
Yeah my bad for not defining it. "Extra-Sensory Perception", basically as you said I believe is the most common feature -- but in general I think encompasses cheats that generally boost your "senses". So it could use audio to visually draw on your screen/radar where the sound came from.
The screenshot in this repo is kind of similar to wallhacks, but you could imagine this could easily be extended to show dropped items and the 3D audio location: https://github.com/ryanjpwatts/esp-analysis
Moving away from the technical solution space - I'm curious, have their been any games (or communities) with a high entry fee/deposit (e.g. $500 USD) to join kept in escrow and lost in the event you're discovered to be cheating?
There are plenty more questions like paying for mods/review, securing the money, paying for servers, etc.. but my basic question is if cost of entry exceeds cost of reward from cheating has ever been attempted in a game.
Apparently buying a new copy of a $10-20 game isn't enough to keep people away from cheats. Less so when there is prize money on the line or skins (e.g. CS2) worth $100k.
I've seen private cheats for games with less-than-terrible anticheats charge that monthly, if not weekly. You're underestimating how much people are willing to pay to play with cheats, and overestimating how much regular people are willing to pay to play against players without them.
Csgo became free at some point, and I remember the amount of smurfing increasing a lot then. Have rarely noticed cheaters, but smurfs are just as bad if not worse. They do at least require new accounts to waste some time playing deathmatch to be eligible for competitive.
> Does it cause pop-in when peeking?
The goal is early reveal, not exact last-millisecond reveal.
CS2FOW predicts using movement and ping, reveals enemies slightly before exact visibility, and keeps revealed enemies visible briefly. This intentionally leaks a small near-corner window to avoid late pop-in.
This fails to address the main point of the "pop-in" issue relevant to fog of war systems, which is that it is the victim of the peek that gets the worst pop-in effect, the peeker much less so. The aggressive peeker gets the benefit of the early-prediction from the server since they're the initiator of the movement, whereas the victim only begins to receive the information after the peeker has already gotten two network roundtrips worth of early prediction.
Peeker's advantage is not directly related to fog of war. The peeker is moving so before the movement is even sent to the server, the client's camera began moving. As such, the peeker will have at least a tick, usually more before that new position is available to the opponent.
"Fixing" this would make movement sluggish: any movement would need to be validated by the server. Meaning delay between pressing keys and actual movement.
"Same tick" is a misnomer for a few reasons. First of all, games use UDP, which is basically a "fire and forget" protocol (which means packets get dropped routinely). Second of all, realtime games use some interpolation/prediction to make up for latency (and aforementioned dropped packets).
So it's sort of a "relativistic" temporal system, not a linear "oh now you're at t=1, now you're at t=2" kind of timeline. And there's all kinds of complicated ways you create concensus between multiple clients, between server and clients, etc. (A lot of this remains an active research area.)
That would have to include your own position on your own client. Adding a delay of the RTT of the worst latency in the server to your inputs
Some games still do this. RTS games notably, but hide it with mouse and sound effects. If anyone remembers the Starcraft 1 option of "extra high latency", it would work by increasing the delay.
Interesting, could it be mitigated by the server doing its own prediction and defogging the peeker early? Or is lag prediction in CS2 not entirely client-sided.
It's more that momentum-based defogging means that the peeker has control over how to manipulate the server's prediction, whereas the victim who is already disadvantaged by network latency now gets an additional penalty of the movement initiation being not telegraphed.
To solve this, the fog of war would need to use purely positional near-edge tolerances, which defeats the entire purpose of fog of war to begin with, which is the pre-aiming reaction time advantage of tracking the peeker through walls in addition to having a farther lever point from the cover than the peeker.
Wallhack is locked into the DNA of CS for some reason. The most common defense by far is mass denial. For the great majority of players that seems to be good enough.
Not just CS, I don't think people realize how prevalent cheating is in any multiplayer game. The issue is compounded by the fact that many high skill ceiling games are plagued by "micro cheats" being used by players that are already fairly decent at the game even without them, making it borderline impossible for casual players to tell if what just happened to them was a fair skill gap or someone cheating.
I don't play multiplayer games anymore for that reason. Too easy to go on an emotional tilt where you feel like you're suffering from paranoia and suspecting too many players of cheating. It's absolutely ruined competitive games for me.
I'm fine as long as the game is somewhat evenly matched, and not fine if it's not. With or without cheating. Then whatever cheaters they can catch and shadowban, great. Smurfing is a way bigger problem anyway, cause some people treat the game like a job and will beat you more reliably than cheaters.
This has been done before in both 1.6 as well as Source. I helped with some of these implementations back in the late-2000s when I was playing professionally and I even tried to kickstart an anti-cheat hardware solution about a decade ago[1].. spent way too much time working on some of these problems. The main issue with occlusion was slightly increased latency, visual jitter because of interpolation (especially around corners), and a few other more technical problems[2]. It's good enough for public servers, but not tenable in serious competition.
Cheating has always been a problem in FPSs, and it likely won't go away. That's why premier competitions have always been on LAN.
[1] https://www.pcgamer.com/introducing-gameref-the-anti-cheat-h...
[2] Hard to fully obfuscate audio sources, hard to obfuscate hitboxes since you still need them for collision checking (e.g. if a grenade bounces off an enemy player behind a wall—the server does not do all physics for all clients), and this is on top of the engine itself sometimes requiring actual entities, so you're stuck with these dummy entities in memory, and so on.
I wonder why similar methods haven't been employed in MMO servers to help curb botting/cheating there. The impact of jitter and loss of smoothness in a tab-target game like WoW would be minimal (even in PvP), because it's always had a noticable level of artifacts like rubberbanding.
Well, if you cheat in WoW, Blizzard might just sue you[1], so that tends to be quite effective :)
[1] https://en.wikipedia.org/wiki/MDY_Industries,_LLC_v._Blizzar....
How would it help? MMOs generally don't need to know where things are right now since it's mostly static, no?
WoW has a lot of mechanics involving line of sight (eg a spell you begin casting when the target was in LOS will fail when the casting time finishes if the target moves out of LOS) and positioning (AOE spells, spell ranges, NPCs/objects you can interact with only within a certain range, among many others)
Why on earth don't the producers of the game implement this? It sounds trivial to do?
Because what do you think matters more in an online game:
A. Smooth and consistent client experience, where bullets hit what you aim at (client-side prediction) where aimbots and wallhacks work.
B. Jittery/laggy client experience, where aimbots still work, but wallhacks are disabled?
You can only choose one option.
Generally, everyone agrees "A" is the best option and cheaters will be dealt with at game time. It's annoying, but that's the cost of online video games.
Also even if it worked perfectly, there'd still be other practical ways to cheat. In a way it's better to detect cheats than prevent them, because you waste a lot more of their time sticking them into a pool of cheaters and can also undo it. Though afaik Counterstrike tells you when you're low-trust.
C. give everyone wall hack and aimbot.
The many tradeoffs involved are not trivial, this can only feasibly work well on LAN.
This is the reason why Valorant is the least playable among all competitive shooters if your internet is anything lesser than Google campus fiber, ironically in spite of having even-slower-than-CS movement physics on its side to mask the problem.
Riot conveniently cherry picks the best case scenario and handwaves the actual technical tradeoffs in their smug "we solved peeker's advantage!" engineering blog posts that are really just barely-disguised monorail Gish gallop.
CSGO already added this over a decade ago.
I was on the other side of this in League of Legends. They used to have packets leak information to the client about player position. The classic examples are for stuff like particle emission or spell usage. Well at some point they decided that they had enough and did a pretty major rework of their netcode to only send player positions when you were supposed to have vision on them (plus a tiny extra radius). That absolutely wrecked the determinism of the game, as small jitters would cause skill shots to hit you before they even drew in your game, players would become invisible as the packets arrived out of order. Particle emitters would bug out.
This stuff i way harder than people imagine. I think League eventually got it somewhat figured out, but it took a couple of years from what i recall.
my first thought was to have lots of hidden players running around that only you can see. The grenade thing kinda ruins it.
Except when the professionals are doing the cheating. LAN won’t save you. Word.exe
Valve also implemented this on CS:GO back in 2015 [0], and enabled by default in competitive servers, so I would consider it absolutely tenable (FACEIT, the platform used by competitive variants, had their own hand-rolled SMAC implementation, before using the 1st party solution, albei,t that solution was buggy). Why Valve didn't port this over to CS2, I will never know.
[0]: https://www.reddit.com/r/GlobalOffensive/comments/35zwwy/opt...
> so I would consider it absolutely tenable
Always confuses me why people speak so authoritatively on topics they aren't versed in. PVS culling is not even remotely comparable to occlusion culling, mainly because wallhacks are not relevant accross the map; in fact they are only useful when opponents are always well into your PVS range.
FYI: there are also some clever ways to get around PVS culling (mostly by inferring opponent position based on other indicators, like gunfire).
PVS-based culling is very different from the kind of fog of war system in discussion here. The cases that these FoW systems purports to deal with would all be "pass" cases for PVS culling.
PVS culling solves the informational/strategic advantage aspect provided by wallhacks, but not the pre-aiming reaction-time advantage in a peeker vs holder scenario.
I wonder how often wall hacks are actually used in high-level competitive play by cheaters vs ESP. ESP seems like the better route to avoid manual review flagging suspicious activity. Audible cues (which this currently does not mitigate, and I'm not sure it can) are things that can genuinely separate players by skill and you'd think someone running such a cheat just has very good hearing.
>CS2FOW uses static baked map geometry. Dynamic occluders such as doors, breakables, props, smokes, particles, and projectiles are intentionally out of scope for now.
Market window on Mirage just became more powerful on these servers :)
Very cool project nonetheless.
I didn't know what ESP was; from some googling, it appears to notify you when someone is aiming at you?
Yeah my bad for not defining it. "Extra-Sensory Perception", basically as you said I believe is the most common feature -- but in general I think encompasses cheats that generally boost your "senses". So it could use audio to visually draw on your screen/radar where the sound came from.
The screenshot in this repo is kind of similar to wallhacks, but you could imagine this could easily be extended to show dropped items and the 3D audio location: https://github.com/ryanjpwatts/esp-analysis
Moving away from the technical solution space - I'm curious, have their been any games (or communities) with a high entry fee/deposit (e.g. $500 USD) to join kept in escrow and lost in the event you're discovered to be cheating?
There are plenty more questions like paying for mods/review, securing the money, paying for servers, etc.. but my basic question is if cost of entry exceeds cost of reward from cheating has ever been attempted in a game.
Apparently buying a new copy of a $10-20 game isn't enough to keep people away from cheats. Less so when there is prize money on the line or skins (e.g. CS2) worth $100k.
>e.g. $500 USD
I've seen private cheats for games with less-than-terrible anticheats charge that monthly, if not weekly. You're underestimating how much people are willing to pay to play with cheats, and overestimating how much regular people are willing to pay to play against players without them.
Yeah you'll deter legit players with the escrow way before you'll deter cheaters. It's a good thought but probably not going to work.
Csgo became free at some point, and I remember the amount of smurfing increasing a lot then. Have rarely noticed cheaters, but smurfs are just as bad if not worse. They do at least require new accounts to waste some time playing deathmatch to be eligible for competitive.
Why wouldn't you just send the positions to both clients in the same tick? Seems trivial to solve.
Peeker's advantage is not directly related to fog of war. The peeker is moving so before the movement is even sent to the server, the client's camera began moving. As such, the peeker will have at least a tick, usually more before that new position is available to the opponent.
"Fixing" this would make movement sluggish: any movement would need to be validated by the server. Meaning delay between pressing keys and actual movement.
"Same tick" is a misnomer for a few reasons. First of all, games use UDP, which is basically a "fire and forget" protocol (which means packets get dropped routinely). Second of all, realtime games use some interpolation/prediction to make up for latency (and aforementioned dropped packets).
So it's sort of a "relativistic" temporal system, not a linear "oh now you're at t=1, now you're at t=2" kind of timeline. And there's all kinds of complicated ways you create concensus between multiple clients, between server and clients, etc. (A lot of this remains an active research area.)
That would have to include your own position on your own client. Adding a delay of the RTT of the worst latency in the server to your inputs
Some games still do this. RTS games notably, but hide it with mouse and sound effects. If anyone remembers the Starcraft 1 option of "extra high latency", it would work by increasing the delay.
Interesting, could it be mitigated by the server doing its own prediction and defogging the peeker early? Or is lag prediction in CS2 not entirely client-sided.
It's more that momentum-based defogging means that the peeker has control over how to manipulate the server's prediction, whereas the victim who is already disadvantaged by network latency now gets an additional penalty of the movement initiation being not telegraphed.
To solve this, the fog of war would need to use purely positional near-edge tolerances, which defeats the entire purpose of fog of war to begin with, which is the pre-aiming reaction time advantage of tracking the peeker through walls in addition to having a farther lever point from the cover than the peeker.
Why hasn't valve poured a billion or two on fixing this concept and implementing it?
>Release Notes for 5/26/2015
>– Added trace-based visibility checks to prevent networking invisible enemy players.
https://blog.counter-strike.net/2015/05/11988
Wallhack is locked into the DNA of CS for some reason. The most common defense by far is mass denial. For the great majority of players that seems to be good enough.
Not just CS, I don't think people realize how prevalent cheating is in any multiplayer game. The issue is compounded by the fact that many high skill ceiling games are plagued by "micro cheats" being used by players that are already fairly decent at the game even without them, making it borderline impossible for casual players to tell if what just happened to them was a fair skill gap or someone cheating.
I don't play multiplayer games anymore for that reason. Too easy to go on an emotional tilt where you feel like you're suffering from paranoia and suspecting too many players of cheating. It's absolutely ruined competitive games for me.
I'm fine as long as the game is somewhat evenly matched, and not fine if it's not. With or without cheating. Then whatever cheaters they can catch and shadowban, great. Smurfing is a way bigger problem anyway, cause some people treat the game like a job and will beat you more reliably than cheaters.
Why doesn't Valve implement this natively?
This is good. However, it still sends info about the players ~200ms ahead which still makes you lose.