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

141–150 of 169 posts

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

#141

Post by reifiedgent »

pedrocr wrote: post #136
boomlinde wrote: post #133

Earlier quoted context omitted.

> By your numbers then the OP is right. By my numbers (though as you can clearly see from the link I posted, >200ms latencies are not uncommon), and Carmack's assumptions in 1996 about what latencies would be acceptable. > 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. He designed for which by the frame of reference he cites (T1 connection…

>200ms latencies are not uncommon Those numbers match my experience a long time ago with Quake3 based games where you'd pick servers that are local to you and get 10-40ms latencies. > He designed for I didn't forget the > It seems more likely to me that perception on what an acceptable hand to eye latency is has changed, just like the perception on acceptable frame rates. Right, makes sense that the expectation today…

NQ (NetQuake, as the original Quake is sometimes known) 'feels off' on just 10ms. Movement becomes slightly just out of sync with your input.

10-30ms is a bit optimistic, depending on how large you define a geography. Many ADSL/VDSL connections, best case, start with 5ms of latency, and often higher (say 20ms) due to interleaving. Cable tends to be around 10ms IIRC but can suffer from significant jitter which makes things worse. So for a lot of players the servers would need to be in the same city to achieve that target.

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

#142

Post by debaserab2 »

nickjj wrote: post #88
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…

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…

Actually, there's nothing sad about the state of code editors in the world today. I'm not sure what code editors you're regularly using that is giving you that kind of latency, but there's plenty -- more than ever before, in fact, that definitely don't have this problem (some of which are even electron based!).

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

#143

Post by apezdedookie »

Insanity wrote: post #76

It seems like almost every time something about Carmack is posted, people point to the book "Masters of Doom", about the development of id games (Wolf3d, doom, commander keen). It's pretty interesting read imo: https://www.goodreads.com/book/show/222146.Masters_of_Doom

I recently read the book and it blows my mind how Carmack was able to program so relentlessly. Always moving on to the next thing and doing the impossible. He's definitely on a whole other level.

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

#144

Post by Profan »

ethbro wrote: post #21
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…

I have no idea how I remember this, but there's a write-up about the Age of Empires netcode (written ~96, released end-of-97): https://www.gamasutra.com/view/feature/131503/1500_archers_o... Because of the unique challenges, they did a lot of synchronized client-side simulation (based on minimal state transfer over the net). ... and apparently encountered a lot of the issues with doing that (no random anything!!!).

This isn't the same as client side prediction though, the entire game simulation in the aoe case practically runs on every client, where the only input to the simulation are commands that are passed between all players and executed in lockstep, where the simulation essentially stops if for a given turn no command for that turn has been received.

Gives you really low bandwidth reqs (and randomness is still possible assuming you just seed things the same on all machines).

But also means you might have to wait 50-200ms (or some arbitrary sliding window depending on network conditions) until your click actually registers ingame as a move as commands are scheduled to be processed far enough in the future (some number of command turns in the future) that you at that point would have received every other players commands for that given turn and thus be able to execute all commands for all players locally for that turn, which is not ideal if you're playing a twitchy shooter, but alright if it's an RTS.

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

#145

Post by DanHulton »

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.

I am now imagining a (probably short) story in which the AI does learn to predict players perfectly, even the creative ones, and ends with a gamer taking his hands off the controller and allowing the AI to play exactly as he would have and wondering what was ever the point.

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

#146

Post by staunch »

Alupis wrote: post #54
staunch wrote: 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…

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…

Sure, this is why you have a < 60ms ping restriction or whatver. You simply don't let players play on a server with high latency because then it's a bad experience for everyone else. This is how competitive Quake Live servers worked.

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

#147

Post by staunch »

boomlinde wrote: post #61
staunch wrote: 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…

I get 8ms RTT to servers in my city on a normal cable modem today. People in major cities have nearly LAN-quality latency within ~500 miles.

Packet loss is extremely low, which is easy to tell using a builtin netgraph.

Screen buffering should be reduced as much as possible and vsync is not something competitive players would ever want. Pros all disabled it in Quake Live for sure.

Players on modern connections that are playing on servers in their city do not need CSP.

In practice it's not that bad to have CSP if it's not really doing much (due to all players being low latency) but I know from playing NetQuake vs Quake Live with low latency that it's nicer not to have it at all.

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

#148

Post by staunch »

instantwhat wrote: post #140
staunch wrote: 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…

Go listen to actual competitive FPS players, and hear them complain about having 60 ms latency. Listen to them complain about living on one U.S. coast and playing on servers on the opposite one and having 80-100 ms latency. Listen to players in EU who play on NA servers because they don't like players' behavior on EU servers, and they're willing to suffer 150 ms latency. Then visit Australia and listen to players who…

This is why you ping restrict servers. There's no way to make a game competitive when one player has 10ms ping and another has 100ms (10x higher!) ping. It's just bad for everyone.

Which is exactly what competitive Quake Live players do and I suspect CS players probably do. Every player has 15-40ms ping and it's amazing.

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

#149

Post by nine_k »

Gene_Parmesan wrote: post #127
jasonrhaas wrote: post #123

Earlier quoted context omitted.

Typing delay is a pet peeve of mine. This is why I have stuck with Sublime and Vim even though there are more powerful editors out there like VsCode or PyCharm. If you want a fast editor, switch to Sublime 3.

I find VS Code to be just about the only electron-based editor I can use without getting frustrated with typing latency. It's usually not noticeable unless the process is chugging for unrelated reasons.

VS Code is Electron-based, but not Atom-based, thankfully.

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

#150

Post by staunch »

keerthiko wrote: post #53
staunch wrote: 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…

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 l…

Within a US city or state it's very rare to have much packet loss at all. It's very easy to spot using the builtin netgraph in Quake Live and other games.

Players that are separated by thousands of miles should not be playing competitive FPS games together. It's physically impossible to make it a consistently good experience.

Post reply on HN