Ex Valve dev on CS:GO’s codebase • Hacker News Board

Re: Ex Valve dev on CS:GO’s codebase

#61

Post by yreg » Mon, Nov 23, 2020, 3:03 PM UTC

daemin wrote: post #55

yreg wrote: post #34

Earlier quoted context omitted.

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…

That kind of looks useful, would be nice if it handled Perforce and could be installed on private servers. Don't think the company would want to release all the code publicly.

Are you sure it couldn't be installed locally?

My client is a bank with private GitHub servers, so I assume their codescene is self hosted as well.

edit: Yep, there is an on-premise option: https://codescene.com/pricing/

Re: Ex Valve dev on CS:GO’s codebase

#62

Post by silicon2401 » Mon, Nov 23, 2020, 3:05 PM UTC

meibo wrote: post #23

laurentdc wrote: post #11

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

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…

Is there a way to check what games/platforms install kernel drivers? I recently installed trackmania and after jumping through what felt like 10 hoops just to play the game (log in to epic, download epic games store, log into ubisoft, etc etc), I realized I have idea how much stuff is being installed on my pc after all these steps.

Re: Ex Valve dev on CS:GO’s codebase

#63

Post by chompychop » Mon, Nov 23, 2020, 3:13 PM UTC

Jugurtha wrote: post #54

chompychop wrote: post #43

Earlier quoted context omitted.

Could you point me to any open source projects/references you've used for your platform that showcases this plugin architecture? I'm a junior developer and I'd really like to learn and incorporate this in my projects.

Sure, here you go. That'll get you started. We didn't adopt any of that or a specific solution/library/way, but they were good resources to think about the matter. That's from our internal wiki, and "Plugin Architecture" was the first entry in that, just to tell you about how important it was. Also, given that you describe yourself as a "junior developer", here's a reply to an Ask HN about "How to become a senior dev…

Thanks a lot for taking the time to list these resources (in this post as well as in the other Ask HN post)! This is really helpful for beginners like me. :)

Re: Ex Valve dev on CS:GO’s codebase

#64

Post by tester34 » Mon, Nov 23, 2020, 3:14 PM UTC

meibo wrote: post #40

tester34 wrote: post #36

Earlier quoted context omitted.

>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.

>Some of us value our privacy more than getting rid of the one hacker we get per week.

oh c'mon.

It's heavily dependent on the game.

There's different % of cheaters in CS, in LoL, in Tibia and a lot of other games.

e.g there isn't a lot of cheaters in LoL because (besides other) cheats do not have as huge impact there as in other games like shooters.

On the other hand cheats in Tibia are just bots that exp for people whole days (in majority of the cases; at least before BattleEye).

>Some of us value our privacy

Installing and running giant program which can do shitton of crazy things under the hood already says that I trust enough that vendor.

Unfortunely their soft does not need kernel level permissions in order to be dangerous to my privacy, so what's the exactly difference?

All they have to do in order to compromise my privacy would be just sending screen shoots to the cloud that I'm writting snarky comments on HN.

Re: Ex Valve dev on CS:GO’s codebase

#65

Post by Bjartr » Mon, Nov 23, 2020, 3:14 PM UTC

dx87 wrote: post #9

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".

There is nothing more permanent than a temporary solution.

Re: Ex Valve dev on CS:GO’s codebase

#66

Post by bogwog » Mon, Nov 23, 2020, 3:15 PM UTC

daemin wrote: post #52

matsemann wrote: post #45

Earlier quoted context omitted.

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.

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.

And game development usually involves a lot of iteration, so setting up tests is at best a waste of time, and at worst a crutch that hurts productivity.

Re: Ex Valve dev on CS:GO’s codebase

#67

Post by mepian » Mon, Nov 23, 2020, 3:15 PM UTC

dx87 wrote: post #6

josefresco wrote: post #2

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.

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.

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.

Re: Ex Valve dev on CS:GO’s codebase

#68

Post by bogwog » Mon, Nov 23, 2020, 3:26 PM UTC

areoform wrote: post #56

eertami wrote: post #35

Earlier quoted context omitted.

>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, eve…

> 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 That is surprising. I had assumed that CS:GO was an incredibly steady cash cow. IIRC, CS:GO pioneered the digital collectibles + loot box market, and has somewhere between 600k to 1.1M+ active players during any given day. https://steamcharts.com/app/730 The trading market also seems particula…

The guy who wrote the tweet in the OP regularly posts publicly about the internal structure and politics at Valve. Reading through that gives me the impression that money is never a factor at Valve, and it's all about 1) whether anyone cares enough to work on a project and/or 2) whether someone is trying to impress/kiss-ass to climb the social pyramid.

I can't imagine the idea of rewriting CS:GO from scratch just to improve maintainability is going to get very far.

Plus players will 100% notice even the tiniest changes, and will complain about it forever. A game like CS:GO will never die, just look at the player numbers for its predecessor which has 6000-7000 daily active players.

Re: Ex Valve dev on CS:GO’s codebase

#69

Post by marktangotango » Mon, Nov 23, 2020, 4:51 PM UTC

Jugurtha wrote: post #37

arkitaip wrote: post #17

Earlier quoted context omitted.

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…

That’s a rosy picture, but I’d point out that atrocities such as Eclipse Rich Client platform and associated OSGi specs are where this plugin concept can lead and it has its own problems! Complexity and discoverability are two!

Re: Ex Valve dev on CS:GO’s codebase

#70

Post by Jugurtha » Mon, Nov 23, 2020, 5:03 PM UTC

marktangotango wrote: post #69

Jugurtha wrote: post #37

Earlier quoted context omitted.

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…

That’s a rosy picture, but I’d point out that atrocities such as Eclipse Rich Client platform and associated OSGi specs are where this plugin concept can lead and it has its own problems! Complexity and discoverability are two!

It's not a panacea, but as a guiding thought it has served us well. We don't go all in on things "just because", and we develop what we need as opposed to what we imagine we need, and stop at an abstraction level that gets the job done.