When to use it
Good first targets are values that change often but through clear game events:
- health
- ammo
- cooldowns
- speed or damage multipliers
- match score or soft currency
Do not start with every value in the game. Pick one or two high-value targets and verify clean behavior first.
Mental model
The game must tell Korvayne which changes are legitimate. A direct write to a normal field gives the SDK no context.
Bad:
Health = Health - Damage
Good:
ProtectedHealth.Set(ProtectedHealth.Get() - Damage)
The second pattern updates the expected protected value. The guard can then detect when memory changes outside that path.
Integration pattern
- Create a protected value wrapper during player or match setup.
- Read through the wrapper when gameplay needs the current value.
- Write through the wrapper for damage, healing, reloads, cooldown resets, and other legitimate changes.
- Call the per-frame or periodic SDK tick recommended by the wrapper.
- Log first, then enable restore or termination only after normal gameplay is clean.
Actions
| Action | Behavior | Use |
|---|---|---|
report | Emit evidence only. | First integration tests. |
restore | Write the expected value back. | Useful friction against simple memory edits. |
terminate | Close the game when configured and licensed. | Only after testing and usually for strong signals. |
Scope
Blueprint and C# teams: expose named nodes or wrapper classes such as Protected Float - Get, Protected Float - Set, KorvayneProtectedFloat, and KorvayneProtectedInt. Users should not pass raw memory addresses.
For server-authoritative multiplayer, ValueGuard is still a client-side signal. The game server should remain authoritative for health, inventory, matchmaking, and rewards.
