Why Games Need Anti-Cheat
Separate a player's requests from the game's decisions, and connect prevention, detection, and fair enforcement.
Cheatsheet for Lesson 15.1
A one-page summary of “Why Games Need Anti-Cheat” you can keep beside your notes. Plain Markdown.
Lesson 15.1 — Why Games Need Anti-Cheat: cheatsheet
- Remember: Protect the shared result first. Decide what a suspicious request means using its context.
Key terms
- false positive: A false positive is an honest case incorrectly marked suspicious.
- false negative: A false negative is cheating that the detector misses.
- Telemetry: Telemetry is recorded information about a running system.
Review
- Q: A client claims score 99 in the toy world. The server has score 3 and one available one-point coin. What should determine the final score? A: The server validates the pickup and awards its one-point reward
- Q: Who controls the computer running a game client? A: The player using that client
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.
Requests cross an authority boundary
Section titled “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.
Request move to x = 900
Step 1: Client to Server: x = 100
A request, not a new position.
Alone 900 − 100 = 800 > 5: refuse
Step 2: Server: x = 100 (alone)
The step is measured from the server’s own position.
Reply you are at x = 100
Step 3: Server: x = 100 to Client
The client’s view snaps back.
The server knows the player was at x = 100 and allows at most 5 units per tick.
Request move to x = 104
Step 1: Client to Server: x = 100
A small step.
Alone 104 − 100 = 4 ≤ 5: accept
Step 2: Server: x = 100 (alone)
The server applies it to its own state.
Reply you are at x = 104
Step 3: Server: x = 100 to Client
The server, not the client, decided that.
The same check passes a request that fits the rules.
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 = 4.
Change the claimed score or pickup conditions. Watch the claim stop at the boundary; only an available coin reached in this toy world adds a point.
The claimed 99 is ignored. One accepted pickup adds one point. Score ends at 4.
Read the steps
- The server starts with score 3. The client can request an action, but cannot replace that score.
- A claimed score of 99 travels toward the boundary. The server does not use it.
- The claim stops at the authority boundary. Score remains 3.
- The server simulates the player reaching the coin position.
- The valid pickup consumes the available coin and sends its one-point reward to the score update.
- The final score is 4: 3 + 1. The claimed 99 never becomes the server's score.
This toy world starts with 3 points; an available, reached coin is worth one point.
This simulation needs JavaScript. The lesson text around it works through the same numbers.
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.
Different advantages leave different observations
Section titled “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.
Prevent, detect, and respond
Section titled “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.
A false flag has a cost
Section titled “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.
Who owns the reward?
A client claims score 99 in the toy world. The server has score 3 and one available one-point coin. What should determine the final score?
The server owns the available coin and reward. A permitted pickup changes 3 to 4; authentication and packet integrity do not make a claimed score authoritative.
Finished Lesson 15.1?
Mark it done and the lesson list shows a beside it. A chapter whose lessons are all done is marked done too. Progress is saved in this browser only.
Plain Markdown, saved in this browser.
This book grew out of the original Game Hacking Academy by attilathedud and has been rewritten as a beginner-first course. Like the original repository, its source is published under the Apache License 2.0.