7 ms·

I never made claims to be any kind of game programmer, but sure. Fine, as I recall, Doom data assets are searched linearly whenever they need to pull new data.

I never made claims to be any kind of game programmer, but sure. 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.

jodrellblank 8d ago
> "if walk monster manually trolls the map" 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 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.
tialaramex 17d ago
You probably have a point on linear search for assets (I haven't checked but I've assumed you're right about how it works in the released source) 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.

jodrellblank 8d ago

> "if walk monster manually trolls the map" 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 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.

tialaramex 17d ago

You probably have a point on linear search for assets (I haven't checked but I've assumed you're right about how it works in the released source) 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.