Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ex Valve dev on CS:GO’s codebase

twitter.com

Post reply on HN
Print view View original

41–50 of 129 posts

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

#41

Post by flohofwoe »

mam2 wrote: post #14
wccrawford wrote: post #8

"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 res…

No unit test ?

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

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

#42

Post by anonymousab »

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

Presumably, server sdmins, mods or players can votekick players who they think are cheating. If a player is cheating such that they are indistinguishable from another good player, then that's kind of mission accomplished and doesn't really matter if they stay.

This general philosophy has been around in all CS games and has worked well IMO. Just gotta find an applicably well maintained server to play on first.

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

#43

Post by chompychop »

Jugurtha wrote: post #4

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

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.

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

#44

Post by haunter »

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.

.

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

#45

Post by matsemann »

flohofwoe wrote: post #41
mam2 wrote: post #14

Earlier quoted context omitted.

No unit test ?

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

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.

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

#46

Post by ownagefool »

Cthulhu_ wrote: post #18
Jugurtha wrote: post #4

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

Definitely; the biggest challenge in software development is keeping things manageable. I think this is why microservices are so popular; the individual services are manageable. But that's a misconception, because the overall architecture becomes a monstrosity, especially if there is no oversight (which in my experiences with the pattern, there wasn't).

I think microservices are and aren't an overreaction.

If you think of microservices as contract enforcement, it should be harder to produce unintended consequences on the macro level, because everything should flow through the api. (assuming you don't have something weird like several microservices manipulating the same data sources directly), so architecturally it's easier to understand code/data flows than the same monolith system that hasn't properly enforced modularity.

The main problem is most folks rushing head first into the silver bullet don't understand is things have trade off, and in microservice land it's versioning, testing, deploying, and monitoring.

Nowadays, though the tooling is pretty good, and if you put your microservices in a monorepo (seems backwards, I know) you can avoid the versioning, testing and deployment difficulties, and use GKE + istio and you've got tooling to help handle the ops problems, so actually, maybe enforcing code quality is actually the harder problem, and limiting the size and scope does sorta make sense.

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

#47

Post by dx87 »

laurentdc wrote: post #27
exoque wrote: post #24

Earlier quoted context omitted.

Won't this hack be caught by VAC? And if not, what is VAC actually doing?

It's not caught by VAC. I changed the glow colour (which probably changed the signature), tested it a few months ago on local server and then played some Valve deathmatch on official servers, account is still good. I'd expect the game to at least throw me out of the server if I tamper with what objects should light up, but nope.

They do bans in waves to try and keep people from knowing what cheat/hack they used that got them banned. VAC might not have caught you, or you might get banned in one of the waves where they ban thousands of people all at once.

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

#48

Post by dx87 »

haunter wrote: post #44
dx87 wrote: post #6

Earlier quoted context omitted.

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.

.

> not all of their games have been ported to it

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

#50

Post by exoque »

anonymousab wrote: post #42
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

Presumably, server sdmins, mods or players can votekick players who they think are cheating. If a player is cheating such that they are indistinguishable from another good player, then that's kind of mission accomplished and doesn't really matter if they stay. This general philosophy has been around in all CS games and has worked well IMO. Just gotta find an applicably well maintained server to play on first.

Getting kicked (and sometimes even banned) from such a server just because you're playing well one day isn't much fun.
Post reply on HN