that video on mario 64 invisible walls is incredibly impressive but also I feel like the sheer amount of "for some reason"s and "this game is soooo glitchy and buggy" comments in the video are going to do a lot of work disguising the fact that every single one of these optimizations are probably the only reason ANY of that shit runs on the n64 hardware to begin with
experienced gamedevs didn't take these shortcuts for fun, they likely were under signifiant time pressure, under a shifting technical landscape, and trying to optimize for complex collision on a processor whose clock speed is significantly outdone by any post-2007 graphing calculator
the fact that by and large ONLY speedrunners see these issues is frankly a real testament to how well they did
I particularly want to call out the final topic of the video, which is that ground height-sorting in mario 64 is handled by comparing the height of each object's first vertex (in order, which is arbitrary) - which means that in some cases objects can be sorted lower than they should be due to ties or awkward first-vert placement.
I 1000% guarantee you this was a late-in-development optimization addition. They were almost certainly doing some sort of more complex detection and it was eating up too much frame time and so they redesigned it with the two principles that cause the bug in question, which is:
- only compare two vertices' world locations, total, a single math operation
- then abort as soon as the check is successful and don't check any other collision anymore
This smells very strongly of frantic optimization. "what platform is below mario" is a check that has to run every frame and it's almost certain that on maps like Tick Tock Clock there are situations where probably 7-10 possible valid ground planes can be underneath mario at any given time. During dev, not knowing the N64's final specs, you set it up to just be a thorough check that compares every possible landing spot, and suddenly you're a month from release and the game needs to ship in time to be a launch title and mario's ground collision check is taking like 400 ms, your manager is like "just make it run! we'll test for any bugs where the vertices cause weird collision" so you do that and you catch and adjust for anything you notice, and the minor remaining ones get left out.
It's extremely telling, IMO, that ALL the places this bug is an issue are minor props and weird unusual collision cases that are very hard to notice in normal play. There were probably way more at first and then they went through and fixed every reported one by hand. "why didn't they just build a tool" you might think, but they were almost certainly working under significant time constraints and sometimes you just say "good enough" and throw testers at it and then move on to the next bug and the next optimization. This is quintessential game development, and not a bit of it lazy. Shit's hard and time is a real thing.
Super Mario 64 as you see it here is about 50% complete but only 20% mapped out. We have worked on this game for a year and a half, but design work on the game concept began a year before that. During that time, we shared ideas with the hardware design people.
Hardware technology is very important, but if we rely too much on the hardware and not enough on ideas, you won't make games. You'll have demonstration software. New technology can make things more interesting. For example, the Nintendo 64 can produce advanced images, but if that's all we emphasize, the game will be boring. The problem we face is how to use advanced technology to enhance gameplay. The technology is just a tool for the expression [...]
the game just barely ran within the confines of what was possible in mid-90s technology, because their primary priority was making a fun platformer game in 3D, which was at the time a brand-new concept - and trying to make the hardware catch up to their vision, and only optimizing because they were ultimately constrained by reality.



This is basically exactly the sentiment I was going to express