Lesson 13: Anti-Cheat Systems & Security

With performance tuned and core gameplay in place, keeping your battle royale fair and secure is the next step. Cheats and exploits can ruin the experience and drive players away. This lesson covers how to design for server authority, validate client input, and apply practical anti-cheat measures so your game stays competitive and trustworthy.

By the end of this lesson you will have a clear security mindset, validation patterns for critical actions, and a short checklist to harden your Unreal multiplayer project.

What You'll Learn

By the end of this lesson, you will be able to:

• Apply server authority so the server is the source of truth for game state
• Validate critical actions (movement, damage, inventory) on the server before applying them
• Identify common cheat types (speed hacks, aimbots, wallhacks, packet manipulation) and how they relate to your architecture
• Use replication and RPCs safely so clients cannot forge or bypass server logic
• Plan for ongoing security (logging, metrics, and updates) without building a full anti-cheat SDK from scratch

Why This Matters

In a battle royale, fairness and trust are core to retention:

• Fair play – Validated, server-authoritative logic makes cheating harder and easier to detect
• Stable economy – If you have progression or monetization, server-side checks protect rewards and purchases
• Community health – Visible anti-cheat and clear policies help keep players and content creators engaged
• Platform and legal – Many storefronts and regions expect basic security and privacy practices

You do not need to implement a full proprietary anti-cheat on day one. You do need a solid foundation so that later additions (e.g. reporting, analytics, or a third-party solution) can plug in cleanly.

Prerequisites

Before starting this lesson, make sure you have:

• Completed Lessons 1–12 in this course
• A battle royale project with movement, combat, matchmaking, and performance tuning in place
• Basic familiarity with Unreal replication (replicated properties, RPCs, server vs. client execution)
• Access to your dedicated server or listen server setup for testing

Step 1: Enforce Server Authority

The golden rule of multiplayer security: the server decides. Clients send requests and display results; the server validates, applies, and replicates state.

What Should Run on the Server

• Movement and physics – Server simulates or validates position/speed; clients send input, not final coordinates
• Damage and health – Server applies damage, updates health, and replicates; clients never directly set health
• Inventory and items – Server grants/removes items and replicates; clients request actions (e.g. pick up, drop)
• Game rules – Match start/end, zone shrink, win conditions, respawn rules
• Sensitive RPCs – Any RPC that changes game state (e.g. “use item”, “buy from shop”) should run on the server and validate parameters

What Clients Do

• Send input (move, look, fire, use)
• Request actions via server RPCs (e.g. “request pick up this item”)
• Display replicated state (positions, health, inventory) and play local effects (audio, VFX)
• Optionally run client-side prediction for responsiveness, with server reconciliation

Pro Tip: In Blueprint and C++, always ask “who can call this, and who can change this value?” If a client can set a replicated variable or trigger a state change without server validation, treat it as a potential exploit.

Mini-Task: Audit One Critical System

Pick one system (e.g. damage, pickups, or movement) and list: (1) where the decision is made (client vs. server), (2) what the client sends, (3) what the server validates. If the client can directly set a replicated variable that affects fairness, plan to move that logic to the server and have the client only send inputs or requests.

Step 2: Validate Critical Inputs and Actions

Server authority only works if the server checks what it receives. Validation means: “Is this action allowed for this player, in this state, at this time?”

Movement and Position

• Do not trust client-reported position as the sole source of truth. Use server-side movement or server reconciliation (compare client position to server simulation and correct or reject).
• Reject moves that are impossible (e.g. too far in one frame, inside solid geometry, or outside playable area).
• Optionally use movement validation in Unreal (e.g. CharacterMovementComponent with server-side physics) so the server recomputes movement from input.

Damage and Combat

• Damage should be calculated and applied on the server (who shot whom, with what, at what distance).
• Validate: weapon exists, has ammo, is in range, line of sight if required, and cooldowns/rate limits.
• Reject duplicate or out-of-order damage events (e.g. same hit ID, or timestamp in the past).

Inventory and Economy

• All grants and removals (pickups, purchases, rewards) happen on the server.
• Validate: item exists, player is allowed to hold it, capacity limits, and (if applicable) cost and currency balance.
• Use server RPCs for “pick up”, “drop”, “use”, “buy”; server responds with updated replicated state.

Common Mistakes to Avoid

• Trusting client-reported stats – E.g. “I killed 10 players” must be derived on the server from actual damage/kill events.
• Allowing client to call multi-cast or server RPCs with arbitrary parameters – E.g. “deal 1000 damage to player X” must never be accepted as-is; server should compute damage from game state and rules.
• Skipping range/rate checks – Validate rate of actions (e.g. shots per second, pickups per second) to limit burst abuse.

Step 3: Understand Common Cheat Types and Mitigations

You do not have to solve all of these in one lesson. Prioritize: (1) server authority and validation for movement, damage, and inventory; (2) replication and relevance so clients do not receive data they should not see.

Step 4: Secure Replication and RPCs in Unreal

• Replicated variables – Only the server (or the owning client where intended) should set values that affect fairness. If a variable is replicated and affects scoring, health, or inventory, ensure only server logic writes it.
• Server RPCs – Use for actions that must run on the server (e.g. “RequestPickup”, “RequestUseItem”). Validate all parameters (actor refs, indices) and game state before applying.
• Client RPCs – Use for one-off effects (e.g. “PlayHitEffect”) or UI updates. Do not send sensitive data that could be used to gain an advantage (e.g. full enemy positions).
• Reliable vs. unreliable – Use Reliable for critical, rare events (e.g. purchase, level completion) so they are not dropped; use Unreliable for high-frequency, non-critical updates (e.g. position) to save bandwidth. Do not send critical state over unreliable RPCs and then trust it.

Pro Tip: In Unreal, mark server RPCs with UFUNCTION(Server, Reliable) (or Blueprint equivalent) and validate inside the server implementation. Keep client RPCs for “display only” or non-authoritative effects.

Step 5: Logging, Metrics, and Next Steps

You do not need a full anti-cheat SDK to start. You do need visibility:

• Log critical actions on the server (e.g. damage dealt, kills, pickups, purchases) with player ID, timestamp, and context. This supports debugging and later review of suspicious behavior.
• Metrics – Track rates of actions (e.g. kills per minute, accuracy) per player or per match. Extreme outliers can be flagged for manual or automated review.
• Policies – Define what is allowed (e.g. macros, streaming tools) and what is not (e.g. memory editing, packet injection). Publish and enforce via Terms of Service and in-game messaging.
• Updates – Plan for periodic security passes: new features should be reviewed for “who can call this, who can set this?” and validation added where needed.

If you later integrate a third-party anti-cheat (e.g. Easy Anti-Cheat, BattlEye), your server authority and validation still matter; those tools often focus on detection and enforcement on the client and/or server, while your game logic remains the foundation.

Troubleshooting

Summary

• Server authority – Server is the source of truth for movement, damage, inventory, and game rules; clients send input and requests and display replicated state.
• Validation – Server validates every critical action (position, damage, pickups, purchases) before applying; reject impossible or duplicate requests.
• Replication and RPCs – Only the server (or intended owner) sets replicated state that affects fairness; use Server RPCs for state-changing actions and validate their parameters.
• Common cheats – Mitigate with server-side logic (movement, damage, relevance) and avoid trusting client for authoritative data.
• Visibility – Log key actions and track metrics so you can debug and later improve detection and policy enforcement.

In the next lesson you will focus on Analytics & Player Data Collection: what to measure, how to instrument your battle royale, and how to use data for balance and operations without compromising privacy or performance.

For deeper reading, see Unreal Engine Multiplayer Programming and best practices for replication and RPCs. Found this useful? Bookmark it and share it with your team when designing your next multiplayer feature.