Live data from Hacker News

John Carmack on QuakeWorld latency and business model (1996)

raw.githubusercontent.com

111–120 of 169 posts

Re: John Carmack on QuakeWorld latency and business model (1996)

#111
post #45

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.

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...

That would make the delay much worse if you mis-predict the users action. Games would also have to add additional 100ms lag for all important events.

Re: John Carmack on QuakeWorld latency and business model (1996)

#112
post #109
post #45

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.

> For better or worse, reflex (time) based games will just not be played on Stadia by serious gamers.

True, but don't overestimate the importance of "serious gamers" to the industry's bottom line. IIRC, mobile gaming is now making more money than all PC and home systems combined.

Re: John Carmack on QuakeWorld latency and business model (1996)

#113
post #111

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...

That would make the delay much worse if you mis-predict the users action. Games would also have to add additional 100ms lag for all important events.

If you had a big enough server, you could render multiple frames for each possible user action...

Re: John Carmack on QuakeWorld latency and business model (1996)

#114
post #59

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...

They probably would, but the creative players would suffer from it. AI never predicts creativity.

I think prediction failures are more likely to punish the opponents of the unpredictable guy. In a lot of online shooters, people with 300ms+ ping blink around unpredictably and appear to suddenly murder you out of nowhere, but they don't seem to have any trouble themselves.

Re: John Carmack on QuakeWorld latency and business model (1996)

#115
post #108

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…

The worst part was having a 200ms ping and getting constantly smoked by the guy with the sub-100ms ping. Hence the acronym LPB (low ping bastard).

I dunno, I actually hated the HPBs more, because at least I could rationalize getting beat by an LPB, i.e. someone with a technological advantage over me. ;-)

Re: John Carmack on QuakeWorld latency and business model (1996)

#116
post #88

Earlier quoted context omitted.

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…

vs code typing latency is on the order of 50ms. its more than necessary but not as bad as you are implying

VS Code is pretty good for an Electron app

Re: John Carmack on QuakeWorld latency and business model (1996)

#117
post #9

Complete aside about Carmack and reducing VR latency from https://www.gamasutra.com/view/news/226112/How_John_Carmack_... : "He gave the example of increasing the refresh rate on the Gear VR during development. He was working, at that time, with its Galaxy S III phone. Android triple-buffers graphics, inducing a 48 millisecond delay into the system -- making VR impossible. Carmack pulled apart Android to hack that ou…

Carmack is probably the most self-consistent opinionated creator out there, given that so many years on he still sticks to one of his original quotes: > "Focused, hard work is the real key to success. Keep your eyes on the goal, and just keep taking the next step towards completing it. If you aren't sure which way to do something, do it both ways and see which works better." He'll even do Samsung's work for them to f…

Carmack's brain is so much like a computer that it even does speculative execution branch prediction!

Re: John Carmack on QuakeWorld latency and business model (1996)

#118
post #80

Earlier quoted context omitted.

It's funny. Sure, DSL brought the (much) bigger bandwidths, 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. But either they improved or it's just the normal. Anyway, I stopped playing shooters in the early 00s and so I don't really care anymore. source: German who never had a 56k modem but started with ISDN in 1998 and can'…

> 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.

Re: John Carmack on QuakeWorld latency and business model (1996)

#119

I fondly remember the old Quake 1 days. It was pretty much the last game I played seriously. Reading Carmack .plans were a regular routine and while many of the details went over my head, it made us feel part of the whole id experience. Finally networked Quake was an amazing experience when it came out. I had started my first job in an ASIC design company. All the computers were Solaris based Sun workstations, yet we…

Same story, but not as glamourous, on a Windows NT4 Rollout (1997). Also recall us downloading South Park at a (then) stellar speed - only took half an hour to download a highty compressed half hour episode, a thing of sheer magic at the time :)

Re: John Carmack on QuakeWorld latency and business model (1996)

#120
post #47

Earlier quoted context omitted.

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…

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 <50ms connections. But OPs point that the assumptions underlying Carmack's redesign have once again shifted seems correct, at least for that specific design.

Post reply on HN