52  Core Protocol (d_net)

This tour explores how DOOM synchronizes multiplayer games through the d_net module’s network protocol, packet structures, and core functions.

doomdata_t defines the network packet payload containing game commands and timing data for multiplayer synchronization.
linuxdoom-1.10/d_net.h (lines 62–74)

doomcom_t serves as the main network communication structure, containing game configuration settings and network metadata. It wraps the actual packet data (stored in its doomdata_t field) with information needed for network routing and game setup.
linuxdoom-1.10/d_net.h (lines 79–127)

HGetPacket copies reboundstore into netbuffer, restoring the doomdata_t state for loopback communication.
linuxdoom-1.10/d_net.c (lines 196–199)

During initialization in D_CheckNetGame, netbuffer is set to point at doomcom->data (line 572), linking the packet payload pointer to the doomcom_t buffer. consoleplayer and displayplayer are then initialized from doomcom->consoleplayer (line 573), showing extraction of the current player index.
linuxdoom-1.10/d_net.c (lines 572–573)

NetUpdate creates and broadcasts player commands to peers, D_QuitNetGame sends exit notifications to other players, and TryRunTics executes game ticks based on available network data.
linuxdoom-1.10/d_net.h (lines 131–139)

NetbufferSize calculates the size needed for a network packet containing game commands.
linuxdoom-1.10/d_net.c (lines 90–93)

NetbufferChecksum calculates a checksum value for network packets. On UNIX systems, it returns 0 due to byte ordering concerns.
linuxdoom-1.10/d_net.c (lines 98–115)

ExpandTics reconstructs complete game tick values from compressed network data, maintaining synchronization between networked game instances.
linuxdoom-1.10/d_net.c (lines 120–127)

The next steps examine the network packet handling routines HSendPacket and HGetPacket in d_net.c. These functions handle the low-level sending and receiving of network data.

HSendPacket combines a checksum of the network buffer with additional flags before sending a packet. When node is 0, it handles the packet as a special case.
linuxdoom-1.10/d_net.c (lines 142–149)

HSendPacket validates the game state before sending network packets: it skips during demo playback and prevents sending in non-network games.
linuxdoom-1.10/d_net.c (lines 156–163)

HGetPacket processes loopback packets stored in reboundpacket.
linuxdoom-1.10/d_net.c (lines 192–199)

HGetPacket attempts to receive a network packet, returning false if none is available.
linuxdoom-1.10/d_net.c (lines 208–216)

HGetPacket validates incoming network packets by checking length and checksum.
linuxdoom-1.10/d_net.c (lines 214–222)

The next steps examine GetPackets and NetUpdate, which handle retrieving and sending network packets to keep all DOOM nodes synchronized during gameplay.

GetPackets processes incoming network data packets into game commands.
linuxdoom-1.10/d_net.c (lines 261–269)

GetPackets processes incoming network packets. It skips setup packets and extracts the sending player’s console and node information.
linuxdoom-1.10/d_net.c (lines 269–277)

When a packet is lost, the receiver can request retransmission by setting NCMD_RETRANSMIT. GetPackets processes these requests by marking which game tick to resend from.
linuxdoom-1.10/d_net.c (lines 303–311)

GetPackets calculates where to start copying network commands from the received packet into the local command buffer.
linuxdoom-1.10/d_net.c (lines 340–347)

The next steps examine NetUpdate, which synchronizes game state between networked DOOM players by exchanging command packets between peers.

NetUpdate synchronizes game time across networked players, managing the pacing of game updates.
linuxdoom-1.10/d_net.c (lines 368–376)

NetUpdate processes input events and generates new game tics for the console player, ensuring the number of pending tics stays within bounds.
linuxdoom-1.10/d_net.c (lines 398–404)

NetUpdate prepares game state packets for each connected node, setting tic counts and enforcing size limits.
linuxdoom-1.10/d_net.c (lines 416–424)

NetUpdate handles packet retransmission by checking remoteresend flags for each node.
linuxdoom-1.10/d_net.c (lines 431–438)

GetPackets processes any incoming network commands.
linuxdoom-1.10/d_net.c (lines 444–446)

This group of steps examines TryRunTics, which drives the game’s timing system and coordinates network play by determining when to advance the game state.

TryRunTics coordinates game timing across network nodes, managing the synchronization of game ticks between players.
linuxdoom-1.10/d_net.c (lines 636–644)

TryRunTics calculates how many game ticks to process this frame.
linuxdoom-1.10/d_net.c (lines 648–656)

TryRunTics processes multiple game ticks, ensuring the game state stays synchronized with network play.
linuxdoom-1.10/d_net.c (lines 735–743)

Next we’ll look at D_CheckNetGame and D_QuitNetGame, which handle starting and ending network game sessions.

D_CheckNetGame performs network game initialization and setup, preparing DOOM for networked multiplayer.
linuxdoom-1.10/d_net.c (lines 555–563)

D_QuitNetGame cleanly disconnects the local player from an active network game.
linuxdoom-1.10/d_net.c (lines 602–610)

And that’s DOOM’s network protocol - keeping all players in sync through careful packet exchange and tick management.