FUNDAMENTALS OF GAME DESIGN, SECOND EDITION

DON’T STORE SENSITIVE DATA ON THE PLAYER’S COMPUTER

A game typically contains two kinds of data about a player. Your game needs to keep settings or preferences about the way the player appears and likes to play, as well as information that's actually relevant to the game state: the player's position, score, possessions, and so on. In Monopoly, for instance, the player's playing piece (hat, shoe, car, and so on) belongs in the former category; it doesn't matter to the state of the game which token the player uses. However, the player's properties, cash, and position on the board belong in the latter category; changes to those attributes affect the player's status in the game.

This second kind of information shouldn't be stored on the player's own computer. Even with encryption techniques, you have to assume that someone will tamper with any data kept on the player's machine to give that player an unfair advantage. If your game truly generates too much sensitive data about each character to store it all on the server, at least store a checksum over the data when the player logs out so that when he logs back in again, you can check his data and determine whether it has been improperly modified in the meantime.

DON’T SEND THE PLAYER DATA HE ISN’T SUPPOSED TO HAVE

A common characteristic of real-time strategy games is the fog of war, in which unexplored areas of the map appear dark and the player cannot detect movements of the enemy unless a friendly unit nearby can plausibly see them. Single-player games store all of this information in the player's computer; it's just not visible to the player. Online games should not send any such hidden information to the player. If the player hacks the game to lift the fog of war, he can see unexplored areas and watch the movements of enemy units, giving him a significant advantage over his opponents.

DON’T LET THE CLIENT PERFORM SENSITIVE OPERATIONS

In designing a client/server game, you must always strike a balance between the amount of processing that the server does and the amount that the client does. It saves CPU time on the server for you to offload as much of the processing work onto the client as you can, but it isn't always safe. Suppose, for example, that you're designing a simple role-playing game in which the player occasionally encounters monsters and must fight them. It reduces the load on the server if the server sends the client some information about the current monster and lets the fight take place entirely on the player's computer. After the fight, the client sends a message back to the server reporting whether the player won, lost, or ran away, but this presents a danger: If the player hacks the client, he can program it to report that he wins every fight. In fact, the server, not the client, should perform the computations for the fight and determine whether the player won or lost.