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 blame "bad netcode" when they experience lag or reverse state transitions when synchronization between players is lost. Although these events are sometimes caused by bugs, other networking-related causes include high latency between server and client, packet loss, or network congestion. Depending on the game implementation, these issues can also be caused by non-network factors such as frame rendering time or inconsistent frame rate. Netcode is often designed to mask networking irregularities and create a synchronous and smooth gamestate across multiple users.

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 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. During an online match, games must receive and process players' input within a certain time for each frame, and if a remote player's input of a particular frame arrives when another one is already running, desynchronization between player simulations is produced. There are two main resolutions to this conflict implemented in modern games: delay-based and rollback-based resolution.

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, 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, 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, as if it were an offline game, and predicts the inputs of the remote player or players instead of waiting for them. Once these remote inputs arrive, 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. Some games utilize a hybrid solution in order to disguise these "jumps" 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, 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. To address this uneven input flow, there are standard solutions such as waiting for the late entries to arrive to all machines 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, 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 and in other video game genres.
There is a popular MIT-licensed library named GGPO designed to help implement rollback networking to games.

Games using rollback netcode

Latency

is unavoidable in online games, and the quality of the player's experience is strictly tied to this. The latency of the players' network 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.

Tick rate

A single update of a game simulation is known as a tick. The rate at which the simulation is run on a server is often referred 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 , 64 ticks per second, 30 ticks per second and 20 ticks per second. 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 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.