4 ms·

From the .plan it appears that the qw client didn't predict entities aside from the player. I don't understand the fundamental difference between netquake and q

by powercf 10y ago

From the .plan it appears that the qw client didn't predict entities aside from the player. I don't understand the fundamental difference between netquake and quakeworld so I can't explain why, but quakeworld always felt somewhat "unreal" when playing with a high ping, whereas netquake didn't (it just felt slow). I would imagine this isn't very relevant these days, as nobody plays with a 300ms ping (+ packet loss) any more.

whatever_dude 10y ago
NetQuake had no prediction, you'd only see what your client got from the server. It felt weird, but it was 100% correct, even if a bit delayed. QuakeWorld had prediction, so it'd render everything to the best of its abilities, and then correct as needed. You didn't just get the position of a rocket, for example; you got its velocity vector too. And everything was UDP based, so missed packets could easily be ignored and the clients would fill in the blanks. For all its weirdness, it was a beautiful thing back then. I haven't taken a deep look into modern game protocols, but I believe games today go a bit further. They don't just get position and velocity vector from the client, they spawn and control read-only entities on the client side. The client runs a full simulation. The result is that you get a seemingly much smoother experience, with no interruptions or corrections. But the downside is that you might be seeing things that are completely incorrect. You'll see yourself killing someone and their model playing a death animation, but then one second later you're dead once the client gets the truth from the server. Personally, I prefer the way QuakeWorld did things. It at least allowed you to compensate for the lag - leading rockets, etc. Playing QuakeWorld with a ~200ms lag was mostly fine for me. But if I play a game with 50ms lag, I'll be getting my shots all wrong and not even realizing it.

by powercf 10y ago

whatever_dude 10y ago

NetQuake had no prediction, you'd only see what your client got from the server. It felt weird, but it was 100% correct, even if a bit delayed. QuakeWorld had prediction, so it'd render everything to the best of its abilities, and then correct as needed. You didn't just get the position of a rocket, for example; you got its velocity vector too. And everything was UDP based, so missed packets could easily be ignored and the clients would fill in the blanks. For all its weirdness, it was a beautiful thing back then. I haven't taken a deep look into modern game protocols, but I believe games today go a bit further. They don't just get position and velocity vector from the client, they spawn and control read-only entities on the client side. The client runs a full simulation. The result is that you get a seemingly much smoother experience, with no interruptions or corrections. But the downside is that you might be seeing things that are completely incorrect. You'll see yourself killing someone and their model playing a death animation, but then one second later you're dead once the client gets the truth from the server. Personally, I prefer the way QuakeWorld did things. It at least allowed you to compensate for the lag - leading rockets, etc. Playing QuakeWorld with a ~200ms lag was mostly fine for me. But if I play a game with 50ms lag, I'll be getting my shots all wrong and not even realizing it.