Going Real Time - HTML5 Mobile Game Development - page 421

Figure 21-1: A game of pong between Safari and Firefox.
As mentioned, although this is a lot of code to look at in one pass, the majority of it should look familiar
from Block Break. After the initial engine set-up code, the game defines three paddle classes.
The first, Q.Paddle , simply defines a paddle that moves left or right depending on its direction attribute.
The draw method is also overridden to draw a simple black rectangle.
The second paddle class inherits from Q.Paddle and defines the player's paddle: Q.PlayerPaddle . Its
only job is to override the step method to control the direction property based on player input. It also emits
a move event to the server that includes its direction and current x position every time its direction changes.
The third paddle class, Q.EnemyPaddle , represents the opposing paddle when the player is playing. Its
only override from the base Q.Paddle class is to bind to the socket to set the paddle's direction and position.
This is the move message passed from the Q.PlayerPaddle passed through by the app server.
The Q.Ball class used to represent the ball bears a lot of similarities to the ball from Block Break. The
primary difference is that properties of the ball here either are updated occasionally by the server or periodically
sent to the server to pass to the other player.
Even though both games are simulating the game at theoretically the same speed, differences in clocks, net-
work delays, and graphics capabilities mean that the two clients would slowly fall out of sync with each oth-
er. To combat this, the full position and direction of the ball is passed from client to the server at a rate of
ballRate , which is set to half of a second in the example.