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

51–60 of 129 posts

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

#51

Post by CraigJPerry »

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 has been my experience too - not in ML (i have zero experience there) but in software architecture more generally. The idea of locality of change, of encapsulation, of interfaces as a way to reduce the amount of stuff you need to know in order to change the system. It is a pretty effective strategy for keeping the "cost to change" a software product low.

There have been downfalls for me though - interestingly never the obvious problem. To me the obvious problem is performance, there's usually an overhead in a plugin system of some sort but it hasn't been an issue for me yet, maybe i'm just lucky.

An annoying real issue has been adding in dependencies between plugins, that has always introduced horrible issues later on. I think based on my current life experiences i'd even choose to duplicate functionality over introducing dependencies now - despite the fact that idea is basically anethema to conventional wisdom.

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

#52

Post by daemin »

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.

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.

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

#53

Post by tetraca »

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.

If I remember right, VAC doesn't necessarily immediately ban a cheater. It might instead put them on a list. After the hack's popularity increases, there is a mass ban of everyone detected using the hack at a later date.

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

#54

Post by Jugurtha »

chompychop wrote: post #43
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.

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

https://news.ycombinator.com/item?id=25025253

Plugin Architecture:

Dynamic Code Patterns: Extending Your Application with Plugins - Doug Hellmann

Link: https://www.youtube.com/watch?v=7K72DPDOhWo

Description: Doug Hellmann talks about Stevedore, a library that provides classes for implementing common patterns for using dynamically loaded extensions

PluginBase - Armin Ronacher:

Link: http://pluginbase.pocoo.org/

Description: Armin Ronacher is the creator of Flask, Jinja, and a bunch of other stuff.

Miscellaneous links on plugin systems:

https://developer.wordpress.org/plugins

https://techsini.com/5-best-wordpress-plugin-frameworks/

https://eli.thegreenplace.net/2012/08/07/fundamental-concept...

https://pyvideo.org/pycon-us-2013/dynamic-code-patterns-exte...

https://en.wikipedia.org/wiki/Hooking

http://chateau-logic.com/content/designing-plugin-architectu...

https://www.odoo.com/documentation/user/11.0/odoo_sh/getting...

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

#55

Post by daemin »

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…

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.

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

#56

Post by areoform »

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…

> 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 particularly active and Valve takes a cut of each transaction of their digital goods. It's an attractive model. There are dedicated companies that have sprung up around it and seem to prosper.

Other indirect indicators seem to be green as well. Back when it was a phenomenon, it sold at least 25M+ units before it was made free-to-play. This is on par with Minecraft. The installed player base is in the hundreds of millions. It's essentially a giant social network with multiple monetization opportunities.

I am struggling to see how this wouldn't be profitable.

Surely, Valve must make enough in a month to hire 50+ people and give them 18 to 24 months to re-write the engine?

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

#57

Post by [deleted] »

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.

[deleted]

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

#58

Post by arkitaip »

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…

Thank you, I appreciate the detailed answer.

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

#59

Post by toyg »

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…

> instead of [...] building a brand new engine without the baggage

Time to bring up this classic post: https://www.joelonsoftware.com/2000/04/06/things-you-should-...

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

#60

Post by Jugurtha »

CraigJPerry wrote: post #51
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 has been my experience too - not in ML (i have zero experience there) but in software architecture more generally. The idea of locality of change, of encapsulation, of interfaces as a way to reduce the amount of stuff you need to know in order to change the system. It is a pretty effective strategy for keeping the "cost to change" a software product low. There have been downfalls for me though - interestingly ne…

>The idea of locality of change, of encapsulation, of interfaces as a way to reduce the amount of stuff you need to know in order to change the system. It is a pretty effective strategy for keeping the "cost to change" a software product low.

Yes, not only keeping the cost of change low, but unlocking potential in a way that seems prescient but is just common sense. I like to think about this in terms of "unit of thought", "protocols, interfaces, specs", "impedance matching" to maximize power transfer, unknown future consumers.

Doing that adaptation upstream prevents people writing adapters downstream. It may be adding a "REST" API so that consumers you may ignore can work with that. It may be using Cloudevents spec for your events to make it easier for people to work with that. It may be making sure the output of your system is a Docker image to make it easier to use that elsewhere for a user, whether that may be a human or something else.

Systems that produce known/standardized/understood building blocks unlock a lot of potential and avoid downstream work.

Post reply on HN