14 ms·

John Carmack on QuakeWorld latency and business model (1996)

395 points by undefined1 7y ago

keyle 7y ago
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.
- ethbro 7y ago
  > "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.'
  - staunch 7y ago
    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.
    - Alupis 7y ago
      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.
      - staunch 7y ago
        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.
        Alupis 7y ago
        That's not really a great solution, particularly for less popular games where there may not be many local servers, or servers that are not full, or servers that have at least some other players.
    - keerthiko 7y ago
      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.
      - staunch 7y ago
        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.
    - boomlinde 7y ago
      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 https://wondernetwork.com/pings
      - pedrocr 7y ago
        By your numbers then the OP is right. Carmack says: the bottom line is that I was working with the wrong basic assumptions for doing a good internet game. My original design was targeted at <200ms connection latencies. People that have a digital connection to the internet through a good provider get a pretty good game experience. Unfortunately, 99% of the world gets on with a slip or ppp connection over a modem, often through a crappy overcrowded ISP. This gives 300+ ms latencies, minimum. 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. Maybe games have gotten more complex or our expectations higher so prediction is still worth it even on <50ms connections. But OPs point that the assumptions underlying Carmack's redesign have once again shifted seems correct, at least for that specific design.
        boomlinde 7y ago
        > 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 <200ms which by the frame of reference he cites (T1 connection) probably was a lot lower than 200ms on average. > Maybe games have gotten more complex or our expectations higher so prediction is still worth it even on <50ms connections. Quake was not a very complex world, but more important (to latency) is that it's a fast paced game by today's standards (IME). 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. To me, joining an online shooter with >100ms latency (even with prevalent client side prediction) feels debilitating, especially if other players have lower latencies. > But OPs point that the assumptions underlying Carmack's redesign have once again shifted seems correct, at least for that specific design. Yes, I agree that PPP and SLIP are not common any more. High latency unfortunately is, and client side prediction is still an effective mitigation strategy that makes a huge difference to online play. The specific design used in Quake has of course been superseded.
    - taneq 7y ago
      Latency is better than it was so prediction times are shorter, but there's still latency so prediction is still important.
    - uasm 7y ago
      > "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.
      - staunch 7y ago
        Fair point but bandwidth has also increased from 56 kbit/s 100,000 kbit/s. CPUs have had similarly massive increases in speed as well. A lot of the extra bandwidth usage is also probably in large part due to sloppiness. John Carmack did some impressively smart things in Quake Live to reduce bandwidth usage. I doubt most modern games like PUBG are anywhere near as optimized.
    - instantwhat 7y ago
      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 suffer 300 ms latency to play with people who aren't in the relatively small Australian population for whatever game they're playing. Then take out CSP from their games and watch what happens. CSP will always be necessary for any Internet-based game. Only LANs have low enough latency to not need it.
      - staunch 7y ago
        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.
        keerthiko 7y ago
        I don't get it, many people want to play a game and there just aren't enough players in their city, games want as many players as possible to be playing them. Your requirement that games ping-restrict servers is an absolute non starter: unless the game is already guaranteed to have hundreds of players active and available near any given player at any given time of day, and evenly distributed redundant always-up servers that scale for demand near every player cluster across the planet. I think CSP is a far more realistic solution to giving a good player experience than magicking player base activity and distribution
        staunch 7y ago
        For major games like PUBG and Fortnite this shouldn't be a problem at all. It might mean that it takes 60 seconds of matchmaking to join a new game instead of 6 seconds. What you get in exchange is a stable and predictable competitive game. I, and many others, experienced endless frustration in PUBG due to players warping around corners and shots that were clear hits missing due to CSP. And I'm not one to complain about this kind of thing unnecessarily. It really sucked. The PUBG people didn't even geolock their servers at all last time I played, so you could be playing with people with 300ms+ ping which is just miserable. For less successful games maybe you have to increase the maximum ping from 40-60ms to 80-100ms or something but it should be kept as low as possible. The more players per city, the lower you can make the maximum ping. I realize that this might make it more difficult for people in Australia (or whereever) to find a game but it seems even more wrong to make the experience bad for everyone all the time. And at least when they do find a game it will be a great experience instead of terrible.
- Crinus 7y ago
  It helps that he was his own manager and didn't had anyone else to convince that this was a good idea :-P
Nition 7y ago
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 round-trip wait), you could still shoot someone on the client and miss them on the server. You had to shoot ahead of them, further if your latency was worse. As far as I know, Source engine was the first to add lag compensation, which has the server rewind the other players to be where you would have seen them on the client. Since client-side prediction can be performance intensive, and lag compensation can be difficult for anything beyond simple raycast checks, many games still don't do both. Team Fortress 2 for instance does lag compensation on basic guns but not on things like the soldier's rocket or the pyro's flamethrower. Some games simply allow the client to decide who they hit, which removes the need for either solution, but totally opens things up to cheaters without some very careful server-side validation. [1] https://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization#Client_Side_Prediction https://developer.valvesoftware.com/wiki/Latency_Compensatin...
- keyle 7y ago
  Yeah probably. JC created a lot of standards for the ones to follow. And I remember reading the valve stuff the first time, it blew my mind.
  - Nition 7y ago
    The Valve docs there are very well written. It was the first time I really understood all the concepts too. Overview of Source engine networking: https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking https://developer.valvesoftware.com/wiki/Source_Multiplayer_... Ways they combat latency: https://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization https://developer.valvesoftware.com/wiki/Latency_Compensatin... Lag compensation (server): https://developer.valvesoftware.com/wiki/Lag_compensation https://developer.valvesoftware.com/wiki/Lag_compensation Prediction (client): https://developer.valvesoftware.com/wiki/Prediction https://developer.valvesoftware.com/wiki/Prediction
ashika 7y ago
>There are all sorts of other cool stats that we could mine out of the data: greatest frags/minute, longest uninterrupted quake game, cruelest to newbies, etc, etc. I agree with his use of a double etc there.
chr1xzy 7y ago
pushlatency -120
robocat 7y ago
Complete aside about Carmack and reducing VR latency from https://www.gamasutra.com/view/news/226112/How_John_Carmack_is_bending_Samsungs_VR_strategy.php 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 out. Though he'd written several emails to Samsung in attempts to convince them to give back that buffer, "It's easy to argue against an email, but it's much harder to make the argument when you can have the two things and stick them on your face and, 'Tell me this isn't better.'"
- sisu2019 7y ago
  Games usually let you control if and which buffering to use so for an OS to be stuborn about it and waste Carmacks time over a simple toggle is pretty maddening
- keerthiko 7y ago
  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.
  - AdmiralAsshat 7y ago
    Carmack's brain is so much like a computer that it even does speculative execution branch prediction!
- def_true_false 7y ago
  Is android doing triple buffering wrong? Where does the extra 16ms delay come from?
delhanty 7y ago
Presumably by HN readers, saved to archive already 7 times today! https://web.archive.org/web/*/https://raw.githubusercontent.com/ESWAT/john-carmack-plan-archive/master/by_day/johnc_plan_19960802.txt https://web.archive.org/web/*/https://raw.githubusercontent....
- soulofmischief 7y ago
  Is there a good browser extension for archiving pages in one click? Firefox.
  - teddyh 7y ago
    There was Scrapbook, now replaced by ScrapbookQ.
  - Crinus 7y ago
    I do not know about submitting to archive.org, but i use Save Page WE for Firefox to make full local copies of sites (it essentially takes the current DOM state and inlines all external files/dependencies to a single HTML file and then prompts you to save that file which can be opened later): https://addons.mozilla.org/en-US/firefox/addon/save-page-we/ https://addons.mozilla.org/en-US/firefox/addon/save-page-we/
    - soulofmischief 7y ago
      Thanks for the suggestion. You might be interested in Zotero [0] for a more general solution. It supports saving to HTML, saving to PDF, etc. and allows you to organize everything with tags. [0] https://www.zotero.org/ https://www.zotero.org/
  - ungzd 7y ago
    There's https://warcreate.com/ https://warcreate.com/, but it's for Chrome. I don't know details of it, but aren't both browsers use the same API for extensions? Then probably it's possible to port it, or to install right away. It creates .warc files, which are supported by Internet Archive. I don't know if it integrates uploaded .warc files to Wayback Machine, but Archive Team uses this format to upload manually archived sites to Internet Archive.
SmirkingRevenge 7y ago
What 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
kzahel 7y ago
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 running into walls.
- SmirkingRevenge 7y ago
  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.
  - hulahoof 7y ago
    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).
- KuhlMensch 7y ago
  Hm, I think the engineering story is the interesting aspect: What an elegant client-as-terminal I have for this incredibly popular physics simulation! Oh no! it takes up too much bandwidth. Welp - time to throw out the old lock-step game-loop architecture, and allow each client to stream incremental updates I'm sure many contemporary engineers had similar problems, and considered the same approach, but either shrank-from or gave-up on rustling together an elegant solution. Like many problems in the early days of 3d/internet gaming, Carmack seems to have rapidly and nicely solved it with imagination & experimentation, all informed by a broad and deep understanding of data structures, & algorithms, and presumably an industry-leading amount of experience.
- nugga 7y ago
  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-physics-everything-you-ever-wanted-to-know https://www.quakeworld.nu/forum/topic/2356/qw-physics-vs-nq-...
SmirkingRevenge 7y ago
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-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.
- FooHentai 7y ago
  >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 and ones that cannot will fail. If nobody can reliably crack it, cloud gaming won't take off. Back in the 90s there was no viable competitor aside from LAN parties, and those weren't available to you every evening.
  - bni 7y ago
    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
    - 7y ago
ttul 7y ago
“I have a T1 to my house...”
- usefulcat 7y ago
  In 1996, one would have been lucky to be able to have ISDN, so having a T1 was more like 'money is no object' territory.
  - jib 7y ago
    Or you were in university/connected to a university. The Swedish qwctf scene at least was very clearly divided in 20ms people who went to or worked at, a university, and 150ms people who played from home. There were some 50-60ms ISDN people too but I can only remember a few.
  - jandrese 7y ago
    In the late 90s a T1 cost about US$1,500/month. It came with a bunch of service guarantees and the like because it was aimed squarely at businesses. A T1 is only 1.5mbps too, fast for the time but in absolute terms not that great. The only other options were 56k modem (48kbps on a good day) and frame relay or ISDN, which was a solid 64kbps and lower latency than a modem but also far more expensive than it should have been (US$200-300/month).
    - dspillett 7y ago
      ISDN ("It Still Does Nothing" to give its facetious full name from the time) lines were often bonded, usually to give 128kpbs though faster configurations were possible, though of course there was an increased cost for this.
  - matwood 7y ago
    The office of one of my early programming jobs had an ISDN line. I would carry my home desktop into the office to download things/play games. The next job I had was in a much bigger company, and the office I was in had equivalent of 70+ T1s. Most of those were to support the phone system though.
speedplane 7y ago
Why is this article hosted on github? Obviously it wasn't created there as it was written in 1996. Are all the message boards and forums where this type of material was likely posted really defunct or unusable now? Do we now need to rely on enterprising internet historians to find gems on older platforms just to copy them to the newer platforms? Will Github be around in 20 years? Will the next historian have to unearth it from github just to copy it to the next platform?
- CaliforniaKarl 7y ago
  > Are all the message boards and forums where this type of material was likely posted really defunct or unusable now? The original source of this material (and the other articles) was John Carmack's .plan file. See https://en.wikipedia.org/wiki/Finger_protocol https://en.wikipedia.org/wiki/Finger_protocol The .plan file is by its nature ephemeral, as the user can change it whenever. But the content was archived. The GitHub is just the latest mirror. > Will the next historian have to unearth it from github just to copy it to the next platform? Maybe!
- eswat 7y ago
  Hey, repo owner here. That does seem to be the case here. I had re-hosted these .plan files from a website – which has removed them – that had re-hosted them from Shacknews – which had also removed them. GitHub seemed like a quirk-and-dirty way to re-host these while giving others an easy way of duplicating the original files so they’re less likely to be lost in the ether.
- thrower123 7y ago
  Why not? While this is a bit of an exception, given the prominence of the author, most internet content is always at risk of being wiped away from the record. Let a thousand mirrors bloom.
diarmuidc 7y ago
I fondly remember the old Quake 1 days. It was pretty much the last game I played seriously. Reading Carmack .plans were a regular routine and while many of the details went over my head, it made us feel part of the whole id experience. Finally networked Quake was an amazing experience when it came out. I had started my first job in an ASIC design company. All the computers were Solaris based Sun workstations, yet we were able to get network quake up and running on them! I just can't imagine such a thing happening today but maybe that's more to do with me being 20 years older than anything else. For sure no one is porting game engines to Solaris these days ;)
- newaccoutnas 7y ago
  Same story, but not as glamourous, on a Windows NT4 Rollout (1997). Also recall us downloading South Park at a (then) stellar speed - only took half an hour to download a highty compressed half hour episode, a thing of sheer magic at the time :)
nemo1618 7y ago
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.
- DrOctagon 7y ago
  I've been keeping personal .plan files since the last time I saw them mentioned on HN. So only a couple of weeks at this stage. In some ways they reflect the way I've gone about a days work more clearly than other project management/bug tracking software I'm required to use.
- vinkelhake 7y ago
  I think Carmack popularized their use at the time. A bunch of news sites started tracking them. Blue's News still has an archive from back then: https://www.bluesnews.com/cgi-bin/summary.pl https://www.bluesnews.com/cgi-bin/summary.pl Click on a company, a person and then use the drop down to view older entries.
- staunch 7y ago
  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 https://en.wikipedia.org/wiki/Finger_protocol
- bitwize 7y ago
  Well, Twitter, Facebook, etc. are the modern replacements for the "status updates" you used to put in your .plan file. .plan was just a simple text file you left in your home directory; it would be displayed to any user who attempted to query you with the 'finger' command. These days the 'finger' protocol is not really used anymore due to security vulnerabilities. But back then, Unix really was a social-moedia OS, and the internet was a decentralized, federated social network. (There were actually two such files; .project was used to give a high-level summary of what you were working on, while .plan was used to talk in detail about what you were currently doing at the moment.)
staunch 7y ago
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 < 60ms ping restriction, which is how most Quake Live servers operated when I used to play that game. 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!
jspdown 7y ago
It seems to be the premises of client-side prediction. I submitted a link on HN yesterday that may interest some of you guys: https://news.ycombinator.com/item?id=19908875 https://news.ycombinator.com/item?id=19908875
hellofunk 7y ago
I see everyone in this thread reference CSP [0] and I keep thinking they’re all talking about the foundations of core.async or Golang. [0] https://www.reaktor.com/blog/why-csp-matters-i-keeping-things-in-sync/ https://www.reaktor.com/blog/why-csp-matters-i-keeping-thing...
sshine 7y ago
> 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.
tranlinhlan 7y ago
https://beautyfriend.vn/products/toner-cap-nuoc-accoje-hydrating-aqua https://beautyfriend.vn/products/toner-cap-nuoc-accoje-hydra...
Insanity 7y ago
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 https://www.goodreads.com/book/show/222146.Masters_of_Doom
- apezdedookie 7y ago
  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.
tarruda 7y ago
Good times. If I remember correctly, it was possible to drop everyone from a quake server (especially team fortress, when your team was about to lose) by spamming chat messages in the console
k__ 7y ago
Is he happy with his Oculus job after the FB deal or will he leave after the Quest comes out?
- bob1029 7y ago
  I always wondered about how he felt about that role. I feel like Carmack could still run one of the best software shops on earth, even if he had to start from scratch. The man invented the concept of "it will be ready when it's done", and has an incredibly positive attitude towards handling difficult (challenging) problems. If the stars aligned and Carmack decided to get back into making new software-based gaming experiences (especially around the DTX/ATX area), I would be incredibly tempted to investigate opportunities.
system2 7y ago
It is interesting to see so many grammar and spelling errors in this short article. Almost sounds like he didn't write this himself.
eswat 7y ago
Link to the origin repo if you’d like to read the entire .plan archive: https://github.com/ESWAT/john-carmack-plan-archive https://github.com/ESWAT/john-carmack-plan-archive
pault 7y ago
> If it looks feasable, 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. Classic! Reminds me of the time I told my dad I wanted to make websites for a living and he replied "hey, that's pretty cool, but I don't think there's enough work available to make it a full time career". (This was circa 1996)
ungzd 7y ago
Maybe FRP (functional reactive programming) can give more abilities to reason when designing networked shooters and internal simulation in games. Just like React had revolutionized GUIs (it's not FRP library, but has ideas from it). With FRP, it's even possible to build "tickless" game logic. However, for now it has limited practicability and I never seen something complete that was built with FRP.
shayolden 7y ago
I a developer on FortressOne - a still actively developed continuation of the original QuakeWorld Team Fortress. We have an extremely active community with games taking place nightly. It's a testament to Carmack that his code from 1996 is still widely used in 2019. https://www.fortressone.org https://www.fortressone.org
womd 7y ago
play'd all the doom/quake... was a pleasure reading this...
arendtio 7y ago
> In a clean sheet of paper redesign, I would try to correct more of the discrepencies Sounds like that is what he did with Quake 3 (don't know about Quake 2). At least in Quake 3, the whole game logic is running in a so-called 'Quake Virtual Machine' file (.qvm) that is exactly the same on server and client (even cross-platform compatible). That way he doesn't just predict the client movements but the whole game world.
john4534243 7y ago
Was the dot plan written to himself or for his teammates ?

395 points by undefined1 7y ago

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.

ethbro 7y ago
> "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.'
- staunch 7y ago
  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.
  - Alupis 7y ago
    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.
    - staunch 7y ago
      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.
      - Alupis 7y ago
        That's not really a great solution, particularly for less popular games where there may not be many local servers, or servers that are not full, or servers that have at least some other players.
  - keerthiko 7y ago
    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.
    - staunch 7y ago
      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.
  - boomlinde 7y ago
    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 https://wondernetwork.com/pings
    - pedrocr 7y ago
      By your numbers then the OP is right. Carmack says: the bottom line is that I was working with the wrong basic assumptions for doing a good internet game. My original design was targeted at <200ms connection latencies. People that have a digital connection to the internet through a good provider get a pretty good game experience. Unfortunately, 99% of the world gets on with a slip or ppp connection over a modem, often through a crappy overcrowded ISP. This gives 300+ ms latencies, minimum. 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. Maybe games have gotten more complex or our expectations higher so prediction is still worth it even on <50ms connections. But OPs point that the assumptions underlying Carmack's redesign have once again shifted seems correct, at least for that specific design.
      - boomlinde 7y ago
        > 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 <200ms which by the frame of reference he cites (T1 connection) probably was a lot lower than 200ms on average. > Maybe games have gotten more complex or our expectations higher so prediction is still worth it even on <50ms connections. Quake was not a very complex world, but more important (to latency) is that it's a fast paced game by today's standards (IME). 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. To me, joining an online shooter with >100ms latency (even with prevalent client side prediction) feels debilitating, especially if other players have lower latencies. > But OPs point that the assumptions underlying Carmack's redesign have once again shifted seems correct, at least for that specific design. Yes, I agree that PPP and SLIP are not common any more. High latency unfortunately is, and client side prediction is still an effective mitigation strategy that makes a huge difference to online play. The specific design used in Quake has of course been superseded.
  - taneq 7y ago
    Latency is better than it was so prediction times are shorter, but there's still latency so prediction is still important.
  - uasm 7y ago
    > "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.
    - staunch 7y ago
      Fair point but bandwidth has also increased from 56 kbit/s 100,000 kbit/s. CPUs have had similarly massive increases in speed as well. A lot of the extra bandwidth usage is also probably in large part due to sloppiness. John Carmack did some impressively smart things in Quake Live to reduce bandwidth usage. I doubt most modern games like PUBG are anywhere near as optimized.
  - instantwhat 7y ago
    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 suffer 300 ms latency to play with people who aren't in the relatively small Australian population for whatever game they're playing. Then take out CSP from their games and watch what happens. CSP will always be necessary for any Internet-based game. Only LANs have low enough latency to not need it.
    - staunch 7y ago
      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.
      - keerthiko 7y ago
        I don't get it, many people want to play a game and there just aren't enough players in their city, games want as many players as possible to be playing them. Your requirement that games ping-restrict servers is an absolute non starter: unless the game is already guaranteed to have hundreds of players active and available near any given player at any given time of day, and evenly distributed redundant always-up servers that scale for demand near every player cluster across the planet. I think CSP is a far more realistic solution to giving a good player experience than magicking player base activity and distribution
        staunch 7y ago
        For major games like PUBG and Fortnite this shouldn't be a problem at all. It might mean that it takes 60 seconds of matchmaking to join a new game instead of 6 seconds. What you get in exchange is a stable and predictable competitive game. I, and many others, experienced endless frustration in PUBG due to players warping around corners and shots that were clear hits missing due to CSP. And I'm not one to complain about this kind of thing unnecessarily. It really sucked. The PUBG people didn't even geolock their servers at all last time I played, so you could be playing with people with 300ms+ ping which is just miserable. For less successful games maybe you have to increase the maximum ping from 40-60ms to 80-100ms or something but it should be kept as low as possible. The more players per city, the lower you can make the maximum ping. I realize that this might make it more difficult for people in Australia (or whereever) to find a game but it seems even more wrong to make the experience bad for everyone all the time. And at least when they do find a game it will be a great experience instead of terrible.
Crinus 7y ago
It helps that he was his own manager and didn't had anyone else to convince that this was a good idea :-P

Nition 7y ago

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 round-trip wait), you could still shoot someone on the client and miss them on the server. You had to shoot ahead of them, further if your latency was worse. As far as I know, Source engine was the first to add lag compensation, which has the server rewind the other players to be where you would have seen them on the client. Since client-side prediction can be performance intensive, and lag compensation can be difficult for anything beyond simple raycast checks, many games still don't do both. Team Fortress 2 for instance does lag compensation on basic guns but not on things like the soldier's rocket or the pyro's flamethrower. Some games simply allow the client to decide who they hit, which removes the need for either solution, but totally opens things up to cheaters without some very careful server-side validation. [1] https://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization#Client_Side_Prediction https://developer.valvesoftware.com/wiki/Latency_Compensatin...

keyle 7y ago
Yeah probably. JC created a lot of standards for the ones to follow. And I remember reading the valve stuff the first time, it blew my mind.
- Nition 7y ago
  The Valve docs there are very well written. It was the first time I really understood all the concepts too. Overview of Source engine networking: https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking https://developer.valvesoftware.com/wiki/Source_Multiplayer_... Ways they combat latency: https://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization https://developer.valvesoftware.com/wiki/Latency_Compensatin... Lag compensation (server): https://developer.valvesoftware.com/wiki/Lag_compensation https://developer.valvesoftware.com/wiki/Lag_compensation Prediction (client): https://developer.valvesoftware.com/wiki/Prediction https://developer.valvesoftware.com/wiki/Prediction

ashika 7y ago

>There are all sorts of other cool stats that we could mine out of the data: greatest frags/minute, longest uninterrupted quake game, cruelest to newbies, etc, etc. I agree with his use of a double etc there.

chr1xzy 7y ago

pushlatency -120

robocat 7y ago

Complete aside about Carmack and reducing VR latency from https://www.gamasutra.com/view/news/226112/How_John_Carmack_is_bending_Samsungs_VR_strategy.php 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 out. Though he'd written several emails to Samsung in attempts to convince them to give back that buffer, "It's easy to argue against an email, but it's much harder to make the argument when you can have the two things and stick them on your face and, 'Tell me this isn't better.'"

sisu2019 7y ago
Games usually let you control if and which buffering to use so for an OS to be stuborn about it and waste Carmacks time over a simple toggle is pretty maddening
keerthiko 7y ago
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.
- AdmiralAsshat 7y ago
  Carmack's brain is so much like a computer that it even does speculative execution branch prediction!
def_true_false 7y ago
Is android doing triple buffering wrong? Where does the extra 16ms delay come from?

delhanty 7y ago

Presumably by HN readers, saved to archive already 7 times today! https://web.archive.org/web/*/https://raw.githubusercontent.com/ESWAT/john-carmack-plan-archive/master/by_day/johnc_plan_19960802.txt https://web.archive.org/web/*/https://raw.githubusercontent....

soulofmischief 7y ago
Is there a good browser extension for archiving pages in one click? Firefox.
- teddyh 7y ago
  There was Scrapbook, now replaced by ScrapbookQ.
- Crinus 7y ago
  I do not know about submitting to archive.org, but i use Save Page WE for Firefox to make full local copies of sites (it essentially takes the current DOM state and inlines all external files/dependencies to a single HTML file and then prompts you to save that file which can be opened later): https://addons.mozilla.org/en-US/firefox/addon/save-page-we/ https://addons.mozilla.org/en-US/firefox/addon/save-page-we/
  - soulofmischief 7y ago
    Thanks for the suggestion. You might be interested in Zotero [0] for a more general solution. It supports saving to HTML, saving to PDF, etc. and allows you to organize everything with tags. [0] https://www.zotero.org/ https://www.zotero.org/
- ungzd 7y ago
  There's https://warcreate.com/ https://warcreate.com/, but it's for Chrome. I don't know details of it, but aren't both browsers use the same API for extensions? Then probably it's possible to port it, or to install right away. It creates .warc files, which are supported by Internet Archive. I don't know if it integrates uploaded .warc files to Wayback Machine, but Archive Team uses this format to upload manually archived sites to Internet Archive.

SmirkingRevenge 7y ago

What 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

kzahel 7y ago

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 running into walls.

SmirkingRevenge 7y ago
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.
- hulahoof 7y ago
  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).
KuhlMensch 7y ago
Hm, I think the engineering story is the interesting aspect: What an elegant client-as-terminal I have for this incredibly popular physics simulation! Oh no! it takes up too much bandwidth. Welp - time to throw out the old lock-step game-loop architecture, and allow each client to stream incremental updates I'm sure many contemporary engineers had similar problems, and considered the same approach, but either shrank-from or gave-up on rustling together an elegant solution. Like many problems in the early days of 3d/internet gaming, Carmack seems to have rapidly and nicely solved it with imagination & experimentation, all informed by a broad and deep understanding of data structures, & algorithms, and presumably an industry-leading amount of experience.
nugga 7y ago
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-physics-everything-you-ever-wanted-to-know https://www.quakeworld.nu/forum/topic/2356/qw-physics-vs-nq-...

SmirkingRevenge 7y ago

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

FooHentai 7y ago
>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 and ones that cannot will fail. If nobody can reliably crack it, cloud gaming won't take off. Back in the 90s there was no viable competitor aside from LAN parties, and those weren't available to you every evening.
- bni 7y ago
  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
  - 7y ago

ttul 7y ago

“I have a T1 to my house...”

usefulcat 7y ago
In 1996, one would have been lucky to be able to have ISDN, so having a T1 was more like 'money is no object' territory.
- jib 7y ago
  Or you were in university/connected to a university. The Swedish qwctf scene at least was very clearly divided in 20ms people who went to or worked at, a university, and 150ms people who played from home. There were some 50-60ms ISDN people too but I can only remember a few.
- jandrese 7y ago
  In the late 90s a T1 cost about US$1,500/month. It came with a bunch of service guarantees and the like because it was aimed squarely at businesses. A T1 is only 1.5mbps too, fast for the time but in absolute terms not that great. The only other options were 56k modem (48kbps on a good day) and frame relay or ISDN, which was a solid 64kbps and lower latency than a modem but also far more expensive than it should have been (US$200-300/month).
  - dspillett 7y ago
    ISDN ("It Still Does Nothing" to give its facetious full name from the time) lines were often bonded, usually to give 128kpbs though faster configurations were possible, though of course there was an increased cost for this.
- matwood 7y ago
  The office of one of my early programming jobs had an ISDN line. I would carry my home desktop into the office to download things/play games. The next job I had was in a much bigger company, and the office I was in had equivalent of 70+ T1s. Most of those were to support the phone system though.

speedplane 7y ago

Why is this article hosted on github? Obviously it wasn't created there as it was written in 1996. Are all the message boards and forums where this type of material was likely posted really defunct or unusable now? Do we now need to rely on enterprising internet historians to find gems on older platforms just to copy them to the newer platforms? Will Github be around in 20 years? Will the next historian have to unearth it from github just to copy it to the next platform?

CaliforniaKarl 7y ago
> Are all the message boards and forums where this type of material was likely posted really defunct or unusable now? The original source of this material (and the other articles) was John Carmack's .plan file. See https://en.wikipedia.org/wiki/Finger_protocol https://en.wikipedia.org/wiki/Finger_protocol The .plan file is by its nature ephemeral, as the user can change it whenever. But the content was archived. The GitHub is just the latest mirror. > Will the next historian have to unearth it from github just to copy it to the next platform? Maybe!
eswat 7y ago
Hey, repo owner here. That does seem to be the case here. I had re-hosted these .plan files from a website – which has removed them – that had re-hosted them from Shacknews – which had also removed them. GitHub seemed like a quirk-and-dirty way to re-host these while giving others an easy way of duplicating the original files so they’re less likely to be lost in the ether.
thrower123 7y ago
Why not? While this is a bit of an exception, given the prominence of the author, most internet content is always at risk of being wiped away from the record. Let a thousand mirrors bloom.

diarmuidc 7y ago

I fondly remember the old Quake 1 days. It was pretty much the last game I played seriously. Reading Carmack .plans were a regular routine and while many of the details went over my head, it made us feel part of the whole id experience. Finally networked Quake was an amazing experience when it came out. I had started my first job in an ASIC design company. All the computers were Solaris based Sun workstations, yet we were able to get network quake up and running on them! I just can't imagine such a thing happening today but maybe that's more to do with me being 20 years older than anything else. For sure no one is porting game engines to Solaris these days ;)

newaccoutnas 7y ago
Same story, but not as glamourous, on a Windows NT4 Rollout (1997). Also recall us downloading South Park at a (then) stellar speed - only took half an hour to download a highty compressed half hour episode, a thing of sheer magic at the time :)

nemo1618 7y ago

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.

DrOctagon 7y ago
I've been keeping personal .plan files since the last time I saw them mentioned on HN. So only a couple of weeks at this stage. In some ways they reflect the way I've gone about a days work more clearly than other project management/bug tracking software I'm required to use.
vinkelhake 7y ago
I think Carmack popularized their use at the time. A bunch of news sites started tracking them. Blue's News still has an archive from back then: https://www.bluesnews.com/cgi-bin/summary.pl https://www.bluesnews.com/cgi-bin/summary.pl Click on a company, a person and then use the drop down to view older entries.
staunch 7y ago
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 https://en.wikipedia.org/wiki/Finger_protocol
bitwize 7y ago
Well, Twitter, Facebook, etc. are the modern replacements for the "status updates" you used to put in your .plan file. .plan was just a simple text file you left in your home directory; it would be displayed to any user who attempted to query you with the 'finger' command. These days the 'finger' protocol is not really used anymore due to security vulnerabilities. But back then, Unix really was a social-moedia OS, and the internet was a decentralized, federated social network. (There were actually two such files; .project was used to give a high-level summary of what you were working on, while .plan was used to talk in detail about what you were currently doing at the moment.)

staunch 7y ago

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 < 60ms ping restriction, which is how most Quake Live servers operated when I used to play that game. 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!

jspdown 7y ago

It seems to be the premises of client-side prediction. I submitted a link on HN yesterday that may interest some of you guys: https://news.ycombinator.com/item?id=19908875 https://news.ycombinator.com/item?id=19908875

hellofunk 7y ago

I see everyone in this thread reference CSP [0] and I keep thinking they’re all talking about the foundations of core.async or Golang. [0] https://www.reaktor.com/blog/why-csp-matters-i-keeping-things-in-sync/ https://www.reaktor.com/blog/why-csp-matters-i-keeping-thing...

sshine 7y ago

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

tranlinhlan 7y ago

https://beautyfriend.vn/products/toner-cap-nuoc-accoje-hydrating-aqua https://beautyfriend.vn/products/toner-cap-nuoc-accoje-hydra...

Insanity 7y ago

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 https://www.goodreads.com/book/show/222146.Masters_of_Doom

apezdedookie 7y ago
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.

tarruda 7y ago

Good times. If I remember correctly, it was possible to drop everyone from a quake server (especially team fortress, when your team was about to lose) by spamming chat messages in the console

k__ 7y ago

Is he happy with his Oculus job after the FB deal or will he leave after the Quest comes out?

bob1029 7y ago
I always wondered about how he felt about that role. I feel like Carmack could still run one of the best software shops on earth, even if he had to start from scratch. The man invented the concept of "it will be ready when it's done", and has an incredibly positive attitude towards handling difficult (challenging) problems. If the stars aligned and Carmack decided to get back into making new software-based gaming experiences (especially around the DTX/ATX area), I would be incredibly tempted to investigate opportunities.

system2 7y ago

It is interesting to see so many grammar and spelling errors in this short article. Almost sounds like he didn't write this himself.

eswat 7y ago

Link to the origin repo if you’d like to read the entire .plan archive: https://github.com/ESWAT/john-carmack-plan-archive https://github.com/ESWAT/john-carmack-plan-archive

pault 7y ago

> If it looks feasable, 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. Classic! Reminds me of the time I told my dad I wanted to make websites for a living and he replied "hey, that's pretty cool, but I don't think there's enough work available to make it a full time career". (This was circa 1996)

ungzd 7y ago

Maybe FRP (functional reactive programming) can give more abilities to reason when designing networked shooters and internal simulation in games. Just like React had revolutionized GUIs (it's not FRP library, but has ideas from it). With FRP, it's even possible to build "tickless" game logic. However, for now it has limited practicability and I never seen something complete that was built with FRP.

shayolden 7y ago

I a developer on FortressOne - a still actively developed continuation of the original QuakeWorld Team Fortress. We have an extremely active community with games taking place nightly. It's a testament to Carmack that his code from 1996 is still widely used in 2019. https://www.fortressone.org https://www.fortressone.org

womd 7y ago

play'd all the doom/quake... was a pleasure reading this...

arendtio 7y ago

> In a clean sheet of paper redesign, I would try to correct more of the discrepencies Sounds like that is what he did with Quake 3 (don't know about Quake 2). At least in Quake 3, the whole game logic is running in a so-called 'Quake Virtual Machine' file (.qvm) that is exactly the same on server and client (even cross-platform compatible). That way he doesn't just predict the client movements but the whole game world.

john4534243 7y ago

Was the dot plan written to himself or for his teammates ?