They missed the 3rd(!) bug in those few lines of code? The normalization was done before zeroing out the Z component, so the resulting vector isn’t actually normalized.
That's most indie game devs of the period, but more so at id Software which splintered the team during Quake's development due to internal squabbles, causing John Romero and others to leave id.
You can even tell that from the quality of Quake's levels which start with beautifully crafted and intricate levels, and as you approach the end, progress into "whatever, let's just ship it, this is gonna sell" kind of levels that were mostly just boring repetitive filler to pad the play time.
This rings really true to me. I only had played the shareware version of quake and only recently played the full game, and the second half really felt like padding.
Some gimmicks in particular were really overused later on (I specifically recall that at a certain point I could just tell "There's going to be an ogre hidden in this corner").
I'm not sure if there was also some other reasons - maybe they decided to use some of the best designs for the shareware, maybe ran out of space for more enemies or maybe there's just way more nostalgia for the first levels - but I'm happy to see that some people share a similar opinion.
Though it certainly is nicer on my wallet to normally grab games on sale.
Also, the distinct style of the last episode is easily explained by the fact that all of its maps were built by Sandy Petersen. E3 was mostly American McGee, while John Romero and Tim Willits worked on E1 and E2.
I'm not a fan of Petersen's maps either, but they are regarded (and liked) as quite unique, compared to the rest of the game.
I had a pirate pre-release copy of Quake that I'd wished I'd saved. But in any case I do remember there were changes to the maps all over the game, so the levels were definitely not done in order. The biggest difference I remember is the ending in the final game is totally different. The pre-release had a more Doom style waves of monsters fight on a sort of giant terrace. I didn't particularly like that doom style ending, but also felt the release game's ending was kind of an anti climactic gimmick.
The better single player levels in Quake are actually really intricate and well-designed single player levels too, in exactly the way that Doom levels were great.
Some of the enemy design in Quake is actually pretty good, too, with sharply distinguished silhouettes between enemies, and good discrete gameplay property differentiation between them - well, at least for the zombies, the fiends, and the shamblers. Some of the others are fine, too (scraggs, grunts).
I think the bigger issue is they bit off way more than they could chew.
Specifically, Doom's single player mechanics thrive on having hordes of enemies interacting with highly interconnected levels in interesting ways, making space management a big part of the single player game play. Trying to figure out where you're safe to pick a fight, or how to steer the hordes around to create a space where it's safe to fight, is a big part of the draw. But, because rendering 3d monsters was so expensive compared to 2d sprites, Quake couldn't do hordes when it shipped, and fighting just a few enemies at a time (with their health highly jacked up) was a totally different experience. It could have been made to work, but they would have had to stray a lot further from the Doom gameplay recipe than they did.
And they also would have needed, I think, a lot more monster variety. A single player game with 30 different enemy types that were interesting and differentiated would have been much stronger.
That's my two cents, anyway.
IIRC (this is well-documented if you want to double check), Tim Willits made most of the Episode 1 maps, John Romero made most of the episode 2 maps, American McGee made most of the Episode 3 maps, Sandy Peterson made most of the episode 4 maps, and John Romero made most of the level 1, military base themed maps in each episode.
The episode 4 maps are often barren, lacking in details, and missing much of the beautiful interconnections of earlier maps... but this is also true of Peterson's maps from Doom (he did a lot of episode 3 in the original Doom, IIRC). So I think it's more of "this guy might be a strong game designer in a lot of other contexts, but the specific needs of making cutting edge Doom/Quake style maps isn't a great fit for him".
I was at Raven Software at the transition from the Doom engine and other 2.5D engines to Quake (and then Quake 2, and then Quake 3, and then Doom 3), and there were a number of existing designers who were fine game designers in earlier, 2d contexts who found their skills severely out of sync with the changing demands of 3d map making, and most of them eventually had to transition to other roles or leave the industry.
His Quake maps especially give me the impression that he was more into trying to come up with ideas on what is possible for the player to do in the freedom allowed in 3D space than how to make a good looking environment (especially in Quake's theme that didn't really have to conform to any realistic constrains and could have shapes floating in space, physically impossible architectures or whatever).
One of them is the nature of interactivity in the levels themselves. There's a spectrum between having a game grammar made of distinct discrete interactive reusable objects and then building unique situations by assembling them in interesting ways, versus having (essentially) unique scripted traps or interactive things or set pieces that only show up in one place. Older action games that inspired Doom tend to draw from that former tradition; a lot of FPS games that came after Quake tended to go more down that second road. Quake's trigger system specifically opened up the door to a rudimentary kind of visual scripting that made the latter style of design more possible in a way that wasn't possible in Doom (although it was possible in Hexen via HexenC(?)). I think you could say that that style of design really came more into its own with Half-Life, which foregrounded unique interactivity grounded in very specific, themed levels much more clearly. Doom at its best seems like it's much more in the design space of, say, Robotron and old Mario games. Fewer unique set pieces, much more focus on discrete interactive toys to be recombined... and given id's background with Commander Keen and their earlier recreation of the first level of Mario 3, this design influence shouldn't be a surprise. Anyway, Quake feels like it is at the intersection of these two styles of design.
I think it is true that Peterson did try to go more down that second road of design in the episode 4 maps in a way that there was less of in other maps, and that it interesting.
But the other thing that sticks out to me more so, in terms of level design, is about the way the space is shaped. A lot of the very best Doom and Quake levels have a tendency of having different parts of levels intersect and interact in interesting, playful ways. The order that you see areas is different from the order that you hear areas is different from the order that you can attack into or interact with areas is different from the order you can move through areas is different from the order that different kinds of enemies can move through areas or attack areas. And that changes as you progress through a level, get keys, and activate switches. There's a tendency for levels to start somewhat linear and movement constrained but give information about later areas in a somewhat more non-linear, tantalizing way, and then as a player progresses, for the player's movement in a level to become more like a multiply connected graph as switches, keys, and activated lifts make a lot of one-way paths become two-way. And that style of design plays to the strengths of Doom and Quake using BSPs for levels as their fundamental data structure - BSPs specifically make these kinds of weird and surprising visual and physical intersections between areas manageable in terms of computational performance on 90's era hardware.
Whether or not someone considers the design approaches I just outlined appealing is fundamentally an aesthetic issue, obviously - there's no one right way to enjoy a game. But my general sense is that the Sandy Peterson maps in Doom and Quake tend to explore these approaches to play much less than the maps made by other designers.
afaik Romero was fired for not working. Cubicle walls came down because Romero was playing Doom on the clock instead of making the game(his form of protest for not making an RPG or something). If you look at Quake code most broken/lazy stuff was done by him. Example https://www.youtube.com/watch?v=DEkjDkr0Qmc
The only real complaint I have is the use of the Spawn enemy, which is generally considered the worst designed enemy in the game. But the enemy placement in episode 4 has the advantage that it makes relatively little use of the Ogre, which I consider the second worst enemy, because it has too much HP for something so common, and is too predictable on Nightmare difficulty (to the point that some people say Hard difficulty is actually more difficult than Nightmare).
* https://fabiensanglard.net/quakeSource/index.php
I recommend checking it out.
EDIT: i was thinking of the analysis done on Quake 2, which is more about the engine:
* https://fabiensanglard.net/quake2/index.php
while the one about is regarding the multiplayer system, which is still an amazing bit of dev.
Github:
By what metric?
Popularity? PR? Net worth? Complex software? Competitive programming? Impact?
For every "top" SE there are tens of similarly skilled engineers that you have never heard of
His record speaks for itself. I know it is tough to imagine what it was like programming 3D engines meant to run on graphics non-accelerated PCs running DOS, without the internet knowledge or collaboration available to us now, but the stuff he was doing was absolutely revolutionary. He basically created PC gaming as we know it today by creating a market for 3D accelerators and before that by doing it in software very well. He also did this stuff in an record amount of time. From Wolfenstein 3D (1992) to Quake (1995) he made three separate engines which each revolutionized the industry one after the other.
EDIT: The metric I am using is 'impact' in an industry and in society in general -- the impact of Doom and Quake on culture and the adoption of computers and PC gaming and many other things can not be overstated. You can draw a direct line from Doom to Quake to nVidia to CUDA and machine learning if you want.
[1] https://advances.realtimerendering.com/s2021/Karis_Nanite_SI...
Similarly there's the work nvidia is doing, using AI technology to upscale graphics instead of rendering things at 4K.
Hobbyists make complicated things quite regularly, although I don't know about 10x quake.
10x a quake for modern hardware, maybe (could be quite simple)
10x software rendered dos quake with loads of asm, probably not.
It adds frames since I think 3.0.
Update: https://youtu.be/6O2B9BZiZjQ looks good around 3:54 Nvidia refer to “deep learning for image denoising” which to me seems like DLSS.
Ray tracing without DLSS might be a different denoising technique. Is it really slow when you turn it on ?
[1]: https://valvedev.info/archives/abrash/
All of Carmack's engines were YEARS ahead of their time. Everyone was doing baked lighting and employing various gimmicks for dynamic-looking shadows, and this dude (and his team) comes in and destroys everyone with this fully-, actually-dynamic lighting system. I don't think anyone else even came close until Crysis in 2007.
If that isn't a top 10 programmer performance than I don't know what is.
2001 macworld demo: https://www.youtube.com/watch?v=80guchXqz14
Nobody's saying he isn't brilliant. But it's not possible to declare him as a "top 10" programmer without actually taking into account all the other programmers.
I think there are at least 10 other programmers that you've never heard of, but that have had as much or more impact on society in general as Carmack did.
Isn't it enough to just say he's brilliant? Ranking programmers is a fool's errand and serves no purpose other than to devalue other brilliant programmers.
(Also, I think measuring how brilliant someone is by how much impact they've had on society doesn't make much sense. Those are two entirely different things.)
I guess? I don't know. There are so many programmers that have had a much greater overall impact and such than Carmack has (which in no way takes away from Carmack's accomplishments!) that I find it hard to say either way.
That's part of why I think trying to rank people is a bit strange. I doubt that there is even much consensus on what it takes to be a "programming god" in the first place.
But I do agree that Carmack is great!
If you correlate against lines of code written over a lifetime then John Brunner and Vernor Vinge bubble to the top. They're my go-to examples for people who think that literature reviews "don't matter".
Kind of a fun exercise since we get to see all the different values out there in the world.
He's very good. Enough people agree. I recommend letting it at that.
I guess a better way of putting it would’ve been the SystemShock would have run a lot faster if it had BSP.
Where would you rank Linus Torvalds?
On this particular case, Linus has publicly admitted that he struggles with empathy.
I spend so much time trying to do a good job which I can be proud of and yet I always know there are bugs and I just hope not too many players notice and get annoyed by them.
And here we are, pointing out poorly written code in practically ancient software and attributing it to one particular programmer. Of course, Carmack has more than shown his worth throughout his career. But I dread the thought of a forum post pointing out mistakes I've made at work like this.
It's part of why it took me so long to dare publish articles about fun stuff I've done at work.
I’m not an elegant coder. My code isn’t perfect. It does run however and is pretty efficient mostly bug free. It does it’s useful thing and I can be proud of that.
Having gone through enough code reviews to know there is a huge amount of polish one can give code. It’s a trade off between perfect and Good enough.
I’m hopeful new languages and patterns leveraging libraries help make our code better or at least let us write more if it.
-- "We Make Shitty Software... With Bugs!"
http://scripting.com/davenet/1995/09/03/wemakeshittysoftware...
I think it is a good mindset to have. We must all assume that software is an imperfect thing done by imperfect beings. Even celebrate it.
On this particular case, I recommend concentrating not on the fact that there was a bug, but on the fact that the code written so many years ago is still relevant for someone today. Focus on that. Try to make something that someone will find a bug in 30 years from now.
Snippet:
I want bug free software. I also want software that runs at infinite speed, takes no bandwidth, is flexible enough to do anything, and was finished yesterday.
Every day I make decisions to let something stand and move on, rather than continuing until it is "perfect". Often, I really WANT to keep working on it, but other things have risen to the top of the priority que, and demand my attention.
* https://raw.githubusercontent.com/ESWAT/john-carmack-plan-ar...
That's why pieces I publish about my work usually contain a fairly long section about potential further improvements.
https://github.com/ESWAT/john-carmack-plan-archive/blob/mast...
It's a _fascinating_ snapshot into Quake's development.
I have no idea if his .plan is a record of what he, specifically, was doing, or if he was just capturing what the programming team was doing, but at the very least, it makes clear that he was aware of huge amounts of very highly specific game code issues as they were being worked on and was almost certainly deeply involved.
Hmm... 11 would put me at 19999, so I must've been more like 12 or 13. I remember that's when I started taking gamedev seriously.
Carmack is great but you can't really say he's better than say some guy you've never heard of who wrote a bunch of absolutely brilliant algorithms inside a missile defense system and it's all super secret. Or someone who did amazing work on a compiler Carmack used or brilliant work in an OS kernel that you're never going to know about, or some AI code, or something deep within a stock exchange's platform.
Carmack's perceived greatness is elevated because almost 100% of what he has worked on is directly visible to the average consumer.
If a musician had a noticeable impact on culture and was prolific, I don't see why we can't put them in a bracket of [in top #]. The ranking is really just to illustrate my respect for his work, accomplishments, insightful communications, and continued relevance as well as impact on my life and those around me. You can call that 'dumb' if you like, but I am human just like you and am not above placing some people's accomplishments above those of others.
Most programmers are quickly forgotten if they were ever known in the first place. In terms of cultural impact, think of the programmers behind our PC or mobile operating systems, major consumer app categories like spreadsheets, word processors, photo or video editing, etc. Of course some nerds of computing history can cite folks behind all these, but it is niche trivia to most of the population.
It also seems like an era coming to a close where a solo programmer can deliver an impactful product. Who gets the credit instead? Usually an executive or entrepreneur gets the credit. Sometimes this person programmed early on, but often they either transitioned to management or started there and other programmers were responsible for delivering the product we eventually know.
This is true but you have to look at it differently. There are generally two ways of looking at history: the 'great man'[0] theory, or the 'of the times' theory.
If you look at it one way Woz and Carmack and Torvalds and the others were instrumental in shaping their surroundings and without those specific people we would have lost out on basically the entire technological world as we know it.
If you look at it another way, they were inevitable -- the times were such that it was bound to happen (or at least extremely likely) because of a great confluence of events that could never be arranged or predicted, and if Woz had electrocuted himself making the Apple I power supply module then someone else would have done something similar around the same time and we end up at the same spot (but Steve Jobs becomes a moderately successful Bay Area Benz dealer and we all use Blackberry phones with physical keyboards in 2023).
The era of an individual engineer or programmer making a paradigm shifting breakthrough in his or her basement may be over, but that just means the times have shifted into another dynamic. What that is can not be predicted, but if we do survive the oncoming crises upon us and somehow also never end up turning the planet into smoldering radioactive ash over a shipping lane dispute or something, there will be a time when such a person can be expected to emerge and do it again.
[0] excuse the masculine nature of this terminology, but unfortunately that is what it is called, though I haven't formally studied history in a while and it could have changed
But also as much fun for people with appropriately specialized interests, so it'll probably keep happening.
1) Perseverance and focus: He kept rewriting the quake renderer, pushing it faster and better, where other people had long ago settled for a lesser variant or given up.
2) Try everything, even the stupid ideas. When he wrote quake, the wisdom was that the FPU was way to slow for a game. He managed to do z-divisions for blocks of 16 pixels on it, while the integer code spit out the pixels.
3) Attention to detail. The doom span renderer was sub pixel precise, which was pretty unique for its time. It looked better in a hard to define way.
4) Code quality. Doom and quake are very readable, very portable and heavily documented. The average 1-person codebase tends to be messy and undocumented, as nobody else ever takes a look. On the other hand, plenty of fixmes in there. It was unabashedly special cased where he could get away with it.
5) He consumed whatever idea he could get. BSPs were an obscure research trick before he took them and ran with it.
He had huge holes in his 3D knowledge when writing doom, as he admits himself. He didn't care until quake forced him to level up. But he could look in the mirror, say he needed to do better, and learn the extra things when he had to.
I don't know if Carmack is that much smarter than the average HNer, but he surely works a lot harder. And that's an even better compliment, in my book
I'm pretty sure I've read it in "Masters of Doom".
Modifying Quake to run on the Occulus Rift was a breeze[2], compared to the mountains of garbage I have to wade through with wipEout.
[1] https://twitter.com/phoboslab/status/1653707447586922498
That's really cool, will you share your efforts anywhere? Love a bit of anti-gravity racing myself. I recommend you listen to the OST whilst coding it for maximum immersion.
In the likely event that this fails, I'll just YOLO it and put it on Github. After all, Sony didn't care that I published[1] all of wipEout's assets seven years ago.
I still find vector programming hard though, so if I was writing anything like this I'd always visualise it as part of my testing. i.e temporarily render out the other beams and possibly the intermediate vector as necessary (pretty much what they did in this video). That makes testing easier to verify and debugging way more intuitive.