Tanuki-loving Tanuki Shill

Agreed. Learning how they were doing collision checks for terrain combined with the fact that I genuinely can't remember ever encountering issues with it as a child blew my mind. I really don't love how speedrunners talk about games on a technical level.

have you seen any of the videos from the guy doing the big speedup romhack? kaze emanuar, i think. he's very much on team "look they were doing the best they could as some of the first programmers on this system, and with 30 more years of knowledge of that hardware, that's why i can do this" in a lot of his videos on the subject, and it's incredibly refreshing

Yeah, I felt that especially when he was kind of talking shit about "copy and pasting" stuff. Like, why would you design and model four different individual stone platforms or whatever when you can just make one and put it in a few different places?

I /love/ seeing games broken open by speed running, like Mario 64 or Ocarina of time, but the fact that people will call them "Hella buggy" "glitchy" ect even though 99% of the tricks used would never be encountered by a regular player always bugs me.

I speedrunr Virtual Hydlide at the 'highest level' and I've tried to move away from a model of talking about it like the devs were idiots and fools and blah blah blah. Like, yeah, the framerate is terrible, and it's pretty obvious why, but under constraints, reusing a 3D engine you already have working is not completely silly... except it was a golf engine. sucks air through teeth

honestly, I think they weren't even aware of the case of these floor/wall/ceiling leaks and misalignments - and probably encountered "invisible walls" themselves, but chalked it up to incredibly rare floating point glitches (which is sort of true) and didn't have time to investigate.
had they known that they even existed, they'd have probably had tooling to prevent it.

as it stands, the way they implemented physical/interactible world surfaces is honestly clever and maybe not the best way to do it, but the best way they knew how to for sure, considering they likely invented that technique from first principles.

it reminds me of ppl talking about gen 1 pokemon where its like, "the fact that all of these glitches Do This is actually a testament to how hard it is to just crash pokemon" where its like, the parallel universes from the classic pannenkoek video is like, "its so cool that the game loads in a fake version of the level instead of going "you are in a place that doesnt make sense im going to crash now"

honestly I've started closing videos when the person making them gets all negative about an old-ass game with optimizations they couldn't even dream of

like, okay bro let's see your ass go back to the 90s and write good games within the limitations of the n64. I'll wait

And this was a launch game! They weren't even totally familiar with the hardware yet, and were probably developing the game on constantly-shifting hardware over the course of development.

Also something reeeaallly worth observing is that it takes an INCREDIBLE amount of what looks like special-casing if you just write out the algorithm to make physical game mechanics feel "natural".

discovers a glitch 2 decades after a game was released wow, those lazy QA guys. how did they not find this

I agree with this real hard about Super Mario World (so many people say it's super buggy but they're doing crazy nonsense that took 30 years to learn, c'mon), but the invisible wall video hit differently for me! I don't play SM64 that often, and I still remember a couple of these hitting me back in the day. Like yeah that actually is buggier than I thought, and now we know why instead of just "this game is broken"! It feels different to me than the parallel universe-level stuff that's totally outside the realm of normal behavior.

I love that they're bugs caused by a physics system cobbled together by people making one of the first 3D games that worked well 99.9% of the time, and then broke horrendously in a few places. I spent half the video thinking "oh god would I have even tried to fix this if I was working on this game and I caught it."

you see this in modding occasionally as well and I've definitely taken part in it before, i think once issues become obvious to you it's very easy to forget these don't come up in normal playthroughs and because "the developers" often become more of a concept than a group of people, and so it's easier to get more toxic about the stuff you get hindsight on (especially since often there's a feeling of "ok these guys got paid to do this stuff, we're doing it for free and we know their game better than they do, they must suck etc etc!)

To that final paragraph, I would add:

The QA team at Nintendo almost certainly did know about at least some of these weird collision areas. It's just that the QA manager probably assigned them as shippable bugs (IE bugs that won't prevent you from shipping the game) because, as you mention, they had other, more consequential bugs to fix before release.

On a tangentially related note, I'm curious how many of these invisible walls persisted into the Shindou Edition, which Nintendo treated as a bugfix version of the original.

honestly i'm skeptical that it was even a late addition — most of mario 64 is relatively boxy, and "i guess floors will tend to be pretty flat and also spaced out vertically" seems like the kind of assumption that's very easy to make early on, if you're trying to build 3D collision from scratch under such ludicrous constraints that half of it only uses integers. you'd have a hard time building the game in the first place if finding the horizontal plane took 400ms

if they were aware it was a potential problem at all, it would've been very easy to compare e.g. by highest or lowest or middlest point on each tri, which would've added little overhead but fixed most of the issues that even remain now

re the collision quirks generally, what gets overlooked in a bug-oriented dive like this is the kind of cool property that the player is constrained to the level bounds for free. they don't have to draw walls all around it or whatever, because the engine simply will not let you go somewhere that has no geometry. modern 3d physics definitely does not give you that guarantee

I'm begging speedrunners to learn how to talk about jank affectionately. And speak to anyone that has coded professionally if bugs are just "lazy coding". Please. Respect the medium you supposedly love.

it's always a weird thing to me, specially with youtubers, where there is all this "for some reason" about bugs and glitches that people only know about because this youtuber has spent lik 200 collective hours jumping against a wall to try to make something happen when 99% of players never saw something like that when playing

SM64: Built in less than 3 years to create essentially the first 3D platformer from scratch with no real previous precedent for a 3D character controller and character collision resolution system. Becomes one of the most successful and lauded games of all time and players rarely encounter any issues in the entire game.

This video: Took 10 months to build out the visualization of categorization of a very rare edge case that is essentially random to trigger, with 28 years of millions of people experiencing the game, and a community functionally dedicated to breaking it in new and unique ways for two whole decades.

Also this video: Lazy programmers

It's an amazing watch but also is so lacking any sort of alternative perspective on the subject.

Yeah. It's kinda odd to me they didn't have a level geometry tool that would reduce some of the issues (just! split the edge!) but only like two of those areas were ever problems for me (the rolling log area and falling off the ceiling in HMC near the rolling rocks).

There's some "I have no idea what they were thinking here" things in SM64 (why is the sub marked dynamic? why does it redo the raycast for shadows so many times?) but all of them are of the "It works next task aaa we only have three days left" type.

if the devs weren't so lazy they would have nothing to talk about!

There's a corollary to this, which is just how much the programming craft has been changed and improved by talking about it en masse, and by writing shit down and passing on knowledge.

A lot of the, for lack of a better word, managerial knowledge I've brought with me from tech has put certain activist teams I've been in on rocket skates. Concepts like blamelessness and past/present/future you and the importance of tracking work still to be done.

Programming/software development/software engineering still has problems, but we have made so much progress. I think it's important to recognize that progress, partly to remind ourselves that improvement is possible, and partly to inspire searching for ways to export and adapt the lessons learned to other professions.