📄 ch19.htm
字号:
<HTML>
<HEAD>
<TITLE>Chapter 19 -- NetConnect4: Human versus Human</TITLE>
<META>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000EE" VLINK="#551A8B" ALINK="#CE2910">
<H1><FONT COLOR=#FF0000>Chapter 19</FONT></H1>
<H1><B><FONT SIZE=5 COLOR=#FF0000>NetConnect4: Human versus Human</FONT></B>
</H1>
<P>
<HR WIDTH="100%"></P>
<P>
<H3 ALIGN=CENTER><FONT COLOR="#000000"><FONT SIZE=+2>CONTENTS<A NAME="CONTENTS"></A>
</FONT></FONT></H3>
<UL>
<LI><A HREF="#DesigningNetConnect4" >Designing NetConnect4</A>
<UL>
<LI><A HREF="#TheServer" >The Server</A>
<LI><A HREF="#TheClient" >The Client</A>
<LI><A HREF="#PuttingThemTogether" >Putting Them Together</A>
</UL>
<LI><A HREF="#SampleAppletNetConnect4" >Sample Applet: NetConnect4</A>
<UL>
<LI><A HREF="#RunningNetConnect4" >Running NetConnect4</A>
<LI><A HREF="#DevelopingNetConnect4" >Developing NetConnect4</A>
</UL>
<LI><A HREF="#Summary" >Summary</A>
<LI><A HREF="#QA" >Q&A</A>
<LI><A HREF="#Workshop" >Workshop</A>
<UL>
<LI><A HREF="#Quiz" >Quiz</A>
<LI><A HREF="#Exercises" >Exercises</A>
</UL>
</UL>
<HR>
<P>
In yesterday's lesson, you learned how Java supports network communications
through a client/server model. You even built a simple socket
class to help make network communications a little easier. In
today's lesson, you carry the client/server approach a step forward
and build a complete network game supporting multiple players.
Actually, instead of writing a whole new game, you modify a game
you already wrote to support network play. By the end of today's
lesson, you'll have the skills necessary to begin developing your
own network games.
<P>
Today you take the Connect4 game you wrote on <A HREF="ch16.htm" >Day 16</A>
and adapt it to network play between two players. In doing so,
you put the socket class developed yesterday to good use; you
use the socket class as a basis for implementing a complete network
game protocol facilitating game communication between multiple
clients and a server. Sounds like fun, right? You bet!
<P>
The following topics are covered in today's lesson:
<UL>
<LI>Designing NetConnect4
<LI>Sample applet: NetConnect4
</UL>
<H2><A NAME="DesigningNetConnect4"><B><FONT SIZE=5 COLOR=#FF0000>Designing
NetConnect4</FONT></B></A></H2>
<P>
If you recall, the Connect4 game you wrote in <A HREF="ch16.htm" >Day 16's</A>
lesson was a single-player game utilizing artificial intelligence
to simulate an intelligent computer player. The goal now is to
take that game and adapt it for two human players playing the
game over the Web. This task might sound a little daunting, but
keep in mind that the game itself is already written; you're just
adding the network support code.
<P>
As you learned yesterday, the core of Java network game programming
revolves around a client/server communication strategy. Knowing
this, you've probably guessed that a Java network game design
will involve some type of client/server arrangement. In fact,
the design of the NetConnect4 game can be divided cleanly into
the client side and the server side. These two components are
logically separate, communicating entirely through a game protocol
defined between them. Let's take a look at what each of these
pieces is responsible for.
<H3><A NAME="TheServer"><B>The Server</B></A></H3>
<P>
In any Java game, the server side of the game acts almost like
a referee, managing the different players and helping them communicate
effectively. More specifically, a game server takes on the role
of handling the network connection for each player, along with
querying for and responding to events for the players. The role
of a generic game server can be broken down into the following
actions:
<OL>
<LI>Initialize the server socket.
<LI>Wait for a client to connect.
<LI>Accept the client connection.
<LI>Create a daemon thread to support the client.
<LI>Go back to step 2.
</OL>
<P>
The most crucial aspect of this series of events is step 4, when
the server creates a daemon thread to support the client. You're
probably wondering what I mean by "support." Well, in
a generic sense, I don't know what I mean. The reason is that
the daemon thread is where the applet-specific code goes. So a
generic server only knows that it needs to create a daemon thread;
it doesn't know or care about what that thread actually does.
You'll learn more about daemon threads a little later today when
you actually get into the code for NetConnect4.
<P>
A <I>daemon</I> is a process that runs in the background of a
system performing some type of support function.
<P>
You now have an idea about the role a generic game server plays
in the context of a network game. The question, then, is what
role does such a server play in the context of a specific game,
namely NetConnect4? The role of the NetConnect4 server ends up
being not much different from that of the generic server, but
it is important that you understand exactly what it needs to do
differently.
<P>
Because Connect4 is a two-player game, the first job of the server
is to pair up players (clients) as they connect to the game. A
more limited approach would be to permit only the first two players
who connect to play the game. But you're smarter than that and
hopefully demand a more powerful game server. Your game server
enables multiple games to be played at once simply by pairing
additional client players together for each game. In this way,
a typical NetConnect4 server session might have six or eight players
playing at once. Of course, the players know only about the other
player in their immediate game.
<P>
<CENTER><TABLE BORDERCOLOR=#000000 BORDER=1 WIDTH=80%>
<TR><TD><B>Note</B> </TD></TR>
<TR><TD>
<BLOCKQUOTE>
To keep things a little simpler, don't worry about players choosing who they play against; in other words, just pair players on a first-come first-served basis.</BLOCKQUOTE>
</TD></TR>
</TABLE></CENTER>
<P>
<P>
After the server has detected two players and paired them up for
a game, it becomes the responsibility of the server's daemon thread
to dictate the flow of the game between the players. The daemon
accomplishes this by informing each player of the state of the
game, while also modifying the state according to each player's
turn. The responsibilities of the NetConnect4 server and daemon
can be summarized as shown here:
<UL>
<LI>Accept client player connections.
<LI>Pair up players to form separate games.
<LI>Manage the flow of the game.
<LI>Communicate each player's move to the other player.
<LI>Notify the players of the state of the game.
</UL>
<H3><A NAME="TheClient"><B>The Client</B></A></H3>
<P>
The other side of a Java network game is the client. The client
portion of a network game corresponds to the applet being run
by each player. Because game players interact with the client,
the client program is usually much fancier than the server in
regard to how information is displayed. As a matter of fact, game
servers typically don't even have user interfaces; they crank
away entirely behind-the-scenes doing all the dirty work while
the client applets dazzle the users.
<P>
The basic responsibility of a game client is to connect to the
server and communicate the user's actions, along with receiving
game state information from the server and updating itself accordingly.
Of course, along with this comes the responsibility of displaying
the game graphics and managing the entire game interface for the
user. You can probably already see that game clients tend to require
the most work, at least from a strictly design perspective.
<P>
The good news is that you've already written most of the client
for NetConnect4. The Connect4 game you wrote on <A HREF="ch16.htm" >Day 16</A>
is essentially a non-networking game client in that it handles
all the work of managing a game with a user; it displays the graphics,
interfaces with the user, and keeps up with the state of the game.
The focus of building a NetConnect4 client then becomes modifying
the original Connect4 code to transform it into a full-blown client
that can communicate with the NetConnect4 server. The following
is a summary of what functionality the NetConnect4 client needs
to provide:
<UL>
<LI>Connect to the server.
<LI>Notify the player of the connection/game state.
<LI>Communicate the player's move to the server.
<LI>Receive the other player's move from the server.
<LI>Update the game with the state received from the server.
</UL>
<H3><A NAME="PuttingThemTogether"><B>Putting Them Together</B></A>
</H3>
<P>
You might be wondering how this whole client/server game scenario
works in regard to a Web server, because it's apparent that the
game server must be running at all times. For a network game to
work, you must have the game server always running in the background,
meaning that it must somehow be launched by the Web server or
by some type of system startup feature. This makes it available
to connect clients who come along wanting to play.
<P>
When a Web client shows up to play a game, the game server accepts
the client's connection and then takes on the role of hooking
the client up with another client to play a game. The game server
is entirely responsible for detecting when clients arrive as well
as when they leave, creating and canceling game sessions along
the way. Because the game server is being run in the background
all the time, it must be extremely robust.
<P>
<CENTER><TABLE BORDERCOLOR=#000000 BORDER=1 WIDTH=80%>
<TR><TD><B> </B> </TD></TR>
<TR><TD>
<BLOCKQUOTE>
Because the game server is responsible for detecting and pairing clients, it is imperative that the server be running at all times. Without the server, you have no knowledge of or communication between clients.</BLOCKQUOTE>
</TD></TR>
</TABLE></CENTER>
<P>
<H2><A NAME="SampleAppletNetConnect4"><B><FONT SIZE=5 COLOR=#FF0000>Sample
Applet: NetConnect4</FONT></B></A></H2>
<P>
The NetConnect4 sample applet demonstrates all the details of
using Internet network communication to develop a multiplayer
Java game. Even though the focus of today's lesson is on the actual
programming involved in making NetConnect4 a reality, you'll probably
find the code a little easier to follow if you run the finished
product first. Knowing that, let's put NetConnect4 through its
paces and see how to use it. By the way, the complete source code,
executable, images, and sounds for the NetConnect4 game are located
on the accompanying CD-ROM.
<H3><A NAME="RunningNetConnect4"><B>Running NetConnect4</B></A>
</H3>
<P>
This discussion on running the NetConnect4 sample game assumes
that you either have access to a Web server or can simulate a
network connection on your local machine. When I refer to running
the server side of the game, you need to run it in the way that
you typically execute a program based on your Web server configuration.
<P>
<CENTER><TABLE BORDERCOLOR=#000000 BORDER=1 WIDTH=80%>
<TR><TD><B>Note</B></TD></TR>
<TR><TD>
<BLOCKQUOTE>
I tested the game myself by simulating a network connection on my local Windows 95 machine. I did this by changing the TCP/IP configuration on my machine so that it used a specific IP address; I just made up an address. If you make this change to your
network configuration, you won't be able to access a real network using TCP/IP until you set it back, so don't forget to restore things when you're finished testing the game.</BLOCKQUOTE>
</TD></TR>
</TABLE></CENTER>
<P>
<P>
As you already know, the NetConnect4 game is composed of two parts:
a client and a server. The NetConnect4 server is the core of the
game and must be running in order for the clients to work. So
to get the game running, you must first run the server by using
the Java interpreter (<TT><FONT FACE="Courier">java</FONT></TT>).
You do this from a command line, like this:
<BLOCKQUOTE>
<TT><FONT FACE="Courier">java NetConnect4Server</FONT></TT>
</BLOCKQUOTE>
<P>
The other half of NetConnect4 is the client, which is an applet
that runs from within a browser such as Netscape Navigator. Incidentally,
the NetConnect4 client applet is called Connect4, to keep the
name consistent with the original single-player game. After you
have the server up and running, fire up a Java-compatible browser,
and load an HTML document including the NetConnect4 client applet.
On the CD-ROM, this HTML document is called <TT><FONT FACE="Courier">Example1.html</FONT></TT>,
in keeping with the standard JDK demo applets. After running the
Connect4 client applet, you should see something similar to what's
shown in Figure 19.1.
<P>
<A HREF="f19-1.gif" ><B>Figure 19.1 : </B><I>The NetConnect4 game with a single clients player.</I></A>
<P>
At this point, you have the server up and running with a single
client attached to it. Because two players are required to start
a game, the client is in a wait state until another player comes
along. Now, load a second instance of the Web browser with the
same <TT><FONT FACE="Courier">Example1.html</FONT></TT> document;
this is your second player. When the server detects this player,
it pairs the two players and starts the game. Figure 19.2 shows
this scenario.
<P>
<A HREF="f19-2.gif" ><B>Figure 19.2 : </B><I>The NetConnect4 game with two client players in a new game.</I></A>
<P>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -