Games using anti-cheats and their compatibility with GNU/Linux or Wine/Proton

Relevance of the site / list

• Some worry the catalog looks stale (many entries 3–4 years old). Others argue it’s still accurate because anti‑cheat status rarely changes, and when it does, entries get updated quickly.
• Several commenters say they now simply avoid buying games that don’t work on Linux; publishers lose sales when they insist on incompatible anti‑cheat.

Why anti‑cheat is hard on Linux

• One side claims Linux makes cheating easier: users can load arbitrary kernel modules, lack vendor‑locked secure boot, and bypass the integrity assumptions Windows anti‑cheats rely on.
• Others counter that Linux supports secure boot and TPM just fine, but the keys are user‑controlled, which conflicts with anti‑cheat vendors wanting ultimate authority.
• Proposals: a Valve‑controlled or OEM‑locked distro / mode with measured boot, attestation and enforced driver signing; or running the game in protected VMs. Many note this would effectively turn PCs into consoles and is culturally incompatible with typical Linux expectations.

Fundamental limits of client‑side anti‑cheat

• Broad agreement: no client‑side anti‑cheat is unbypassable, on any OS. Hardware and “out‑of‑band” attacks (HDMI capture + vision models, DMA cards, fake input devices, even robots pressing keys) can always win.
• Thus, anti‑cheat is about making cheating inconvenient and expensive enough that most people don’t bother, not about 100% elimination.

Server‑side checks vs client control

• Many advocate server‑authoritative designs and minimizing information sent to clients (to blunt wallhacks, ESP, etc.). Others note practical limits: latency, visibility prediction, audio, and geometry checks make perfect culling infeasible in fast 3D games.
• Statistical and ML‑based detection (reaction times, aim patterns, resource gathering) is used in some games, but suffers from arms‑race dynamics and false positives, especially at high skill levels.
• Several argue that some cheats—aimbots, instant reactions, automation—cannot be fully mitigated server‑side without fundamentally changing game design (e.g., auto‑aim for everyone, slower mechanics).

Centralized matchmaking vs community servers

• Many blame the rise of always‑online, publisher‑run matchmaking for today’s rootkit‑style anti‑cheats: players can’t run their own servers or votekick, so all enforcement must be centralized and automated.
• Defenders of dedicated community servers say smaller, socially cohesive groups with human admins and demos/replays greatly reduce cheating and toxicity, at the cost of convenience and global ranking.

Security, privacy, and user attitudes

• Kernel‑level anti‑cheats are widely described as rootkits and a serious attack surface; people reference past crashes and the risk of exploits with full kernel privileges.
• Some players accept invasive anti‑cheat on a “sacrificial” Windows or console machine while keeping important data on Linux; others refuse any game that requires such software.
• Several note that anti‑cheat increasingly protects monetization as much as competitive integrity (e.g., cosmetic grinds, gacha, in‑game currencies), and is even used in purely PvE or co‑op titles.

Linux gaming workarounds and alternatives

• Many report that most non–kernel‑anti‑cheat titles now run fine under Proton; a handful of competitive games (notably some shooters and MOBAs) are the main holdouts.
• There’s interest in cloud gaming (e.g., GPU streaming services) as a way to play harsh anti‑cheat titles from Linux, offloading the rootkits to someone else’s hardware.
• Consoles are mentioned as a clean separation: locked‑down boxes for competitive games, Linux PCs for everything else, mods, and emulation.