Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

John Carmack on QuakeWorld latency and business model (1996)

raw.githubusercontent.com

Post reply on HN
Print view View original

41–50 of 169 posts

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

#41

Post by nugga »

kzahel wrote: post #17

The only thing QW really added over vanilla "netquake" was client side movement prediction. Hitscan weapons (infinite velocity bullets) only let you know if you had hit or missed based on the response from the server. You had to lead your shots a certain amount based on your current latency in order to hit your target. It was great though. It meant you could bunny hop around corners at extremely high speeds without r…

There are some changes in the movement physics which might not be obvious. QW is more forgiving wrt bunnyhopping as you can gain momentum more easily compared to NQ. The speedrunners still use NQ afaik because it is the original single player game.

https://www.quakeworld.nu/forum/topic/2356/qw-physics-vs-nq-...

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

#42

Post by bni »

FooHentai wrote: post #32
SmirkingRevenge wrote: post #19

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…

>we are entering the era of cloud-based streaming game platforms, like Stadia. The latency problems of the pre-CSP 90's will be rearing their heads again. Its going to be interesting to see how these same problems will be tackled My take is that it'll be the a primary competitive point, nearly as important as the library available. Companies that can deliver the service without introducing these issues will succeed a…

There was modem dialup between two players though. Among my circle of friends in 94/95 there was someone who wanted to play DOOM every night. The games was often coordinated during the day at school, or later by phone.

Also I agree that is not a given that "Cloud gaming" will take off. We have emerging VR were latency is absolutely critical, even more so than for FPS e-sports

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

#43

Post by VectorLock »

SmirkingRevenge wrote: post #19

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 was thinking the other day how simple and elegant dotplans were. They were truly the original social media.

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

#44

Post by staunch »

I always preferred regular NetQuake to QuakeWorld and I played a lot of both for many years. The weird jello-jiggly behavior of client-side prediction with 400-600ms difference between players was always horrible.

With NetQuake you could learn to predict everything in your head over time, which is the primary skill competitive players use. No one has a super fast reaction time (even competitive gamers are ~200ms), the best players simply know what's going to happen next better than other players.

I did play thousands of hours of QuakeWorld (Team Fortress mostly) but it was never as fun or competitive feeling as NetQuake.

And once I got an ISDN connection it was even worse to use QuakeWorld because with a perfectly reliable (low jitter) ~50ms ping on NetQuake everything was incredibly smooth. Watching players with 150ms+ ping ("HPBs") warp around the map while you tried to shoot them was no fun.

Today far too many games rely on bad client side prediction. The last game I played seriously was PUBG and they put all of their servers in Ohio. Being on the west coast with 80ms+ ping it was just a terrible experience all the time, but they apparently (and stupidly) assumed it would work well enough due to client side prediction. PUBG could have been so much more fun with ~20ms California servers and a The way to make online competitive games as good as possible is to embrace low latency connections now that most people have them and focus on placing servers in as many cities as possible. The speed of light can't be overcome no matter what we do, so the solution is for people to play with other people that are within ~500 miles.

I hold out hope that eventually netcode authors will realize this fact and finally re-create the incredible long-lost solidity of NetQuake. All they really have to do is stop being so damn clever!

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

#45

Post by devit »

SmirkingRevenge wrote: post #19

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…

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.

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

#46

Post by VectorLock »

FooHentai wrote: post #32
SmirkingRevenge wrote: post #19

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…

>we are entering the era of cloud-based streaming game platforms, like Stadia. The latency problems of the pre-CSP 90's will be rearing their heads again. Its going to be interesting to see how these same problems will be tackled My take is that it'll be the a primary competitive point, nearly as important as the library available. Companies that can deliver the service without introducing these issues will succeed a…

Now and as it was then the game maker controls the viability of its game's ecosystem. Some game companies think its a market advantage to have open hosting, mod ability, and some don't.

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

#47

Post by staunch »

ethbro wrote: post #22
keyle wrote: post #2

Pretty impressive when you consider this was in 1996! I really like his ability to take out code and 'shoot it'. Back to the drawing board. It's a quality of a great engineer, to be able to reflect on what's been done and admit it's not good enough.

> "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 tell them to stop copying his ancient hack two decades later.

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

#48

Post by staunch »

nemo1618 wrote: post #33

What were .plan files like? I've only ever heard of Carmack using them -- did other prominent devs also publish their .plans? I wonder if there'd be any interest in reviving this. I think it would be cool to have something like an RSS feed of the .plan files from various developers I respect/follow. These days you have to settle for reading their Twitter+GitHub issues.

Other technical people used them as well but probably no one more popular than Carmack. I still remember clearly fingering his .plan directly and excitedly reading them. The good ol' days.

https://en.wikipedia.org/wiki/Finger_protocol

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

#49

Post by fastbeef »

Nition wrote: post #15
pvg wrote: post #12

Earlier quoted context omitted.

The Wikipedia page has a link to a thingie that says Duke Nukem 3D had clientside prediction. https://en.wikipedia.org/wiki/Client-side_prediction

I clicked your link and at first kind of brushed it off as dubious since the only linked source is a press article, but the article is an interview with Ken Silverman himself! So that's pretty credible. The source of the released game is available, so it should be possible to check, except that it's a huge mess (check out BUILD.C).[1] Seems weird that no-one has actually verified this when it could be the first game…

TIL Ken Silverman was 18 freaking years old when he started working on Build.
Post reply on HN