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

Super Street Fighter II Turbo HD Remix Marvel vs. Capcom 2: New Age of Heroes Touhou Suimusou: Immaterial and Missing Power Street Fighter X Tekken Touhou Hisoutensoku Killer Instinct Killer Instinct Classic Killer Instinct 2 Classic Eternal Fighter Zero Melty Blood Actress Again Current Code Brawlhalla Street Fighter V Mortal Kombat XL For Honor River City Ransom: Underground Injustice 2 Marvel vs. Capcom: Infinite Umineko: Golden Fantasia Acceleration of Suguri 2 The King of Fighters '97 Global Match Street Fighter 30th Anniversary Collection Lethal League Blaze Mortal Kombat 11 Fight of Gods Samurai Shodown V Special Power Rangers: Battle for the Grid Fight of Animals Garou: Mark of the Wolves Maiden & Spell Mighty Fight Federation The Last Blade 2 Samurai Shodown NeoGeo Collection Super Smash Bros. Melee Fighting EX Layer Spelunky 2 The King of Fighters 2002: Unlimited Match Dual Souls: The Last Bearer Tough Love Arena Guilty Gear -Strive- Dengeki Bunko: Fighting Climax Ignition The King of Fighters All Star Rivals of Aether Petal Crash Online Nickelodeon All-Star Brawl The King of Fighters '98: Ultimate Match Final Edition Windjammers 2 BlazBlue: Central Fiction BlazBlue: Cross Tag Battle DNF Duel MultiVersus Persona 4 Arena Ultimax Mega Man Battle Network Mega Man Battle Network 2 Mega Man Battle Network 3 Mega Man Battle Network 4 Rockman EXE 4.5 Real Operation Mega Man Battle Network 5 Mega Man Battle Network 6 Capcom Fighting Collection Teenage Mutant Ninja Turtles: Tournament Fighters SNES ver via Teenage Mutant Ninja Turtles: The Cowabunga Collection The Rumble Fish 2

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 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.

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 have used lockstep protocol 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 can also affect perceived networking issues.
If a game uses Transmission Control Protocol, 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. These connections, however, are not quite suited to the network speeds that fast-action games require, as this type of protocol automatically groups data into packets which will be sent through the connection established between the machines, rather than directly. 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.
If the game instead uses a User Datagram Protocol, 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 ; this increases the engine's complexity and might itself lead to issues.