Dana Callista Lexa 🏳️‍⚧️

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.

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

the apex of comedy is when you Google a problem you’re having and the top forum result is “this isn’t a good idea, maybe don’t do this”

Yes I know it’s not a great idea to make Gamemaker resize the window, camera, and main surface every single frame. I can tell by the engine creaking under the weight of the effort. If it was a good idea I wouldn’t be doing it, now either pass the duct tape or get outta here

my takeaway from all the articles about nintendo's Tears of the Kingdom physics talk at GDC is that they basically rolled their own physics system, yes, but that their real success was in managing to, from a design and structural standpoint, put that physics design at the core of their development goals, such that rather than it having to compromise for the sake of other departments' vision, all departments' goals and tools stemmed directly from the physics system and when the physics was getting in the way the solution was not to stopgap it but to iterate and even add to the physics system until it facilitated that gameplay.

That's like. Really hard to do. I can't overstate how hard it is to do that. It requires not just a really strong top-down vision but a willingness to throw away a lot of traditional game design principles and tricks that would interfere with said physics design in favour of coming up with ideas that facilitate it instead. The amount of testing and iteration and organization that must have gone into this whole thing on an every-department level... my god.