Game Development Reference
In-Depth Information
for each ( s in remotes ) {
s.updateRemote(m_ship.x, m_ship.getCoord());
m_map.update(s, true);
}
}
The position is broadcast as an action, so it will not be cached on the server for the
game session, and is not required anyway.
The game loop is called after every 10 milliseconds and the network update
frequency is set to 200 milliseconds. We send up the ships' IDs (masks), universe X
coordinates, Y screen positions, and current speed.
We will create and maintain a
SpaceShip
instance for each remote ship. We will
update the ships' x and y based on the last received update.
There are two issues we need to deal with. First, we receive the updates of the other
ships at the rate of five times per second, while we update everything else on the
screen every 10 milliseconds. This calls for interpolating others ships' positions based
on the last received update. We can do so since we have the last known position and
the speed. And there is another catch: the position we received was via the network
and the server. This means that even the last update we received of the ship is not of
the present moment. All network packets going over the server suffer from this lag.
This calls for prediction.
We will simply add the time it took for the packet because it was created and sent
over the network. However, it is quite impossible to determine the exact time
taken even with a sophisticated time synchronization algorithms. We can at best
approximate the average lag the packet suffered. In Pulse or other client-server-
based implementation, the packet has to travel from the originating client to the
server and then to the destination client. The lag would not be the same for all clients
connected to the server and to make matters worse, the lag does not remain constant
between clients and the server over time.
