The Raw appeal of Multiplayer Games

If you've been fortunate enough to play a multiplayer network game with your friends, you already know how much fun it can be. In many ways, outwitting a real live person is much more fun than competing against a computer player. The reality of going head-to-head with another person can change the whole perspective of a game. I have yet to see a single-player game that evokes the same level of emotion and excitement as is generated from the human factor in multiplayer games.

Arguably one of the most popular multiplayer (and single player, for that matter) games to come along in the past few years is DOOM. DOOM provides a 3D world with previously unheard-of realism and nonstop action. Add to this the ability to share the 3D world with other real people, and it's not hard to see why this game is so compelling.

Even though most of the successful multiplayer games to date, like DOOM, have pitted human players against each other, they don't necessarily have to. The benefits of human interaction in a multiplayer game are just as significant if the human players are working together. I know from experience how fun it can be working together with another person to reach a common goal. One of my favorite games is Super Contra III for the Super Nintendo console game system. This game enables two human players to play together against the computer. In fact, you can get much further in the game with two people cooperating in multiplayer mode than with one player on her own in a single-player game. This approach rewards the players for their cooperation, and in doing so adds another whole dimension to the appeal of the game.

Although the discussion thus far has been limited mostly to games involving multiple human players, there is no reason why you can't have a mixture of human and computer players in a multiplayer game. Consider a Poker game, for example. The participants in the game could be any mixture of human and computer players. The ability to have different combinations of players puts an interesting twist on the AI in the game. Moreover, it would be interesting to see how the human players respond to the other players, knowing that some of them are real and some aren't. A few games out there have taken this approach. The computer version of one of my favorite board games, Risk, takes this approach by filling in for missing human players with computer players.

There are endless possibilities for multiplayer games involving both cooperation and competition among human players. Regardless of the scenario, when real people are involved, a certain synthesis of ideas takes place that just isn't possible with computer players. It's then up to game designers like you and me to chart the course and dream up new ways for people to interact with each other through games.

Network versus Non-Network Games

So far, the discussion of multiplayer games has avoided the issue of where the multiple players are physically located. You've probably assumed that I've been referring to multiple players connected over a network, but that doesn't necessarily have to be the case. Because of the relative difficulty in implementing network games, many multiplayer games have relied on two or more players sitting in front of the same computer. In light of recent advances in network standardization and programming libraries, however, this approach of having multiple players using the same machine is losing its appeal rather quickly. It still works pretty well for many console game systems, because they are specifically designed to support two or more players with one set of hardware, but I wouldn't expect to see very many new computer games using this approach.

The point is that you simply must implement a network interface for multiplayer computer games, even if you provide a non-networked multiplayer option. When it comes to Java games, this point is even more important, because Web users will expect to be able to play against other players on the Web.

To better understand the relationship between network versus non-network multiplayer games, check out Figure 17.1 and Figure 17.2.

Figure 17.1 : A two-player game on a non-networked machine.

Figure 17.2 : A two-player game on networked machines.

In Figure 17.1, a two-player game is implemented on a single machine; in this situation, the players use different keys on the keyboard. Of course, if you figured out how to get two mice working on one machine, that probably would work too! Although this setup certainly works in the confines of your own home, it doesn't help you much when you want to play with a friend who lives halfway across the world. The bright side is that the design for a game like this wouldn't really be any more difficult than a single-player design; you just process two sets of keyboard inputs rather than one. Nevertheless, all the input still is generated on the same machine and with the same timing. The key point is that although there are two players with two different sets of input, only one instance of the game is running.

Now consider the problems associated with this non-network approach: You're requiring two players to squeeze together next to each other and share the keyboard. Furthermore, this setup wouldn't work for games in which each player needs to see information that should be hidden from the other player, such as your hand in Poker (or any multiplayer card game, for that matter).

The configuration in Figure 17.2 shows a two-player game implemented through some type of network connection between the two machines. There are two computers and therefore two separate instances of the game. Although two instances of the game are running, they effectively operate as one. Notice that there is some form of communication between the two computers across the network connection. This is the communication you must implement to keep the two games operating in conjunction. Fortunately, as you'll learn tomorrow, Java provides a lot of the functionality of establishing and maintaining a network communication channel between players.

Gaming on the Internet

Multiplayer games that can run together on different machines also are known as network games, which means that the games are capable of enabling multiple players to connect with each other and play interactively over an external connection between their respective machines. In the case of network Java games, the external network connection is handled through the Internet.

Network games are multiplayer games that can run together on multiple machines.

Even though the ultimate communication medium for network Java games is the Internet, you have to contend with the fact that different game players will access the Internet in different ways. Actually, there are really only two Internet connection scenarios: dedicated and dial-up. A dedicated Internet connection involves a computer being directly connected to the Internet via a direct, high-speed line such as a T1 connection. Actually, slower dedicated lines are available, such as 28,800 baud, but they aren't as popular as their faster counterparts.

A dial-up Internet connection, on the other hand, consists of a computer dialing into an Internet network and establishing a modem connection to the Internet. Technically speaking, a modem connection is certainly physical, but for our purposes, we'll refer to modem connections as modem networks, and networks involving physical network hardware connections as physical networks.

The primary difference between modem networking and physical networking is the bandwidth of communication. Bandwidth refers to how much data can be transferred in a certain amount of time. Most people accessing the Web have already realized that a 28,800 baud modem is a necessity. The absolute minimum modem speed for Web surfing these Chapters is 14,400 baud, but 28,800 baud might as well be the standard, because modems are coming down in price so rapidly.

Bandwidth refers to the amount of data that can be transferred over a network connection in a certain amount of time.

The modem-speed issue is important because the bandwidth can greatly affect the performance of network games. The degree to which the bandwidth affects the game performance, however, is determined by your particular communication strategy. For example, you might be able to figure out a way to send very little data and get by with lower communication speeds. As in all software designs, there are trade-offs, and bandwidth is the big one you must weigh when assessing the communication requirements for your game. This is one aspect of the game design you must be particularly careful about, because the amount of data transferred between games can have a dramatic effect on performance.

As far as managing the details of programming network games in Java, it doesn't matter whether a network is a physical or a modem network. Well, it doesn't matter at least from a protocol and interface perspective. It does matter when you start looking at the performance requirements of a network game. If you haven't guessed already, physical networks are much faster and more reliable than modem networks. Unfortunately, although physical networks provide greater speed and better reliability that helps make multiplayer game design much easier, you can't rely on game players using them. The reality is that few game players have the luxury of a physical Internet connection to play games on. Most physical networks are in the confines of a corporate environment, where game playing generally is frowned upon.

Most game players have available to them only the limited transmission speeds of a modem connection. Therefore, game developers are left programming network games to this lowest common denominator of transmission speed. You simply have to live with the fact that most multiplayer games will be played over modems, so it's your job to design those games accordingly.

Types of Multiplayer Games

Before you get into the design strategies for network games, it's important to understand the fundamental types of network games. The communication design can be affected dramatically by the way the game play progresses, which is determined by the type of game. I've defined two types of network games: turn-based and event-based. Most games should easily fall into one of these two categories.

Turn-Based Games

Turn-based games are games in which each action in the game is based on a player's turn.

The Connect4 game you developed yesterChapter is a turn-based game because you are allowed to make a move only when it is your turn. Sure, you are free to think about your move during the other player's turn, but in the context of the game you can take action only during your turn. Most turn-based games are board games or card games, or simple games played on paper such as Tic-Tac-Toe. I can't think of any action games that would be considered turn-based. That would kind of take the action out of it! Nevertheless, turn-based games are very popular and well-suited for networking.

Knowing that turn-based games revolve around whose turn it is, the network communication design is greatly simplified. This is because only one player can interact with the game at a time. Even though multiple players are technically playing the game, only one player is allowed to make a move at a time. The other players must wait their turn before they can do anything. In this way, the game can be designed so that all the players are in a wait state until it becomes their turn. The flow of the game in turn-based games ends up being circular, as in a game of cards. The turn moves around the group of players one by one. Figure 17.3 shows the play flow of a turn-based game involving five players.

Figure 17.3 : Game play flow of a turn-based game with five players.

As you can see from the play flow, the game allows each player to take a turn; after each turn, the game processes the turn and allows the next player to take a turn. The play flow occurs this way regardless of the number of players. In a two-player game such as Connect4, the turns just move back and forth between the players.

Event-Based Games

Event-based games are games that are dictated by input events that can occur at any time.

Event-based games are much more open-ended than turn-based games. In an event-based game, any player can interact with the game at any time, resulting in an input event. The flow of the game is dictated by the input events rather than turns. As a matter of fact, there is no concept of "turn" in an event-based game. Event-based games include basically all games that don't revolve around turns; examples range from first-person shoot-em-ups such as Duke Nukem 3D to strategy simulators such as CivNet. In the network modes of both these games, any of the players can act independently of any of the other players, generating anywhere from nothing to a massive flood of events.

If you haven't suspected, the communication design for event-based games is much more complex and difficult to implement than that for turn-based games. More importantly, event-based game communication typically requires a much wider bandwidth, because more information is usually being transmitted. It's probably safe to say that each different event-based game you create will have a unique solution. This is because there are so many trade-offs to be made in regard to determining the best way to design the network communication logic. In a game such as Duke Nukem 3D, think about how many things are going on, and even more important, notice how quickly things are happening. Any change in the game from one player's perspective must be communicated to all the other players in some form. Figure 17.4 shows the play flow of an event-based game involving five players.

Figure 17.4 : Game play flow of an event-based game with five players.

Notice from the play flow that the game never "allows" the players to do anything, as in turn-based games. The game just sits back and waits for the players to generate input events. Players can generate these events as often or as seldom as they want, fully independent of the other players. This is what enables you to patiently wait behind a corner while another player runs by haphazardly at full speed. Some people never learn!

Network Game Problems

Now that you know which type of network games you are dealing with, let's look at some of the common problems you will encounter in a network game design. The overriding concern to be dealt with in designing network games is maintaining synchronization. Synchronization refers to how multiple game instances running on different machines maintain the same game state information. Remember that each player is running a separate instance of the game, but the overall goal is to make each of these different instances function logically as one instance. All the internal data structures modeling the state of the game should match exactly on each player's system.

Synchronization refers to how multiple instances of a game maintain the same state information.

You can best understand this concept by looking at an example of what can happen when synchronization is lost. Suppose that two players, Heath and Keith, are playing a network adventure game similar to one of the games in the classic Ultima series. As they are walking along together, they run across a monster. Heath is a little more assertive and starts fighting the monster. Keith is low on life points and decides to just sit in the shade and watch. When Heath finishes off the monster, Keith somehow must be notified-and not just as a matter of convenience; any change in the game that potentially can affect other players must be communicated to them.

Another common problem in regard to synchronization involves using random values in games. It is fairly common for games to place some objects randomly when a game starts, such as treasure or even monsters. Sometimes games use random events just to make things vary a little from game to game. In network games this creates big problems unless each game instance uses the same random values as all the other instances. It would totally blow the synchronization for each game to have things going on randomly with respect to each instance. The point here is that many seemingly insignificant things, such as generating random numbers, can cause major headaches in a network game environment.

Network Game Solutions

Now that you understand the problems, let's move on to some solutions. There are many different approaches to designing network game communications, and all of them must somehow address the problem of keeping each player's instance of the game synchronized with all others. You're going to focus on two basic types of network game synchronization strategies: state synchronization and input synchronization.

State Synchronization

State synchronization is a communication method by which each game instance communicates the current state of itself to the other instances.

The state synchronization method is very robust because there is no chance for information loss; everything regarding the current state of the game is sent to the other instances. In a two-player space battle game, for example, the position and speed of all the planets, asteroids, ships, and bullets would be sent as the current state of the game. Figure 17.5 shows a diagram of the information transfer for state synchronization in a two-player network game.

Figure 17.5 : State synchronization information transfer in a two-player network game.

Sounds good so far. But what about a more complex game such as a role-playing adventure game with entire virtual worlds that the players constantly are interacting with? Sending the state of the entire game starts looking a little more difficult because of the vast amounts of information required to model the game state. And don't forget about the bandwidth limitation you learned about earlier, which keeps you from being able to send loads of information between games. Knowing this, it's easy to see that state synchronization is a fairly messy network communication solution. Although state synchronization is functionally a very solid network solution, technically it's just not always feasible.

Input Synchronization

Input synchronization is a communication method in which each game communicates the input events of its player to the other game instances.

Using input synchronization, each time a player generates input events, such as moving the mouse or pressing keys, the game broadcasts these events to the other games. Using the space battle game example from before, instead of sending the state of all the objects, the game just sends the mouse and keyboard input events generated by the player. Each game then handles each remote (virtual) input from the other games in a similar manner as it handles its own local player's input. Figure 17.6 shows a diagram of the information transfer for input synchronization in a two-player network game.

Figure 17.6 : Input synchronization in a two-player network game.

There has to be a catch, right? Of course there's a catch; there's always a catch! Input synchronization works fine as long as all the changes in the game are dictated solely by the inputs of the players. Practically speaking, this rarely is the case. There are usually random effects in a game such as placement of background objects. These random effects wreak havoc on games relying on input synchronization because they aren't reflected by the player input and therefore are never communicated between games.

If you happen to have a game in which the entire play flow is dictated by the inputs of the players, input synchronization is for you. Otherwise, you'll have to come up with another solution. Can you think of any games that are dictated entirely by the user inputs? Give up? It ends up that most turn-based games are driven completely by the inputs of the users. So you usually can implement network support for turn-based games by using input synchronization.

A Hybrid Solution

Now that I've painted a pretty bleak picture of network game design, I'll let you in on a practical reality in network game design: You usually will have to use some combination of the two methods mentioned. This hybrid solution would include elements of both state and input synchronization. Using the space battle game example again, you could send the user inputs back and forth using input synchronization, and then use state synchronization to send random events such as initial meteor positions. You still don't necessarily need to transmit the entire state of the game, just the aspects of the game state that can't be figured out by each instance on its own. In other words, random events need to be transmitted to each game instance.

If you run across a gaming scenario that doesn't fit well with any of these approaches, you might figure out a communication technique of your own to add to or replace one of these. As I said earlier toChapter, network gaming is a unique area of programming that leaves room for very few general techniques. You usually have to come up with hybrid solutions that draw on what you've learned combined with new ideas you dream up along the way.

Game Theory

Now that you understand the important aspects of handling communications between network game instances, let's shift gears a little and take a look at an area of theoretical research that impacts multiplayer games. An area of increasingly popular academic research, called game theory, can be used to shed light on how people interact with each other in a multiplayer computer game scenario. Applications of this information could breathe fresh insight into the design of multiplayer games. Game theory won't help you with synchronization problems, but it might help you figure out more creative approaches to the game strategy itself.

Game theory is a branch of mathematical analysis devoted to the study of decision making in conflict situations.

Such a situation exists when two or more decision makers, or players, with differing objectives act on the same system or share the same resources. Game theory provides a mathematical process for selecting an optimum strategy in the face of an opponent who has a strategy of his own. This mathematical process borders on issues related to both multiplayer computer game design and strategic AI.

In game theory, the following assumptions are usually made:

• Each player has available to her two or more well-specified choices or sequences of choices called plays.
• Every possible combination of plays available to the players leads to a well-defined end-state (win, loss, or draw) that terminates the game.
• A specified payoff for each player is associated with each end-state.
• Each decision maker has perfect knowledge of the game and of his opposition; that is, he knows in full detail the rules of the game as well as the payoffs for all other players.
• All decision makers are rational; that is, each player, given two alternatives, will select the one that yields the greater payoff.