HTML and CSS Reference
In-Depth Information
Tips and Tricks
The following sections illustrate some handy tips and tricks for writing network code.
Keep Client Input Times Monotonically Increasing
If the client predicts that one of his or her inputs will arrive at time
t
, then the following input from that client should
have an expected arrival time greater than
t
. Note that, because latency between connections changes randomly and
as new players arrive and leave, many input delay calculations can cause the time not to be monotonically increasing.
In this case, artificially set the input time slightly higher than the previous until the times stabilize. Assuming that
inputs from other clients are monotonically increasing in time makes coding the receiving logic simpler and reduces
the number of fast-forwards.
Keep the Game State Independent from the Rest of the Game
Consider a hockey game, in which the goalie's position determines whether he or she blocks a slap shot. The goalie's
position must be included in the game state. It may be tempting to use the model from the graphics engine to determine
whether the slap shot is blocked, but this removes the isolation of the game engine from the rest of the system. Removing
this isolation makes fast-forwarding problematic (e.g., graphics engines are often capped at a certain number of frames
per second [FPS] and will not run any higher). Do not make the game state depend on the state of the graphics or physics
engine. If the game logic depends on physics, then the physics engine needs to be part of the game state (i.e., the physics
state should be copied into the game state at every frame).
Avoid Floating Point in the Game State
As mentioned previously, floating-point calculations are not deterministic across machines. This is because some
processors have special instructions that allow them to do floating-point math with higher precision than others. Also,
some compilers are more aware of these special instructions and will use them at different times from other compilers.
With JavaScript in particular, all arithmetic is performed in floating point. Although this technically means that no math
can be performed on the game state, in practice all operations on small integers (i.e., less than one million) will yield
the same result across processors, operating systems, and interpreters. Note that most physics engines involve many
floating-point calculations. In this case, expect that clients will be slightly out of sync, use the state broadcast method,
and continuously correct the physics engine as new states arrive. To use client-side prediction, the physics engine must
be fast enough to support fast-forwarding and be able to serialize/restore the state of the engine to the game state.
Keep the Game Engine Small
The game state should only include the information necessary to run a headless (i.e., graphic-less) version of your
game. Images, textures, music files, your site's URL, and other information that does not directly affect game logic
should not be part of the game state. Keeping your game state small has a dramatic effect on the overall bandwidth
consumption of the network. Also, maintaining a light game engine will make it easier to fast-forward the game when
the client needs to catch up. Separate the game engine from the rest of the system so that it can be updated without
updating graphics, sound, or other parts of the game. Physics engines again complicate this, because they often have
an unavoidable effect on the game engine. In this case, the physics engine needs to be considered part of the game
engine, and the physics world state, part of the game state.
