ch17.htm

国外的一本介绍java开发网络游戏的书

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.
<P>
<A HREF="f17-6.gif" ><B>Figure 17.6 : </B><I>Input synchronization in a two-player network game.</I></A>
<P>
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.
<P>
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 <I>are</I> 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.
<H3><A NAME="AHybridSolution"><B>A Hybrid Solution</B></A></H3>
<P>
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.
<P>
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 today, 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.
<H2><A NAME="GameTheory"><B><FONT SIZE=5 COLOR=#FF0000>Game Theory</FONT></B></A>
</H2>
<P>
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.
<P>
<I>Game theory</I> is a branch of mathematical analysis devoted
to the study of decision making in conflict situations.
<P>
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.
<P>
In game theory, the following assumptions are usually made:
<UL>
<LI>Each player has available to her two or more well-specified
choices or sequences of choices called <I>plays.</I>
<LI>Every possible combination of plays available to the players
leads to a well-defined end-state (win, loss, or draw) that terminates
the game.
<LI>A specified payoff for each player is associated with each
end-state.
<LI>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.
<LI>All decision makers are rational; that is, each player, given
two alternatives, will select the one that yields the greater
payoff.
</UL>
<P>
Although general in scope and not originally directed at computer
games, game theory touches on many of the same concerns that are
raised when strategies for multiplayer computer games are being
designed. Two players in a network multiplayer game often go through
much of the same thought pattern as people engaged in a verbal
conflict. Game theory applies equally well to both scenarios.
<P>
Because of its general nature, game theory has seen wide application
in areas such as economics, international trade, labor, public
policy, natural resources, and development. Individuals making
use of game theory in their professions have included philosophers,
political scientists, arms-control negotiators, and evolutionary
biologists.
<P>
You can use game theory in your own multiplayer game designs to
help determine how reactions between players impact the game.
Game theory is also useful in determining computer player strategies
based on the possible range of responses by a human player. It's
all a matter of breaking a game down into a sequence of decisions
that can be compared to other decisions and what reactions they
provoke from other players.
<P>
One particular example that shows how game theory raises strategic
questions applicable to multiplayer computer games is the Prisoners'
Dilemma. The Prisoners' Dilemma is a game that has been, and continues
to be, studied by people in various disciplines, ranging from
biology to sociology and public policy. Among its interesting
characteristics is that it is a &quot;non-zero-sum&quot; game,
meaning that the best strategy for a given player is often one
that increases the payoff to one's partner as well. It has also
been shown that there is no single best strategy; maximizing one's
own payoff depends on the strategy adopted by one's partner.
<P>
The game works like this: Imagine two criminals arrested under
the suspicion of having committed a crime together. The police
don't have enough evidence to convict them, so they are isolated
from each other and separately offered a deal: The one who offers
evidence against the other will be freed. If neither of them accepts
the offer, they are effectively cooperating against the police,
and both get only a small punishment because of lack of proof.
Hence, they both gain. If, however, one of them betrays the other
by confessing to the police, he is freed; the one who remained
silent receives the full punishment because he did not help the
police and because the police now have evidence against him provided
by the other prisoner. If both betray each other, they both will
be punished, but less severely than if either had refused to talk.
The dilemma resides in the fact that each prisoner has a choice
between only two options, but neither can make a good decision
without knowing what the other one does.
<P>
The Prisoners' Dilemma raises some interesting questions regarding
strategies involving multiple players competing for a common goal.
To try your wits at the Prisoners' Dilemma, check out the online
version at <TT><A HREF="http://serendip.brynmawr.edu/~ann/pd.html">http://serendip.brynmawr.edu/~ann/pd.html</A></TT>.
Figure 17.7 shows what the Web site looks like with the interactive
Prisoners' Dilemma.
<P>
<A HREF="f17-7.gif" ><B>Figure 17.7 : </B><I>The interactive Prisioners' Dilemma Web site.</I></A>
<H2><A NAME="Summary"><B><FONT SIZE=5 COLOR=#FF0000>Summary</FONT></B></A>
</H2>
<P>
You should now have some idea about the general theory behind
designing games for multiple players. I know that today's lesson
didn't really present a rosy image of multiplayer game design,
and for good reason; designing games for multiple players over
a network is a difficult task that involves a lot of planning
and creative design. On the other hand, the capability of supporting
multiple human players can make any game orders of magnitude more
fun. And with the Internet looming as the ultimate network for
playing multiplayer games, it's only a matter of time before network
gaming becomes the norm.
<P>
Fortunately, the Java language and class libraries provide many
features to ease the pain in creating multiplayer games with network
support. The task is not necessarily easy, but it's often easier
than prior approaches at building Internet games. In tomorrow's
lesson, you'll learn exactly what support Java provides for network
game development.
<H2><A NAME="QA"><B><FONT SIZE=5 COLOR=#FF0000>Q&amp;A</FONT></B></A>
<BR>
</H2>

<TABLE>
<TR VALIGN=TOP><TD WIDTH=50><B>Q</B></TD><TD><B>If multiplayer Internet games are so cool, why are there still so few of them?</B>
</TD></TR>
<TR VALIGN=TOP><TD WIDTH=50><B>A</B></TD><TD>One of the main reasons there aren't many network games with full Internet support is that only recently has Internet usage started extending to the general game community. Another reason is that it has been 
difficult at best to implement Internet communications in games. However, with the advent of Java and various third-party C and C++ libraries, along with a growing acceptance of the Internet among gamers, you should start seeing most new network games 
sporting Internet support.
</TD></TR>
<TR VALIGN=TOP><TD WIDTH=50><B>Q</B></TD><TD><B>Is bandwidth always a concern when you're designing network games?</B>
</TD></TR>
<TR VALIGN=TOP><TD WIDTH=50><B>A</B></TD><TD>It depends, but more often yes. The only time bandwidth isn't an issue in network games is when a very small amount of information is being transferred between instances. An example of this type of game would be 
a network Connect4 game, in which the only information transferred would be the column of the move.
</TD></TR>
<TR VALIGN=TOP><TD WIDTH=50><B>Q</B></TD><TD><B>Does synchronization get more difficult to maintain when there are more players?</B>
</TD></TR>
<TR VALIGN=TOP><TD WIDTH=50><B>A</B></TD><TD>Usually not because the amount of synchronization information being sent is the same, regardless of how many players there are.
</TD></TR>
</TABLE>
<H2><A NAME="Workshop"><B><FONT SIZE=5 COLOR=#FF0000>Workshop</FONT></B></A>
</H2>
<P>
The Workshop section provides questions and exercises to help
you get a better feel for the material you learned today. Try
to answer the questions and at least think about the exercises
before moving on to tomorrow's lesson. You'll find the answers
to the questions in appendix A, &quot;Quiz Answers.&quot;
<H3><A NAME="Quiz"><B>Quiz</B></A></H3>
<OL>
<LI>What are the two basic types of multiplayer games?
<LI>What is the difference between a modem network connection
and a physical network connection?
<LI>What are the three types of network synchronization solutions?
</OL>
<H3><A NAME="Exercises"><B>Exercises</B></A></H3>
<OL>
<LI>Go to a software store and see whether you can find any games
that support Internet network play.
<LI>Of these games, see how many are turn-based and how many are
event-based.
<LI>Check out the Prisoners' Dilemma Web site, and try out your
own strategy.
</OL>
<P>
<HR WIDTH="100%"></P>

<CENTER><P><A HREF="ch16.htm"><IMG SRC="pc.gif" BORDER=0 HEIGHT=88 WIDTH=140></A><A HREF="index.htm"><IMG SRC="hb.gif" BORDER=0 HEIGHT=88 WIDTH=140></A><A HREF="#CONTENTS"><IMG SRC="cc.gif" BORDER=0 HEIGHT=88 WIDTH=140></A><A HREF="ch18.htm"><IMG 
SRC="nc.gif" BORDER=0 HEIGHT=88 WIDTH=140></A></P></CENTER>

<P>
<HR WIDTH="100%"></P>

</BODY>
</HTML>