https://youtu.be/LmRl0D-RkPU?t=2480
I meant to say that these comments from Bob Martin remind me of testing and proper architecture for the code
Ex Valve dev on CS:GO’s codebase
31–40 of 129 posts
Re: Ex Valve dev on CS:GO’s codebase
#32I 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
They do, it's called VAC, this repo even says you will get banned using this.
[deleted]
Re: Ex Valve dev on CS:GO’s codebase
#33Hence 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.
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
Re: Ex Valve dev on CS:GO’s codebase
#34One 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,…
A way to tackle this further is to use an analytics tool like CodeScene. You link it with your repo and it shows you what people have knowledge across which parts of code[0].
Then you can identify parts that share too few contributors and encourage people to work on them together. You might also find parts where the knowledge is already lost, since everyone who worked on it already left the company. In that case some team can volunteer to take ownership of the code and take time to make some sense of it.
Of course, easier said than done.
[0] https://codescene.io/projects/167/jobs/55946/results/social/...
Re: Ex Valve dev on CS:GO’s codebase
#35Earlier quoted context omitted.
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.
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 cr…
>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.
It admittedly gets a bit more difficult when these hacks and quirks are part of what create the unique feel of your game engine. People have played CS at such high levels for so long that switching engine at all is likely going to introduce some difference in feeling, even if you think you've accounted for all the unique bugs and interactions. If you remade Quake 3 in a new engine, people are going to hate it. See Quake 4, for example.
Source 2 would still be a nice jump for CS:GO, but the team just doesn't have the resources at present to get this all done. Dota 2, being the style of game that it is, isn't as affected by a difference in feel as a first person twitch shooter.
Re: Ex Valve dev on CS:GO’s codebase
#36I 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
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 tec…
>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.
Re: Ex Valve dev on CS:GO’s codebase
#37One 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,…
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.
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.
Re: Ex Valve dev on CS:GO’s codebase
#38Hence 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.
[deleted]
Re: Ex Valve dev on CS:GO’s codebase
#39Hence 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.
> 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.
Re: Ex Valve dev on CS:GO’s codebase
#40Earlier quoted context omitted.
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 tec…
>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.
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.