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

71–80 of 129 posts

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

#71

Post by daemin »

bogwog wrote: post #66
daemin wrote: post #52

Earlier quoted context omitted.

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.

The best benefit we've found for unit tests is in low level platform specific code and generic containers. Things of that nature which absolutely must work and can themselves be tested in isolation.

I'm sure when we finish the project and look back on it we can go in, clean up, and implement far more unit tests for the code we already have.

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

#72

Post by leetcrew »

arkitaip wrote: post #17
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,…

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.

you need to have someone who is very comfortable saying "no" to be in charge of maintaining the interface. otherwise, and especially if the plugin devs have access to the core code, they will say stuff like "hey, I see you have a very convenient function in the core, can you expose it for my plugin?". once you open the door to this, your encapsulation suffers death by a thousand cuts. you can end up with a de facto monolithic codebase that also has a complicated plugin interface that doesn't really encapsulate anything.

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

#74

Post by leetcrew »

bogwog wrote: post #68
areoform wrote: post #56

Earlier quoted context omitted.

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

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

this. to any readers unfamiliar with the community, it's hard to overstate how much cs players abhor change.

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

#75

Post by The_Colonel »

leetcrew wrote: post #72
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.

you need to have someone who is very comfortable saying "no" to be in charge of maintaining the interface. otherwise, and especially if the plugin devs have access to the core code, they will say stuff like "hey, I see you have a very convenient function in the core, can you expose it for my plugin?". once you open the door to this, your encapsulation suffers death by a thousand cuts. you can end up with a de facto m…

> you need to have someone who is very comfortable saying "no" to be in charge of maintaining the interface.

Of which the end result will be that the desired functionality will be somehow hacked within the plugin or will not be available at all.

Problem with such plugin based architecture is that it relies on a well designed interface. Person which designs the interface needs to have very good idea of how that interface will be used in the future, which is difficult / often impossible thing to do.

When business requirements change, you then have the difficult dilemma - just insist on "no", introduce a minimal hack, redesign interfaces to support the use case in a clean way (possibly big task) etc.

> your encapsulation suffers death by a thousand cuts. you can end up with a de facto monolithic codebase that also has a complicated plugin interface that doesn't really encapsulate anything.

Yes, worst outcome of all. In reality, plugin based architecture is no silver bullet. It can be very counter productive, especially when you're figuring out what you actually want to build, as you build it.

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

#76

Post by Matthias247 »

est31 wrote: post #12

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.

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.

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

#77

Post by [deleted] »

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.

[deleted]

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

#78

Post by leetcrew »

The_Colonel wrote: post #75
leetcrew wrote: post #72

Earlier quoted context omitted.

you need to have someone who is very comfortable saying "no" to be in charge of maintaining the interface. otherwise, and especially if the plugin devs have access to the core code, they will say stuff like "hey, I see you have a very convenient function in the core, can you expose it for my plugin?". once you open the door to this, your encapsulation suffers death by a thousand cuts. you can end up with a de facto m…

> you need to have someone who is very comfortable saying "no" to be in charge of maintaining the interface. Of which the end result will be that the desired functionality will be somehow hacked within the plugin or will not be available at all. Problem with such plugin based architecture is that it relies on a well designed interface. Person which designs the interface needs to have very good idea of how that interf…

> When business requirements change, you then have the difficult dilemma - just insist on "no", introduce a minimal hack, redesign interfaces to support the use case in a clean way (possibly big task) etc.

one thing I will add is that every new feature does not have to be a plugin just because you have a plugin interface. "implement it directly in the core" is a perfectly valid fourth choice. some things just aren't suited to a plugin implementation.

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

#79

Post by corytheboyd »

yreg wrote: post #34
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,…

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…

Fully support those who want to use these tools, just don’t forget they are not a crutch. You can still write hard to work with code and know exactly who the SME is. That doesn’t make the code less difficult to work with, less error prone to change. That can only be solved by design and enforced through discipline.

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

#80

Post by kllrnohj »

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

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.
Post reply on HN