One thing I have found extremely interesting was how Valve hit the jackpot with many early hires.
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.
Because technically, they didn't. As they say in the documentary, the version of the game that they made after the first year or so was bad, and they acknowledged it, and they changed their processes and introduced the "cabal" - so they basically paid that first year to gather experience. And what's important, their publisher Sierra was okay with it.
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?
> I don't see that happening today, to be honest, in "AAA" titles at least.
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.
Today they ship in early access, which is a better approach since it opens you up to a ton of feedback. The most recent, and successful, example being Baldurs Gate 3.
The problem is with these "AAA" games. I've spent a dozen years having great fun with perfectly enjoyable and memorable 7/10 games. Nowadays a 7/10 is a death sentence for a gaming studio. The industry is poisoned.
I think time and trust is so critical. I remember a talk by the people who made FoundationDB about their approach to testing. They spend a year just creating a variant of C++ that allowed them to control concurrent execution order and build a framework to simulate/mock network, disc access etc. It's incredible work and AFAIK more than paid for itself. Yet, at most places it would be impossible to get a year-long testing effort of that scale funded or really any engineering effort that produces nothing shippable. All too often you might get 3 months and after 2, a urgent product request comes up and the work sits and rots away till it's useless and nobody gets back to it
Sierra is an interesting company. In the video game industry has very few well known female game designers, and that was even more true back then. Yet the adventure game genre had several - Roberta Williams, Lori Cole, Jane Jensen, and Christy Marx (not as well known, but her games are well regarded), all of whom worked for Sierra. One has to wonder if Roberta Williams being co-owner of the company (and the designer of the first graphical adventure game) is one of the reasons for this.
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.
I’m sure all these people were talented, but it reinforces my own belief that the most important things are passion and focus. I feel like the tech world fixates on 10x programmers like Carmack, but motivated people can pull off amazing things.
I think for most hiring, regardless of industry, the secret is searching for passion, focus, (I would add) ability/willingness to learn new skills, and a positive attitude toward other humans.
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.
Carmack was the giant whose shoulders a lot of games - including Half-Life - stood on; I'd say he's a 100x or 1000x even, but then, engine developers are usually unknown and underrated. The work he did and what the Unreal engine now does is not to be underestimated.
They knew Michael Abrash from working at Microsoft who went to id, told them to "you should use our engine". They went to id and walked out with the quake engine, and some advice from Romero.
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.
That coupled with the fact that the talent pool and tooling for game development were limited. Having id at your back was a superpower (which is arguably still true today when you compare their tech to other engines).
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 struck me, too. They really took a chance on so much staff, without any real proof that they'd be able to deliver. My impression was that this was a lot more common then than now. These days, you have to be capable of work a level or two above what's needed for shipping, presumably because management and timelines are so warped that you'll be rushed and overworked and still have to deliver. People starting out or shifting careers don't have anything like this kind of backing; you go it alone and hope that you're developing the skills necessary to get hired.
Goldeneye was developed by Rare, who had been in existence for 10 years by the time Goldeneye was released. I'd be really surprised if they had landed the rights to a big IP and then turned a bunch of newbies loose on it.
Some of them had experience in map making and modding though, correct? I don't know if Dario Casali had a CS degree at the time or if he does now, but he was making Doom maps and contributed to Final Doom prior to being hired at Valve. I think he had economics degree at the time. He recently did a play through of HL with him giving commentary and realy fascinated, definitely watch that. He talks about how a bunch of them didn't really know how to make a game and somehow they did it.
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.
They hit the jackpot or, a reasonably motivated developer, under a cool project to keep them engaged and a nurturing environment with peers in the same situation is on high chance of flourishing?
I was heavily involved with the australian team fortress (quake 1 version) community in the late 90s and 'bro' (Robin Walker) and John Cook were gods to us, regularly involved in the RMIT/Melbourne Lan scene and online even when back then mostly it was 28.8/33.6k modems with a few LPBS on East coast uni isdns.
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.
I was in the same scene (Clan PlanetFortress FTW). Robin and those guys saved us from the annoying cheaters that were exploiting the old qw code. I was so excited for them when they got hired by Valve to make TFC and then 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.
I don't understand this comment. The original Counter-Strike mod came out around the same time as TF got ported to HL. Unlike TF, CS had pretty much consistent releases of some kind from CS up to 1.6 to Condition Zero and then Source and Go. I don't think there was any salvaging of TF stuff into CS.
To be clear, CS was developed independently of TF, and had a different genealogy as it were. Certainly some developer crossover later on, but probably more by people wanting to work on it instead of being told to.
I have seen some early draft designs for a WW2 themed shooter that might have been part of that early TF2 concept. Then Day of Defeat came along and fit the bill nicely.
So, this begs a rather obvious question. What makes that team different? Is it the talent, the leadership, the focus on product?
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.
Most developers probably don't care and just want to get paid. Beyond that, I imagine you're not usually empowered to make big changes unless you're relatively senior, and even if you decide to be the kind of developer that's always striving towards self improvement your job is unlikely to reward you for your skill development. I think there's just a lot of diminishing returns.
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.
> Most developers probably don't care and just want to get paid. Beyond that, I imagine you're not usually empowered to make big changes unless you're relatively senior, and even if you decide to be the kind of developer that's always striving towards self improvement your job is unlikely to reward you for your skill development.
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.
Valve did have a few key people (not to mention complete access to the best 3D engine source code at the time) who really did know what they were doing.
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.
To me it seems like their passion drove them to learn as much as they could. They knew enough to get the job done, but not enough to know that they "couldn't do" the things they wanted to do.
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.
There are lots of reasons why Half-life was a success. You shouldn't discount stupid luck, as well. Their first iteration was awful, as mentioned in the YouTube video. They essentially had to start over with a "cabal" and pull the game together with the good scraps of work they had already done.
Here's a more detailed article on the cabal process (starting on page 2):
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.
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.
Sad reminder of the crunch, even when the result turns out to be a success. Hours like that pushed me out of modding and into boring old business software.
Yep. Web development provides a more pleasant, if perhaps less exciting, way of life than gamedev. And you can still do gamedev in your spare time (you have spare time!)
Dario’s descriptions of the working conditions are pretty brutal in this series. Relentless 12-16 hour days, arguments in emails, demotivating management. I grew up with a fairytale idea of what working at Valve must have been like - a brilliant environment of smart people doing their best work. Although I’m still sure that’s true, I don’t think I’d be willing to make the sacrifices these developers did for the sake of a video game. Astonishing
Each video tends to start with a couple of minutes dedicated to story telling. One of the videos I found most interesting was the last one about multiplayer maps because Dario had a lot to say about designing the maps.
Watched it yesterday, game development is so wild. Especially this one, basically everybody were just amateur and passionate with little to no background in programming or even gaming.
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.
Loved the documentary. I played the hell out of that game back in the day. There’s a renaissance of Half-Life Deathmatch too (short-lived, no doubt) if anyone wants a hit of nostalgia. Valve even released a couple of the concept art character models, some gameplay tweaks, and some new maps. New content for a 25 year old game.
Also FYI, Half-Life and HL2 are currently both very playable in VR. Half-Life even runs natively on the Quest 2.
Readit News
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..."
https://youtu.be/SVFnYLTsxdc&t=18m30s
Deleted Comment
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.
Deleted Comment
Deleted Comment
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.
Deleted Comment
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.
[1] https://en.wikipedia.org/wiki/Blind_men_and_an_elephant
[2] https://en.wikipedia.org/wiki/The_Mythical_Man-Month
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.