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

51–60 of 169 posts

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

#51

Post by keerthiko »

robocat wrote: 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 fulfill the purpose of that quote.

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

#52

Post by jspdown »

timeimp wrote: post #10
Nition wrote: post #3

Someone correct me if I'm wrong, but I believe this was the genesis of client-side prediction for games. If you don't know what that is, Valve has some good documentation on it (relating to Source engine, but it's the same concept).[1] Latency was still a problem even with CSP because we didn't yet have lag compensation on the server. So although you got an authoritative server (no cheating) and instant inputs (no ro…

Any idea why the would not implement lag compo for projectile-based weapons? Too much processing power required?

When you aim someone and click you want to hit what you see. This is a big problem with lag compo, you are in the present but you see other players in the past. In order to avoid this behavior, a common practice is to send what you see, your target, when you shoot.

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

#53

Post by keerthiko »

staunch wrote: post #47
ethbro wrote: post #22

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…

I think gaming netcode engineers would love to ditch CSP, but the problem is even though low-latency connections are mainstream, stable latency connections are not. It's always possible to have lag spikes or temporary slowdowns in your routing or connection.

Second, it's also possible to end up through matchmaking lobbies on a server halfway around the world from one or more of the players in a given match. At some level the limitations of physics still result in noticeable latency and CSP is still mandatory for any fast-paced real-time online multiplayer game.

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

#54

Post by Alupis »

staunch wrote: post #47
ethbro wrote: post #22

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…

Maybe you could elaborate on this?

CSP is still relevant as far as I can tell. Yes, connections in a lot of countries are now on average lower latency, and yes on average CSP might not be required.

However, it's not uncommon to have a couple of high latency connections on a game server (player in another country, roommate is running bit torrent, or just a poor connection). You can't always guarantee low latency, and sometimes connections are interrupted temporarily and packets get lost (assuming UDP).

Short of full sync more often, CSP helps make these unpredictabilities a little more tolerable and transparent for the player.

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

#56

Post by bullen »

Nition wrote: post #3

Someone correct me if I'm wrong, but I believe this was the genesis of client-side prediction for games. If you don't know what that is, Valve has some good documentation on it (relating to Source engine, but it's the same concept).[1] Latency was still a problem even with CSP because we didn't yet have lag compensation on the server. So although you got an authoritative server (no cheating) and instant inputs (no ro…

But why is it called prediction? It's not predicting the future, it's simply simulating the present! Is it because the client is "predicting" where the server thinks the player should be?

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

#57

Post by maccard »

bullen wrote: post #56
Nition wrote: post #3

Someone correct me if I'm wrong, but I believe this was the genesis of client-side prediction for games. If you don't know what that is, Valve has some good documentation on it (relating to Source engine, but it's the same concept).[1] Latency was still a problem even with CSP because we didn't yet have lag compensation on the server. So although you got an authoritative server (no cheating) and instant inputs (no ro…

But why is it called prediction? It's not predicting the future, it's simply simulating the present! Is it because the client is "predicting" where the server thinks the player should be?

> Is it because the client is "predicting" where the server thinks the player should be?

Yep

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

#58

Post by Vogtinator »

devit wrote: post #45
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.

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

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

#59

Post by neiman »

Vogtinator wrote: post #58
devit wrote: 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...

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

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

#60

Post by hulahoof »

SmirkingRevenge wrote: post #23
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…

You say "only", but for those of us who's ping on a good day was between 250-300ms, it was miraculous. It is interesting though, how lag compensation on one particular aspect of the game can make such a big difference, even though the lag is still there in full force in other (just as critical) aspects of the game.

Even to this day playing from Australia it's not uncommon to have a 250-300ms ping on US/EU servers (depending on the game may be the closest English servers).
Post reply on HN