Netcode 01022022

Last updated February 1, 2022

Notes

Ping

• Ping == RTT
• ICMP Echo Request
• Varies highly with congestion
• Testing IRTT

At lower MTU, packet delays are lower than at higher MTU. Higher MTU results in good link utilization, lower MTU results in good link utilizations at lower bandwidth, degrading to fair utilization at high bandwidth.

Routing

• Choosing the fastest route to the datacenter
• Routing tables
• Tracert data can be manually fed
• Chosing a higher update rate

Tick Rate

• Simulation rate : Frequency at which game processes and produces data
• Processing window for a tick $T=1/f$
• Lesser the tick processing time =>Greater available window for tick to be sent $\because$ (Processing window is limited )

Network Model

• Dedicated Server
• Client Hosted
• P2P

Packet Loss

• Defective NIC
• Faulty drivers
• Interference / Congestion particularly in WiFi
• Router firmware/ hardware
• Network Congestion
• Advances
  - CoDel - Fair Queuing (FQ) with Controlled Delay (CoDel) - The Cake Algoritm

Jitter

• Latency Variation
• Standard Deviation from mean latency

infil.net

Netcode infil.net

• The game executes its game loop, which (among other things) asks the players’ controllers for inputs, checks the network for new information, runs AI for any CPU players, animates the moves each character is doing, and checks if someone is now getting hit. After it’s done all these things, it draws the results of all its calculations to the screen, then does it all again 16 milliseconds later. In fighting games, this loop needs to be tight and consistent for all players who play your game, regardless of how fast or slow their computer is.
• The game only needs to send player inputs over the network to play online matches. We get to avoid sending complicated information about the game state and can save a lot of bandwidth.
• When games send information to each other and then rely on the computers to independently run the simulations in sync, it’s said they are using lockstep networking.
• Clients police themselves by asking each other periodically if they have the same game state.
• When playing online, your own inputs are received immediately, but your opponent’s inputs for the same frame need to be sent over the network and will arrive late. The game needs a strategy for how it will deal with these late inputs while keeping the game feeling as close to offline play as possible.
• Delay-based or input delay, is the simplest and most common implementation for games using lockstep networking. If a remote player’s inputs are arriving late because they need to be sent over the network, delay-based strategies simply artificially delay the local player’s inputs by the same amount of time.
• The main problem is consistency. Because networks are notoriously inconsistent, delay-based strategies struggle because they are terrible at handling network fluctuations. Suppose there is a spike in the connection and some information from your opponent takes a little longer than the estimated 3 frames to reach you. Because the game simply cannot proceed without information from both players, it has no choice but to stop and wait for the input to arrive, causing the game to chug and lurch along during moments of prolonged network trouble.
• Rollback’s main strength is that it never waits for missing input from the opponent. Instead, rollback netcode continues to run the game normally. All inputs from the local player are processed immediately, as if it was offline. Then, when input from the remote player comes in a few frames later, rollback fixes its mistakes by correcting the past. It does this in such a clever way that the local player may not even notice a large percentage of network instability, and they can play through any remaining instances with confidence that their inputs are always handled consistently. $Act Now , Aplogize Later$
• Rollback allows each client to temporarily break the lockstep model – the game may be showing slightly different things to each player, depending on the connection quality and what’s happening at the time of the rollbacks. However, the game will always correct itself to be the same for both players whenever the inputs have been received a few frames later.
• Rollback is particularly great for lossy connections, like WiFi
• When input is missing, what rollback solutions actually do is duplicate the last known input from the remote player for the current missing frame. If they were holding down-back, the game predicts they will continue to hold down-back. If they were holding a button, the game assumes they are probably still holding that button. The game then runs with these predicted inputs for the remote player instead. All it really does is assume the remote player has not changed their inputs from the last time it received information from the network.
• We can eliminate (frequent rollbacks) by combining delay-based and rollback solutions. In fact, every modern fighting game that uses rollback is built on a delay-based framework, with the important caveat that the delay is fixed at the start, and never changes.As long as the delay is small and consistent, players will quickly adapt and many will not even notice a difference from offline play.
• GGPO Rollback open source implementation

#networking #netcode