The Basics
Before we get into the specifics of how the two netcode strategies work, we first have to set a few ground rules that govern fighting games and introduce a few terms.
In fighting games, time is measured in a unit called a frame. Just to make the discussion easier, we’ll assume that all fighting games operate at 60 frames per second, which means that one frame is around 16 milliseconds (ms) of real time.
Importantly, this isn’t just how fast the game renders new images to your screen; every frame, 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.
When playing a fighting game offline against your friend, you connect two controllers to one computer or console. If you both happen to press a button within the same 16 millisecond window, the game will receive and process the inputs on the same frame and apply the logic as expected. You will both see the same output, because there is only one computer doing the calculations.
This changes when two players are playing over the internet.
First of all, information always takes time to send through a network. This is measured in ping, the amount of time it takes for information to be sent to the other player and then back to you. Over a connection with 90ms ping, for example, it takes 45ms (on average) for information to reach the other side, which is about 3 in-game frames. This means games now need to be clever about how they handle the input part of their game loop, as they can no longer guarantee button presses for the remote player will line up with the local player.
Secondly, two different computers are now trying to run two copies of the game at the same time, but still produce identical results for both players. That’s why it’s a great idea for fighting games to be deterministic -- given identical inputs, every machine that runs the game must produce identical results. This is cool for non-networking features like replays, because you can simply save the inputs from each player and always reconstruct the match perfectly, but it also means 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. They don’t talk to a central authority that keeps track of the game for them and tells them what to do, like a server. Instead, they police themselves by asking each other periodically if they have the same game state. If the games start to disagree about the state of the game, they are desynced and will probably just have to abandon the match entirely. Games talking to each other directly can often be faster than being forced to talk through an intermediary, and lockstep solutions are particularly good at preventing many types of cheating. For example, even if you hacked your game so Ryu can throw faster fireballs, my simulation of the game won’t agree with yours and we will quickly desync.
Now, after all this setup, we can finally get to the meat of the problem. If we have a deterministic fighting game that uses lockstep networking, the only thing we need to play online matches is the input from both players. Let’s talk about these "clever ways" a fighting game handles player inputs that are never received on time.