Offline progression is great for players. They can play on a train, on a tablet, or with weak mobile internet. But offline mode creates a hard security question: how much should the game trust data that was created while the server was not watching?
Start with a damage limit
The best first question is not "Can this be hacked?" The answer is always yes, given enough effort. A better question is, "What is the maximum damage if this offline data is edited?"
If offline mode can create unlimited premium currency, ranked points, or rare tradeable items, the risk is high. If offline mode can only unlock a few local levels or collect small capped rewards, the risk is lower.
Put those limits in product terms before implementation starts. For example: "offline mode can earn at most two hours of idle rewards," or "offline crafting can queue common items, but rare event rewards sync online." Clear rules make the later technical checks much easier to explain and enforce.
Protect local state
Offline progress needs local storage. Protect that storage with encryption, integrity checks, versioning, and rollback detection. Anti-Cheat can help protect PlayerPrefs and file-based saves so simple edits are easier to detect.
Protected storage does not make the client fully trusted. It makes tampering harder and gives the game a signal when something looks wrong.
Store more than the current progress value. Include a save version, last trusted server revision, monotonic local sequence number, and integrity tag. If the player restores an older save, the server can see that the client is trying to sync from a stale revision instead of treating the uploaded state as fresh truth.
Queue actions instead of trusting totals
Instead of only storing "new balance is 5000," store a queue of actions: completed level, earned reward, spent item, claimed daily bonus. When the player reconnects, the server can review the actions and rebuild the result.
This gives the server more context. It can reject impossible actions, duplicate claims, invalid timing, or rewards that exceed offline limits.
The important fields are the action ID and the source context. An action ID lets the backend process retries safely. The source context tells the server whether the reward came from a level, event, crafting recipe, idle timer, or purchase-related flow.
Use server reconciliation
Reconciliation means the server compares offline claims against server rules. It can approve, reduce, delay, or reject rewards. It can also flag accounts that repeatedly send impossible offline progress.
This works best when players understand the rules. For example, you can allow offline rewards but show that some rewards sync when the device is online again.
Real systems usually keep a ledger of accepted, reduced, rejected, and duplicate actions. That ledger is useful for support, fraud review, and fixing bugs in offline rules without guessing why a player's progress changed.
Be careful with time
Device time is easy to change. Daily rewards, energy systems, crafting timers, and offline earnings should not blindly trust the phone clock. Use server time when online, store last trusted sync time, and limit how much offline time can be claimed.
Also track drift. If a device repeatedly jumps forward before claiming rewards and then jumps back before syncing, treat that as a signal. You do not need to ban immediately, but you can cap rewards, require a fresh online sync, or move high-value timers to server-owned state.
Separate low-risk and high-risk progress
Low-risk progress can be generous offline. Story progress, local achievements, settings, and non-tradeable cosmetics may be acceptable. High-risk progress needs limits: premium currency, ranked points, competitive rewards, tradeable items, and event prizes.
A useful pattern is "local now, trusted later." Let the client show offline progress immediately for a good player experience, but mark high-risk rewards as pending until the backend confirms them. This keeps offline play smooth without letting edited local state become permanent economy truth.
Log suspicious offline patterns
Watch for repeated rollbacks, impossible reward amounts, time jumps, duplicate claims, and offline sessions that always end with perfect outcomes. These signals can help you tune limits without punishing honest players too quickly.
Log the save revision, action IDs, offline duration, claimed reward totals, reduced rewards, rejected actions, and device-time drift. Those fields help you tell the difference between a broken rule, a bad network session, and repeated manipulation.
Do
- Protect offline saves with encryption, integrity checks, and versioning.
- Queue important offline actions and reconcile them with the server later.
- Set clear limits for offline rewards, currency, timers, and repeatable events.
- Give each offline action a unique ID so reconnect retries cannot apply it twice.
Don't
- Do not let offline mode create unlimited premium currency or ranked progress.
- Do not trust device time for valuable rewards without checks.
- Do not accept offline actions blindly when the player reconnects.