📄 ch20.htm
字号:
<HTML>
<HEAD>
<TITLE>Chapter 20 -- Multi-User Games and CGI </TITLE>
<META>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000EE" VLINK="#551A8B" ALINK="#CE2910">
<H1><FONT COLOR=#FF0000>Chapter 20</FONT></H1>
<H1><B><FONT SIZE=5 COLOR=#FF0000>Multi-User Games and CGI</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="#MultiUserGames" >Multi-User Games</A>
<UL>
<LI><A HREF="#Planning" >Planning</A>
<LI><A HREF="#Outlining" >Outlining</A>
<LI><A HREF="#Coding" >Coding</A>
</UL>
<LI><A HREF="#Summary" >Summary</A>
</UL>
<HR>
<P>
Ever since the World Wide Web was created, its multimedia potential
has attracted both game designers and game players. In addition,
the worldwide connectivity of the Internet makes the Web a natural
arena for multi-player games.
<P>
CGI programs are, for the most part, the backbone of gaming on
the Web. Whether it is a two-player game of Checkers or an extensive
open-ended MUD, CGI provides the capabilities required to provide
on-the-fly page generation and state retention necessary to maintain
a multi-player game on the Web.
<P>
The first step in creating a multi-user game for the Web is to
check to see if it has already been done. The Web is a big place,
and there is a good chance that someone else has done something
similar to what you have planned. There is no need to re-invent
the wheel (unless, of course, your wheel is better).
<P>
A quick glance at Yahoo! shows several dozen entries under the
category of "Interactive Web Games" (see Figure 20.1).
Only a few of these are true multi-player games, but even those
that do not fit this description can be useful as a learning tool
in the quest for the perfect multi-player game. Web-based games
as a whole can be grouped by "multi-playerness" to gauge
better how they relate to true multi-player gaming:
<P>
<A HREF="f20-1.gif" ><B>Figure 20.1:</B> <I>Yahoo!'s interactive Web games.</I></A>
<BR>
<UL>
<LI><FONT COLOR=#000000>Single-Player Games-These </FONT>are the
most common games on the Web, ranging from board games (Chess,
Checkers, and so on) and simple image manipulation (Mr. Potato
Head, Dart Boards, Sliding Picture Puzzles), to fully realized,
intricate Virtual Worlds. What connects these games is the fact
that each person playing a particular game is playing alone, with
no contact with any other players.
<LI><FONT COLOR=#000000>Noninteractive Multi-Player </FONT>Games-These
are games in which many people may be playing at once. Although
each player may be aware of each other's actions, no player can
affect another player's game. Making a noninteractive multi-player
game can be as simple as adding a high score table to a single-player
game. By far, the most widespread of this type of game are the
many "Scavenger Hunts" on the Web (see Figure 20.2).
Often sponsored by commercial entities, many of these games have
real-life money and prizes at stake.
</UL>
<P>
<A HREF="f20-2.gif" ><B>Figure 20.2:</B> <I>Lingua Center's Web Scavenger Hunt.</I></A>
<UL>
<LI><FONT COLOR=#000000>Cooperatively </FONT>Interacting Multi-Player
Games-Most of these "games" are not really games at
all but cooperative endeavors between several people. Web-based
"Interactive Fiction" and "Interactive Art"
have become enormously popular, enabling people to build upon
others' ideas in a public environment. The theory behind these
"games" is useful when considering true multi-player
games because, unlike most noninteractive games, most cooperative
games require the information entered by one player to be remembered
and to be automatically available to all players. This creates
the problem of "state retention" that is crucial to
multi-player games.
<LI><FONT COLOR=#000000>"True" Multi-Player Games-A</FONT>
"true" multi-player game is a game in which more than
one player is present, and the actions of one player can possibly
affect (positively or negatively) another player's game. This
usually also entails informing the other player that his or her
game has been altered. Because the Web is a "connectionless"
medium, this can be a nontrivial (even downright difficult) task.
Some games, such as Netropolis (<TT><FONT FACE="Courier"><A HREF="http://www.delphi.co.uk/netropolis">http://www.delphi.co.uk/netropolis</A></FONT></TT>,
shown in Figure 20.3), use a turn-based mechanism, so each player
knows when to update his or her browser. Others, such as Onslaught
(<TT><FONT FACE="Courier"><A HREF="http://www.webplayer.com/">http://www.webplayer.com/</A></FONT></TT>,
shown in Figure 20.4), are real-time, requiring the players to
be constantly on their toes. No matter the type of game, making
playable multi-player games is one of the most difficult tasks
to accomplish over the Web.
</UL>
<P>
<A HREF="f20-3.gif" ><B>Figure 20.3:</B> <I>Welcome to Netropolis.</I></A>
<P>
<A HREF="f20-4.gif" ><B>Figure 20.4:</B> <I>On the battlefield of Onslaught.</I></A>
<H2><A NAME="MultiUserGames"><FONT SIZE=5 COLOR=#FF0000>Multi-User
Games</FONT></A></H2>
<P>
The first (and arguably the most important) part of creating a
Web-based multi-player game (or any game, for that matter) is
planning. This is also the part that most programmers skip or
gloss over. After you have your idea for BlastMasters from Outer
Space in 3D, it is very tempting to begin hacking away at it all
at once with only your inspiration to guide you. Not giving in
to this temptation is important, especially for games meant for
the Internet. It is a waste of time to code an earth-shattering
24-bit graphics full-motion video epic only to find out that no
browser on the planet can play it.
<H3><A NAME="Planning">Planning</A></H3>
<P>
Planning is often not that difficult. A couple of pages of outline
and a little research can cut your coding time in half. To begin,
write down the answers to the following questions:
<OL>
<LI><I>What is your game about?</I> This is the easy part. What
do you want to make? A space game? A western? An abstract mind
game? Here, your imagination is the only limit.
<LI><I>How are the players going to interact?</I> This is a base
of your actual coding. Are your players going to fight? If so,
will it be close-up or long-range combat? Will they trade? Communicate?
All of the above?
<LI><I>What constraints are going to be on the game?</I> Because
the Web is a connectionless medium, there is no constant link
open between the client and the server. This makes on-the-fly
updates difficult, if not impossible, by means of standard CGI
(it is possible by using tools like Java, but that's another can
of worms). Because of this, turn-based games are most natural
for CGI. You must decide how long you want your turns to be. A
minute? You better hope your players have fast connections to
keep up. A day? You better hope your players have long attention
spans. Also included in this question is the idea of "scalableness."
Are you expecting five players to play this game? 100? Do you
want to start at five and move to 100? These are questions best
answered before you type your first <TT><FONT FACE="Courier">printf()</FONT></TT>
statement.
</OL>
<H3><A NAME="Outlining">Outlining</A></H3>
<P>
Now you know what you want to do, you have a vague idea of how
you are going to do it, and you have an idea of the size of the
project. The next step is outlining. Ask yourself what your game
entails. Break it up into segments and even write pseudo-code
for parts. As an example, consider one of the most basic game
designs: A bunch of people in a room shooting at each other. (Remember
"Tank" on the Atari 2600?)
<P>
What does this game entail?
<UL>
<LI><FONT COLOR=#000000>Character creation-People must be able
to make new characters in order to join the game.</FONT>
<LI><FONT COLOR=#000000>Map generation-A map that shows the positions
of all the players has to be displayed.</FONT>
<LI><FONT COLOR=#000000>Moving and attack-There must be some mechanism
to carry out player requests to move or attack.</FONT>
<LI><FONT COLOR=#000000>Report-Players must somehow be notified
that they have hit or missed their target (or that they have been
hit themselves).</FONT>
</UL>
<P>
You could even break this down further into more detailed segments,
including pseudocode, along the way. The more detailed your outline
is, the sooner design flaws will show up, and the quicker coding
will be.
<P>
Now we must choose how the information in this game will be stored.
Again, because the Web is a connectionless medium, the server
forgets about the client after data has transferred. The CGI program
itself is therefore responsible for "remembering" information
about the player. There are many ways to do this, but the three
most common (and easiest to implement) are E-Mail, Database, and
Daemon.
<UL>
<LI><FONT COLOR=#000000>E-Mail: This </FONT>is by far the easiest
because Form-to-E-Mail programs exist in bounty for every language
used in CGI. (For example, <TT><FONT FACE="Courier"><A HREF="http://www.boutell.com/email">http://www.boutell.com/email</A></FONT></TT>
or, for Mac users, <TT><FONT FACE="Courier"><A HREF="http://www.lib.ncsu.edu/staff/morgan/E-mail-cgi.html">http://www.lib.ncsu.edu/staff/morgan/E-mail-cgi.html</A></FONT></TT>.)
However, the price to pay for ease is speed and power. Unless
you use an automatic mail-handling program (such as procmail),
the game will progress only every time you read your mail. Even
if you use mail filtering, you must write programs to interpret
the forms and act accordingly. For slow-moving, long-term games,
this may not be a bad thing, and an e-mail interface should be
considered (maybe a "shared-fiction" type game where
players are basically role-playing, for example). However, e-mail
is probably not the best interface for "Shoot 'Em Up Alley."
<LI><FONT COLOR=#000000>Database: This is </FONT>perhaps the most
useful (and most used) method of interaction. This entails taking
the output from the form and storing it in a database of some
sort. This can be as simple as dumping the information to a text
file for later manipulation, or as complicated as connecting to
a full-featured database server for on-the-fly addition and modification
of data. (Several packages exist to ease CGI interaction with
most popular database servers, including mSQL, Sybase, Oracle,
and many others.) For its simplicity in retrieval, this is the
method we are going to use for our sample game.
<LI><FONT COLOR=#000000>Daemon: Though the </FONT>Web itself is
a connectionless medium, there is nothing stopping your CGI program
from taking the data given to it from the form and then connecting
to some sort of daemon and dealing with it at its leisure. The
major disadvantage of this method is that it requires a daemon
process to be continually running for the life of the game. This
can be nontrivial in DOS/Windows platforms. Even on UNIX, it can
be inconvenient if you are a user on a time-sharing system with
fixed quotas. This method does have a large speed advantage and
the added bonus of elimination of file manipulation, which can
be bothersome in the CGI arena. Also included in this category
are CGIs that, instead of connecting to a custom server, connect
to a server that already exists for another purpose. For example,
a CGI could take input from a form, connect to a (probably modified)
MUD server, and then perform actions on the MUD based on the content
of the form. This sort of MUD-WWW interaction is one of the most
popular frontiers of Internet gaming at the present.
</UL>
<P>
In addition to these three options, you can make your form interface
with your game in other ways. For example, you can store retrievable
information about users on their browsers in the form of small
packets of data called <I>cookies</I>. However, cookies are supported
in only a small number of browsers (and in a nonstandard way among
those browsers).
<P>
For our own small multi-player game (let's call it "The Cage"
because it's really just a bunch of people in a cage shooting
at each other), we'll use a database to store information about
the players and the game. This allows us to make the game relatively
fast paced and still avoid the programming complexities of an
entire daemon.
<H3><A NAME="Coding">Coding</A></H3>
<P>
Only now, after completing a good portion of the game in thought
and theory, do we make the step of choosing a language in which
to write the game. There are several choices available for CGI
programming, all of which have strengths and weaknesses in regard
to game necessities. The first thing to consider is complexity.
Which languages do you know? While it never hurts to learn a new
language, if you can write the program with a language you already
know, it may be best to stick with that language. If you've already
had classes in Visual Basic or Pascal, it's very possible that
they will be able to handle the great majority of your CGI needs.
Then there is speed. How fast does this really have to be? If
your game is to have hundreds of simultaneous players and large
computations, speed will be a factor, and a fast language such
as C or C++ might be called for. In our case, there will be only
5 to 10 players at once, and the computations are minimal, so
this is not really a factor. Power is another concern. Whatever
type of game you are making, it will be necessary to parse text
(if only to read the form input). For this reason, Perl has become,
by far, the most widely used language on the Web and the one we
will use to write "The Cage."
<P>
As per our earlier outline, the first thing to provide is a means
for character generation. What is a character? The character is
the human player's presence in the world of the game, and until
computers acquire the capability to be subjective, our only means
of representation of a character is by statistics. Luckily, computers
are very good at statistics. In our case, the statistics are relatively
straightforward. Each player needs a unique identifier; in this
case, we'll use an ID number. A player name is also nice for color.
Because we'll be displaying on a two-dimensional screen, a 2D
grid is natural for our playing field (although 3D or even more
is possible and worth exploring). So we need two coordinates to
place our players in the "cage." If players will be
attacking each other, we need some measure of health; call it
"hit points" for lack of originality. A mechanism for
preventing other players from interfering with a player's move
would also be helpful. We will implement that mechanism with another
stat that is a "hidden" password. Finally, we will include
a list of players who have hit the player recently, so he or she
will know who to plan that sneak attack against. For simplicity,
we will represent these <BR>
statistics in a form similar to a UNIX password file:
<BLOCKQUOTE>
<TT><FONT FACE="Courier">id:name:x position:y position:hit points:password:attackers</FONT></TT>
</BLOCKQUOTE>
<P>
To avoid conflicts, before we write a new character to our database,
we first have to check it against the existing players. So our
first function will gather information from our database (in a
file called state.dat) and store it in an associative array.
<P>
<CENTER><TABLE BORDERCOLOR=#000000 BORDER=1 WIDTH=80%>
<TR><TD><B>Caution</B></TD></TR>
<TR><TD>
<BLOCKQUOTE>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -