John Carmack on QuakeWorld latency and business model (1996) • Hacker News Board

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

#61

Post by boomlinde » Wed, May 15, 2019, 8:02 AM UTC

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…

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 even the latency introduced by screen buffering and vertical sync may make or break yor game, and in reality the latency is of course much higher, usually around 100ms or higher. Check your assumptions: https://wondernetwork.com/pings

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

#62

Post by fsiefken » Wed, May 15, 2019, 8:14 AM UTC

neiman wrote: post #59

Vogtinator wrote: post #58

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.

Perhaps if you train the model on the existing movement and action history of the particular player

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

#63

Post by taneq » Wed, May 15, 2019, 8:18 AM UTC

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…

Latency is better than it was so prediction times are shorter, but there's still latency so prediction is still important.

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

#64

Post by Nition » Wed, May 15, 2019, 8:25 AM UTC

fastbeef wrote: post #49

Nition wrote: post #15

Earlier quoted context omitted.

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.

I feel a bit mean to all involved in linking this but at the same time it's an extremely interesting piece of history; check out GEORGE.TXT, found in a leaked alpha version of Blood (another Build engine game): https://tcrf.net/Proto:Blood/Alpha_Demo#GEORGE.TXT

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

#65

Post by teddyh » Wed, May 15, 2019, 8:32 AM UTC

soulofmischief wrote: post #25

delhanty wrote: post #11

Presumably by HN readers, saved to archive already 7 times today! https://web.archive.org/web/*/https://raw.githubusercontent....

Is there a good browser extension for archiving pages in one click? Firefox.

There was Scrapbook, now replaced by ScrapbookQ.

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

#66

Post by sshine » Wed, May 15, 2019, 8:40 AM UTC

> I would like to see internet focused gaming become a justifiable biz direction for us.

> Its definately cool, but it is uncertain if people can actually make money at it.

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

#67

Post by uasm » Wed, May 15, 2019, 8:45 AM UTC

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…

> "We're not on PPP or SLIP connections anymore and yet game devs are still writing netcode as though we are."

Your average multiplayer today is significantly more complex than Quake. More data needs to pass through, at higher rates. The network is still very much a bottleneck.

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

#68

Post by theK » Wed, May 15, 2019, 8:52 AM UTC

neiman wrote: post #59

Vogtinator wrote: post #58

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.

No offense but I think you underestimate the predictive potential of millions of hours of game state

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

#69

Post by Slartie » Wed, May 15, 2019, 9:11 AM UTC

fsiefken wrote: post #62

neiman wrote: post #59

Earlier quoted context omitted.

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

Perhaps if you train the model on the existing movement and action history of the particular player

Oh, that's a great idea!

Stadia could sell it as an add-on to players which not only don't want to play their games themselves, but also aren't satisfied by watching other people play through their games on YouTube or Twitch. With this add-on, they can finally watch themselves play through their games, without having to lift a finger to, you know, actually play!

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

#70

Post by Nition » Wed, May 15, 2019, 9:12 AM UTC

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?

Basically yeah.

The server has the authority on where you are, to prevent you cheating by sending it bogus positions. You send inputs (not your position) and the server gives you your new position back.

Problem is of course it takes time for the inputs to go to the server, and for your new position to come back. So in a naive implementation you press to move forward, and don't actually move for a while while you wait for a return signal.

So instead, say it's tick 100 on the client and you get a position from the server marked as tick 90. Instead of moving the player to the tick 90 position, which is in the past for you, you take that and "predict" ahead (a.k.a. run the simulation) 10 more ticks to get to tick 100. Including re-running any new inputs you did during those ticks.

There are situations where the client may predict differently to what the server actually does - maybe you bumped into another player and due to latency they were in a different place for you than for the server. In that case you'll either get suddenly teleported to a different place as the server data keeps coming through, or if you're lucky the game will kind of smoothly correct you over a few frames.