Netcode

Netcode is a blanket term most commonly used by gamers relating to networking in online games, often referring to synchronization issues between clients and servers. Players often infer "bad netcodes" when they experience lag or when their inputs are dropped. Common causes of such issues include high latency between server and client, packet loss, network congestion, and external factors independent to network quality such as frame rendering time or inconsistent frame rates. Netcodes may be designed to uphold a synchronous and seamless experience between users despite these networking challenges.

Netcode types

Unlike a local game where the inputs of all players are executed instantly in the same simulation or instance of the game, in an online game there are several parallel simulations (one for each player) where the inputs from their respective players are received instantly, while the inputs for the same frame from other players arrive with a certain delay (greater or lesser depending on the physical distance between the players, the quality and speed of the players' network connections, etc.). During an online match, games must receive and process players' input within a certain time for each frame (equal to 16.  ms per frame at 60  FPS), and if a remote player's input of a particular frame (for example, of frame number 10) arrives when another one is already running (for example, in frame number 20, 166. ms later), desynchronization between player simulations is produced. There are two main solutions to resolving this conflict and making the game run smoothly:

Delay-based

The classic solution to this problem is the use of a delay-based netcode. When the inputs of a remote player arrive late, the game delays the inputs of the local player accordingly to synchronize the two inputs and run them simultaneously. This added delay can be disruptive for players (especially when latency is high), but overall the change is not very noticeable. However, these delays can be inconsistent due to sudden fluctuations in current latency. Should the latency between players exceed an established buffer window for the remote player, the game must wait, causing the screens to "freeze". This occurs because a delay-based netcode does not allow the simulation to continue until it receives the inputs from all the players in the frame in question. This variable delay causes an inconsistent and unresponsive experience compared to offline play (or to a LAN game), and can negatively affect player performance in timing-sensitive and fast-paced genres such as fighting games.

Rollback

An alternative system to the previous netcode is rollback netcode. This system immediately runs the inputs of the local player (so that they are not delayed as with delay-based netcode), as if it were an offline game, and predicts the inputs of the remote player or players instead of waiting for them (assuming they will make the same input as the one in the previous tick). Once these remote inputs arrive (suppose, e.g., 45 ms later), the game can act in two ways: if the prediction is correct, the game continues as-is, in a totally continuous way; if the prediction was incorrect, the game state is reverted and gameplay continues from the corrected state, seen as a "jump" to the other player or players (equivalent to 45 ms, following the example). Some games utilize a hybrid solution in order to disguise these "jumps" (which can become problematic as latency between players grows, as there is less and less time to react to other players' actions) with a fixed input delay and then rollback being used. Rollback is quite effective at concealing lag spikes or other issues related to inconsistencies in the users' connections, as predictions are often correct and players do not even notice. Nevertheless, this system can be troublesome whenever a client's game slows down (usually due to overheating), since rift problems can be caused leading to an exchange of tickets between machines at unequal rates. This generates visual glitches that interrupt the gameplay of those players that receive inputs at a slower pace, while the player whose game is slowed down will have an advantage over the rest by receiving inputs from others at a normal rate (this is known as one-sided rollback). To address this uneven input flow (and consequently, an uneven frame flow as well), there are standard solutions such as waiting for the late entries to arrive to all machines (similar to the delay-based netcode model) or more ingenious solutions as the one currently used in ''Skullgirls'', which consists of the systematic omission of one frame every seven so that when the game encounters the problem in question it can recover the skipped frames in order to gradually synchronize the instances of the games on the various machines.

Rollback netcode requires the game engine to be able to turn back its state, which requires modifications to many existing engines, and therefore, the implementation of this system can be problematic and expensive in AAA type games (which usually have a solid engine and a high-traffic network), as commented by ''Dragon Ball FighterZ'' producer Tomoko Hiroki, among others.

Although this system is often associated with a peer-to-peer architecture and fighting games, there are forms of rollback networking that are also commonly used in client-server architectures (for instance, aggressive schedulers found in database management systems include rollback functionality) and in other video game genres.

There is a popular MIT-licensed library named GGPO designed to help implement rollback networking to games (mainly fighting games).

Potential causes of netcode issues

Latency

Latency is unavoidable in online games, and the quality of the player's experience is strictly tied to this (the more latency there is between players, the greater the feeling that the game is not responsive to their inputs). That the latency of the players' network (which is largely out of a game's control) is not the only factor in question, but also the latency inherent in the way the game simulations are run. There are several lag compensation methods used to disguise or cope with latency (especially with high latency values).

Tickrate

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 is often between 128 ticks per second (such is Valorant's case)'','' 60 ticks per second (in games like Counter-Strike: Global Offensive and Overwatch), 30 ticks per second (like in Fortnite and Battlefield V's console edition) and 20 ticks per second (such are the controversial cases of Call of Duty: Modern Warfare, Call of Duty: Warzone and Apex Legends). 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.

Because of limitations in the amount of available bandwidth and the CPU time that's taken by network communication, some games prioritize certain vital communications while limiting the frequency and priority of less important information. As with tickrate, this effectively increases synchronization latency. Game engines may limit the number of times that updates (of a simulation) are sent to a particular client and/or particular objects in the game's world in addition to reducing the precision of some values sent over the network to help with bandwidth use. This lack of precision may in some instances be noticeable.

Software bugs

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 (such as Age of Empires) 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.

Transport layer protocol and communication code: TCP and UDP

A game's choice of transport layer protocol (and its management and coding) can also affect perceived networking issues.

If a game uses a Transmission Control Protocol (TCP), there will be increased latency between players. This protocol is based on the connection between two machines, in which they can exchange data and read it. These types of connections are very reliable, stable, ordered and easy to implement, and are used in virtually any operation we do on the Internet (from web browsing to emailing or chatting through an IRC). These connections, however, are not quite suited to the network speeds that fast-action games require, as this type of protocol (Real Time Streaming Protocols) automatically groups data into packets (which will not be sent until a certain volume of information is reached, unless this algorithm - Nagle's algorithm - is disabled) which will be sent through the connection established between the machines, rather than directly (sacrificing speed for security). This type of protocol also tends to respond very slowly whenever they lose a packet, or when packets arrive in an incorrect order or duplicated, which can be very detrimental to a real-time online game (this protocol was not designed for this type of software).

If the game instead uses a User Datagram Protocol (UDP), the connection between machines will be very fast, because instead of establishing a connection between them the data will be sent and received directly. This protocol is much simpler than the previous one, but it lacks its reliability and stability and requires the implementation of own code to handle indispensable functions for the communication between machines that are handled by TCP (such as data division through packets, automatic packet loss detection, etc.); this increases the engine's complexity and might itself lead to issues.

See also

* Online game
* Lag (online gaming)
* GGPO

References

{{Reflist

Multiplayer video games
Servers (computing)
Video game development
Video game platforms