There are several attractions to using the Internet to play games. The Internet can make games available to large numbers of users on a round-the-clock basis. The Internet can provide users with the opportunity to build global support communities for particular games and allow direct marketing of game-related items to consumers.

It is harder to add Internet capability to a game after it is written than during the design phase. There are several networking issues that must be taken into a count when a multiplayer game is being designed.

Session-Oriented Multiplayer Games

Not every multiplayer game is amenable to delivery on the Internet. In many ways, turn-based games are easier to deploy than fighting games because of inherent latency problems with Internet communications.

Even for turnbased games, designers need to decide whether new players can drop in at any time or whether they can join only at fixed points in the game. In session-oriented multiplayer games, new players can join the game only when a new round or a new level of play begins.

Sometimes this decision is related to whether the online game is designed to be short in duration or whether it will be a persistent game, which never ends and in which players drop in and out. Designers need to consider what will happen to the lost entities created as players or servers drop out of games.

Should an AI take over for a lost entity? Can a backup server replace a lost network connection? In games that last longer than 3 hr, it is important for users to be able to save incomplete games or characters they developed. Whether a game should be saved on the server or on a client machine may depend on the size of the gamestate information structure.

Synchronization Problems

With networked game communications, the key problem is synchronizing the sharing of game-state information among several users in a timely manner. One solution is to use state synchronization, which requires each player’s game instance to send a copy of its current state information to each of the other game instances.

This requires a lot of bandwidth and takes a lot of time in the peerto- peer model. A second solution is to use input synchronization. This requires each game instance to communicate its player’s input to each of the other game instances. This reduces the amount of bandwidth required.

If a game includes random events that do not depend on user inputs, the input synchronization system can fall apart. When random events are allowed in game play, a combination of these two synchronization techniques may need to be used.

This means that a game instance may need to share information on its user’s input as well as on changes in its game-state information with each other game instance following a random event.

Information-Sharing Concerns

The problem of sharing information in a timely manner among widely scattered Internet users has two other dimensions: bandwidth and latency. Bandwidth issues can be dealt with after a game is written by using such techniques as data compression or by limiting the number of game players.

Latency must be addressed during the design. If peer-to-peer networking is used for a multiplayer game, it is sometimes wise to make one of the peer machines take on the added responsibility of relaying messages to all game players, much like a server would do in the client/server model.

Intelligent routing schemes might also need to be used. It is doesn’t matter whether each player in a multiplayer game has exactly the same view of the game state or not. The only thing that matters is that players do not miss seeing important events (e.g., when one player shoots at another).

In modern operating systems, it is possible to separate game communication from graphics displays (renderings) by using separate threads for communication and rendering. Dead reckoning is used to render game objects based on their last known information (e.g., heading and velocity). This reduces the amount of information that must be shared among players. This also helps deal with unreliable network connections.

If a connection is lost, dead reckoning can be used to predict the game-state changes until the connection is restored. This assumes that no major changes take place during the time the connection is missing. Sometimes it is wise to build in delays to the time required to process each user input, so that when delays occur, the users do not notice them as much.

In the real world, humans cannot see objects beyond the horizon or in the next room. It is not necessary to render these objects until the player could reasonably expect to see them. Sometimes the client needs to keep two copies of the game state.

One copy contains changes based on the actual actions taken by all players, and one copy contains changes made by dead reckoning. When information is received indicating that the copies are no longer acceptably in synch, the state discrepancies need to be fixed by the client when it is convenient.

Sometimes these discrepancies can be hidden from the player by scheduling game-state changes two or three virtual time periods in the game’s future story line and waiting to render them on the screen until their correctness is verified.

Network Protocol Trade-offs

Sometimes designers need to consider carefully which networking protocols provide the best means of communicating among game clients. Much of the time, Internet communication is done using the TCP protocol, which is reliable, stream oriented, connection persistent, and slow.

Part of the reason it is slow is that although data packets are always delivered, the packets must be assembled before the message can be delivered. The UDP/IP protocol is unreliable and has small packets and very low overhead.

The UDP/IP protocol can be much faster than TCP, but the programmer has the responsibility of checking information to see that it is received in the proper order (Bernier, 2000). Simply using faster network connections (e.g., Internet2) does not eliminate the need to consider these trade-offs between TCP and UDP/IP.