131–140 of 169 posts
Carmack's dotplans are always interesting history to read. If you weren't a gamer (or alive) at the time when quakeworld came around, you might not appreciate how amazing it was for multiplayer games on the internet. On dial-up, you were lucky to have 150ms latency. Before client-side-prediction, that latency applied to every action you took in game, including player movements. Hit the up-arrow, and you wait 150-300m…
Carmack's dotplans are always interesting history to read. If you weren't a gamer (or alive) at the time when quakeworld came around, you might not appreciate how amazing it was for multiplayer games on the internet. On dial-up, you were lucky to have 150ms latency. Before client-side-prediction, that latency applied to every action you took in game, including player movements. Hit the up-arrow, and you wait 150-300m…
Sadly we live in a world today where some local code editors could really benefit from CSP because they add 100-200ms of latency to every character you press. I'm not sure if it's funny or sad that there's more key press latency typing into most local Electron apps than connecting to a Quake 3 server 200 miles away back when I had 56k dial-up in 2000. If you want to fast forward to today's internet, with an average i…
Earlier quoted context omitted.
You must be living under a very pleasant rock if you think that low latency, to the degree that client side prediction is useless, is mainstream. Not accounting for routing, drops and mux/demuxing, and assuming that the signal travels at the speed of light as the crow flies, from west coast USA to where I'm at, the latency is 29ms or roughly two frames. This would be debilitating in an online game without CSP where e…
By your numbers then the OP is right. Carmack says: the bottom line is that I was working with the wrong basic assumptions for doing a good internet game. My original design was targeted at So he designed for 200ms and then the real world was 300+ so it didn't work. Your 100ms would then work fine in that context. Maybe games have gotten more complex or our expectations higher so prediction is still worth it even on…
By my numbers (though as you can clearly see from the link I posted, >200ms latencies are not uncommon), and Carmack's assumptions in 1996 about what latencies would be acceptable.
> So he designed for 200ms and then the real world was 300+ so it didn't work. Your 100ms would then work fine in that context.
He designed for which by the frame of reference he cites (T1 connection) probably was a lot lower than 200ms on average.
> Maybe games have gotten more complex or our expectations higher so prediction is still worth it even on
Quake was not a very complex world, but more important (to latency) is that it's a fast paced game by today's standards (IME). It seems more likely to me that perception on what an acceptable hand to eye latency is has changed, just like the perception on acceptable frame rates. To me, joining an online shooter with >100ms latency (even with prevalent client side prediction) feels debilitating, especially if other players have lower latencies.
> But OPs point that the assumptions underlying Carmack's redesign have once again shifted seems correct, at least for that specific design.
Yes, I agree that PPP and SLIP are not common any more. High latency unfortunately is, and client side prediction is still an effective mitigation strategy that makes a huge difference to online play. The specific design used in Quake has of course been superseded.
Earlier quoted context omitted.
The servers could predict what the user does in the next 100ms. Not the same kind of CSP, but fits well into "powered by AI" marketing...
...what's the point of playing competitive first-person-shooters when an AI is at the controls. And those types of game are the ones that are suffering most from input latency.
In a twitch shooter, you mouse over a visible opponent. Would the AI be more likely to pre-emptively pull the trigger for you? Or more likely delay and swing the aim passed the opponent before shooting at air? AKA Is the training set for predictive user actions based on experience of players better or worse at the game than you?
Earlier quoted context omitted.
By your numbers then the OP is right. Carmack says: the bottom line is that I was working with the wrong basic assumptions for doing a good internet game. My original design was targeted at So he designed for 200ms and then the real world was 300+ so it didn't work. Your 100ms would then work fine in that context. Maybe games have gotten more complex or our expectations higher so prediction is still worth it even on…
> By your numbers then the OP is right. By my numbers (though as you can clearly see from the link I posted, >200ms latencies are not uncommon), and Carmack's assumptions in 1996 about what latencies would be acceptable. > So he designed for 200ms and then the real world was 300+ so it didn't work. Your 100ms would then work fine in that context. He designed for which by the frame of reference he cites (T1 connection…
Those numbers match my experience a long time ago with Quake3 based games where you'd pick servers that are local to you and get 10-40ms latencies.
> He designed for
I didn't forget the > It seems more likely to me that perception on what an acceptable hand to eye latency is has changed, just like the perception on acceptable frame rates.
Right, makes sense that the expectation today is much higher.
>High latency unfortunately is, and client side prediction is still an effective mitigation strategy that makes a huge difference to online play.
Just for curiosity, how low does it need to go for prediction to no longer be useful? I guess if you want to be able to have players from all over the world play each other then you have to deal with 300+ ms of latency. But if you are willing to do servers on each geography it seems 10-30 ms would be feasible. Would that be enough?
Earlier quoted context omitted.
> but when moving from ISDN to DSL, ping times increased again and it made total sense to play ESL matches over telephone dialup instead of DSL. Telekom used "interleave" by default, which provided very slightly faster download speeds. And caused about 70 ms latency to the first hop. I had to contact them and ask them to change my ADSL to "fast path". This dropped the latency to maybe 20 ms (IIRC, my memory might fai…
Thanks for the reminder! Yes, I remember fast path. But if memory serves it wasn't immediately available with the 768kbit plan, only a little later. Or at least the knowledge hadn't widely spread.
Earlier quoted context omitted.
You can't really do prediction if you are not rendering the game locally, so all you can do is have a lot of servers all over the world and rely on most customers having a low latency fiber link.
TVs has been so slow for so long anyway. I suspect we will just have a ton of point and click style games or games that are mostly simulations with relatively uninteresting inputs but with potentially bigger visuals, or casual games where even 300ms+ latency doesn't make much of a difference. For better or worse, reflex (time) based games will just not be played on Stadia by serious gamers. We have VR for that now.
VR actually introduces further latency problems. With a TV, your typical PS4 can cover up latency issues with spectacle, as you mentioned. That's a big reason I suspect so many console games feel like a movie today, with tons of cutscenes and quick time events. I've been playing a lot of Bloodborne lately, and while it's an action game, it's still incredibly slow compared to something like Quake.
But with VR, when you move your head you expect the world to feel as if it is real. A TV is artificial, and latency is not an intrusion in the experience. But with VR, latency is felt on a deeper level. Potentially resulting in headaches and nausea.
The funny thing is that John Carmack is riding the state-of-the-art decades later on this front as well: https://www.wired.com/2013/02/john-carmacks-latency-mitigati...
Carmack's dotplans are always interesting history to read. If you weren't a gamer (or alive) at the time when quakeworld came around, you might not appreciate how amazing it was for multiplayer games on the internet. On dial-up, you were lucky to have 150ms latency. Before client-side-prediction, that latency applied to every action you took in game, including player movements. Hit the up-arrow, and you wait 150-300m…
I remember when I was a kid in the 90s and my dad connected two computer to play Doom. The connection was so slow it was almost impossible to play. When my brother and I saw each other’s characters walking around my mind was so blown at the time. Really a great memory. Wait, you can play the same game from 2 computers?
Earlier quoted context omitted.
> "While I can remember and justify all of my decisions about networking from DOOM through Quake, the bottom line is that I was working with the wrong basic assumptions for doing a good internet game." I'm not one for hero worship, but I think that's as close to engineering zen as one can get. Aka 'I'm brilliant. I thought I was doing the smart thing. Turns out reality was otherwise. I'm changing my approach.'
What's kind of sad and funny is that these assumptions changed again and no one seemed to have noticed. We're not on PPP or SLIP connections anymore and yet game devs are still writing netcode as though we are. Client side prediction should have been a temporary hack until low latency connections were mainstream not a permanent aspect of all gaming netcode, and yet it is. Maybe Carmack will wake everyone up again and…
Then take out CSP from their games and watch what happens.
CSP will always be necessary for any Internet-based game. Only LANs have low enough latency to not need it.