<!--<TABLE>
	<TR>
		<TD>
			The Essentials of Multiplayer Games
		</TD>
		<TD>
			See Also:
		</TD>
	</TR>
	<TR>
		<TD COLSPAN=2>-->

<FONT FACE="Verdana, Tahoma, Arial" SIZE="2">

<CENTER><FONT COLOR="#003E98" SIZE="5"><B>The Essentials of Multiplayer Games</B></FONT>
<BR><FONT SIZE="1">or, &quot;Some categorization, problems, solutions, general stuff about multiplayer-games&quot;</FONT>
<BR><B>by Jered Wierzbicki</B></CENTER>
<P>There are a few distinct flavors of multiplayer games, all of which require different approaches. On one hand, there're games written for many players, but designed to be played on a single machine. On the other, there are games written for local play, or in general, gameplay across more than one machine with a local connection not reliant on a network (like a null modem cable or dial-up modem game). Finally, there are games which take place over large, wide-area networks. I shall refer to these as single-machine, local, and networked multiplayer games, respectively, from here on in.</P>
<P>In single-machine multiplayer games, the main game loop must call the engine to process each player involved in the game; this includes getting input from them, moving them, rendering their view, and computing any other logic associated with them in the game. In a local multiplayer game, the game loop only needs to process one player, the player on the machine which the game is running, then send information about the player out to the other machines and accept information about the other players (if needed) in return. Networked multiplayer games are similar to local multiplayer games, but a client/server model is generally used whereby each machine transmits its data to one server, then gets information about other players back from the server.</P>

<P><FONT COLOR="#00983E" SIZE="4"><B>Single-machine multiplayer games</B></FONT></P>
<P>When designing single-machine multiplayer games, which are not very common on PCs these days, you must take into account several questions. The most important of these would be, &quot;How is each player going to be getting input to the game?&quot; and &quot;How is each player going to see their character move, with only one screen?&quot;.</P>
<P>Some common approaches include using two input devices, such as a joystick and a keyboard, or sharing one input device, such as two people using one keyboard (there would have to be seperate keys for every action for every player). Trying to share an input device is a very outdated approach, and I'm pretty sure that the gaming community got sick of it early on.</P>
<P>There have been a few more worthy approaches to the display problem. Most single-machine-many-players-at-the-same-time games simply let players share the same view. As a rule, this will work well only if the view isn't first person, and only if (for 3D games) camera control is independent of player positions. In the old side-scroller days, we sometimes saw split screens, wherein each player's view was rendered on a different half of the screen. Split-screens are a big drag on rendering time for any kind of game, and they definitely can make a game cumbersome, but they do work.</P>
<P>About the most effective approach to the display and input problems associated with one-machine mulitplayer games, at least for PCs, is to use a turn-based system. Considering that they're still actually implemented, I'd say that turn-based systems have had the most luck over the ages. Turn-based systems work by switching between player and player and allowing only one player to play at a time.</P>

<BLOCKQUOTE><FONT FACE="Courier New, fixedsys" SIZE=2 COLOR="#000088">
//A turn-based thingy

//somewhere in a header
player *cur_player;

.....

//somewhere in some source file
void switch_player(player *p) {
     cur_player = p;
     switch_level(p-&gt;level);
.....

//in the main loop
move((player *)&amp;cur_player);

</FONT></PRE></BLOCKQUOTE>


<P>Anyone that can write a single-player game and has an understanding of scalable design knows enough to write a single-machine multiplayer game. Because I've covered scalability, and I assume that you can write a game (as a game programmer...), you can write one, if you'd like. I suspect that you wouldn't like to; you're probably more interested in networked games.</P>
<P>Single-machine multiplayer PC games are becoming progressively more extinct, but I find it fit to note that old single-machine techniques aren't useless. Consoles, mind you, are still very big on one-machine multiplayer.</P>

<P><TABLE WIDTH="90%" CELLPADDING="5" BORDER=1 ALIGN="center"><TR><TD >
    Opinion: Turn-based systems and one-machine single-player games in general are acceptable for &quot;the other&quot; gaming market, that wants to remember what the Atari felt like when they used to pull it out of the closet every other Saturday, but hard-core gamers on modern consoles should be ashamed of it. Hardcore PC gamers might even loathe it, because &quot;MyMachineOnlyMonopoly&quot; is averting the one big advantage of the PC as a gaming platform over everything else; networking, networking, networking. The multiplayer game market paradigm shifted towards interactivity a long, long time ago, and is presently shifting towards networking. Don't overlook it.
</TD></TR></TABLE>

<P><FONT COLOR="#00983E" SIZE="4"><B>Local multiplayer games</B></FONT></P>
<P>Local multiplayer games have been around for quite some time. Support for null-modem play is still very common in today's games. On the contrary, direct machine-to-machine modem connections are a lot less popular than they once were, due to the fact that it gets a bit limiting facing the phone charges associated with long-distance modem calls.</P>
<P>The architecture of a local multiplayer game is fairly simple. Each machine is responsible for updating the game for one player. Each machine then stores the changes in player state in a <i>packet</i> (a packet is data with a header to be transmitted across a connection), which is sent to the other machines. The other machines in the game use this data to update their game-state, and send out information about their own players' movements, and the cycle continues.</P>
<P>Obviously, the specific implementation of this scheme is different between different games: In realtime games, asynchronous packet transmission is a must, and the game has to stay synchronized even if data packets are missed. In non-realtime games, you can rely on sending and receiving packets at a definite time, and you also don't have to worry about overburdening your data stream.</P>
<P>So here's a basic recepie for a local multiplayer game. First, you establish a connection to the other machine(s) in the game. This shouldn't be too hard, considering that a phyisical one (such as a LAN or a null-modem cable, or a direct phone line [modem]) must exist for your game to be considered &quot;local&quot;. Then, you somehow negotiate the initial setup of the game. Finally, the game begins, and you begin the data-transfer process just described. Then, of course, you close the &quot;connection&quot;. It's conceptually simple.</P>
<P>Here's some code to convey all of this, and a bit more (a very simple example).</P>

<BLOCKQUOTE><PRE><FONT FACE="Courier New, fixedsys" SIZE=2 COLOR="#000088">
//pseudo-code

#define NEW_GAME        2
#define LEAVING_GAME    4
#define SOMETHING       8
#define RESET           16

#define ESCAPE_SEQUENCE 0xFFFFFFFF

#define MAX_QUEUE       16
#define MAX_BUFFER      256

typedef struct {
int obj,x,y,z,frame;  //none of these can be 0xffffffff
input_status i;       //no elements of this can be 0xffffffff
unsigned char flags;  //can't = 255 (0xFF)
int magic;            //always 0xFFFFFFFF to indicate the end of the packet
} game_packet;

game_packet queue[MAX_QUEUE];
int cur_queue=0, unprocessed_packets=0;
int sync_err=0, packets_lost=0; //sync_err is a reserved flag for major
                                //synchronozation errors

unsigned char serial_buffer[MAX_BUFFER];
int cur_buf=0, last=0;

//read this carefully (regarding an imaginary interrupt handler <i>x</i>):

//how it works: