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

121–129 of 129 posts

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

#121

Post by nephrenka »

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.

Yes, there's an on-prem version of CodeScene that can be run on private servers. The latest release is described here: https://codescene.com/blog/architectural-analyses-simplified...

To analyse Perforce, you setup an automated conversion to a read-only Git repo that you then point the analysis to.

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

#122

Post by nephrenka »

corytheboyd wrote: post #79
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…

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.

Fully agree! That's why I recommend to monitor the code health trends continuously -- the earlier we can catch any potential issues, the better: https://codescene.io/projects/167/jobs/55946/results/warning...

We have these code health trends supervised as part of our pull requests and use them as (soft) quality gates. [1]

[1] https://codescene.com/blog/measure-code-health-of-your-codeb...

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

#123

Post by slavik81 »

rng_civ wrote: post #120
jrockway wrote: post #99

Earlier quoted context omitted.

I am surprised that game engines aren't set up to test simple scenarios programmatically. I play a lot of Overwatch and the bugs / patch notes about fixing those bugs amaze me every time; they tell me a lot about how the software is designed and tested. There was one bug where a character has a deployable ability that doubles the damage and healing of all projectiles that pass through it. One day, the patch notes rea…

The only game I'm aware of with an extensive automated testing infrastructure is Minecraft: https://youtu.be/vXaWOJTCYNg?t=993

Riot has written about their League of Legends test infrastructure https://technology.riotgames.com/news/automated-testing-leag...

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

#124

Post by mercer »

Tehdasi wrote: post #106
kllrnohj wrote: post #86

Earlier quoted context omitted.

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

To add to the list of 'bugs that are now features', in SF2 'combos' were a bug, they were not intended to be part of gameplay. Their inclusion is arguably the basis of the 1v1 fighter genre.

That sounds interesting. could you tell more about that, or point me to a good article/video about it?

I never got into 1v1 fighters myself, but they were a big part of my childhood.

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

#125

Post by jrockway »

slavik81 wrote: post #123
rng_civ wrote: post #120

Earlier quoted context omitted.

The only game I'm aware of with an extensive automated testing infrastructure is Minecraft: https://youtu.be/vXaWOJTCYNg?t=993

Riot has written about their League of Legends test infrastructure https://technology.riotgames.com/news/automated-testing-leag...

Interesting! That looks exactly like the test I wanted to write.

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

#126

Post by XCSme »

nawgz wrote: post #115
XCSme wrote: post #104

Earlier quoted context omitted.

> It admittedly gets a bit more difficult when these hacks and quirks are part of what create the unique feel of your game engine Oh, the memories! I was so upset when bunny-hoping was mostly removed when CS:GO was released. I played the HNS (hide-n-seek) mode in CS 1.6 more than the normal game-mode. Most of the HNS mechanics were based on game bugs: bunny-hopping, long-jump (sync mouse movement with player movement…

CSGO still has bhops, longjumps, surfing, and jumpbug; I think jumpbug is harder and I'm not sure about edgebug. Was there really such reliance on jumpbug and edgebug in this game mode?

I am not sure this was always the case with CS:GO.

I know there are servers now that have those type of modes, but I think they have to use some custom server parameters for the physics to make it work more like it used to do.

I remember when I first tried CS:GO coming from 1.6 when it came out, there were no HNS servers as the default physics model really didn't allow for bhops and longjumps the way it used to work. Or maybe, even if somehow it still allowed for those things, the mechanical difference was too big so it didn't feel the same.

In the end I "just" played like 1000 hours in CS:GO and quit the game as there was no real HNS replacement as it used to be. I still played the normal mode for 1k hours as there were a few very nice 24vs24 servers were everyone was using microphone and try-harding.

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

#127

Post by XCSme »

nawgz wrote: post #115
XCSme wrote: post #104

Earlier quoted context omitted.

> It admittedly gets a bit more difficult when these hacks and quirks are part of what create the unique feel of your game engine Oh, the memories! I was so upset when bunny-hoping was mostly removed when CS:GO was released. I played the HNS (hide-n-seek) mode in CS 1.6 more than the normal game-mode. Most of the HNS mechanics were based on game bugs: bunny-hopping, long-jump (sync mouse movement with player movement…

CSGO still has bhops, longjumps, surfing, and jumpbug; I think jumpbug is harder and I'm not sure about edgebug. Was there really such reliance on jumpbug and edgebug in this game mode?

For example, I found this question from 6 years ago: https://www.reddit.com/r/GlobalOffensive/comments/276pvz/can...

So apparently not only bhoping is harder (jumping window much smaller), the default speed is also capped at a very low value (300), where in 1.6 it was uncapped and you could have easily reached 400-500 speeds while bhoping.

Another related thread: https://www.hltv.org/forums/threads/1169582/16-movement

So, although changes are not clear, all of those who did play HNS before agree that mechanics are different and it just doesn't feel the same, you don't have the same freedom, it feels a lot more sluggish.

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

#128

Post by andrewmcwatters »

The renderer in Source is one of the places I don’t have a great understanding of. Quake’s is fairly straightforward, but the shader system Source has complicates understanding a lot more than if you had licensee access.

The way they talk to entities to handoff determining visibility is fantastic, and there are a number of other small design details that make the engine very pleasant to work with as a modder or game developer—but there are some things that are rather hard as an engine developer working with Source, or black boxes because no one has public information of how particular systems work anymore.

Even internally at Valve they’ve broken particular portions of Source and the Half-Life codebases because they don’t understand how particular interfaces work anymore, but some older members of the hlcoders community still do.

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

#129

Post by Arelius »

kllrnohj wrote: post #91
Arelius wrote: post #87

Earlier quoted context omitted.

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

> 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. Which is what I said, you can screenshot & compare. But it becomes a fuzzy compare due to acceptable precision differences. And it ends up being more of an integration test and not a unit test.…

> Which is what I said, you can screenshot & compare. But it becomes a fuzzy compare due to acceptable precision differences

You make it sound rigorous than it can be. A readback doesn't need to be a "screenshot" and doesn't need to be of a full scene. A frame buffer can be a 1x1 value.

Regarding precision differences, it's not much different than testing floating point math anywhere else. Shaders allow fast-math style optimizations generally, but they can be disabled at least on some platforms[1][2], otherwise one can take care in floating point math, or provide tests just using integer math.

> And it ends up being more of an integration test and not a unit test.

Sure, if you just setup scenes, render, screenshot and do a fuzzy compare, that looks more like an integration test. And I agree it's more common to see integration tests for renderers. But really, it's a bit more involved in that you have to deal with uploads, command queues, readbacks, but you really can setup the infrastructure to do proper unit tests, and then you can decide how you want to handle unit testing of flexible precision code, either toggling precision in the compilers, or building your tests to properly bound your expected precision, or both.

> GPU shaders are completely different. Numbers do not have consistent behavior across differing hardware & drivers.

This is an outdated and simply not true view, every modern (PC-Spec?) GPU hardware has IEEE754 compliant floats. They have to, otherwise GPGPU wouldn't have taken off in scientific computing. compiler defaults may just not be right.

[1] https://github.com/Microsoft/DirectXShaderCompiler/blob/mast... [2] See: #pragma optionNV(fastmath off)

Post reply on HN