Presumably by HN readers, saved to archive already 7 times today!
https://web.archive.org/web/*/https://raw.githubusercontent....
John Carmack on QuakeWorld latency and business model (1996)
11–20 of 169 posts
Re: John Carmack on QuakeWorld latency and business model (1996)
#12Someone 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…
The Wikipedia page has a link to a thingie that says Duke Nukem 3D had clientside prediction.
Re: John Carmack on QuakeWorld latency and business model (1996)
#13Someone 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?
[deleted]
Re: John Carmack on QuakeWorld latency and business model (1996)
#14Someone 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…
The engine for the first Halflife was a customized and modified version of Id’s engine, so originally they shared not only some principles but also code. “GoldSrc is a game engine developed by Valve Corporation, first showcased in the 1998 first-person shooter game Half-Life. Elements of GoldSrc are based on a heavily modified version of id Software's Quake engine. “ https://en.wikipedia.org/wiki/GoldSrc
[deleted]
Re: John Carmack on QuakeWorld latency and business model (1996)
#15Someone 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…
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 ever doing CSP. The only other sites I can find mentioning it are just quoting your linked Wikipedia page.
Re: John Carmack on QuakeWorld latency and business model (1996)
#16What a great summation of the internet in the 90's: "Client. User's modem. ISP's modem. Server. ISP's modem. User's modem. Client. God, that sucks."
Then followed by Carmack's 90's internet experience: "Ok, I made a bad call. I have a T1 to my house, so I just wasn't familliar with PPP life. I'm adressing it now."
:p
Re: John Carmack on QuakeWorld latency and business model (1996)
#17The 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 running into walls.
Re: John Carmack on QuakeWorld latency and business model (1996)
#18Someone 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?
Projectiles are simulated on the server
Re: John Carmack on QuakeWorld latency and business model (1996)
#19Carmack'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-300ms before the game responds and moves your character forward. CSP really was an amazing break through, and made multiplayer action games feasible on the internet.
This is particularly relevant now, that 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 in this new context. Internet speeds are higher now, but so are our expectations.
I doubt we'll have the nice, simple dotplan files that Carkmack left for us to read and remember, from all the SRE's at Google, sadly.
Re: John Carmack on QuakeWorld latency and business model (1996)
#20Earlier quoted context omitted.
Any idea why the would not implement lag compo for projectile-based weapons? Too much processing power required?
Projectiles are simulated on the server
All weapons are simulated on both the server and the client in the case we're talking about here. It's just that raycast weapons are rewound on the server to compensate for the client's latency, and projectiles aren't. The server has the authority on actual hits and damage done for all weapons.