John Carmack on QuakeWorld latency and business model (1996)

https://raw.githubusercontent.com/ESWAT/john-carmack-plan-archive/master/by_day/johnc_plan_19960802.txt

by undefined1 • 7 years ago

395 162 7 years ago

raw.githubusercontent.com

keyle2• 7 years 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.

ethbro2• 7 years 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.'

staunch10• 7 years 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.

Crinus2• 7 years ago

It helps that he was his own manager and didn't had anyone else to convince that this was a good idea :-P

Nition7• 7 years 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_Compensatin...

keyle2• 7 years 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.

Nition7• 7 years 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_...

Ways they combat latency: https://developer.valvesoftware.com/wiki/Latency_Compensatin...

Lag compensation (server): https://developer.valvesoftware.com/wiki/Lag_compensation

Prediction (client): https://developer.valvesoftware.com/wiki/Prediction

code_duck• 7 years ago

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

timeimp• 7 years ago

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

forrestthewoods• 7 years ago

Projectiles are simulated on the server

tkiley• 7 years ago

lag compensating projectiles on the client decreases usability more often than you'd think.

Projectiles like rockets apply a lot of forces to the player which are not easily predictable. If you fire a rocket and client-side prediction has it leaving your vicinity without collision but the server has someone stepping into the path of the rocket so it explodes close enough that the explosion exerts force that changes your position, you're going to have a really bad misprediction on the player's position, which of course can get waaaay worse if the player launches another rocket while the first rocket's effect on player position has not been sorted out properly.

reifiedgent2• 7 years ago

I think the effect on other players would be pretty jarring, especially if said projectiles / explosions jolted players in the air at high velocity.

IIRC QW's client side movement prediction didn't attempt to predict the effects of, for instance, shooting a rocket at your feet/rocket jumping, which meant on high latency connections there'd often be a bit of a delay before your view caught up with where the server thought you actually were. This also applies to rockets fired by other players. Lower latency had the effect of not only making it easier to fire rockets at enemy players, it also made everything seem smoother when people fired rockets at you.

Later versions of QW created from the GPL source release have introduced lag compensation for hitscan weapons, but I'm not aware of any attempts to do so for projectiles.

jspdown2• 7 years ago

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

pvg• 7 years ago

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

Nition7• 7 years ago

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.

[1] https://github.com/videogamepreservation/dukenukem3d

bullen• 7 years ago

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?

maccard• 7 years ago

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

Yep

Nition7• 7 years ago

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.

SteveSmith16384• 7 years ago

Predicting it, because it only knows the facts up to ~200 milliseconds in the past.

ndepoel• 7 years ago

Source may have been the first engine to formally support lag compensation on the server side, but something similar was already implemented previously as a mod for Quake 3 called "Unlagged". Essentially what it did was maintain a buffer of all player positions over the last X number of milliseconds and whenever a raycast check needed to be done, it looked back in that buffer based on the current ping of the player requesting the raycast.

There is still some documentation left on the internet: https://www.ra.is/unlagged/faq.html https://openarena.fandom.com/wiki/ModCompat/Unlagged

dvdgsng• 7 years ago

dm17 unlagged instagib. good times.

Thaxll• 7 years ago

I searched the entier HN article and everyone missed a big paper, the tribe networking model: https://www.gamedevs.org/uploads/tribes-networking-model.pdf

This is one of the most influential paper for multiplayer games. ( probably #1 ). Tribe was the first game to have client side prediction and rollback, this is what most games use nowdays.

degenerate• 7 years ago

Related note: you can download and play any of the classic Tribes games from https://www.tribesuniverse.com

ggambetta• 7 years ago

Here's my humble contribution to provide a clearer explanation, and a simple live demo with source code, of client-side prediction, entity interpolation, and server reconciliation: https://gabrielgambetta.com/client-server-game-architecture.... It's a relatively popular alternative source to Valve's (excellent) documents.

ashika• 7 years 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• 7 years ago

pushlatency -120

robocat• 7 years ago

Complete aside about Carmack and reducing VR latency from https://www.gamasutra.com/view/news/226112/How_John_Carmack_... :

"He gave the example of increasing the refresh rate on the Gear VR during development. He was working, at that time, with its Galaxy S III phone. Android triple-buffers graphics, inducing a 48 millisecond delay into the system -- making VR impossible.

Carmack pulled apart Android to hack that 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• 7 years 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

keerthiko4• 7 years 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• 7 years ago

Carmack's brain is so much like a computer that it even does speculative execution branch prediction!

def_true_false• 7 years ago

Is android doing triple buffering wrong? Where does the extra 16ms delay come from?

delhanty• 7 years ago

Presumably by HN readers, saved to archive already 7 times today!

https://web.archive.org/web/*/https://raw.githubusercontent....

soulofmischief2• 7 years ago

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

teddyh• 7 years ago

There was Scrapbook, now replaced by ScrapbookQ.

Crinus2• 7 years 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/

ungzd2• 7 years ago

There's 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.

SmirkingRevenge3• 7 years 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."

kzahel• 7 years 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.

SmirkingRevenge3• 7 years 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• 7 years 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• 7 years 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• 7 years 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-...

SmirkingRevenge3• 7 years 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.

FooHentai2• 7 years 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• 7 years 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

VectorLock2• 7 years ago

Now and as it was then the game maker controls the viability of its game's ecosystem. Some game companies think its a market advantage to have open hosting, mod ability, and some don't.

VectorLock2• 7 years ago

I was thinking the other day how simple and elegant dotplans were. They were truly the original social media.

devit• 7 years ago

You can't really do prediction if you are not rendering the game locally, so all you can do is have a lot of servers all over the world and rely on most customers having a low latency fiber link.

Vogtinator• 7 years ago

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

flohofwoe2• 7 years ago

For the camera alone one could do a few tricks on the client like VR's timewarp/reprojection, but that doesn't work for gameplay actions (like pressing the fire/jump button).

Theoretically the server could speculatively render and transmit a number of different "potential future frames", and the client throws the wrongly predicted frames away.

That's a nice way to burn even more energy and bandwidth though ;)

sly0103• 7 years ago

TVs has been so slow for so long anyway. I suspect we will just have a ton of point and click style games or games that are mostly simulations with relatively uninteresting inputs but with potentially bigger visuals, or casual games where even 300ms+ latency doesn't make much of a difference. For better or worse, reflex (time) based games will just not be played on Stadia by serious gamers. We have VR for that now.

wink2• 7 years ago

It's funny. Sure, DSL brought the (much) bigger bandwidths, but when moving from ISDN to DSL, ping times increased again and it made total sense to play ESL matches over telephone dialup instead of DSL. But either they improved or it's just the normal. Anyway, I stopped playing shooters in the early 00s and so I don't really care anymore.

source: German who never had a 56k modem but started with ISDN in 1998 and can't really remember a ping > 100 on EU servers ;)

vardump2• 7 years ago

but when moving from ISDN to DSL, ping times increased again and it made total sense to play ESL matches over telephone dialup instead of DSL.

Telekom used "interleave" by default, which provided very slightly faster download speeds. And caused about 70 ms latency to the first hop.

I had to contact them and ask them to change my ADSL to "fast path". This dropped the latency to maybe 20 ms (IIRC, my memory might fail me on this number).

I think ISDN was about 40 ms to first hop, but again, it's been a long time.

nickjj• 7 years ago

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 internet connection it takes around 150ms to ping a server in the Netherlands from California. That's over 5,000 miles (8,000 kilometers). Somehow a local key press has the same latency with certain code editors. What have we gotten ourselves into.

nikanj• 7 years ago

Not just Electron either, writing an email in Outlook frequently gives me half-a-second pauses before the typing catches up with the cursor

gameswithgo• 7 years ago

vs code typing latency is on the order of 50ms.

its more than necessary but not as bad as you are implying

kmlx• 7 years ago

i discovered recently that there could be some progress to be made wrt latency in editors: https://makepad.github.io/makepad/

// This is Makepad, a work-in-progress livecoding IDE for 2D Design. // This application is nearly 100% Wasm running on webGL.

jasonrhaas• 7 years ago

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.

bsaul• 7 years ago

my iOS phone freezes approx twice a day for 2 seconds whenever i type text. I remember playing with the keyboard buffer overflow sound when i was playing on my cpc464 (as in 64k of ram and 4Mhz cpu) in the 80s, and it took me longer than that to trigger it.

"The mess we're in" famous talk by joe amstrong should be transformed into a website listing all of those absurdities, as a way to public shame the culprits.

bdamm• 7 years ago

Usually that kind of typing lag is caused by something running amok on the machine. Often for me it has been company installed backup software, to which I send SIGSTOP (not SIGKILL or SIGQUIT, since those cause re-start.)

debaserab2• 7 years ago

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

wil421• 7 years ago

I remember when I was a kid in the 90s and my dad connected two computer to play Doom. The connection was so slow it was almost impossible to play. When my brother and I saw each other’s characters walking around my mind was so blown at the time. Really a great memory. Wait, you can play the same game from 2 computers?

C1sc0cat• 7 years ago

I recall staying late in the office at British telecom and using our super high end oracle forms dev pcs (£4k) and 20 inch monitors(£2k) to play doom.

pault2• 7 years ago

The worst part was having a 200ms ping and getting constantly smoked by the guy with the sub-100ms ping. Hence the acronym LPB (low ping bastard).

sbarre• 7 years ago

I dunno, I actually hated the HPBs more, because at least I could rationalize getting beat by an LPB, i.e. someone with a technological advantage over me. ;-)

john45342432• 7 years ago

What is CSP ?

ttul• 7 years ago

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

usefulcat• 7 years 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• 7 years 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• 7 years 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).

matwood• 7 years 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• 7 years 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• 7 years 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

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!

eswat2• 7 years 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• 7 years 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• 7 years 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• 7 years 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• 7 years 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• 7 years 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• 7 years 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

Click on a company, a person and then use the drop down to view older entries.

staunch10• 7 years 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

bitwize• 7 years 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.)

staunch10• 7 years 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!

jspdown2• 7 years 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

hellofunk• 7 years 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-thing...

sshine• 7 years 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.

Insanity• 7 years 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

apezdedookie• 7 years 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• 7 years 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__• 7 years ago

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

bob1029• 7 years 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• 7 years 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.

eswat2• 7 years ago

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

pault2• 7 years 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)

ungzd2• 7 years 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• 7 years 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

womd• 7 years ago

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

arendtio• 7 years 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.

john45342432• 7 years ago

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

John Carmack on QuakeWorld latency and business model (1996)

Related Stories