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

81–90 of 129 posts

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

#81

Post by echlebek »

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

This is an implementation of the "ports & adapters" or "hexagonal architecture" pattern. Seems like you may have independently discovered it. :)

https://en.wikipedia.org/wiki/Hexagonal_architecture_(softwa...

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

#82

Post by tschwimmer »

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…

There was backlash about Riot's Vanguard but I feel it was mostly driven by the gaming media as the vast majority of consumers don't understand the nuance of userspace vs kernelspace.

I'd expect more developers begin to deploy kernel-level anticheat in the future.

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

#83

Post by Ekaros »

Cthulhu_ wrote: post #21
bogwog wrote: post #16

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

I think it's reasonable to remember that Half-Life 2 or Source goes back to days when Valve was still just a gamestudio. So they didn't have the resources they have now. Yes original Half-Life, expansions and Counter-Strike were popular, but Steam for one wasn't a thing. But they weren't printing money yet. So spending time on engine with a ambitious game wasn't something they had money or time for.

And then Global Offensive is title originally developed by third-party. So I don't think those guys either were going to put huge effort in engine. And once it got going, there is little push to replace it again. Specially when it's raking massive amounts of money in even in the state it is...

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

#84

Post by moron4hire »

matsemann wrote: post #45
flohofwoe wrote: post #41

Earlier quoted context omitted.

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.

There's also no easy way to test for things like "do the shadows render correctly".

About the only thing you can do is take before/after screenshots and compute a signal-to-noise ration on a diff between the images. Which makes for an extremely fragile test definition. What if you change the default FOV of the camera? Now all your tests fail for no good reason.

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

#85

Post by anonymousab »

exoque wrote: post #50
anonymousab wrote: post #42

Earlier quoted context omitted.

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.

IMO it's way better than dealing with intrusive and oft buggy anticheat, and there's always a chance that you'll find yourself with the rare but inevitable false positive bans that these systems give out. Moreso when they been you simply for having software they don't like on your system (e.g. autohotkey with Blizzard, reverse engineering software with many devs...)

Joining a new server from a list with filters is fast and easy.

Just as it is to find and acclimate to a server that is at your skill level and/or becomes familiar enough with you not to kick you for a hot streak.

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

#86

Post by kllrnohj »

eertami wrote: post #35
Cthulhu_ wrote: post #21

Earlier quoted context omitted.

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

> It admittedly gets a bit more difficult when these hacks and quirks are part of what create the unique feel of your game engine.

An example of this in the Quake 3 engine (and now permanent behavior in the CS series) is air strafing. It's a glitch in how Quake 3 handles motion vectors. But it's now also enshrined behavior, complete with entire game modes in CS built around it (KZ & surf maps). If you went and made an entirely new engine, or even just used something off the shelf like Unity or Unreal, you'd have to add that bug back. It's core to the gameplay now.

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

#87

Post by Arelius »

kllrnohj wrote: post #80
flohofwoe wrote: post #41

Earlier quoted context omitted.

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

Also in this case talking about the graphics stack it's not like OpenGL or DirectX are setup to be testable. You can't really "unit test" shader code, the best you can do is render it in some test scenes and screenshot the results. Which ends up flaky & noisy due to valid-per-spec differences in GPU & driver behaviors.

Every language has valid-per-spec differences. That's exactly why you test.

For sure OpenGL/DX requires more infrastructure to run unit tests than a generic block of C code. But it's absolutely possible to "unit test" shader code, with buffer read-back and/or vertex stream out, among other options. It's more the game engines themselves that aren't setup for unit tests rather than the graphics stack

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

#88

Post by kllrnohj »

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.

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.

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

#89

Post by JamesSwift »

gameswithgo wrote: post #28
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 a video like that for every game ever made.

I think anything that follows a traditional release cycle (i.e. you cut a release instead of push continuous updates to a server) has these accidentally-permanent hacks. Every mobile application I've worked on certainly has.

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

#90

Post by Jugurtha »

echlebek wrote: post #81
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,…

This is an implementation of the "ports & adapters" or "hexagonal architecture" pattern. Seems like you may have independently discovered it. :) https://en.wikipedia.org/wiki/Hexagonal_architecture_(softwa...

I was trained as an EE so control theory, feedback systems, adapters, ports, connectors, buffers and impedance matching, transfer functions all stuck with my way of approaching designing systems, including human systems/organizations.

The way I describe it as "receptors" as in neurotransmitters is because this fascinates me. Both nicotine and acetylcholine bind to nicotinic acetylcholine receptor (nAChRs). I found that to be amazing.

Post reply on HN