Real-Time Multiplayer Network Programming - HTML5 Game Development Insights - page 195

Interpolate Between Game States
Because of bandwidth limitations, the game state can only update ten or fewer times a second, yet most games run at
60 FPS. The way to ensure that your game is smooth is to interpolate the graphics between game states. For example,
if the unit is at position 1 in the current game state, and that same unit is known to be at position 2 in the next game
state, the graphics engine can slide that unit from 1 to 2 while the game engine is in between states. Interpolation also
lessens the effect of server correction by smoothly sliding units into their correct positions.

Do not Assume a Particular Sequence of Game States
Many graphical and sound effects depend on a particular game-state change, such as scoring a point. Note that,
because the server is updating the client's game state, and the client is trying to predict future game states that may
not be accurate, any subsequent graphical or sound effects may be invalid. Care must be taken to ensure that the
graphics and sounds are still smooth, despite jumps in game state. One method for handling this is only to play
notification sounds when the server and the client agree on an event.

Send Checksums of the Game State
Because bugs in the network engine typically do not crash the game, it is important to send checksums of the game
state frequently. A checksum is a small sequence of characters intended to describe a larger block of data. Although
it is possible, in theory, for two clients to have a different game state with the same checksum, it is highly unlikely.
Adding and verifying checksums will allow you to catch errors as soon as such errors cause the game state to go out
of sync. Checksums make the debugging process much simpler by isolating exactly where there can be a bug in the
code. One common method of generating a checksum in JavaScript is to stringify the game-state object and then use a
library, such as CryptoJS ( https://code.google.com/p/crypto-js/ ) , to hash the string. This small hash can then be
passed around as the checksum.

Case Study: FrightCycle
FrightCycle is a Halloween-themed light-cycle racing game, in which players try to trap each other with the trail of
their light cycle, while also avoiding collision with other trails, their own trail, and the sides of the map. FrightCycle fits
the description of a real-time multiplayer network game because all players make decisions simultaneously, timing is
of importance, and several players can play a game across the Internet. To view the repository for FrightCycle , visit the
following URL: https://github.com/MisterTea/JSRealtimeNetworking .
The next sections begin with an overview of the technology used in FrightCycle and then discuss the specifics of
implementing a state broadcast system with time synchronization and client-side prediction.

Getting Started
Although much of the technology in FrightCycle is not specific to real-time network programming and is thus
outside the scope of this chapter, it is important to spend some time explaining the code base. First, let's look at the
dependencies:

• Browserify allows the same “require” syntax (known as CommonJS requires) in

node.js to
work in browser-based JavaScript. Browserify can also obfuscate and compress client-side
JavaScript.

•

Socket.IO is an event-based WebSocket client and server library. This library handles the
real-time communication in FrightCycle .