A multiplayer game asks several computers to agree on one world. Each player controls a client, the program that sends their input and draws their view. The player also controls the machine running it. That machine cannot be the sole authority for shared positions, scores, and rewards.
Anti-cheat combines controls that prevent, detect, and respond to unauthorized advantages in the shared game. It includes game design, server validation, client protection, investigation, and enforcement. A scanner alone cannot repair a game that accepts any score a client sends.
Section: Requests cross an authority boundary.
An authority boundary separates a request from the party allowed to decide its result. In Lesson 9.10, a Source client predicts movement, while the server owns the accepted simulation.
Consider a toy game with three points already earned. One uncollected coin is worth one point. A client claims that its score is now 99. The server ignores that claimed total. It checks whether the player’s simulated position reaches the available coin. A valid pickup removes the coin and adds its reward: 3 + 1 equals 4.
Context: The claimed score is a message from the client. The starting score and remaining coin belong to the server’s own state; only the accepted pickup changes them.
The boundary prevents this score manipulation even if the client display has been changed. Detection can still help explain the attempted request, but protecting the result does not have to wait for an account ban.
In brief: Protect the shared result first. Decide what a suspicious request means using its context.
Section: Different advantages leave different observations.
An information advantage exposes something the player should not know, such as an opponent behind a wall. An input advantage automates decisions or timing that the game requires the player to control. A state advantage changes movement, damage, inventory, or another accepted result.
Other problems involve message order and volume, account abuse, or the game’s economy. A reward request arriving twice may be a normal retry after packet loss. The game must prevent duplicate rewards before deciding whether the repetition was malicious.
These categories overlap. They describe changes to available information, control of actions, or accepted game state. An accessibility device and an automation tool may both produce unusual inputs. Policy, supported controls, and the actual advantage matter when interpreting them.
Section: Prevent, detect, and respond.
Prevention stops an invalid effect. A server rejects movement through a solid wall or refuses a purchase without sufficient currency. Detection identifies an observation worth investigating. A sequence of inconsistent movement commands may trigger a recorded flag. Deterrence makes abuse less attractive through clear enforcement policies and credible consequences. Mitigation reduces harm while a case is being resolved.
These jobs need different evidence. A malformed request can be rejected immediately. An irreversible accusation needs stronger support than an unusual mouse movement. Publicly accusing a player also exposes them to harassment, so a defender should separate internal investigation from public messaging.
Section: A false flag has a cost.
A false positive is an honest case incorrectly marked suspicious. A false negative is cheating that the detector misses. Neither rate can be understood by looking only at players already banned.
Telemetry is recorded information about a running system. Useful telemetry includes the version of the check, server state, command timing, and the reason a check failed. It lets an investigator reproduce a decision and notice when a game update changes legitimate behavior.
An enforcement system also needs corrections and appeals. Keep the evidence needed to review a case, limit who can access it, and stop collecting data that does not help protect the game. This chapter studies defenses in owned offline examples. It does not require testing a live service or another player’s machine.