HTML and CSS Reference
This introduction should be enough to get you started with Socket.io, but the next section shows you how to
build a simple pong game where two players can bounce a ball back and forth between each other.
Building a Multiplayer Pong Game Using
Using a WebSocket-based technology opens up a lot of different possibilities for multiplayer game play, includ-
ing real-time action games. To see this in action, you build a two-player pong game where players bat a ball
back and forth across the screen.
In the game, both players simulate the entire game on each device; however, one player acts as the “master,”
and one acts as the “slave.” The master controls the true location of the ball and sends updates periodically to
the slave, who updates the location of the ball to reflect the true game state.
Dealing with Latency
One of the problems with multiplayer, real-time gaming is the issue of latency. Depending on the speed of the
network and the distance between the server and players, latencies of more than 100ms and dropped packets
are common on mobile. This means that to keep the action going you need to do some predictive modeling that
takes latency into account.
Your pong game deals with this by calculating a “delay,” which is the time it takes to get a packet from one
player to another. It uses that delay to calculate how much farther the ball or other player should have moved
from the time the data left one player to the time it arrived at another.
Because both games simulate the path of the ball, each player should see the ball updating smoothly while
the slave player occasionally sees a blip course correction if the ball on one device is out of sync with the other
As you can see when playing the game, this works to varying levels of success depending on the browser
and connection. As of this writing, mobile devices still have a way to go with WebSocket support, so a semi-
real-time game might be a better option than a multiplayer action game.
There's only one way to combat cheating in a multiplayer HTML5 game: Never trust anything the client tells
you except for user input. This means that the server needs to simulate the entire game and take user input only
to update the state of the game.
Rather than, for example, a client saying, “My paddle is at x location 200,” the client tells the server, “I want
to move my paddle to the right,” and the server updates the position of the paddle appropriately, responding
to all the clients with the updated paddle position. Doing this means that the client can never tell the server to
do something that's not physically possible in the game because the server is going to calculate the only game
simulation that matters.
For example, in a game of pong, the player can't suddenly move from the left side of the screen to the right
side of the screen. If the server just accepts the player's paddle position as fact, though, this could happen.