15 ms·

Ex Valve dev on CS:GO’s codebase

166 points by hnthwaccount 6y ago

josefresco 6y ago
I'm not familiar, are they still running "Source 1" or have they moved on? If so, I don't see how this is very relevant beyond mildly interesting because it relates to a game many love and still play.
- deleted 6y ago
  [deleted]
- dx87 6y ago
  They're on Source 2 now, but not all of their games have been ported to it. A former employee said that Source 2 is pretty much just Source 1 with some extra phsyics bolted on, not a completely new engine.
  - haunter 6y ago
    .
    - dx87 6y ago
      > not all of their games have been ported to it
  - mepian 6y ago
    That's a large understatement. The arguably most important part of any game engine is development tools, and those were completely rebuilt and are nothing like Source 1's tools. You can see this for yourself by installing and comparing CS:GO SDK and Dota 2 Workshop Tools in Steam.
  - kllrnohj 6y ago
    Source 2 is Source 1 with most of the key systems replaced. They may have started with physics, but they didn't stop there. Many game engines are a collection of modules, Source included. So it becomes a fuzzy line when it becomes a "new" engine. Does replacing one module make a new engine or not? How about 2? 3? And I very much do mean "replaced" there. Physics, since you mentioned that, was switched from Havok to the in-house developed Rubikon. And since Havok is a licensed middleware, they couldn't just bolt some new stuff on and call it theirs. That's going to be a full from scratch replacement. Similarly the "UI module" was fully replaced, from the Flash-based Scaleform to Valve's in-house Panorama which is fairly similar to HTML5/CSS/JS. This module replacement was also "ported" to Source 1, and was implemented in CSGO as well. Which gets back to the lines between game engines "versions" are blurry.
    - tecleandor 6y ago
      It's the Engine of Theseus! ;)
    - smileybarry 6y ago
      Another nice example of that is the engine used in Ubisoft's Splinter Cell games. Technically it's Unreal Engine 2.5 (and some of the file formats are similar), but every single subsystem was replaced by now that only some of the tooling is still Unreal Engine 2.5 (which is arguably the important part to keep intact for game designers). Even the renderer isn't UE2.5 anymore.
breendreams 6y ago
Wasn't CS:GO developed by Hidden Path?
- diesal11 6y ago
  Initially but has been maintained by Valve for some time now. Having said that, it's built on Valve's Source Engine, so still faced many of the same issues
- jbverschoor 6y ago
  That's a vey good name for codepaths which are difficult to find :-)
- deleted 6y ago
  [deleted]
Jugurtha 6y ago
One of the best, and first, things we did when starting our machine learning platform was to design it using a plugin architecture. There's a lot of scar tissue and horrible experience through our previous ML products we built for enterprise. Namely, it was extremely hard to onboard new developers to work on the product. They had to understand the whole thing in order to contribute. Changing something was also hard, since it was intertwined. Adding a feature or removing a feature was hard. Especially given the fact we were not designing to spec, and the domain experts we were building for could not give feedback. That was a constraint outside of our control, so we were building for users we never met based on what we thought would make sense. The first commits on our own platform were to establish a plugin architecture. There's a core, and there are plugins. We could add or remove functionality changing a config file. Applications are plugins and onboarding is easy and smooth, since a junior developer can start working on one plugin and then expand their knowledge. We're reaping the rewards of that.
- arkitaip 6y ago
  Are there any drawbacks of using a plugin centric approach? Typically there is loss of expressiveness in code, loss of performance or disconnect between core and plugin development.
  - Jugurtha 6y ago
    Not that I could see at this point. It is not a panacea, but for us, it was a way to contain scope at different levels. For exaple, we have the platform and it has icons on the sidebar for Notebook, Object Storage, etc. Every single one of these is a separate application and a separate repository. These applications are independent in how they deal with business logic, so there's no loss of expressiveness. They just must present certain "receptors" or interface if they want to be plugged into the system. The "interface" is a big word, and someone can produce a valid minimal plugin (that does nothing except be loaded) in two minutes. This allows us to contain details of a plugin to the plugin itself, and not having it leak to other parts of the product. If we want to activate/de-activate the plugin, it takes less than 10 seconds manually. Now, sometimes a plugin depends on another plugin. But they make their requests to that plugin, and fall-back to something else in case that plugin is unavailable. The amount of engineering time this has saved us is delightful. I think of all the code we did not have to write and it makes me smile. That's for containment and encapsulation at the application level. But we also follow that mode at the functionality level, too. For example, model detection and tracking is done by plugins. We like to do things and have an abstraction so that we can churn out functionality for similar things "industrially", without thinking too much, but also so we could remove things easily without breaking the rest. Making code not just easy to add, but easy to remove is important. When we did that, we were able to remove a lot of code, too. It is a spectrum, and we started by using it to contain at the "app" level.
akhilcacharya 6y ago
It seems like code quality was a big factor in the delay of Source 2 and future Valve games as well. At what point do you cut and run from legacy? The end result is pretty fantastic, but it was expected 5 or 6 years ago.
wccrawford 6y ago
"Also, if you touched the renderer, even in a simple way, and a team later encountered a rendering bug, you would be blamed and have to fix it. Even if the bug had nothing to do with your change. This taught programmers to not change anything unless absolutely necessary." I've seen this effect in code that wasn't nearly this bad, and I've even felt this way... But in the end, I've decided to do it anyhow. The end result was that I became the guy that could fix anything (in other people's minds, anyhow) and my job was actually more secure than if I'd followed the path of least resistance. Had these devs followed the hard path, too, I think it would have helped get things cleaned up, instead of continuing to pollute everything even worse. Sometimes developing is hard, and you just can't shy away from the hard parts. It just makes everything else harder.
- mam2 6y ago
  No unit test ?
  - flohofwoe 6y ago
    The Source engine hails from the 90s, testing hadn't been invented back then ;) But on a more serious note, writing automated tests for game engines involves a lot more than just "duh, unit tests" (especially when testability wasn't a concern in the original design).
    - matsemann 6y ago
      Game code can be hard to unit test, it needs integration tests on actual hardware. Lots of weird stuff on all chips that need to be taken care of.
      - daemin 6y ago
        Yep, lots of interaction tests that can be quite brittle and can take a long time to run, even with a farm of servers and consoles. A lot of small and low level stuff can be unit tested but during production things like writing good tests falls through the cracks.
dx87 6y ago
Doesn't suprise me. I was watching a video where they had devs watch a speedrun for HL:2, and they said that there are a ton of hacky fixes that never got properly fixed. They said that same code is now in HL:Alyx, and that it's funny looking through the code for a modern AAA game and seeing comments like "Quick hack to get demo stable for E3 2005. Add permanent fix after show".
- daemin 6y ago
  Yep, that happens all the time. Some quick fix is added before a trade show and 2-3 years later it's still there and going into the release. The reasons vary but it's usually one or more of: people forgot, issue was created but was never important enough to get worked on, the fix works fine and the comment should be removed, the code path is no longer executed.
- bogwog 6y ago
  Professional game development seems to revolve around the art of quick hacks. Gamers aren't going to care whether your code is clean or not, and they sure as hell won't want to wait for you to tidy it up.
  - Cthulhu_ 6y ago
    But the weird thing here is that Source is based on GoldSrc which was based on Quake; apparently, instead of learning from years of experience and building a brand new engine without the baggage, they decided to just keep building on top of the old stuff? I mean to a point I get it, but if some code is unmaintainable, you don't keep trying to fix it, you have to decide to replace it. Valve has no excuse, they make crazy amounts of money, they can fund the development of a new engine from scratch easily. They just choose not to.
    - gameswithgo 6y ago
      Quake is full of hacks and bug too.
    - eertami 6y ago
laurentdc 6y ago
I still don't get why they can't make a basic anticheat or protect the process memory like most other games (even the Faceit AC client itself for CS:GO!). Is there some explanation like keeping compatibility with very low end PCs? You can get wallhacks in multiplayer by simply using WriteProcessMemory calls. [0] [0] https://github.com/Snaacky/Diamond/blob/master/diamond.py https://github.com/Snaacky/Diamond/blob/master/diamond.py
- mschuster91 6y ago
  When the code is chaotic enough it may be impossible to write an anti-cheat that can't be guaranteed to not trip from ordinary in-game code.
- meibo 6y ago
  To be even remotely safe from this, you need to use a kernel driver, which is invasive and widely seen as unacceptable - at the moment anyhow. See Riot and Valorant from earlier this year. There was a lot of outcry and the response from the devs was basically "we don't give a damn". Other games, for example, scan window titles or signature for a variety of debuggers/hacking tools like IDA and x64dbg. There's many techniques and variations you can apply to make things like this more "annoying" - but never impossible. Earlier this year, there was a PCI card PoC that would read memory and act as an "undetectable" wallhack - people are clearly crafty enough to always find their way around.
  - tester34 6y ago
    >There was a lot of outcry and the response from the devs was basically "we don't give a damn". Because "we" gamers tend to prefer to have fair game Playing against cheaters destroys fun and the games itself. It's hard trade off, but your average gamer would rather to play fair game.
    - meibo 6y ago
      I don't think you can attribute this universally to "gamers" - there's a lot of games that don't have obvious hacking problems by employing various other measures which aren't as invasive. I'd call myself a "gamer" and would never install something like Valorant - and most of my friends didn't either. Some of us value our privacy more than getting rid of the one hacker we get per week.
est31 6y ago
TBH this issue exists in many larger codebases that don't take separations of concerns seriously. Solution: take it seriously. That's harder than it sounds and depending on the problem domain is next to impossible, you should still try it.
- Matthias247 6y ago
  Absolutely true, the issue exists in many code-bases and organizations. And even trying to keep things decoupled will only help so much. A 10+ year old codebase which is mostly driven by new feature development will very often have accumulated so much cruft and workarounds that trying to make and further modifications is rather likely to break something else.
02020202 6y ago
this is yet another issue for programmers but not for the business. the product is seen as a black box by the business and if it gets expected output for provided input, it does not matter what is going on inside of it. it makes money and in the end that is the only thing that truly matters. of course programmers will keep on complaining but in the end, it does not matter. if it works, don't fix it. doing rewrites brings nothing to the business, only to the developers. sure, the rewrite will save dev hours along the way but the rewrite itself is not free so all in all...if it works... btw this is also why language design of composition instead of inheritance is so important for big projects. you will learn this way way too late if you do not get it already.
stefan_ 6y ago
Hence why game engines are now their whole own business, and before that time, people used to just start fresh with every game, maybe having a drawer of useful snippets. Crunch time is fundamentally incompatible with the discipline needed to not end up in this place.
- tester34 6y ago
  I don't think it's only cuz of lack of discipline I think sometimes in project this complex you (nor anyone) have no idea where some code SHOULD be and inserting it in "wrong" place causes weird things later
- deleted 6y ago
  [deleted]
- 0x445442 6y ago
  > Crunch time is fundamentally incompatible with the discipline needed to not end up in this place. The hubris of trying to circumvent the law of fast, good, cheap; pick two.
robmsmt 6y ago
https://youtu.be/LmRl0D-RkPU?t=2480 https://youtu.be/LmRl0D-RkPU?t=2480
- robmsmt 6y ago
  I meant to say that these comments from Bob Martin remind me of testing and proper architecture for the code
offtop5 6y ago
Could a big part of the problem be just how old the engine is ? I assume many if not all the original devs have left.
Scuds 6y ago
richgel999 has posted before about Valve's toxic culture - so bikeshedding about "well why don't you just... " is beside the point in the larger context of perverse incentives. https://twitter.com/richgel999/status/1330765701037101057?s=20 https://twitter.com/richgel999/status/1330765701037101057?s=...
- an_opabinia 6y ago
  It's a refreshing perspective. It is still not that much of a knock on Valve - after all, they hired him, seems like they made the right choice, he is really articulate, voted with his feet, etc. etc. It actually makes him and Valve look pretty good, especially since it's such engineering and strategy focused and honest criticism, and none of it concerns illegal stuff either, like retribution.
XCSme 6y ago
Offtopic: I was checking his bio: "Entrepreneur at Binomial, open source dev. Previously SpaceX, Valve, and Ensemble Studios/Microsoft. SIBO survivor. From New Jersey. Opinions my own. He/him." At the end wrote "He/him". Anyone knows what does this mean and what is this trend? Is this to clearly state your gender and how you identify yourself?
- d0100 6y ago
  Signaling that he agrees and supports people chosing their preferred pronouns. Maybe even supports compelled pronoun use.
- eznzt 6y ago
  https://en.wikipedia.org/wiki/Virtue_signalling https://en.wikipedia.org/wiki/Virtue_signalling In this case, it is a way of saying "I lean left".
  - keeganpoppen 6y ago
    if we’re being pithy, i feel like signaling “i’m woke” would be more apt.
- tw102 6y ago
  there are plenty of people who, e.g. - don't want to show their face on the internet - people whose appearance is ambiguously gendered - people who are not the gender that people assume from pictures of them - people who used to be addressed as a different gender and, when addressed, want to be referred to correctly. for instance, i'll never show my face on the internet, but i like it better when someone says "_he_ wrote that program" rather than "_she_ wrote that program." for all those people, it makes sense to put their pronouns in their bio. but that leaves the problem: if only the people in the above categories put pronouns in their bio, and you have pronouns in your bio, that might imply you are, for instance, ambiguously gendered. so people who are conventionally masculine like Rich put pronouns in their bio to normalize it, and to make sure that "having pronouns in one's bio" is not a "thing only OTHER people do". i think it's a good thing to do. i'll do it too.
andrewmcwatters 6y ago
The renderer in Source is one of the places I don’t have a great understanding of. Quake’s is fairly straightforward, but the shader system Source has complicates understanding a lot more than if you had licensee access. The way they talk to entities to handoff determining visibility is fantastic, and there are a number of other small design details that make the engine very pleasant to work with as a modder or game developer—but there are some things that are rather hard as an engine developer working with Source, or black boxes because no one has public information of how particular systems work anymore. Even internally at Valve they’ve broken particular portions of Source and the Half-Life codebases because they don’t understand how particular interfaces work anymore, but some older members of the hlcoders community still do.

166 points by hnthwaccount 6y ago

I'm not familiar, are they still running "Source 1" or have they moved on? If so, I don't see how this is very relevant beyond mildly interesting because it relates to a game many love and still play.

deleted 6y ago
[deleted]
dx87 6y ago
They're on Source 2 now, but not all of their games have been ported to it. A former employee said that Source 2 is pretty much just Source 1 with some extra phsyics bolted on, not a completely new engine.
- haunter 6y ago
  .
  - dx87 6y ago
    > not all of their games have been ported to it
- mepian 6y ago
  That's a large understatement. The arguably most important part of any game engine is development tools, and those were completely rebuilt and are nothing like Source 1's tools. You can see this for yourself by installing and comparing CS:GO SDK and Dota 2 Workshop Tools in Steam.
- kllrnohj 6y ago
  Source 2 is Source 1 with most of the key systems replaced. They may have started with physics, but they didn't stop there. Many game engines are a collection of modules, Source included. So it becomes a fuzzy line when it becomes a "new" engine. Does replacing one module make a new engine or not? How about 2? 3? And I very much do mean "replaced" there. Physics, since you mentioned that, was switched from Havok to the in-house developed Rubikon. And since Havok is a licensed middleware, they couldn't just bolt some new stuff on and call it theirs. That's going to be a full from scratch replacement. Similarly the "UI module" was fully replaced, from the Flash-based Scaleform to Valve's in-house Panorama which is fairly similar to HTML5/CSS/JS. This module replacement was also "ported" to Source 1, and was implemented in CSGO as well. Which gets back to the lines between game engines "versions" are blurry.
  - tecleandor 6y ago
    It's the Engine of Theseus! ;)
  - smileybarry 6y ago
    Another nice example of that is the engine used in Ubisoft's Splinter Cell games. Technically it's Unreal Engine 2.5 (and some of the file formats are similar), but every single subsystem was replaced by now that only some of the tooling is still Unreal Engine 2.5 (which is arguably the important part to keep intact for game designers). Even the renderer isn't UE2.5 anymore.

breendreams 6y ago

Wasn't CS:GO developed by Hidden Path?

diesal11 6y ago
Initially but has been maintained by Valve for some time now. Having said that, it's built on Valve's Source Engine, so still faced many of the same issues
jbverschoor 6y ago
That's a vey good name for codepaths which are difficult to find :-)
deleted 6y ago
[deleted]

Jugurtha 6y ago

One of the best, and first, things we did when starting our machine learning platform was to design it using a plugin architecture. There's a lot of scar tissue and horrible experience through our previous ML products we built for enterprise. Namely, it was extremely hard to onboard new developers to work on the product. They had to understand the whole thing in order to contribute. Changing something was also hard, since it was intertwined. Adding a feature or removing a feature was hard. Especially given the fact we were not designing to spec, and the domain experts we were building for could not give feedback. That was a constraint outside of our control, so we were building for users we never met based on what we thought would make sense. The first commits on our own platform were to establish a plugin architecture. There's a core, and there are plugins. We could add or remove functionality changing a config file. Applications are plugins and onboarding is easy and smooth, since a junior developer can start working on one plugin and then expand their knowledge. We're reaping the rewards of that.

arkitaip 6y ago
Are there any drawbacks of using a plugin centric approach? Typically there is loss of expressiveness in code, loss of performance or disconnect between core and plugin development.
- Jugurtha 6y ago
  Not that I could see at this point. It is not a panacea, but for us, it was a way to contain scope at different levels. For exaple, we have the platform and it has icons on the sidebar for Notebook, Object Storage, etc. Every single one of these is a separate application and a separate repository. These applications are independent in how they deal with business logic, so there's no loss of expressiveness. They just must present certain "receptors" or interface if they want to be plugged into the system. The "interface" is a big word, and someone can produce a valid minimal plugin (that does nothing except be loaded) in two minutes. This allows us to contain details of a plugin to the plugin itself, and not having it leak to other parts of the product. If we want to activate/de-activate the plugin, it takes less than 10 seconds manually. Now, sometimes a plugin depends on another plugin. But they make their requests to that plugin, and fall-back to something else in case that plugin is unavailable. The amount of engineering time this has saved us is delightful. I think of all the code we did not have to write and it makes me smile. That's for containment and encapsulation at the application level. But we also follow that mode at the functionality level, too. For example, model detection and tracking is done by plugins. We like to do things and have an abstraction so that we can churn out functionality for similar things "industrially", without thinking too much, but also so we could remove things easily without breaking the rest. Making code not just easy to add, but easy to remove is important. When we did that, we were able to remove a lot of code, too. It is a spectrum, and we started by using it to contain at the "app" level.

akhilcacharya 6y ago

It seems like code quality was a big factor in the delay of Source 2 and future Valve games as well. At what point do you cut and run from legacy? The end result is pretty fantastic, but it was expected 5 or 6 years ago.

wccrawford 6y ago

"Also, if you touched the renderer, even in a simple way, and a team later encountered a rendering bug, you would be blamed and have to fix it. Even if the bug had nothing to do with your change. This taught programmers to not change anything unless absolutely necessary." I've seen this effect in code that wasn't nearly this bad, and I've even felt this way... But in the end, I've decided to do it anyhow. The end result was that I became the guy that could fix anything (in other people's minds, anyhow) and my job was actually more secure than if I'd followed the path of least resistance. Had these devs followed the hard path, too, I think it would have helped get things cleaned up, instead of continuing to pollute everything even worse. Sometimes developing is hard, and you just can't shy away from the hard parts. It just makes everything else harder.

mam2 6y ago
No unit test ?
- flohofwoe 6y ago
  The Source engine hails from the 90s, testing hadn't been invented back then ;) But on a more serious note, writing automated tests for game engines involves a lot more than just "duh, unit tests" (especially when testability wasn't a concern in the original design).
  - matsemann 6y ago
    Game code can be hard to unit test, it needs integration tests on actual hardware. Lots of weird stuff on all chips that need to be taken care of.
    - daemin 6y ago
      Yep, lots of interaction tests that can be quite brittle and can take a long time to run, even with a farm of servers and consoles. A lot of small and low level stuff can be unit tested but during production things like writing good tests falls through the cracks.

dx87 6y ago

Doesn't suprise me. I was watching a video where they had devs watch a speedrun for HL:2, and they said that there are a ton of hacky fixes that never got properly fixed. They said that same code is now in HL:Alyx, and that it's funny looking through the code for a modern AAA game and seeing comments like "Quick hack to get demo stable for E3 2005. Add permanent fix after show".

daemin 6y ago
Yep, that happens all the time. Some quick fix is added before a trade show and 2-3 years later it's still there and going into the release. The reasons vary but it's usually one or more of: people forgot, issue was created but was never important enough to get worked on, the fix works fine and the comment should be removed, the code path is no longer executed.
bogwog 6y ago
Professional game development seems to revolve around the art of quick hacks. Gamers aren't going to care whether your code is clean or not, and they sure as hell won't want to wait for you to tidy it up.
- Cthulhu_ 6y ago
  But the weird thing here is that Source is based on GoldSrc which was based on Quake; apparently, instead of learning from years of experience and building a brand new engine without the baggage, they decided to just keep building on top of the old stuff? I mean to a point I get it, but if some code is unmaintainable, you don't keep trying to fix it, you have to decide to replace it. Valve has no excuse, they make crazy amounts of money, they can fund the development of a new engine from scratch easily. They just choose not to.
  - gameswithgo 6y ago
    Quake is full of hacks and bug too.
  - eertami 6y ago

laurentdc 6y ago

I still don't get why they can't make a basic anticheat or protect the process memory like most other games (even the Faceit AC client itself for CS:GO!). Is there some explanation like keeping compatibility with very low end PCs? You can get wallhacks in multiplayer by simply using WriteProcessMemory calls. [0] [0] https://github.com/Snaacky/Diamond/blob/master/diamond.py https://github.com/Snaacky/Diamond/blob/master/diamond.py

mschuster91 6y ago
When the code is chaotic enough it may be impossible to write an anti-cheat that can't be guaranteed to not trip from ordinary in-game code.
meibo 6y ago
To be even remotely safe from this, you need to use a kernel driver, which is invasive and widely seen as unacceptable - at the moment anyhow. See Riot and Valorant from earlier this year. There was a lot of outcry and the response from the devs was basically "we don't give a damn". Other games, for example, scan window titles or signature for a variety of debuggers/hacking tools like IDA and x64dbg. There's many techniques and variations you can apply to make things like this more "annoying" - but never impossible. Earlier this year, there was a PCI card PoC that would read memory and act as an "undetectable" wallhack - people are clearly crafty enough to always find their way around.
- tester34 6y ago
  >There was a lot of outcry and the response from the devs was basically "we don't give a damn". Because "we" gamers tend to prefer to have fair game Playing against cheaters destroys fun and the games itself. It's hard trade off, but your average gamer would rather to play fair game.
  - meibo 6y ago
    I don't think you can attribute this universally to "gamers" - there's a lot of games that don't have obvious hacking problems by employing various other measures which aren't as invasive. I'd call myself a "gamer" and would never install something like Valorant - and most of my friends didn't either. Some of us value our privacy more than getting rid of the one hacker we get per week.

est31 6y ago

TBH this issue exists in many larger codebases that don't take separations of concerns seriously. Solution: take it seriously. That's harder than it sounds and depending on the problem domain is next to impossible, you should still try it.

Matthias247 6y ago
Absolutely true, the issue exists in many code-bases and organizations. And even trying to keep things decoupled will only help so much. A 10+ year old codebase which is mostly driven by new feature development will very often have accumulated so much cruft and workarounds that trying to make and further modifications is rather likely to break something else.

02020202 6y ago

this is yet another issue for programmers but not for the business. the product is seen as a black box by the business and if it gets expected output for provided input, it does not matter what is going on inside of it. it makes money and in the end that is the only thing that truly matters. of course programmers will keep on complaining but in the end, it does not matter. if it works, don't fix it. doing rewrites brings nothing to the business, only to the developers. sure, the rewrite will save dev hours along the way but the rewrite itself is not free so all in all...if it works... btw this is also why language design of composition instead of inheritance is so important for big projects. you will learn this way way too late if you do not get it already.

stefan_ 6y ago

Hence why game engines are now their whole own business, and before that time, people used to just start fresh with every game, maybe having a drawer of useful snippets. Crunch time is fundamentally incompatible with the discipline needed to not end up in this place.

tester34 6y ago
I don't think it's only cuz of lack of discipline I think sometimes in project this complex you (nor anyone) have no idea where some code SHOULD be and inserting it in "wrong" place causes weird things later
deleted 6y ago
[deleted]
0x445442 6y ago
> Crunch time is fundamentally incompatible with the discipline needed to not end up in this place. The hubris of trying to circumvent the law of fast, good, cheap; pick two.

robmsmt 6y ago

https://youtu.be/LmRl0D-RkPU?t=2480 https://youtu.be/LmRl0D-RkPU?t=2480

robmsmt 6y ago
I meant to say that these comments from Bob Martin remind me of testing and proper architecture for the code

offtop5 6y ago

Could a big part of the problem be just how old the engine is ? I assume many if not all the original devs have left.

Scuds 6y ago

richgel999 has posted before about Valve's toxic culture - so bikeshedding about "well why don't you just... " is beside the point in the larger context of perverse incentives. https://twitter.com/richgel999/status/1330765701037101057?s=20 https://twitter.com/richgel999/status/1330765701037101057?s=...

an_opabinia 6y ago
It's a refreshing perspective. It is still not that much of a knock on Valve - after all, they hired him, seems like they made the right choice, he is really articulate, voted with his feet, etc. etc. It actually makes him and Valve look pretty good, especially since it's such engineering and strategy focused and honest criticism, and none of it concerns illegal stuff either, like retribution.

XCSme 6y ago

Offtopic: I was checking his bio: "Entrepreneur at Binomial, open source dev. Previously SpaceX, Valve, and Ensemble Studios/Microsoft. SIBO survivor. From New Jersey. Opinions my own. He/him." At the end wrote "He/him". Anyone knows what does this mean and what is this trend? Is this to clearly state your gender and how you identify yourself?

d0100 6y ago
Signaling that he agrees and supports people chosing their preferred pronouns. Maybe even supports compelled pronoun use.
eznzt 6y ago
https://en.wikipedia.org/wiki/Virtue_signalling https://en.wikipedia.org/wiki/Virtue_signalling In this case, it is a way of saying "I lean left".
- keeganpoppen 6y ago
  if we’re being pithy, i feel like signaling “i’m woke” would be more apt.
tw102 6y ago
there are plenty of people who, e.g. - don't want to show their face on the internet - people whose appearance is ambiguously gendered - people who are not the gender that people assume from pictures of them - people who used to be addressed as a different gender and, when addressed, want to be referred to correctly. for instance, i'll never show my face on the internet, but i like it better when someone says "_he_ wrote that program" rather than "_she_ wrote that program." for all those people, it makes sense to put their pronouns in their bio. but that leaves the problem: if only the people in the above categories put pronouns in their bio, and you have pronouns in your bio, that might imply you are, for instance, ambiguously gendered. so people who are conventionally masculine like Rich put pronouns in their bio to normalize it, and to make sure that "having pronouns in one's bio" is not a "thing only OTHER people do". i think it's a good thing to do. i'll do it too.

andrewmcwatters 6y ago

The renderer in Source is one of the places I don’t have a great understanding of. Quake’s is fairly straightforward, but the shader system Source has complicates understanding a lot more than if you had licensee access. The way they talk to entities to handoff determining visibility is fantastic, and there are a number of other small design details that make the engine very pleasant to work with as a modder or game developer—but there are some things that are rather hard as an engine developer working with Source, or black boxes because no one has public information of how particular systems work anymore. Even internally at Valve they’ve broken particular portions of Source and the Half-Life codebases because they don’t understand how particular interfaces work anymore, but some older members of the hlcoders community still do.