| You'll find many interesting videos and articles if you search "netcode". It is easy to underestimate the complexity of domains you're not familiar with, but that just means more fun when you find out how unexpected problems crop up and the innovative ways they are solved. Your middle paragraph is works fine for LAN, and is how games were programmed. send controller input over the network, compute the next state, send controller input over the network, repeat.
But, things get complicated as network delay goes up. Imagine you put two consoles next to each other with a 150ms delay Ethernet cable between them. If you always have to wait for your opponent's inputs, a 150ms delay makes the maximum tick rate drops to less than 7 ticks per second. You can't just start the game at the same time, with the same seed and apply inputs as soon as they arrive. The games would instantly desync, because your inputs from frame 1 apply on frame 15 for your opponent, and your opponent's inputs from frame 1 don't get to you until your frame 15. ok so just update the engine so that local inputs are processed 15 frames later. that works, but it makes players nauseous. and what if there is a lag spike? Modern netcode can gracefully deal with network delay, lag spikes, dropped packets, faulty client hardware, and more, while being computationally and network efficient, and can't be exploited for an unfair advantage. A proper explanation of rollback code involves special relativity and time travel. It's so cool. I'm working on my own article and I'll try to send it to you when I'm done. |