Doom networking component

From its first release, Doom supported networked multiplayer gameplay in addition to its single-player gameplay. It was one of the first popular games to support networked play.

Player view
Players can see other players in a multiplayer game. Each player has a different suit color to identify them (green, indigo, brown, and red). A different drawing function is used to draw player sprites, offsetting the green colors in the  player sprite to different palette values in order to change the suit color.

The status bar code includes code to allow talking to other players. Pressing 'T' brings up a cursor where the player can type their message. Pressing the first letter of a player's color name ('G', 'I', 'B' or 'R') allows a message to be sent to an individual player. The text is sent serially: each game tic command has a field for a single character used for multiplayer chat. Typed characters are placed into a queue. When tic commands are generated, characters are read from the queue and stored inside the tic command. The messages are reassembled by the other players.

External drivers
Early versions of Doom (v1.1) included support for IPX networks inside the Doom executable. This was later replaced with a modular system wherein external executable "driver" files provide network functionality to the main Doom executable.

The later versions of Doom include two executables, IPXSETUP.EXE and SERSETUP.EXE, which provide IPX network and modem functionality respectively. The executables are passed the appropriate parameters to set up the connection (IPXSETUP uses broadcast packets to locate other computers setting up a game; SERSETUP will dial the modem or listen for incoming calls). Once a connection has been established, the driver will invoke the main Doom executable.

In starting Doom, the driver passes a  command line parameter. This is used to specify the memory address of a structure inside the driver's memory. This is possible because of DOS's lack of memory protection; it is impossible to do this kind of "hack" inside a modern operating system. The passed structure contains various parameters to be used in the game: the number of players, the start level, gameplay mode (cooperative or deathmatch), as well as various fields used in communication between the driver and the main Doom executable. The driver sets up an interrupt handler. Doom can then send and receive packets by setting a field inside the structure to specify the command type (send or receive packet) and invoking the interrupt. The interrupt is caught by the driver which performs the desired operation. The communication structure includes a buffer in which received data and data to be transmitted is placed.

Because of the modular nature of the external driver system, it is possible to write new drivers to support other kinds of networks. id Software released the source code to SERSETUP and IPXSETUP in 1994. Following this, several new drivers were developed, some improved versions of the original utilities (such as Doomatic), others supporting entirely different network systems. The released source code was initially under a restrictive license, but permission was obtained in 2005 for the code to be relicensed under the [[Wikipedia:GNU General Public License|GNU GPL].

Multiplayer engine
The Doom networking engine is a peer-to-peer system. Each player in the game is an independent "peer" running its own copy of the game. Periodically (every 1/35th of a second), the input from each player (in the form of keyboard, mouse, joystick, etc.) is sampled and placed into a tic command. This is a simple structure which stores how the player wishes to move: there are fields for forward/backward movement, sideways movement (strafing), turning, and actions such as "use" and "fire".

After being generated, the tic commands are placed into a queue. They are then transmitted to all other players in the game. The networking engine periodically checks for newly received packets. Tic commands from other players are stored in a buffer. When the tic commands for all players have been received, the game advances.

Generation of tic commands is independent of the game advancing; for example, a player may generate commands to be used several tics into the future even though the game has not yet advanced to that point. Because of this, in multiplayer games the game itself will not slow down, but there may be a short delay between the pressing of a key and the desired action occurring. The delay depends on the latency between players; hence, the playability of the game is dependent on the player with the slowest connection speed.

The protocol used in Doom is based around negative acknowledgements. Each packet includes a number of tic commands and the number of the first command. If the packet is not the next expected packet, it is assumed that a packet has been lost and a resend request is transmitted to the sender.

Code structure
The code structure is divided into system-specific and system-independent sections. The file i_net.c contains a system-specific interface for sending packets. The engine can run over any system which allows packets to be sent and received. Under DOS, i_net.c uses the external driver system to communicate with IPXSETUP and SERSETUP. In the Unix ports of Doom, UDP/IP is used.

The higher level d_net.c file contains the system-independent portion of the networking code. The code has separate concepts of node and player: a node is simply a computer connected to the game. Each player has a corresponding node, but a node does not necessarily have a player. This was used to implement the "three monitor" system which existed in early versions of Doom: the "left" and "right" screens were nodes but not players.

Particularly important in the d_net.c file is the  function. This checks to see if the engine should generate a new tic command. To ensure playability, this function is called frequently, even from inside the rendering code. The  function checks if enough tic commands have been received from all players and if so, advances the game.

The following variables are important:


 * : Locally generated tic commands. These are stored in a circular buffer.
 * : This is a circular buffer into which received tic commands are placed.  A maximum of BACKUPTICS (usually 12) tic commands can be queued.
 * :The last tic command received from each player.
 * :This is true if a particular node is connected to the game. It is set to false when a node leaves the game.
 * : This is true if a particular player is in the game. It is set to false when a player leaves the game.
 * : The next game tic to be run.
 * : The next game tic to generate a command for. Ideally this should be as close to gametic as possible.
 * :Each player's corresponding node.