Game Development Reference
In-Depth Information
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.
Persistent Worlds
A good many online games are not really games at all by the definition you learned
in Chapter 1, “Games and Video Games.” Persistent worlds such as
World of Warcraf t
,
EverQuest
,
Anarchy Online
, and so on constitute permanent environments in which
players can play, retaining the state of their avatar from one session to another.
Persistent worlds present a number of special problems and design requirements,
which this section discusses at a general level. For a more in-depth discussion, read
Designing Virtual Worlds
by Richard Bartle (Bartle, 2003), and
Developing Online
Games: An Insider's Guide
by Jessica Mulligan and Bridgette Patrovsky (Mulligan and
Patrovsky, 2003).
