In previous articles I talked about how to "lie a little" to the player and give them the feeling that the game behaves naturally: long-known tricks that have been thoroughly battle-tested in single-player games. But everything changes once a network shows up and the logic has to be split between the server and the clients. It turns out that a match shouldn't simultaneously own the inventory, the accounts and the rest of the game's household, and the computer the game runs on suddenly... belongs to the player, not the developer. If, through an oversight, we've given the client the right to tell the server where the character is, how much money it has and whom it just killed, then sooner or later someone will come along who interprets those rights far more broadly than the developer ever intended.
There's always a Vasya. He's been playing for ages and doesn't really care about his rating, but he hates losing. He hates it so much that he's willing to spend more money and time preparing for a match than on the match itself. His opponent is Vasily, a factory worker who shows up in the evening after his shift and just wants to play: an average computer, home Wi‑Fi through two walls and the reflexes of a tired man. Vasily sometimes wins but more often loses, and he's generally fine with that, as long as he's sure he's losing fair and square.
Vasya gets branded with the shameful word "cheater" and pictured as a guy with an aimbot who snaps his crosshair unnaturally fast onto the heads of enemies behind a wall. That's probably the most spectacular version: easy to show in a video and easy to denounce in the comments. But technically an aimbot is just one of the simplest members of a big family of ways to tell the game a lie, and the lie works in both directions. If you can tamper with what another player sees, you can also see what you're not supposed to see, or meddle with the data exchange, or leave the client alone entirely and exploit people, the economy and the trust of the dev team's support. Vasya, of course, has tried it all... otherwise what kind of Vasya would he be. And sometimes it's even a way to land a job, go white-hat as a respectable "security consultant" and break game services for a salary, but that's a different story.
Letting the client be in charge
Suppose a character moves around the map, and after every frame the client sends the server its new position. While the game is small and nobody's heard of it, this is even convenient: the player's computer has already calculated the movement, the server just stores the coordinates and broadcasts them to everyone else. Except that along with the coordinates we've handed Vasya the right to tell the server any story about his movement he sees fit. Today his character walked two extra meters, tomorrow he ended up behind a wall, and the day after it turned out that the laws of physics simply don't apply in Vasya's version of the game.
That's how teleport and speedhack cheats work, and that's also how money, items and XP appear out of nowhere. If the client can say "I earned a thousand coins" and the server records that thousand without asking how it was earned, then what we have is not so much a sophisticated hack as badly distributed responsibilities. All Vasya has to do is change the client's state or craft a request the game never meant to accept from an ordinary player, and the server obligingly makes the result official. That's why every anti-cheat guideline advises moving critical logic to the server and only the server, and treating the client as a point of data compromise. And if you can't avoid computing things on the client, then at least verify that the level being completed is the one the player actually started, that the final score is within acceptable bounds, and that the spent items really were in the inventory.
The next step is an authoritative server, where the client no longer reports "I'm already standing at point X" but only sends an intent to move in some direction, or a wish to press a button or use an ability. The server validates the command, runs the simulation itself and publishes the new state to the clients. Vasya didn't become any more honest because of this, but he can no longer dictate the result and expect it to be accepted. It's a bit like how you can confidently tell a market vendor that you've already paid, but that won't work on a card terminal in a store, no matter how honest your eyes look.
Money out of thin air
As a kid, Vasya played Fallout and pumped up his bottle caps with a memory scanner, a routine familiar to anyone who's ever opened ArtMoney. Your character has 1000 caps, you search the process memory for every cell holding 1000, spend a few, search the results for 950, and after a couple of iterations you're left with a single address you can write anything into. In a single-player game that's the end of the story, and the only thing you spoil is your own fun. In a networked game everything depends on who owns that cell. If the gold lives on the server and the client only holds a copy for display, then our l33t h4x0r sees a million Nuka-Cola caps on his screen and can't buy so much as a bowl of radscorpion stew with them. But if, on purchase, the client just tells the server that it bought something, then the million suddenly becomes real.
When ArtMoney stops helping, Vasya moves on to packets. He puts a proxy between the client and the server, looks at what goes out during a purchase and finds something like "buy item 517 for 100 coins". The price in that request is usually unnecessary, since the server already knows what item 517 costs, but since the client sent it and the server read it, Vasya changes 100 to 1 and walks off with his purchase. This packet-handling bug is so common, and so thoroughly paid for by other people's economies, that it made it onto the mandatory checklist for networked game development: everything that can be computed on the server is computed on the server, and the client sends only an identifier of what the player wants to do. But known doesn't mean fixed, and most games still launch with a hole like this in their protocol.
A separate classic is negative numbers: Vasya sells a merchant minus one sword, or gives a friend minus five hundred caps, or deposits minus ten potions into storage. If somewhere along the way a signed number turned into an unsigned one, or the "does the player have enough items" check was written only for positive quantities, the server dutifully does the arithmetic and pays Vasya for a sword that never existed. Bugs like this sit in MMOs for years, and they almost never look like a vulnerability during code review, just a function where someone forgot that the number of swords can't be less than zero.
Another trick from this series is called replay: Vasya intercepts the "claim daily quest reward" request and sends it twenty more times in a row. If the server doesn't remember that the reward was already given out, or the requests are processed in parallel and the check passes for all of them at once, then twenty rewards is exactly what Vasya gets. This security hole gets patched with one-time operation IDs, which the server remembers and never executes twice, and with rate limits on anything that hands out valuables. Poor Vasily doesn't think about any of this; he just notices one day that the server is full of that rare mount you're supposed to get once a day.
When the server didn't keep up
Even if the server takes nothing on faith, Vasya still has the "timing hack", or more precisely, the gaps between events the server considers atomic when they actually aren't. The classic dupe goes like this: Vasya starts trading an item with a friend and, at the moment of confirmation, yanks out the network cable. Just kidding... sort of. The item has already been written to the friend's inventory, but the record of its removal from Vasya's inventory didn't get saved in time, the server rolls Vasya back to his last save, and now the sword exists in two copies.
There are dozens of variations on this scheme, and new ones keep appearing. Two parallel requests to move an item, tricks with different containers, hopping between game servers, logging in with one client to two shards at once, a server crash right after a reward is issued, DDoSing the database with write requests, writes landing in the database after a rollback or a wipe, and a little bit more. In every case Vasya breaks neither the client nor the protocol; he just looks for a spot where the game logic assumes two operations will happen together, while the inventory server doesn't know that or can't process it in time.
The cure for dupes is boring and expensive: unique identifiers and a single owner, moves wrapped in a transaction that either goes through entirely or not at all, and background jobs that scan the database for items with identical IDs and for abnormal wealth growth on individual accounts. Honest Vasily, of course, never duped anything, but he's the first to see the consequences when auction prices drop tenfold in a week and the sword he fairly earned is suddenly worth nothing. And then the developers roll out a wipe or a rollback that hits everyone, not just Vasya.
Faster than time
When the server stopped accepting coordinates, crafty Vasya didn't get upset; he switched to the classic time cheat, the "speedhack", except now it messes not with position but with the clock. A game usually learns how much time has passed between frames from system timers, and if you tamper with them so that the client counts a second and a half for every real second, the character will honestly run at its normal speed, Vasya will simply have more seconds than everyone else. In a client-authoritative game that's enough, and in a server-authoritative one Vasya starts sending movement commands more often than he should, or with timestamps that run ahead.
So the server has to keep its own clock: look at how much time has passed since the previous command, take the character's maximum speed into account and work out what distance was even reachable in that time, and while it's at it, cap the number of commands a client can send per tick. This is done with a movement budget: the client gets a piggy bank of allowed movement that refills as server time passes and is drained by every action, so a short burst after lag goes through, while systematic overspeeding quickly hits an empty piggy bank.
But once again, you can't make such a check strict with zero tolerance. Vasily's packets arrive in bursts because his router sometimes lags or drops out and then dumps everything at once, and from the server's point of view, Vasily at that moment looks exactly like Vasya with a speedhack. That's why suspicious movement usually doesn't get you banned right away; the character is simply snapped back to the last valid position, that "rubber-band" jerking you've seen more than once if you've ever played on bad internet. And statistics are always collected too, so that later someone can figure out which of the two is the real Vasya and which is just Vasily.
When Vasya sees everything
Wallhack and ESP give Vasya not speed but knowledge: enemy outlines behind walls, their names, health, weapons and other data that's hidden in normal play but known to the client, because how else would it draw the other players?
Sometimes it's the client-side rendering that gets tampered with, and the cheat simply draws extra information, but it's much nastier when the client receives data from the server that it has no need to know. If the server has sent the coordinates of an enemy standing behind an opaque wall, you can no longer hide him from Vasya with a rendering setting. Any information that has left the server stops being safe, and from then on all we can do is rely on the good faith of a program owned by the client.
So wallhack protection starts with the question of what the server sends to each client. If Vasily physically can't see Vasya, his client usually doesn't need Vasya's exact coordinates, and the server can send only the part of the state needed for the current picture, taking into account distance, line of sight and the game's rules. Riot once described in detail how in Valorant the server computes visibility itself and holds back enemy positions until they get close to the field of view, and that's probably the best-known example of this approach in a competitive shooter.
This solution certainly isn't free, of course. If you only send an enemy once he becomes visible, he'll pop out of thin air with a ping-sized delay, so visibility is computed with a margin, the server predicts who'll peek around a corner in the next few frames, and it all burns server time, which is always in short supply anyway. Then there's sound: Vasily is supposed to hear an enemy's footsteps behind a wall, which means the client needs at least a rough position of their source, and Vasya happily turns that sound into a marker on his screen. But if the server doesn't deal with this, it will hand Vasya, with its own hands, part of the advantage that the anti-cheat will later have to fight.
Freecam and a wider view
Sometimes Vasya doesn't even need to see through walls; it's enough to pull the camera further back, or detach it from the character and fly around the map in freecam mode. In strategy games and games with a large field of view, this lets him check in advance where the enemy is heading, and in a shooter, an extra slice of view can reveal what the normal camera hides beyond the edge of the screen. This isn't always a hack of the server state; more often you can just modify the client to show a picture the game designer never intended to give you, which is why camera restrictions also end up being part of the rules of fair play.
This is where the history of cheats goes back to single-player games, where developers left in free-camera modes, teleport commands or collision toggles for debugging levels. In old games such features were often accessible through the developer console, and in some projects they stayed in even after release, because nobody wanted to break the familiar testing workflow just to remove one command. In multiplayer games that same debug camera turned into free reconnaissance. A wider FOV isn't necessarily a cheat in itself, but getting around camera restrictions or obtaining information beyond the permitted view can already give an unfair advantage.
When everyone has the whole world
In strategy games Vasya behaves differently, because the networking there works differently. Most classic RTS games, even modern ones, run on deterministic lockstep: instead of level snapshots, only player commands travel over the network, and each client simulates the entire world with all participants on its own, but thanks to determinism everyone ends up with the same result. This lets you push thousands of units through a slow connection without sending a single position at all, but the scheme has an obvious downside: the entire match state, including the enemy army on the other side of the map, sits in every participant's memory, and the fog of war exists only at the rendering level.
Hence the maphack, which became almost a genre of its own in StarCraft, Warcraft III and Age of Empires. Vasya just has to remove the fog or put on the minimap what the client already knows, and he sees how many workers Vasily has, where the second base is going up and where the army is heading. The server can't hide this data, because without it Vasya's client simply couldn't run the simulation, and here an authoritative server in the usual sense no longer helps.
On the other hand, lockstep has a nice property that Vasya discovers when he tries to go further. If he doesn't just read memory but also slips himself some resources or speeds up construction, his simulation diverges from Vasily's, the state checksums stop matching, and the match falls apart in a desync. So lockstep by itself protects well against modifying the state and doesn't protect at all against reading it. That's why maphacks are caught mostly by behavior: by reactions to things the player couldn't have scouted or seen yet, by clicks and camera movements into fogged areas, and by analyzing replays, which in these games are almost free, since a replay is just a list of commands.
An aimbot that doesn't touch the game
An aimbot solves the aiming problem for Vasya: figure out where the enemy is and put the crosshair there, but implementations vary wildly. The classic version reads positions from client memory and nudges the camera angles; a triggerbot is more modest and only pulls the trigger when the crosshair lands on an enemy. And as in-process protection grows, Vasya gradually moves the cheat further and further away from the game.
First outside the process: a DMA card plugged into a PCIe slot reads the gaming PC's memory directly, and the analysis happens on a second computer that has no anti-cheat at all, while the gaming system has neither a foreign process nor a suspicious driver. Then outside the computer altogether: the screen image goes through a capture card to a second PC, a neural network finds the enemies in it, and the commands come back through a device that looks to the system like a perfectly ordinary mouse. On consoles a similar niche is occupied by adapters like Cronus Zen and XIM, which let you play with a mouse where nobody expected one and can run recoil-compensation scripts, and in 2023 Activision made a separate announcement that Ricochet had learned to detect such devices.
This is where protection focused on process memory hits its ceiling, because it can't read the world outside the client, and the less a cheat interferes with the game itself, the less use there is in methods that look for the usual traces of tampering. For a Vasya like this, the game turns into a very dynamic computer vision task, and to the server he looks like a player who just moves his mouse very fast and very accurately.
And that brings us to the main question of this article: how is quick-handed Vasya different from Vasily, who got a good night's sleep yesterday and is on fire today? The answer is sought in statistics, not in an individual shot. A human's reaction time fluctuates, a mouse trajectory has a characteristic acceleration and deceleration, misses are distributed in a particular way, and even a very good player sometimes overshoots the target and comes back. A cheat, even with added noise, is usually too stable: a reaction of the same number of milliseconds every time, aim correction with no overshoot, aiming that begins before the enemy has even appeared on screen. Back at GDC 2018 Valve talked about VACnet, which learns to tell such patterns apart in CS:GO match recordings, and since then almost every major shooter has had a system like that. But the line remains blurry, and the better Vasya disguises his bot as a human, the greater the chance that a very good Vasily gets suspected along with him.
No‑recoil, no‑spread and rapid fire
But even if Vasya doesn't want to trust his aiming to a neural network, he still has cheats that don't need to move the mouse at all. For example, he can compensate for recoil (no‑recoil), remove spread (no‑spread), or make a weapon fire faster than it should (rapid fire). In some games these things are done with in-game macros or by changing client behavior; in others they run into server-side checks of fire rate and shot results. It's a separate headache for anti-cheat, because the player may be aiming completely on his own, while his weapon behaves like a super-duper golden legendary gun with half its drawbacks cancelled.
The first widely known cheats of this kind became especially noticeable as networked shooters developed in the late nineties, and games like Counter-Strike quickly saw third-party programs that changed weapon behavior or automated repetitive actions without full-blown interference in the game code. As developers started validating player actions on the server, simply changing the local animation was no longer enough to gain certain advantages, but the workarounds kept evolving alongside specific games. For Vasily, though, the difference doesn't really matter, because either way Vasya somehow shoots like a T-800, with no misses and no regrets.
Silent aim
There's an even sneakier option called silent aim, where the crosshair on screen doesn't have to point at Vasily at all, but the shot result is processed as if the direction were different. This depends on how the particular game is built, and it doesn't mean any client can order the server to register a hit wherever it likes, but it nicely shows the difference between the picture the player sees and the data the game bases its decisions on. A regular aimbot tries to quietly guide the crosshair onto the target, while silent aim leaves the crosshair where it is and swaps out the shot data being sent.
Techniques like these are especially in demand in commercial online shooters, ever since regular aimbots started attracting attention not only from players but also from anti-cheats, which detected crosshair movements that were too sharp or aiming that was suspiciously precise. This branch of cheat-making has grown into its own industry with a turnover of, mind you, around $100 million a year, and you'll agree turnover like that doesn't come out of nowhere.
But silent aim itself isn't a single technology so much as the name of a whole class of tricks. If the server determines the shot result on its own from verifiable data, there are fewer opportunities for such manipulation, but that doesn't mean it can't be used, and nimble-fingered... there should probably be a different adjective here... Vasya can keep looking one way while his gun spins around all by itself.
If Vasya is really good with his hands
It's a similar story with reach cheats, when Vasya hits an enemy with his sword from a distance at which normal game logic wouldn't even offer to press the attack button. This is achieved either by modifying the client or by exploiting a bug in hit handling, but in both cases the defense boils down to the server itself checking the distance, the characters' states, the line of attack and whether the action is allowed at that particular moment. If, however, the server simply trusts an "I hit him" message, which happens less rarely than you'd think, then Vasya suddenly has a very long sword, and Vasily has a perfectly reasonable question about why he should bother leveling up his armor at all.
The idea itself isn't new, but it used to look a bit different. In old games with local simulation, it was enough to change values in memory or exploit a bug in collision checks to attack from an impossible position. But as online games developed, these tricks moved to the boundary between client and server, where Vasya no longer necessarily changes the length of his sword in the literal sense, but looks for a situation in which the server checks the distance incorrectly or uses a stale character position. I think it's clear why such bugs became interesting in melee games, where even a few centimeters or a few frames can easily decide the outcome of a fight.
Your router is lying to the server too
A networked game exists in several places at once and is constantly reconciling states that differ slightly from one another: packets get delayed, lost or arrive out of order, clients predict movement while waiting for the server's response, and on a hit the server rewinds the world to check what the shooter saw on his screen. All this machinery exists so that Vasily with his 80 millisecond ping can play normally, and Vasya takes advantage of it precisely because it was designed from the start to forgive network problems.
The best-known example is the lag switch, deliberately creating delays or short connection dropouts, and the internet has tools for this by the truckload, starting with perfectly innocent utilities for testing bad networks. Vasya "freezes" his outgoing traffic for a second, runs across an exposed stretch during that time, and everyone else sees his character twitch, vanish and then reappear already behind cover. With lag compensation you can also do the opposite: keep an artificially high ping so the server rewinds time further back, and Vasily, who on his own screen has already ducked behind a wall, still catches a bullet from the past. That's why the rewind window is always capped, and clients with too much latency get less benefit from it, even though every such restriction also hits honest players with bad connections.
The trouble is that latency by itself proves nothing. Vasily really might have bad Wi‑Fi, an overloaded router or a route to the server through half of Europe, and telling Vasya's periodic "slowdowns" apart from Vasily's problems is about as much fun as working at the local internet-censorship office. So instead of looking at a single high ping, they look at a combination of events: how regularly the dropouts repeat, the sequence of commands before and after the delay, and above all, how often a dropout coincides with a moment that's convenient for the player. And the more aggressive such a system is, the more often it turns into a ban generator for people whose access point just happens to be in an unlucky spot.
Messing with packet order
What does the router have to do with it? Well, packets can not only be delayed, but you can also try to shuffle their order or send sequences of messages the server didn't expect. If the protocol ties commands together poorly, a cunning Vasya can try to make different parts of the game process events in a different order, for example, accepting an action first and only then checking the condition that should have forbidden it. A packet arriving out of order isn't a cheat by itself, since any decent network protocol has to account for losses and reordering, but if the handlers rely on events always arriving in the expected sequence, Vasily gets a good chance of becoming a quick frag.
In early online games, manipulating the network exchange often made it possible to influence the course of a match, and once people learned to control delays deliberately, the lag switch became the scourge of racing games. But delaying packets and changing their order doesn't automatically mean the server can be fooled, and Vasya, being a man exceptionally attentive to other people's mistakes, decides to test that assumption in practice.
Bots, macros and cheating that isn't technical at all
Not every advantage requires digging into memory or the protocol. A macro repeats a combo with intervals identical down to the millisecond, a bot farms resources for hours while Vasya sleeps, and in games with a live economy those resources are then sold for real money. So bot operators have a thoroughly commercial interest, and developers have an entire department that hunts these bots by their overly regular daily routines and overly repetitive routes.
Beyond that lies territory where technology is barely needed. Vasya boosts other people's accounts for money by sitting down and playing on them himself. In a battle royale, Vasya and his buddy land in different squads, hop on a Discord call and team up against everyone else, and when Vasily is streaming, Vasya simply watches the broadcast and knows where he's hiding, which is why serious tournaments show matches with a delay.
An executable scanner is useless in such cases: the match is unfair, but there's nothing forbidden in the client, the participant is exploiting the rules from outside the game. That's why anti-cheat has gradually grown from a program that looks for a forbidden file into a system that watches the client, network events, match results and long-term account behavior. Big Brother is... how does the rest of it go?
Forcibly disconnecting your opponent
There's also the option where the goal isn't to win the firefight but to keep Vasily from finishing the match at all. In games with direct peer-to-peer connections or with poorly built network message handling, you can try to knock your opponent out of the session. Sometimes it's enough to trigger an error that makes the match hang or get declared invalid. That's no longer a lag switch, where Vasya ruins his own connection at a convenient moment, but an attack on someone else's connection or on the shared session. Defending against this has to be done architecturally: hiding players' addresses behind intermediate relays and not letting any single client control the lifecycle of the whole match.
This problem became more and more noticeable as online games moved from LANs and direct connections to mass internet sessions. In architectures where one of the players acted as host, that player could have more ways to influence the session, and deliberately dropping the connection sometimes made it possible to avoid a loss or wreck the match, which is annoying, of course, but contained. Nowadays such attacks get localized pretty quickly, and important matches are played on dedicated subnets that only work with trusted addresses.
(this is where I ran out of example GIFs)
Rating manipulation
Sometimes Vasya doesn't even try to cheat inside the match, but picks convenient opponents through the rating system itself: he queues up as a group with suitable accounts or exploits quirks in how rating is awarded after a win. Here the vulnerability lies in the algorithms that decide whom Vasya will play against and how many points he'll get for the result. Technically, violations like these are very hard to catch, and the line between a violation and merely unpleasant behavior can only be drawn by meatbags, while from the system's point of view it's all permissible, even though it distorts matchmaking, the economy and trust in the leaderboards.
This variety of, let's call them "rating cheats", appeared and evolved in parallel with ratings, ranked matches and automatic matchmaking. As soon as games started measuring a player's skill with a number and using it to build matches, there were people who wanted to control that number by more than just honest wins.
Intentional losses (aka deranking, or intentional losing) were used to get into easier matches, and on a smurf account, Vasya in a good mood goes to "relax" at a low rating, where his opponent turns out to be Vasily, who has only just started figuring out the game. Later came queue manipulation, match-fixing and thrown matches between players who know each other, including at tournaments, to influence the rating algorithms.
Unlike a wallhack, here Vasya may not install anything at all, because he's exploiting not the client code but people and the rules of the system itself, which is probably the nastiest case for a developer. All that's left is to analyze match results, links between accounts and player behavior over a span of several months... as Uncle Gabe used to say, you can't bake kitten pies without one important ingredient.
Vasya's life after the ban
Sooner or later Vasya gets banned, and it turns out that for him it's more of an inconvenience than a punishment. In a free-to-play game a new account costs one email address, so after accounts they start banning hardware: the anti-cheat remembers serial numbers of drives and the motherboard, MAC addresses and other identifiers, and on the second lap Vasya learns about HWID spoofers that fake those identifiers. Next come binding to a phone number or a payment method, restrictions on ranked modes for new accounts, and each such step makes Vasya's next attempt more expensive, but at the same time complicates life for Vasily, who just bought a new laptop or changed his number.
Another technique invented against Vasya is ban waves. If you ban immediately after a detection fires, Vasya gets very precise feedback: this version of the cheat got caught and that one didn't, and the cheat developer quickly fixes whatever he was caught by. That's why confirmed cheaters are often accumulated for weeks and banned in one wave, so it's much harder to link a ban to a specific detection, and those who paid for a cheat subscription get time to renew it.
And before the ban, Vasya can spend quite a long time playing in his own separate world. Systems like Trust Factor in CS match players with similar reputations, and accounts with a suspicious history gradually start meeting mostly each other. Vasya isn't formally banned and keeps winning, only now he's beating other Vasyas just like him, and Vasily doesn't notice anything, because he's simply stopped running into them.
What protection is actually made of
The most reliable protection is still the right distribution of trust, and that's where everything starts. The server itself owns the important state: character position, health, inventory, currency, progress and match results; client commands are checked for validity, and critical actions are limited by frequency and context, so Vasya can't earn in a second what the rules say takes weeks, skip a level with a single command or spend an item he never had. This layer doesn't catch cheaters at all; it simply makes a large share of cheats pointless.
On top of it runs the client-side anti-cheat, which checks the integrity of the game process, looks for known tampering tools and notices attempts to read or modify the game's memory. Some of these solutions live in user mode, while others install a kernel driver along with the game that sees the system far more broadly, and there have long been arguments around these drivers about privacy and security, since the game is effectively being given rights that most other programs on the computer don't have. Most players, Vasily included, have long accepted such a driver as a given and install it without reading, while Vasya responds by moving where the driver can't reach: DMA cards and second computers.
The third part is behavioral analysis, handled by dedicated teams. They gather everything available to the server, from movement heatmaps and command history to action tempo, accuracy and streaks of results, and look for a picture that's hard to explain as human play. A single perfect shot proves nothing; a good player can pull off a beautiful frag. But when, over a long series of matches, unusually precise aiming, improbable reactions and knowledge of positions that couldn't have been scouted all add up, the suspicion becomes well-founded, and that's usually when the ban wave arrives.
It's Vasya who needs to be fooled
One of the most charming approaches was shown by Activision when in 2023 it added so-called hallucinations to Ricochet. The idea is to create decoys in the world that are visible only through a cheat: fake targets behind or inside a wall that an honest client doesn't render and that Vasily will never know about. If Vasya starts tracking an empty spot, aims there or rounds a corner as if someone were standing there, the server gets a signal that his client sees more than it should, and the cheat effectively rats out its own owner.
The same logic is behind measures that don't so much punish as disarm. Ricochet, for example, has a mode in which a suspicious player's bullets stop dealing damage, and a mode in which he loses his weapon right in the middle of a match, while Vasya meanwhile keeps thinking he's just having bad luck. For a competitive shooter this is a controversial move, but the general principle is useful: first keep the exploit from ruining Vasily's match, and only then calmly deal with the punishment.
This is also where it becomes clear why all matches write detailed logs. Every match has an identifier, events and timestamps of player actions that can be tied to a specific session; replays are built from them and independent statistics are collected. Logs by themselves won't find an aimbot, but they make it possible to take apart a specific incident, check Vasily's complaint and keep one spoiled lobby from becoming a problem for the whole service.
But it's Vasily who gets fooled again...
So far in this story the developer has been protecting Vasily from Vasya, but trust works both ways, and a commercial game can also use technical means in a way that leaves the player completely misunderstanding what's going on. The nastiest example is bots posing as live players: with human nicknames, avatars and match histories, they fill empty slots in lobbies and, if the operator so wishes, can help certain participants get better results. Vasily thinks he's competing against people, sometimes even for real money or prizes, while some of his opponents are generated by the platform, and accusations of this kind surface in the industry from time to time.
It's important not to confuse this with honest bots. Bots in PvE, in training mode or in a queue where the game tells you outright that it has added artificial opponents are a perfectly reasonable way to cut waiting times, and technically they may be the very same bots running the very same algorithms. The only difference is that Vasily was told the truth, and when money depends on the outcome of a match, that difference stops being a trifle.
Softer forms are even more common: "offer expires in 10 minutes" timers, rewards that vanish if you don't log in tomorrow, endless quest chains that nudge you to come back right now. A timer by itself isn't a deception, and a progression system doesn't have to be built against the player, but when the real odds of getting a reward, the nature of your opponents or the terms of the competition are deliberately hidden, you can no longer call it good UX.
In essence it's the same Vasya, just sitting on the other side of the server. Vasya wants the server to believe a false claim about a position, a hit or a balance, while a dishonest game wants Vasily to believe a false claim about the number of live opponents or the meaning of a result, and in both cases one side makes a decision based on information it can't verify for itself.
Fair play doesn't start with anti-cheat
You can't eliminate cheating with any one method; it's not an AntiCheat = true flag after which all participants suddenly become honest. Every new defense changes the economics of making cheats, every new cheat forces you to reconsider where the boundary of the work already done lies, and over the course of this article Vasya has gone from a memory scanner to a second computer with a capture card, not because he finds it more interesting, but because all the simpler roads were closed to him one by one.
Most of those closed roads look completely unspectacular: the client isn't given powers it doesn't need, critical changes are validated on the server, items move in transactions, matches are isolated from one another, enough data is collected for investigations, and suspicion isn't confused with proof. None of this ever makes it into YouTube or Twitch videos, but in return forty Vasilys on a Friday evening are arguing about weapon balance instead of fuming about a quick-handed Vasya who's shown up on the server.
All articles