It was literally people that often didn't even have a CS or let alone gaming background and yet so many of them proved to be relentlessly resourceful, creative and hard working.
The guy who wrote most of the HL code wasn't even a developer and at the time was studying to become a lawyer or accountant iirc.
I can't but think that timing, founders but also straight up luck played an absolutely crucial factor.
I don't see that happening today, to be honest, in "AAA" titles at least. Budgets have gone through the roof, and the publisher won't give you a plan B, they will force the developer to duct-tape what they have and ship it no matter what. And the game can always be patched later, right?
Thanks for adding that caveat; it's an unfair comparison IMO to compare the well-selling games of 25 years ago with AAA games of today. Half-Life was built by a team of about 80 people according to a quick Google, and there wasn't the ecosystem of tooling, resources and outsourcing that we have today, versus hundreds if not thousands of people (if you include outsourcing / engines / etc) for AAA titles today. And the modern day game devs will have enjoyed a relevant education, whereas back then those educations didn't exist yet. Notably, John Carmack did a lot of ground work in translating math into 3D video game engines; he was behind Wolfenstein, then Doom, then Quake, and the Quake engine was used as the basis for Half-Life's.
Anyway, 80 people is pretty substantial even at the time; for comparison, indie hits like Hades had ~20 people working on it, Hollow Knight's Team Cherry has just 3 employees (but they used Unity so they didn't have to do much engine programming, and the ports to various consoles was outsourced); Wube (Factorio) has had a few dozen people working on it. "indie" hit Kingdom Come: Deliverance had like 240 people working on it.
You could likely do the same today, but the key would be finding someone (like Gabe) to fund it whilst it got off the ground.
Another interesting story is when Ken Williams (Roberta Williams husband, the other co-owner of the company) hired middle-aged retired police officer Jim Walls to design the Police Quest adventure games (he designed the first three). Ken apparently was talking to his hairdresser about his idea for a police adventure game, when she mentioned that Walls, her husband, might be an interesting person to talk to.
Specific job skills can be taught or learned. If you have the right attitude, positive outlook, and are inherently someone who learns things, you can be very successful in most jobs.
Too often, hiring filters for specific job skills/credentials. Because these are supposed to be a proxy for the softer skills. It's not as effective, but much easier to deploy at scale, I think.
Sometimes it really helps who you know, and there is always some element of luck in making it. Having a great team certainly made that game what it was. It was interesting how they balance realism and fun.
Its always interesting how things get made.
DYKG recently did a video about Ken Sugimori (the Pokemon guy). He is an overly harsh critic of his own skills, but I think there is a kernel of truth in this insight:
"It's kind of embarrassing to admit actually - but [video games were] a brand new industry back then, and standards were lower than in other fields..."
That doesn't take away from a bunch of inexperienced people making an awesome game though. That was hard to do I'm sure. I couldn't even dream of accomplishing that.
The struggle for them to move on from qwtf to 'tf2' was probably for the best as a lot of the lessons they learned in the wilderness there helped when they were taken on by value and worked on HL2.
Also find it somewhat amusing was that TF2 was originally going to be a much more 'realistic' modern miltary shooter before the scope creep killed it.
Instead we got Counterstrike. I'm not complaining as CS:Source is one of those games that I spent hours upon hours honing my skill.
As a long time JavaScript developer I honestly believe, and I really mean this, that maybe 4% of the people employed primarily doing JavaScript work actually know what they are doing. Just 4%.
It seems at the beginning many of the early Valve team had a lot of passion but almost no real experience in that kind of code or product. They got a massive springboard with the Quake code and then figured out the rest. They didn't stagnate on the Quake code, but wildly modified it to fit their needs. Most JavaScript people are not capable of this. They just stagnate at their favorite framework and then just spin around code style and process.
What differentiates that early Valve team from all these various JavaScript teams? It clearly isn't education or professional maturity.
Have you ever tried playing a competitive multiplayer game? There's people that will play games for thousands of hours without ever improving.
Sometimes I think people encounter bottlenecks and they're not sure how to overcome them.
Bingo. I got a release coming up, I just need to ship this -- ain't got no time for fancy stuff, and higher-ups don't want fancy or flourish, just make it work. And even if there is room for trying something new, it probably doesn't matter if the users DGAF about the new feature.
Keep in mind that building video game levels, models, animations and such back then was dramatically simpler than it is now.
One person did all the texture work for the whole game. One person did all the sound effects and music, and also coded the DSP engine to add real-time sound manipulation based on the environment.
You can do a lot with a few very talented people who are willing to guide a whole bunch of smart, eager and motivated folks.. which I think is what happened at Valve.
More experienced devs may have thrown out a lot of the ideas the Half Life team ended up implementing as "too time consuming" or "practically impossible". Valve's devs at the time weren't experienced enough to make those assumptions, so they just worked their asses off to figure out how to do it.
Here's a more detailed article on the cabal process (starting on page 2):
https://web.archive.org/web/20210823181232/https://www.gamas...
From 1999 and much more detailed than the video.
Now, game development is inherently waterfall. You work for years and built up to this huge release. Nowadays you might have some agile processes embedded into milestones, etc. But fundamentally it's all leading to a huge waterfall.
That's important. Because what agile does, today, is that it turns autonomous developers into cogs of a large machine. But Valve's "cabal" was entirely free to do whatever they felt best. Gabe Newell probably had final say and input, but ultimately the group had flexibility. The developers had full system awareness. They weren't pulling Jira tickets off a board like a blind man in the elephant parable[1]. They knew how the pieces fit because they put them there. And if the pieces weren't fitting, they had the authority to make them fit.
Perhaps more interesting is how the story of Half-life can be viewed through The Mythical Man-Month[2]
> When designing a new kind of system, a team will design a throw-away system (whether it intends to or not). This system acts as a "pilot plan" that reveals techniques that will subsequently cause a complete redesign of the system.
Their cabal has a bit of overlap with the "surgical team" concept and usage of formal documents. The rest of the employees did nothing while this group operated. Thus, they reduced manpower that actually allowed them to move forward. Slow is Smooth, Smooth is Fast (from the US Navy Seals). Most companies do the opposite. They crank up the number of employees to hit deadlines, which creates more bugs and more work.
Because it's JavaScript. It's a language specifically designed for people who don't care about how anything actually works.
1. Hacker-tinkerer culture, where you want to build new things that haven't been built on new hardware for fundamentally non-commercial reasons. This could be called Carmack-style hacker culture in my mind, which produced Quake.
2. Genuinely extensive programming expertise.
3. Not partaking in the current and quite toxic VC-funded game development culture, where funding dictates rushed deliverables (through schedules, and the constant race to attract funding with demos). It's feature factory or die in a lot of VC-funded scale-ups.
4. Lucky circumstances - knowing someone who could get you Quake source on "just have it, we'll work something out eventually" terms back then was exceptionally lucky. Quake was very far ahead of it's time. Most companies that produce such work now would work very hard to make sure no one else gets it. And that goes back to the hacker culture of just building cool things to share with people that was more common in games then.
5. Time - the games industry was young, before Quake there were no proper 6 DoF generalist 3D game engines, so it was an auspicious time for game development.
I'm a game developer and I am a bit old school, so I'm not the best person to speculate on why JavaScript programmers seem less able to build cool tech. But I have seen many young people approach programming differently now, probably because it has become a lot more commodified. The mindset of a "clock-in clock-out" programmer wasn't common in game circles in the 90s and 00s. Also, there was much less focus on using "correct" idioms and beautiful code as the end goal in hacker circles, and a lot more focus on building something that others haven't built before and working out the details later. Moreover, business viability was rarely the first thing you would think about and work backwards from when you worked on a game project. Business success was a byproduct of building cool games.
If you would remember game trailers from early 00s, like Half-Life 2 (since we are talking about Valve), you would pick up that they show off cool tech like physics simulation, which is quite janky and imperfect. Carmack also has spoken many times about how in his early games (pre-Quake) the graphics would initially be quite bad and he would be worried about getting everything fixed in time. Cool over safe, cool over perfect, and showing off cool things that were not polished was normal.
Nowadays, things are different in some ways. The game development has become methodical and focused on the exploitation of passion for money in a repeatable way. You get as many features as you can for marketing (you only need to have them, they can be whatever quality, it's only for the Steam page and trailer). You cut all the awesome new things as they are a risky waste of money, you instead funnel all the passion into velocity for delivering that bundle of features as quickly as possible for as cheap as possible, and that's it. If you can strike a deal with a nice IP, that will make the game sell a lot more. So will striking a deal with a publisher with deep pockets for marketing. But the "do cool things" hacker culture is gone in AAA and blockbuster games. It's now relegated to indies where quite a lot of janky but incredibly cool games are made. But they have a funding access problem as their business is too risky for most publishers and VCs. And that's probably why we don't see many new and big id and Valve-type companies anymore.
Although with VR, there are some companies that I believe could be like that. And they attract senior talent quite well. With the right management and timing, I think we could see another Valve in VR. Even Carmack played a big role in VR until recently, before he moved on to the next new thing in tech. Being on the precipice of new tech is important for people of that culture.
Also demystify how it's done, almost none of the HL goodness where there at the beginning: the intro, gman, xen, crabs, music, etc. And were just made up along the way.
Also FYI, Half-Life and HL2 are currently both very playable in VR. Half-Life even runs natively on the Quest 2.
In a way, studios have hyper-focused on pre-ordering in order to get around this. Games are now investments that eventually get fixed and "live up to" their cost, instead of a polished finished product. Studios and publishers now focus on pre-ordering over finishing.
- (Paulie) "You're late!"
- (Ralphie) "Well, tomorrow I can be on-time, but you'll be stupid forever"
The conclusion was a dumpster fire for so many issues, and it wasn't for lack of original content to derive from I'd argue.
This is produced by same crew as the Half-Life doc. SecretTape who produced HL doc is the for-hire arm of NoClip.
Half-Life 25th Anniversary Update - https://news.ycombinator.com/item?id=38307889 - Nov 2023 (258 comments)
Couldn't you just move the mouse slower so the turning is slower? Or lower the mouse sensitivity?
To me, the biggest factors to (worse) sickness are
1. Narrow FOV: usually the bigger the FOV, the better. But when it starts to have too much of "fisheye" effect, it can be detrimental.
2. How "fluent" your character moves -- if you have to stop/decelerate constantly (for any reason: interact with objects, clash with walls, sharp turns), it induces sickness very quickly.
Third perspective games are typically much better, but if it's in a confined space (like in a room) for extended time, it's as bad as FPS.
The best FPS I've played in term of having close to no motion sickness is Overwatch. Apex Legends is pretty good in this regard too.
Any Valve title is a vomit festa.
