Hacker News new | ask | show | jobs
by 101008 1457 days ago
Interesting article! Congrats on the launch. But as an ocassional gamer I thought the way online games work was different.

For example, I play FIFA online and I believed that once a match making had place, Player A (me) synced a seed with Player B, and then the only thing that had to go over the network was the input, and every device could generate the game since they shared the same seed (which makes it deterministic).

Isn't much more complicated to have the engine on the server and send the state to the device?

3 comments

The vast majority of games don't work the way you're talking about. I think the only ones that do are fighting games where latency is crucial.

It's much more complicated to only share input because to avoid desync the game engine has to be able to either rollback the state to accept inputs from other players sent over a slow connection, or alternatively just pause the game until it receives the next tick's inputs. See this article: https://arstechnica.com/gaming/2019/10/explaining-how-fighti...

It's easier to prevent cheating if the engine is on the server. Could you elaborate on what you mean by

> they shared the same seed (which makes it deterministic)

In addition to game init params (like random seeds), the game state is also a function of time, which cannot be synchronized the same way that seeds can.

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.