Concepts of Distributed 1 Running head: CONCEPTS OF DISTRIBUTED MULTIPLAYER GAME SYSTEMS Concepts of Distributed Multiplayer Game Systems Vanna Bushong Evangel University
Concepts of Distributed 2 Abstract The world of multiplayer online gaming is an ever expanding technology in which players around the world can connect their video game consoles to a network and compete against each other from remote locations. The following research explores the concepts involved in designing a distributed multiplayer game system that makes this type of play possible. This paper examines the network factors considered in the development of such a distributed system like bandwidth, latency, and processor power of the game consoles. It also analyzes various system architectures used for online gaming. Finally, it provides an explanation of the quality of service requirements for a distributed multiplayer game system.
Concepts of Distributed 3 Concepts of Distributed Multiplayer Game Systems When William Higinbotham created the first video game in 1958, called Tennis for Two, the entertainment world would never be the same. This primitive game was both created and played on an oscilloscope a device that displays a representation of an electrical current on a fluorescent screen in the Brookhaven National Laboratory (Bellis 2008). Since then, the development of video games and consoles has exploded. The progression of games over the years includes everything from Atari s Pong to Nintendo s Super Mario 64 to EA Sports Madden NFL 09. Game consoles have improved from the Odyssey and Atari 2600 of the 1970s to the Xbox 360, PlayStation 3, and Wii systems of today. The improved consoles led to a greater number of features, including one of today s most popular trends: online gaming. Playing games online meant users could play against opponents on different consoles over a network. Obviously this idea has made an enormous impact on the gaming world, since Microsoft s online game service Xbox LIVE now hosts over 12 million subscribers and Sony s PlayStation Network has 14 million users. These services that make it possible for users to play video games with each other from remote locations are called distributed multiplayer game systems. Distributed multiplayer game systems have some unique requirements because not only are they distributed systems, but each computer or game console involved is a multimedia system itself. A distributed system is a group of processors connected through a network. In this type of system, each individual processor has its own memory and clock, but it can share resources with the other processors through the network. This presents some initial challenges in sharing data efficiently and reliably. At the same time, each processor on the network is part of its own multimedia system. Multimedia systems incorporate audio and video files, and in the case of game systems, these have to be accessed by the user in real time. Therefore, the distributed system must meet the challenge of handling large amounts of data at real time speeds. (Silberschatz, Galvin, & Gagne, 2005)
Concepts of Distributed 4 Considering the complexity of making a distributed multiplayer game system function, this paper will cover some of the basic concepts involved in this challenge. The topics presented should lead to a better understanding of the problems these systems face and the possible ways to solve them. The following sections will address network considerations that must be made in designing the system, possible system architectures, and quality of service requirements. Network Considerations When designing a distributed multiplayer game system, there are some network limitations that first must be considered and addressed. These issues include bandwidth, latency, and the processor power needed to handle network demands. The first issue to be discussed is bandwidth, which is a communication line s transmission capacity, or the amount of data it can transfer per unit of time (Smed, Kaukoranta, & Hakonen, 2001). For example, in a wide area network (WAN), bandwidths may range from tens of kilobits per second to 44.7 megabits per second (Smed, Kaukoranta, & Hakonen, 2001). Local area networks (LANs) generally have faster bandwidths ranging from 10 megabits per second to 10 gigabits per second since they cover a smaller geographical area (Smed, Kaukoranta, & Hakonen, 2001). In the case of distributed game systems, it is common for the individual systems to be connected to their own local area networks and then be linked together with other systems across the country through a wide area network. Since the speed of the network directly affects the speed of online play, distributed system architectures are designed with the goal of reducing bandwidth requirements (Cronin, Filstrup, & Kurc, 2001). The second network consideration is latency, which Distinguished Engineer Jim Waldo (2008) of Sun Microsystems Laboratories described as the enemy of fun (p. 40). Latency is a term that describes the amount of time it takes for a packet of data that has been sent to reach its destination (Spurling 2004). Besides the actual travel time, extra factors like packet processing and routing must be added to
Concepts of Distributed 5 the total time (Smed, Kaukoranta, & Hakonen, 2001). Latency is a big issue for online gaming because the longer it takes to send and receive messages, the less fluid the picture becomes. Game play becomes more difficult; even impossible at some point. The actual point at which latency becomes a problem, however, depends on the type of game being played. For example, latency becomes noticeable at 100 ms and makes playing impossible at 200 ms for games such as first person shooters (FPS) that require precise hand-eye control and frequent updates on players movements and locations (Majewski, Griwodz, & Halvorsen, 2006). On the other hand, real-time strategy type games that do not require such fast response times can handle a much higher latency, perhaps up to 500 ms (Smed, Kaukoranta, & Hakonen, 2001). Since latency can only be reduced not completely eliminated game systems must be designed to simply deal with this problem in the best possible way. A third consideration to make in the design of a distributed game system is the processing power of the individual systems. It is easy to forget that the network itself may not be the cause of all problems, but that the game console running the system may be strained by the addition of network traffic (Smed, Kaukoranta, & Hakonen, 2001). Fortunately, the hardware available for gaming has improved over the years. For example, Microsoft s Xbox 360 contains a 3.2 GHz PowerPC processor with three dual-threaded cores (Thurrott 2007). Sony s PlayStation 3 has a 3.2 GHz cell processor that contains seven single-threaded synergistic processing units (Thurrott 2007). The question is whether the increase in hardware speeds will be able to keep up with the increase in processing requirements as more people join multiplayer game systems (Smed, Kaukoranta, & Hakonen, 2001). Since bandwidth, latency, and processor power are virtually uncontrollable by those designing a distributed game system, these are factors that must be taken into account. The following section will discuss some possible system architectures that have been developed to address the demands of online gaming.
Concepts of Distributed 6 System Architectures There have been three main distributed system architectures developed for online gaming, along with a few other hybrid models. The goal of each design is to handle network traffic in the most efficient manner, considering the elements of bandwidth, latency, and processing power outlined in the previous section. The main architectures include the peer-to-peer (P2P) model, the client-server model, and the server-network model. The peer-to-peer (P2P) architecture is one of the main multiplayer game models used today. When explaining such a model, it is helpful to think of each computer or game console as an individual node. As seen in Figure 1, each of the nodes in a P2P system are equal, and each one sends its messages to every other node on the network (Smed, Kaukoranta, & Hakonen, 2001). Every node stores its own copy of the game state, and when this changes, a message is sent to all the others to update their states as well (Spurling 2004). The P2P architecture can be a beneficial model, but it has its drawbacks as well. One of the benefits is that since each node in a P2P system is equal, there is no centralized server to cause a bottleneck of bandwidth (Spurling 2004). Also, this model makes it fairly easy to expand a game from single player to multiplayer (Smed, Kaukoranta, & Hakonen, 2001). The problems with this architecture,
Concepts of Distributed 7 however, may outweigh the benefits in many situations. For example, network factors like latency make it difficult to keep the game states synchronized on each node (Spurling 2004). Also, scaling the adapting of a system to a change in network load becomes difficult since there is no hierarchy in this architecture (Smed, Kaukoranta, & Hakonen, 2001). Therefore, this model is probably best for a small group of players on a local network. The client-server architecture is likely the most popular type of model for multiplayer gaming. In this architecture, one of the nodes is a server for handling communication and the other nodes are clients connected to it (Smed, Kaukoranta, & Hakonen, 2001). The server holds the game state and is responsible for sending update messages to the clients (Spurling 2004). Figure 2 shows a diagram of this setup. The client-server model is popular for several reasons. Game publishers will have more administrative control if there is a server, so they can easily perform such tasks as copy protection and authentication (Spurling 2004). The network code can be separated from the game code more easily than in a P2P system (Spurling 2004). Another benefit is that the clients do not have to worry about communicating with every other client on the network they only have to send to and receive from the server (Smed, Kaukoranta, & Hakonen, 2001). This does, however, put a great burden on the server. If
Concepts of Distributed 8 it crashes, then every node will be disconnected from the game (Spurling 2004). Also, since all of the messages have to pass through one server, there is always the potential for a bottleneck (Spurling 2004). These problems, however, have not kept the client-server model from being the most widely used architecture in multiplayer gaming. The third main system architecture is the server-network model, which is really a combination of the P2P and client-server models. In this architecture, multiple servers are connected in a peer-to-peer network, while each server hosts its own client-server network (Smed, Kaukoranta, & Hakonen, 2001). As seen in Figure 3, clients only communicate with their own servers, and the servers communicate with each other. The servers hold the game state and send update messages to each other and their own clients. Recent gaming trends have started to prove the benefits of a server-network model. Since there are multiple servers in this model, the demand placed on each individual server is reduced, which leads to better scalability (Smed, Kaukoranta, & Hakonen, 2001). The servers can communicate with each other very quickly, providing the opportunity for a large number of players to join in to a single game (Spurling 2004). These factors have been especially advantageous for the growing popularity of Massively Multiplayer Online Games (MMOGs). In these types of games, large numbers of players can
Concepts of Distributed 9 jump in and out of a single game world at any time, often with the ability to develop their characters and interact with the others (Spurling 2004). Since MMOGs need a high level of scalability, the servernetwork model is an attractive option. The most notable difficulty with this architecture is that the increased number of servers makes handling network traffic a more complex task (Smed, Kaukoranta, & Hakonen, 2001). Each of the distributed system architectures discussed in this section have their advantages and disadvantages. The P2P, client-server, and server-network models should be considered in light of the situations they will be used in. Factors like the number of players and type of game will largely determine what design should be used. Quality of Service Requirements When it comes to multimedia systems such as video game systems, there are high expectations concerning the speed and quality of the data being transmitted. The data rate requirements and the deadlines by which the data is expected to be received are referred to as quality of service (QoS) requirements (Silberschatz, Galvin, & Gagne, 2005). These requirements, of course, will have to be met by a distributed system connecting several multimedia systems. The most important QoS issues to understand include throughput, synchronization, latency, jitter, and reliability. The first QoS requirement is throughput. In a certain time interval, throughput is defined as the total amount of work that can be done, and for multimedia applications like video games, this translates to the required data rate (Silberschatz, Galvin, & Gagne, 2005). In a distributed multimedia system, the throughput is the bandwidth of the network, which was explained in the Network Considerations section of this paper. Since throughput is a way to measure of the amount of game data that can be transmitted per unit of time, distributed systems are always designed with the goal of higher throughput in mind.
Concepts of Distributed 10 Another highly important QoS concern is synchronization. This requirement involves keeping the state of the game identical for every player on the system. This is a critical issue, because obviously a synchronization problem would cause fits for everyone playing the game. Say, for example, a player in a racing game makes a pass for the lead. According to what he sees on his screen, he is in first. However, if his opponent s instance of the game lags behind in synchronization, she may look at the screen at the exact same time and believe she is in the lead. In order to solve this problem, state synchronization and input synchronization have been implemented as the two main solutions. (Spurling 2004) The solutions proposed for the synchronization problem have trade-offs of speed and reliability. State synchronization is a method in which every node in the system sends its entire state of the instance of the game as an event message. (Refer to the diagrams in the System Architectures section to see where the nodes send their event messages for different architectures.) This is a reliable method, since all the information from every player is accounted for. But it is not very efficient for larger games where the updates would be extremely frequent and involve massive amounts of data. Input synchronization, on the other hand, involves each node sending only its game events for example, passing and shooting in a basketball game as event messages. This means less data is required to be sent, but there is a greater risk for deviation between game states. The best solution to the synchronization problem may actually be a combination of both the state and input methods. (Spurling 2004) Latency is the third QoS concern for a distributed multiplayer game system. As mentioned in the Network Considerations section, latency is the total time it takes for a packet of data to reach its destination once it has been sent. Each multimedia system on the network has a requirement for low latency, or else game play will be affected. Because latency between a client and server cannot be directly controlled, the distributed system should be designed to keep things simple. For example, the
Concepts of Distributed 11 messages sent between client and server should be held in a single packet when possible. Also, the servers need to be available to respond to their clients quickly, so they should be created to do very little. Keeping the required communication between clients and servers to a minimum is another way to address the latency problem of a system. (Waldo 2008) Along with the techniques for dealing with latency in the system, several creative methods have been developed for hiding some of the inevitable latency from the players. For example, after players select their teams in a sports game, it will take a minute for the game to load. At this point, a loading screen may appear with tips for better play or a prerecorded video may be shown to distract the players from the amount of time the game is taking to load. Another way to hide latency is for the client to make a best guess regarding what the screen will look like once an event message is sent. Then once the server actually responds, the screen can be adjusted if necessary to match the true result. These methods do not take away the problem of latency, but they do make a difference in hiding it from the players. (Waldo 2008) Another important QoS requirement is minimizing jitter. While latency refers to a delay in receiving information, jitter refers to a variation in this delay over time. Jitter causes the characters on the screen to have jerky, non-fluid movements, which is obviously a distraction and makes the game more difficult to play. Jitter can be caused when network traffic is high and two packets from the same source have to take different routes to get to their destination, resulting in different travel times for each. (Spurling 2004) There are two techniques for eliminating jitter. One is to use a fixed playout delay, in which every packet is timestamped. The routers wait for a specific period of time to collect packets before sending them on, since the travel time variations may cause them to arrive out of order. When the packets are sent on, the routers use the timestamps to know what order they should be in and how much delay there should be between each. Another technique is the adaptive playout delay, in which
Concepts of Distributed 12 the amount of jitter for each packet is estimated and the delay before forwarding them is adjusted to even out the travel times. (Spurling 2004) Reliability is the final QoS requirement to be discussed, although it is not as important to multiplayer gaming as the other requirements. Reliability is a term used regarding the way errors are handled during media transmission and processing (Silberschatz, Galvin, & Gagne, 2005). In a distributed multiplayer game system, errors occur when packets are lost over the network. Networks that use a TCP (Transmission Control Protocol) for data transmission will retransmit every lost packet, meaning this is a reliable protocol that uses a lot of unnecessary bandwidth and overhead (Spurling 2004). The better choice for a game system is a UDP (User Datagram Protocol). This protocol does not acknowledge lost packets, saving bandwidth and overhead (Spurling 2004). The reason reliability is not as important for game systems is because game data is sent so frequently that it would be pointless to retransmit a lost packet. By the time a packet is resent and received, its information is no longer in real-time. Therefore, it is more efficient to simply wait for the next packet. Techniques have been developed for dealing with lost data in a game, so the efficiency of a UDP is preferred. Conclusion Distributed multiplayer game systems are becoming more and more popular, and developers must make improvements continuously to keep up with the growing demand. Finding ways to make the system better will not only improve the gaming experience for current users, but also attract new players into the gaming world. Systems like Xbox LIVE and PlayStation Network have great potential for growth, and it will be interesting to see the developments that come out of these systems over the next several years.
Concepts of Distributed 13 The purpose of this paper has been to present some basic concepts involved in the design of a distributed multiplayer game system. The challenges are unique and the solutions are creative, which is what makes this type of system so interesting. Understanding the network limitations, system architectures, and quality of service requirements is a good foundation for exploring the many aspects of a distributed multiplayer game system.
Concepts of Distributed 14 References Bellis, Mary. (2008). Computer and Video Game History. Retrieved December 2, 2008 from http://inventors.about.com/library/inventors/blcomputer_videogames.htm Cronin, Eric, Filstrup, Burton, & Kurc, Anthony. (2001, May 4). A Distributed Multiplayer Game Server System. Retrieved November 28, 2008 from http://warriors.eecs.umich.edu/games/ papers/quakefinal.pdf Majewski, Chris, Griwodz, Carsten, & Halvorsen, Pål. (2006, May 4). Translating latency requirements into resource requirements for game traffic. Retrieved November 28, 2008 from http://heim.ifi.uio.no/paalh/publications/files/inc2006-games.pdf Silberschatz, Abraham, Galvin, Peter Baer, & Gagne, Greg. (2005). Operating System Concepts. Hoboken, New Jersey: John Wiley & Sons, Inc. Smed, Jouni, Kaukoranta, Timo, & Hakonen, Harri. (2001, September 20). Aspects of Networking in Multiplayer Computer Games. Retrieved November 1, 2008 from http://staff.cs.utu.fi/~jounsmed/papers/aspectsofmcgs.pdf Spurling, Alex. (2004, July 12). QoS Issues for Multiplayer Gaming. Retrieved November 1, 2008 from http://users.cs.cf.ac.uk/o.f.rana/data-comms/gaming.pdf Thurrott, Paul. (2007, November 29). Xbox 360 vs. PlayStation 3 vs. Wii: A Technical Comparison. Retrieved November 28, 2008 from http://www.winsupersite.com/showcase/ xbox360_ps3_wii.asp Waldo, Jim. (2008). Scaling in Games and Virtual Worlds. Communications of the ACM, 51(8), 38-44.