THE LEGENDARY GAME PROGRAMMER
(to be clear, I'm a big fan of Casey)
I’m sure you can find bugs in the work of any game dev you would consider legendary, game implementation is generally very messy
The craftsmanship is dubious. I think it's a problem that people assume Casey knows what he's doing when so often he's like "We're doing it live" and Casey's hand coded solution is pretty bad whereas the thing which came in the box is very good. Casey understands Casey's version, and that's an upside if you are Casey but you are not. If the result was a finished game then hey, whatever, the game was finished and that matters. But that part didn't happen either, so then it's just like watching Tsoding or something.
His second attempt, no matter how he made it, was made with the context of his earlier mistakes.
RAII doesn't lead to spaghetti code necessarily. If anything, "unity builds" would more encourage spaghetti as it's easier to reference anything else in your build.
For video games you can get things pretty badly wrong on the technical front these days and deliver an excellent game, that's one of the things Blue Prince demonstrates really well, a lot of the guts of Blue Prince are a trash fire, but the player will not ordinarily notice so who cares? Rebecca (of Rebecca's Pixel Quest) noticed, hundreds of hours in, that if she has two of certain special items the game gets confused. That's the sort of bug a better engineer wouldn't have, but she'd been playing the game for over a year when she noticed.
They write a specific type of software that is very forgiving of bad architecture. Hell, some games are very forgiving of slow software as well.
For example, since we're talking about Muratori, The Witness does not have any of the concerns something as banal as Word has. The Witness gets to run for a single user as the sole application, without regard for anything else, and doesn't persist anything notable to the system.
There are entire universes of bugs and issues you just never even have to know exist. Hell, even Call of Duty supports multiplayer, which the Witness does not have to do.
Not to mention, sometimes your choice is between good performance or good architecture. Yes, functions cost, abstractions cost, all of this stuff costs. But some applications don't have the luxury of being replaced every Christmas. Some applications never get to "feature complete", they are living entities.
There is massive amount of knowledge in there for anyone bothering to actually learn something and it was all provided free of charge. Hats off to Casey for sticking to it as long as he did.
Fine, as I recall, Doom data assets are searched linearly whenever they need to pull new data. So if you switch to the chainsaw, and need to rev, the game does a linear scan of all graphics, maps, and sounds looking for the vroom noise.
There are many different data structures that could perform this lookup faster. These have been known since the earliest days of computing.
Does it matter? No. Engineering is all about trade-offs. A linear scan was obviously fast enough and simple to implement.
Similarly, if walk monster manually trolls the map, that does not say anything about Casey in isolation. I believe all of Blow's games use a custom game engine, so unless a nav mesh system was already implemented, that was going to take additional work. The walk monster may have been better bang-for-buck.
There are some tradeoffs here, my instinct would be to bring hash tables into play and that's perhaps a mistake because it means you're doing fewer reads but more arithmetic and on some hardware that's a bad trade. But "linear search" is only the simplest and probably not the smartest option.
Casey Muratori has a 50 minute video on "Killing the Walk Monster" which is about how they started looking for glitchy game geometry by pretending to be a player walking around, then by a flood-fill ("walk monster") probing for barriers, then the video is explaining how they designed something "exponentially faster" (both demonstrated starting at time 38:33). The better version was realtime enough that level designers could use its overlays interactively while working on the level, and during test playthroughs. He describes it as "exponentially faster". It doesn't seem like the earlier poster calling it "brute force" is a reasonable description.
https://www.youtube.com/watch?v=YE8MVNMzpbo
And the place the player can walk but shouldn't be able to (off the boat), is not a fault in the walk system, as explained in that video near the end, it's a place where level designers made a mistake.
Titles aside, his talk is really insightful and it is super interesting to do a deep dive on these old computer/programming topics as the modern concepts were being discovered
Yeah Ive been meaning to watch that talk - I love listening to pretty much anything Casey says/does. He's extremely thoughtful and fair.
Exactly!