as their faster counterparts.
<P>
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 <I>modem networks,</I> and networks
involving physical network hardware connections as <I>physical</I>
<I>networks.</I>
<P>
The primary difference between modem networking and physical networking
is the bandwidth of communication. <I>Bandwidth</I> 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 days is 14,400 baud, but 28,800 baud might as
well be the standard, because modems are coming down in price
so rapidly.
<P>
<I>Bandwidth</I> refers to the amount of data that can be transferred
over a network connection in a certain amount of time.
<P>
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.
<P>
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.
<P>
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.
<H2><A NAME="TypesofMultiplayerGames"><B><FONT SIZE=5 COLOR=#FF0000>Types
of Multiplayer Games</FONT></B></A></H2>
<P>
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.
<H3><A NAME="TurnBasedGames"><B>Turn-Based Games</B></A></H3>
<P>
<I>Turn-based</I> games are games in which each action in the
game is based on a player's turn.
<P>
The Connect4 game you developed yesterday 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.
<P>
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.
<P>
<A HREF="f17-3.gif" ><B>Figure 17.3 : </B><I>Game play flow of a turn-based game with five players.</I></A>
<P>
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.
<H3><A NAME="EventBasedGames"><B>Event-Based Games</B></A></H3>
<P>
<I>Event-based</I> games are games that are dictated by input
events that can occur at any time.
<P>
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 &quot;turn&quot; 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.
<P>
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.
<P>
<A HREF="f17-4.gif" ><B>Figure 17.4 : </B><I>Game play flow of an event-based game with five players.</I></A>
<P>
Notice from the play flow that the game never &quot;allows&quot;
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!
<H2><A NAME="NetworkGameProblems"><B><FONT SIZE=5 COLOR=#FF0000>Network
Game Problems</FONT></B></A></H2>
<P>
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.
<P>
<I>Synchronization</I> refers to how multiple instances of a game
maintain the same state information.
<P>
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.
<P>
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.
<H2><A NAME="NetworkGameSolutions"><B><FONT SIZE=5 COLOR=#FF0000>Network
Game Solutions</FONT></B></A></H2>
<P>
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.
<H3><A NAME="StateSynchronization"><B>State Synchronization</B></A>
</H3>
<P>
<I>State synchronization</I> is a communication method by which
each game instance communicates the current state of itself to
the other instances.
<P>
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.
<P>
<A HREF="f17-5.gif" ><B>Figure 17.5 : </B><I>State synchronization information transfer in a two-player network game.</I></A>
<P>
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.
<H3><A NAME="InputSynchronization"><B>Input Synchronization</B></A>
</H3>
<P>
<I>Input synchronization</I> is a communication method in which
each game communicates the input events of its player to the other
game instances.
<P>
Using input synchronization, each time a player generates input
events, such as moving the mouse or pressing keys, the game broadcasts