| | 30 | |
| | 31 | === Cheat prevention === |
| | 32 | |
| | 33 | There are two main ways that players can cheat: |
| | 34 | * Accessing information they shouldn't have access to (e.g. details of their enemies' units that are hidden in the fog-of-war) |
| | 35 | * Modifying the world in ways they shouldn't be able to (e.g. giving themselves extra resources, or causing an enemy's unit to decide to turn around and walk away) |
| | 36 | |
| | 37 | It's impossible to prevent people reading information, so we can just try to make it harder (e.g. by expecting people to run officially validated binaries with some anti-debugger tricks etc). The simulation system is concerned with preventing unfair state modifications. |
| | 38 | |
| | 39 | Since multiplayer is based on synchronised simulation, we assume that all players are running the same basic simulation code, and we can control how it responds to inputs received over the network. (If they're not all the same, they'll go out of sync and the match will stop.) |
| | 40 | |
| | 41 | We can't stop people sending arbitrary commands over the network, so our job is to make sure the simulation code responds to those inputs in a way that makes it hard to cheat. In our model, the GUI is untrusted and can send arbitrary commands to the simulation; the only thing guaranteed by the engine is that each command will be associated with a player ID, which correctly matches the network client the command was received from. The simulation code therefore has sole responsibility for validating the actions against the player ID - make sure players can only move their own units, can only attack enemy units, can only build buildings in clear terrain and when they have sufficient resources, etc. The GUI might do some similar checks to provide immediate feedback to the user, but that must never be relied on. |
