Hacker News Reader

> Casey, meanwhile, has worked on a low-level game development video series for a decade and... never actually shipped a game?

He worked with Jonathan Blow on "The Witness"[0].

As the developer of the "Bink 2" video codec[1] and the animation tool "Granny 3d"[2], his code powers thousands of games.

[0] https://store.steampowered.com/app/210970/The_Witness/, [1] https://www.radgametools.com/bnkmain.htm, [2] https://www.radgametools.com/granny.html

I don't think Casey has ever claimed to be the developer of Bink 2. He usually brings it up when explaining the kind of work that was performed at Rad Game Tools, then explicitly states that his work was largely on Granny 3d in particular.

"Bink [...] was written and researched by [...] mostly Fabian Giesen, Casey Muratori and Jeff Roberts.", Bink Video Credits

https://www.radgametools.com/binkhcrd.htm

> Muratori ... never actually shipped a game?

Ahh, I was just thinking about this morning.

Remember the Muratori v Uncle Bob debate? Back then the ad-hominems were flying left and right, with Muratori being the crowd favourite (a real programmer) compared to Uncle Bob (who allegedly didn't write software).

Then a few months ago Muratori gave a really interesting multi-hour talk on the history of OOP (including plenty of well-thought out criticism). I liked the talk, so I fully expected a bunch of "real programmers" to shoot that talk down as academic nonsense.

Anyway, looks like Muratori is right on schedule to graduate from programmer to non-programmer.

> the entire Unity engine set of games written in garbage-collected C#, including a freaking BAFTA winner in Outer Wilds.

Some of those games (though not all of them, unfortunately) try to work around C#'s garbage collector for performance reasons using essentially adhoc memory allocators via object pools and similar approaches. This is probably what this part...

--- And if you ever do think about these, it’s usually because you are trying to do something performance-oriented and you have to pretend you are managing your own memory. It is common for many games that have been written with garbage collected languages to try to get around the inadequacies of not being able to manage your own memory ---

...is referring to.

> Casey, meanwhile, has worked on a low-level game development video series for a decade and... never actually shipped a game?

These videos are all around 90-120 minutes long, each posted with gaps between them since the previous (my guess is whenever Casey had time) and the purpose and content of these videos is pedagogical so he spends time explaining what he does - they aren't just screencasts of someone writing code.

If you combine the videos and assuming someone works on it 6h/day with workdays alone it'd take around 8-9 months to write whatever is written there but this also ignores the amount of time spent on explanations (which is the main focus of the videos).

So it is very misleading to use the series as some sort of measure for what it'd take Casey (or anyone else, really) to make a game using "low level" development.

Unity isn't written in C#, it's C++. C# is used as the scripting engine.

Yes, of course, but the actual games are written (primarily! sometimes they will optimize something when actually necessary with a lower-level language! that's great!) in the scripting language.

The OP implies heavily that writing a program in a language with anything but pure manual memory management makes you lesser as a programmer than him: "Unfortunately, a lot of people never move past this point on their journey as a programmer" implies he has moved further on in his "journey" than those that dare to use a language with GC.

(and with respect to C++ note that OP considers RAII to be deficient in the same way as GC and ARC)

Indeed to the extent that Casey has a point here (which sure, I think in its original context it was fine, it's just unfortunate if you mistook a clever quip at a party for a life philosophy) C++ is riddled with types explicitly making this uh, choice.

Its not near the top of the list of reasons std::unordered_map is a crap type, but it's certainly on there. If we choose the capacity explicitly knowing we'll want to put no more than 8340 (key,value) pairs into Rust's HashMap we only allocate once, to make enough space for all 8340 pairs because duh, that's what capacity means. But std::unordered_map doesn't take the hint, it merely makes its internal hash table big enough, and each of the 8340 pairs is allocated separately.