3 ms·

I played Quake at the time on dial-up with an approx 250ms - 350ms ping. I believe the majority of players preferred quakeworld, but I always felt it was a regr

by powercf 10y ago

I played Quake at the time on dial-up with an approx 250ms - 350ms ping. I believe the majority of players preferred quakeworld, but I always felt it was a regression on vanilla Quake net play. Vanilla quake was slow, but the world felt "real". Your position, enemies, rockets, doors etc. were where they were, and you could react based on that. Quakeworld added prediction, and more client side processing. As a result, you could no longer depend on things being where they were - the enemy you just saw run around that corner did not run around that corner, and instead fired a rocket in your face. You are dead but your client hasn't got that packet yet.

qwertyuiop924 10y ago
Eh. I wasn't around, so I wouldn't know. Although nowadays, you can still kind of see this problem, as your character abruptly turns to where you were looking a second ago. Also, AFAIK, QW doesn't simulate enemies or rockets clientside, so not seeing an enemy fire a rocket and having it kill you would happen the same way in NetQuake (quake's original network protocol). Of course, I haven't seen the code...
- 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

qwertyuiop924 10y ago

Eh. I wasn't around, so I wouldn't know. Although nowadays, you can still kind of see this problem, as your character abruptly turns to where you were looking a second ago. Also, AFAIK, QW doesn't simulate enemies or rockets clientside, so not seeing an enemy fire a rocket and having it kill you would happen the same way in NetQuake (quake's original network protocol). Of course, I haven't seen the code...

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.