iPhone Game Development - Chris Craft [93]
In this world players can do the following:
Experience dynamic human interaction.
Play competitively against rivals.
Play cooperatively with friends.
Communicate and socialize with other players.
Form friendships and interact with distant players.
Connectivity is another area of interest and variety. Multiplayer games have changed a lot over the years and new technologies have been introduced that allow gamers to connect in more ways than ever before:
Head-to-head. Players play against each other on the same device with separate or shared controllers.
Peer-to-peer. Players in close proximity can connect with each other with wireless technologies like Bluetooth, with a shared network, or simply by using a cable between two devices.
Internet. Players connect with one or more other players on the World Wide Web.
Massive multiplayer. Players connect to a central server that is responsible for coordinating interaction between players and the game.
A game can be considered real-time if a player's interaction with the game environment is fluid and not suspended by another player's turn or input. In real life a game of air hockey at the arcade would be considered real-time. Playing a round of checkers would be an example of a turn-based game. It is important to understand the distinction between the two types of multiplayer games because the strategies employed to connect the players can be very different.
Connecting players on separate devices has some real challenges. Once connected, packets are continually and rapidly exchanged between participants. These packets contain information about player input, status, and anything else necessary to communicate changes in your virtual world. When exchanging packets, there are two issues that must be reckoned with: network latency and lost packets. Dealing with these issues can be a science of its own; however, for now, you need to at least be aware of the problems.
Network latency
Latency is the time it takes for a packet to travel from one device and to be processed by the connected device. This latency is generally short, but for real-time games it can be enough to render your game unplayable. Most real-time games deal with latency by being predictive, in which you measure the latency and use this information to predict the future move you expect the other player to make. For example, in some scenarios you can use the direction and speed of the remote player to calculate a player's next position, assuming the direction and speed will not change. When the next packet is received, you can correct incorrect predictions by making a smooth transition to the proper location. This generally goes unnoticed by players because they are not looking at the same device as remote players who see their actual location. The downside to this method is that occasionally a player may experience anomalies. For example, a person may walk through a wall or see a bullet appear 20 pixels in front of the cannon whenever a missed prediction is corrected.
Lost packets
Lost packets are easier to deal with than latency. Usually if you lose a packet you can interpolate the missing information. For instance, if you lose packet 2 you can interpolate it from information in packets 1 and 3. In other cases you can ignore lost packets and let your prediction logic for latency compensate for the missing data. This just means the latency will span a larger time interval if a packet is lost. At times you will need to send packets containing data that must be delivered. For example, if you are reporting that a player was destroyed, that message must be received on the other end. If critical messages like this are not received, the integrity of the game state is lost. When messages must be reliable, the recipient needs to issue a return receipt once the critical message arrives. If the