Netcode is a blanket term for anything that somehow relates to networking in online games; netcode is a term most commonly used by gamers when discussing synchronization issues between clients and servers. The actual elements of a game engine that can cause so-called "netcode issues" include, among other things, latency, lag compensation or the lack thereof, simulation errors, and network issues between the client and server that are completely out of the game's hands. Netcode as a term tends to be used only in the gaming community, as it is not recognized as an actual computer science term.
Potential causes of netcode issues
is an unavoidable fact of online games, caused by not only network latency, which is largely out of a game's control, but also latency inherent in the way game simulations are run. There are several lag compensation methods used to disguise, reduce, or cope with latency, however their feasibility varies by application. A single update of a game simulation is known as a tick. The rate at which the simulation is run on a server is referred often to as the server's tickrate; this is essentially the server equivalent of a client's frame rate, absent any rendering system. Tickrate is limited by the length of time it takes to run the simulation, and is often intentionally limited further to reduce instability introduced by a fluctuating tickrate, and to reduce CPU and data transmission costs. A lower tickrate increases latency in the synchronization of the game simulation between the server and clients. Tickrate for games like first-person shooters can vary from 60 ticks per seconds for games like Quake or in competitive mode to 30 ticks per seconds for games like Battlefield 4 and Titanfall. A lower tickrate also naturally reduces the precision of the simulation, which itself might cause problems if taken too far, or if the client and server simulations are running at significantly different rates. Games may limit the number of times per second that updates are sent to a particular client, and/or are sent about particular objects in the game's world. Because of limitations in the amount of bandwidth available, and the CPU time that's taken by network communication, some games prioritize certain critical communication while limiting the frequency and priority of less important information. As with the tickrate, this effectively increases the synchronization latency. Game engines may also reduce the precision of some values sent over the network to help with bandwidth use; this lack of precision may in some instances be noticeable. Various simulation synchronization errors between machines can also fall under the "netcode issues" blanket. These may include bugs which cause the simulation to proceed differently on one machine than on another, or which cause some things to not be communicated when the user perceives that they ought to be. Traditionally, real-time strategy games have used lock-step peer-to-peer networking models where it is assumed the simulation will run exactly the same on all clients; if, however, one client falls out of step for any reason, the desynchronization may compound and be unrecoverable.
In order for an online game to function smoothly, player input must be received within a certain time for each frame. However, due to inconsistent network conditions and physical distance between players, this may not be realized. Many games solve this using delay-based netcode, which allows for a buffer within which input can be received. When input fails to be sent within this buffer, the game has to wait, causing freezes. Because this delay can be variable, this causes an inconsistent experience compared to offline play, and can affect player performance in timing-sensitive genres such as fighting games. An alternate solution, rollback networking, predicts remote player input instead of waiting. When this prediction is correct, the game proceeds as-is. If the prediction was incorrect, the game state is reverted and gameplay continued from the corrected state, seen as a "jump". Most games utilize a hybrid solution, with a fixed input delay, and then rollback being used. Rollback requires the game engine to be able to turn back its state, so requires changes to existing engines. A library named GGPO also exists to help implement rollback.
A game's choice of transport layer protocol can also affect perceived networking issues. Should the game use TCP, networking will have a high overhead cost and increased latency. Should it use UDP, the game engine may need to implement its own networking code to handle error conditions and other things that are handled by TCP; this increases the engine's complexity and might itself lead to issues.
