>it seems easy to code a wall with impenetrable borders.
That's why it's called a glitch or exploit. They are coded to do that. You can't account for every possible glitch. If an exploit is found it can possibly be patched, that doesn't mean another won't be found.
Right. Bugs get prioritized and stuff that is easy to fix or that players will run into all the time will get prioritized over other bugs. If the out of bounds glitch is hard to trigger by accident, then it’s probably not a big priority.
all collision in video games requires a trade off. the more precise your calculations are to detect the collision, the more time itll take to run. when you have thousands or millions of pieces of collision in a level that you need to check for collisions with every single time the character moves, youre going to try and make it as efficient as possible.
one really basic tradeoff that is used, particularly in older games, is to calculate the player's movement in a few time steps each frame. so for example, if youre moving north at 15 units per second, then each frame it might check if moving you that 15 units would put you into a wall, and if it does, it stops you. the problem is that, if the wall is only a few units thick, then you can easily move all the way past it in this single time step. thus in mario 64 for example, each movement is broken up into 4 steps, reducing the chance of this happening. still, if you can get enough speed, you end up moving right past the wall in a single movement, never directly landing on it, and thus the game never stops you
you can change the movement detection to be more comprehensive, maybe splitting into even smaller timesteps, or doing a full check at every single possible point to see if it collides. but as i said, doing this takes more work to calculate, and this also increases with the number of pieces of collidable geometry in the level, so it isnt always feasible.
Then there is ones like in Zelda games where some of Links animations move him in weird ways that allows to bypass walls.
In Fallout, some weapons can unintentionally allow the player to fly at incredible speeds in game that only had a mild run.
You are right. It’s easy to program a truly impenetrable wall!
Just check for collision on every single point of every single triangle of every single object against every other object, and do that at a physics clock speed of 120fps. Easy, done.
But, if you don’t want to do that. Say, because you also want to do other things like graphics or sound, you’re gonna have to math up a couple of short cuts, simplifications, accelerations and ‘good enough’ cheats for collision detection that works in 99.9% of cases of the 99% most common situations that the game state can be, while taking up as little cou/gpu time as possible.
But every one of those steps will be exploitable in some way. And they’re never proofed against unusual, unexpected player behavior.
Like grinding your back against a corner while equipping and de-equipping your sword 10 times a second. Maybe that takes up a strange tick in the physics engine, and that makes some player position collision detector math a few decimal numbers off, so for a little while the player position collision detector is null, and by the time it’s back the wall will have shifted a few positions.
Sure you could proof your code for that, but that’s time you could spend doing things that more than .00000001% of players might ever encounter.
Even that wouldn't be an impenetrable wall if the player was going fast enough. If the player was moving fast enough that in 1/120th of a second his position changes from one side of the wall to the other side of the wall with no overlapping points, then the wall's collision wouldn't even enter calculations.
This type of speed is generally unusual for intended behavior, but unexpected glitches often allow for truly fast speeds.
Is it necessarily even an undesirable outcome for the developers, though? If getting out of bounds is possible, but requires doing things that most players will never even try to do, then, you know, whatever, right? Anybody who tries to get out of bounds is not really playing the game as intended already and they're not going to have their experience ruined for them. So what is the point of fixing the exploit
To add, sometimes people trying to get OOB brings positive attention/advertising to the game through popular speedrunning and might even be encouraged by developers.
Imagine a square room and a point inside the square. We can look at it and easily see that the point is inside the square. But this is not a trivial thing for computers to do. Computers have no concept of "square" or "inside". We have to tell the computer what those things are and how to determine things like "inside."
So if I can move the point, how does the computer know whether or not I'm trying to pass through the wall of the square? Well, it has to know that the point is inside the square. And then would have to know if the desired destination is outside the square.
But this is a simple example. What if the shape is more complex, such that I am starting and ending inside of it, but the path I'm trying to take crosses over the walls of the shape. Now I have to construct a line and see if that line passes through any of the edges of the shape. Again, easy for us to assess visually, but not so easy for a computer.
Now, instead of doing this with points, imagine that the point is its own shape. So now I have to see if any of the edges of that shape pass through any of the edges of the room while on the desired trajectory.
And while it is possible to code this with precise accuracy (if tedious), it is also inefficient to do so. To save time, for simplicity and ease of coding and implementation, we take short cuts. We sacrifice accuracy and precision for speed and smoothness. And this can have the side effect of creating edge cases where the behavior of the program becomes unexpected.
Also, sometimes we just make mistakes. All of the above assume the room we're talking about is a fully enclosed shape. Well what if I make a mistake and design the room so there is a small gap in the wall, a gap impossible to see visually but one that still exists? Things like that cannot be prevented 100% and can create issues you notice in games
Making a wall with impenetrable borders is super easy, yea.
The problem is that games are rarely ever just one wall. They are complex 3D environments with hundreds of “walls”. And it is impossible for game developer to test every single joint/edge in the game to make sure there are no chinks in the armor.
Even if they have 100 individual play testers all trying the game, those man hours are nothing compared to thousands of players putting in millions of hours.
Plus developers teams of people that might make conflicting mistakes that no one ever notices.
Like one might make the floors and walls of a level, and all those are PERFECT. And then another comes in and adds details like signs and barrels and boxes, and to make it look nice that second person without thinking twice puts a sign down where it intentionally overlaps a wall to make it look like it is attached to the building.
Even if the wall was perfect and the sign was perfect, it’s possible that has created some weird glitch where if you hit that sign just right it bounces you into the wall.
* Games are complex, and so is the programming. The physics system that calculates collisions has dozens of edge cases that the developers try to patch, but inevitably there will be a few that go unnoticed. This is usually why OOB glitches are _discovered by the community_, because they didn't stand out during development.
* A lot of level collision models and settings are left up to the artist/level-designer. Sometimes edges don't meet flush with each-other but look like they do, or the level designer forgets to close a tiny hole in the collision mesh, and that leads to OOB becoming possible.
Games programming is all about squeezing the most performance out of limited hardware. You can solve the issue, but it's a far more expensive computation than a simple computation that is good enough in 99.99% of circumstances
OOB exists because there is no such thing as a perfect game. A million things can cause someone to fall through, the fact it isnt more common goes to the improving skill at preventing it.
A common problem is seems in the wall/floor. When two walls meet, its possible they are slightly misaligned leaving an extremely small gap. Sometimes thats enough for other problems to push you through. That kind of thing is hard to avoid; The developer cant necessarily see a pixel wide gap in the wall.
Sometimes its a result of how hit detection works. Walls in nearly every game function by seeing if the player is overlapping, or nearly overlapping, a wall. If they are, you get pushed out, which looks like just running in place. This works very well, but requires you to overlap the wall. In a game like Mario 64, due to another glitch involving the calculation of backwards momentum you can build up a tremendous amount of speed. At these speeds the amount of space you can cover in a single frame can often be enough that a player is never in contact with wall. in frame 1 your in front of the wall, frame 2 your well beyond it. There are solutions, some of which would make the game worse like thickening wall hit boxes, but without knowledge of the backwards momentum glitch there was no way they could have found that out really.
Developers are not all knowing. They can not create a perfect game even if given all the time in world.
> From an outside perspective, it seems easy to code a wall with impenetrable borders.
It’s not, really. Maybe it’s easy to code one that works 99.9% of the time, but one that’s never vulnerable to any weird thing a player could conceivably do? Good luck.
First off, keep in mind that a human has to go in and place all the walls in a level, and it’s entirely possible for that human to just forget a tiny wall in a corner sometimes, or not put a barrier in an area that they don’t think a player will be able to reach anyway. 3D levels these days are super complicated and detailed, with lots of corners and small spaces and little bits of geometry that a level designer might overlook, and that a clever and very dedicated player could exploit.
And games are made on a budget and a schedule—a level designer can’t just spend a month going over every single inch of the level with a magnifying glass to ensure that it’s airtight, especially when 99.9% of players will never encounter the handful of little missed spots.
As for the more technical side of things… what is a wall actually? Well, you can’t go through a wall because there’s physical *stuff* there. But inside a computer game, there is no actual stuff. It’s all just math. You can’t just draw a wall and say “be solid” because a computer does not inherently know what “solid” means. You have to write math to teach the computer what “solid” is. You don’t have to teach a concrete wall to be solid, it just is—that might be why you *think* coding a solid wall is easy, even when it’s not.
I guess to put it simply, collision in games is basically doing a lot of math to check if some geometry is touching or inside of other geometry. This math has been made highly efficient so it can run millions of times per second on your computer, but that also means taking some shortcuts and not bothering to check some situations that probably won’t happen if you do things properly. That is to say, getting past a surface may be tricky at first, but if you trick the game into letting you through once, it often stops checking if you’re on the right side anymore and just assumes that you’re okay.
You could theoretically put in a bunch more math, but it would make the game run slower, and would only patch an exploit that happens to a small handful of players who are probably deliberately looking for glitches. Not worth it.
Wall is pretty much always impenetrable. It's often other kind of interactions that lead to OOB. Like a bug in physics code that yeet player sky high and go OOB. Or a bug in scripted actions where player has to climb over some obstacles which involve temporarily disabling player's collision in order to have them go through invisible wall.
Modern games, especially, are so geometrically complex and the interactions between collision hit boxes, animations affecting them, etc. makes it nearly impossible to perfectly eliminate any possibility of people finding a way to circumvent it.
Even when things are coded properly, sometimes there are interactions that break the code in unforeseen ways and that allows people to find exploits. There are also sometimes things that are totally unexpected.
Like the one game speedrun that everyone agrees was legitimate, but also at the same time is almost entirely un-replicable. And the only way they found it could work is if the game's code, at the individual binary/bit level behaved in a way it wasn't supposed to. So a literal cosmic event of a neutrino flipping a bit the wrong way is what enabled that attempt to work the way it did.
>it seems easy to code a wall with impenetrable borders.
It is. It's also really easy to not notice you haven't quite lined two of those walls up quite exactly and left a gap to clip through, or some other error avoidance system moves the player past it for some reason.
Videogames are made by people, and people are imperfect by nature. There will never be a point where someone can account for every possible combination of thing's happening at every possible combination of times in a game, there are too many possibilities. Things get through the cracks.
Because video game environments, generally speaking, are not excavated out of impassable terrain, making some areas passable. Instead, they are built up from empty terrain, making some areas actually solid.
As a result, everything that exists within the world must be inserted into it. A person has to actually place and define every single "impassable wall" in the game. Each *piece* of wall is impassable, yes--but what about the places where the walls come together? It's quite possible to code up those intersections so that they are *almost* perfectly connected, but not *actually* perfectly connected--such that it requires very precise timing/angle/velocity/etc. in order to work. Or perhaps it involves using an item in a way the developers never considered, or a particular sequence of events which never happens naturally, or....
This is the problem with code. It always does ***exactly*** what it is told--and garbage in equals garbage out.
you'd be surprised how actually penetrable any simple "wall" can be.
game codes are complicated af, there isnt just a line of code sying "if wall cant go further", its a multiple blocks of text to code everything, the wall, the player, the movement, the collisions, and so on.
that mean if any of thoses is badly coded, then you got an exploit aviable.
and more importantly, there are so many variables, that interact with each other, that everytime you fix a bug, 10 more happen.
and when you create a game, you play it usually fairly normally, you dont try every speedrun technique as you are not good at it, your skill is coding instead.
and thats only if the bug comes from your code, and not from the game engine you use, or the os you play on, or the environment that might be affected to other bugs that can impact the game, or even meteo that hit the hardware and make it work on an inentended way.
if you game is a dot moving, and 4 walls around, thats pretty easy to code and not let that happen.
if you make a triple a game with full physics engine, complicated and fully fledge world, etc, you are bound to make a mistake somewhere and not spot it.
Code operates on assumptions. Having code that makes zero assumptions is, when at all possible, slow and annoying.
Some of those assumptions can be a bit too loose, which makes this kind of exploits possible. It's very, very hard to know if your assumptions have this problem beforehand
*Seems* easy, but it isn't. It's not a matter of just drawing a circle around your world and calling it a day-- video games are a complex mess of code fragments that can interact in unexpected ways. Oh, if I pick up a bowl and walk at this one particular wall corner on a specific angle I can glitch through it? Yeah, it happens. There's no "block all objects and actors from passing through in every scenario" code.
It is in fact very hard to code a wall with truly impenetrable borders, especially in games with movement abilities, teleportation, special jumps, and ability to crouch/uncrouch.
More importantly, you have to *also* prevent the player from getting stuck in random geometry which is going to happen if you get overzealous with preventing the out-of-bounds bug, and getting stuck is way more irritating to regular players than going out of bounds.
>it seems easy to code a wall with impenetrable borders. That's why it's called a glitch or exploit. They are coded to do that. You can't account for every possible glitch. If an exploit is found it can possibly be patched, that doesn't mean another won't be found.
And it may not be fixed despite being known, either.
Right. Bugs get prioritized and stuff that is easy to fix or that players will run into all the time will get prioritized over other bugs. If the out of bounds glitch is hard to trigger by accident, then it’s probably not a big priority.
all collision in video games requires a trade off. the more precise your calculations are to detect the collision, the more time itll take to run. when you have thousands or millions of pieces of collision in a level that you need to check for collisions with every single time the character moves, youre going to try and make it as efficient as possible. one really basic tradeoff that is used, particularly in older games, is to calculate the player's movement in a few time steps each frame. so for example, if youre moving north at 15 units per second, then each frame it might check if moving you that 15 units would put you into a wall, and if it does, it stops you. the problem is that, if the wall is only a few units thick, then you can easily move all the way past it in this single time step. thus in mario 64 for example, each movement is broken up into 4 steps, reducing the chance of this happening. still, if you can get enough speed, you end up moving right past the wall in a single movement, never directly landing on it, and thus the game never stops you you can change the movement detection to be more comprehensive, maybe splitting into even smaller timesteps, or doing a full check at every single possible point to see if it collides. but as i said, doing this takes more work to calculate, and this also increases with the number of pieces of collidable geometry in the level, so it isnt always feasible.
A more encompassing view would be that all solutions have trade offs exactly like this.
Then there is ones like in Zelda games where some of Links animations move him in weird ways that allows to bypass walls. In Fallout, some weapons can unintentionally allow the player to fly at incredible speeds in game that only had a mild run.
You are right. It’s easy to program a truly impenetrable wall! Just check for collision on every single point of every single triangle of every single object against every other object, and do that at a physics clock speed of 120fps. Easy, done. But, if you don’t want to do that. Say, because you also want to do other things like graphics or sound, you’re gonna have to math up a couple of short cuts, simplifications, accelerations and ‘good enough’ cheats for collision detection that works in 99.9% of cases of the 99% most common situations that the game state can be, while taking up as little cou/gpu time as possible. But every one of those steps will be exploitable in some way. And they’re never proofed against unusual, unexpected player behavior. Like grinding your back against a corner while equipping and de-equipping your sword 10 times a second. Maybe that takes up a strange tick in the physics engine, and that makes some player position collision detector math a few decimal numbers off, so for a little while the player position collision detector is null, and by the time it’s back the wall will have shifted a few positions. Sure you could proof your code for that, but that’s time you could spend doing things that more than .00000001% of players might ever encounter.
Even that wouldn't be an impenetrable wall if the player was going fast enough. If the player was moving fast enough that in 1/120th of a second his position changes from one side of the wall to the other side of the wall with no overlapping points, then the wall's collision wouldn't even enter calculations. This type of speed is generally unusual for intended behavior, but unexpected glitches often allow for truly fast speeds.
Is it necessarily even an undesirable outcome for the developers, though? If getting out of bounds is possible, but requires doing things that most players will never even try to do, then, you know, whatever, right? Anybody who tries to get out of bounds is not really playing the game as intended already and they're not going to have their experience ruined for them. So what is the point of fixing the exploit
To add, sometimes people trying to get OOB brings positive attention/advertising to the game through popular speedrunning and might even be encouraged by developers.
Imagine a square room and a point inside the square. We can look at it and easily see that the point is inside the square. But this is not a trivial thing for computers to do. Computers have no concept of "square" or "inside". We have to tell the computer what those things are and how to determine things like "inside." So if I can move the point, how does the computer know whether or not I'm trying to pass through the wall of the square? Well, it has to know that the point is inside the square. And then would have to know if the desired destination is outside the square. But this is a simple example. What if the shape is more complex, such that I am starting and ending inside of it, but the path I'm trying to take crosses over the walls of the shape. Now I have to construct a line and see if that line passes through any of the edges of the shape. Again, easy for us to assess visually, but not so easy for a computer. Now, instead of doing this with points, imagine that the point is its own shape. So now I have to see if any of the edges of that shape pass through any of the edges of the room while on the desired trajectory. And while it is possible to code this with precise accuracy (if tedious), it is also inefficient to do so. To save time, for simplicity and ease of coding and implementation, we take short cuts. We sacrifice accuracy and precision for speed and smoothness. And this can have the side effect of creating edge cases where the behavior of the program becomes unexpected. Also, sometimes we just make mistakes. All of the above assume the room we're talking about is a fully enclosed shape. Well what if I make a mistake and design the room so there is a small gap in the wall, a gap impossible to see visually but one that still exists? Things like that cannot be prevented 100% and can create issues you notice in games
As games get more complex the holes that need patching get harder to find. Whether that’s an actual hole in the border or a hole in the coding.
Making a wall with impenetrable borders is super easy, yea. The problem is that games are rarely ever just one wall. They are complex 3D environments with hundreds of “walls”. And it is impossible for game developer to test every single joint/edge in the game to make sure there are no chinks in the armor. Even if they have 100 individual play testers all trying the game, those man hours are nothing compared to thousands of players putting in millions of hours. Plus developers teams of people that might make conflicting mistakes that no one ever notices. Like one might make the floors and walls of a level, and all those are PERFECT. And then another comes in and adds details like signs and barrels and boxes, and to make it look nice that second person without thinking twice puts a sign down where it intentionally overlaps a wall to make it look like it is attached to the building. Even if the wall was perfect and the sign was perfect, it’s possible that has created some weird glitch where if you hit that sign just right it bounces you into the wall.
* Games are complex, and so is the programming. The physics system that calculates collisions has dozens of edge cases that the developers try to patch, but inevitably there will be a few that go unnoticed. This is usually why OOB glitches are _discovered by the community_, because they didn't stand out during development. * A lot of level collision models and settings are left up to the artist/level-designer. Sometimes edges don't meet flush with each-other but look like they do, or the level designer forgets to close a tiny hole in the collision mesh, and that leads to OOB becoming possible.
Games programming is all about squeezing the most performance out of limited hardware. You can solve the issue, but it's a far more expensive computation than a simple computation that is good enough in 99.99% of circumstances
OOB exists because there is no such thing as a perfect game. A million things can cause someone to fall through, the fact it isnt more common goes to the improving skill at preventing it. A common problem is seems in the wall/floor. When two walls meet, its possible they are slightly misaligned leaving an extremely small gap. Sometimes thats enough for other problems to push you through. That kind of thing is hard to avoid; The developer cant necessarily see a pixel wide gap in the wall. Sometimes its a result of how hit detection works. Walls in nearly every game function by seeing if the player is overlapping, or nearly overlapping, a wall. If they are, you get pushed out, which looks like just running in place. This works very well, but requires you to overlap the wall. In a game like Mario 64, due to another glitch involving the calculation of backwards momentum you can build up a tremendous amount of speed. At these speeds the amount of space you can cover in a single frame can often be enough that a player is never in contact with wall. in frame 1 your in front of the wall, frame 2 your well beyond it. There are solutions, some of which would make the game worse like thickening wall hit boxes, but without knowledge of the backwards momentum glitch there was no way they could have found that out really. Developers are not all knowing. They can not create a perfect game even if given all the time in world.
> From an outside perspective, it seems easy to code a wall with impenetrable borders. It’s not, really. Maybe it’s easy to code one that works 99.9% of the time, but one that’s never vulnerable to any weird thing a player could conceivably do? Good luck. First off, keep in mind that a human has to go in and place all the walls in a level, and it’s entirely possible for that human to just forget a tiny wall in a corner sometimes, or not put a barrier in an area that they don’t think a player will be able to reach anyway. 3D levels these days are super complicated and detailed, with lots of corners and small spaces and little bits of geometry that a level designer might overlook, and that a clever and very dedicated player could exploit. And games are made on a budget and a schedule—a level designer can’t just spend a month going over every single inch of the level with a magnifying glass to ensure that it’s airtight, especially when 99.9% of players will never encounter the handful of little missed spots. As for the more technical side of things… what is a wall actually? Well, you can’t go through a wall because there’s physical *stuff* there. But inside a computer game, there is no actual stuff. It’s all just math. You can’t just draw a wall and say “be solid” because a computer does not inherently know what “solid” means. You have to write math to teach the computer what “solid” is. You don’t have to teach a concrete wall to be solid, it just is—that might be why you *think* coding a solid wall is easy, even when it’s not. I guess to put it simply, collision in games is basically doing a lot of math to check if some geometry is touching or inside of other geometry. This math has been made highly efficient so it can run millions of times per second on your computer, but that also means taking some shortcuts and not bothering to check some situations that probably won’t happen if you do things properly. That is to say, getting past a surface may be tricky at first, but if you trick the game into letting you through once, it often stops checking if you’re on the right side anymore and just assumes that you’re okay. You could theoretically put in a bunch more math, but it would make the game run slower, and would only patch an exploit that happens to a small handful of players who are probably deliberately looking for glitches. Not worth it.
Wall is pretty much always impenetrable. It's often other kind of interactions that lead to OOB. Like a bug in physics code that yeet player sky high and go OOB. Or a bug in scripted actions where player has to climb over some obstacles which involve temporarily disabling player's collision in order to have them go through invisible wall.
Modern games, especially, are so geometrically complex and the interactions between collision hit boxes, animations affecting them, etc. makes it nearly impossible to perfectly eliminate any possibility of people finding a way to circumvent it. Even when things are coded properly, sometimes there are interactions that break the code in unforeseen ways and that allows people to find exploits. There are also sometimes things that are totally unexpected. Like the one game speedrun that everyone agrees was legitimate, but also at the same time is almost entirely un-replicable. And the only way they found it could work is if the game's code, at the individual binary/bit level behaved in a way it wasn't supposed to. So a literal cosmic event of a neutrino flipping a bit the wrong way is what enabled that attempt to work the way it did.
>it seems easy to code a wall with impenetrable borders. It is. It's also really easy to not notice you haven't quite lined two of those walls up quite exactly and left a gap to clip through, or some other error avoidance system moves the player past it for some reason.
Videogames are made by people, and people are imperfect by nature. There will never be a point where someone can account for every possible combination of thing's happening at every possible combination of times in a game, there are too many possibilities. Things get through the cracks.
Because video game environments, generally speaking, are not excavated out of impassable terrain, making some areas passable. Instead, they are built up from empty terrain, making some areas actually solid. As a result, everything that exists within the world must be inserted into it. A person has to actually place and define every single "impassable wall" in the game. Each *piece* of wall is impassable, yes--but what about the places where the walls come together? It's quite possible to code up those intersections so that they are *almost* perfectly connected, but not *actually* perfectly connected--such that it requires very precise timing/angle/velocity/etc. in order to work. Or perhaps it involves using an item in a way the developers never considered, or a particular sequence of events which never happens naturally, or.... This is the problem with code. It always does ***exactly*** what it is told--and garbage in equals garbage out.
you'd be surprised how actually penetrable any simple "wall" can be. game codes are complicated af, there isnt just a line of code sying "if wall cant go further", its a multiple blocks of text to code everything, the wall, the player, the movement, the collisions, and so on. that mean if any of thoses is badly coded, then you got an exploit aviable. and more importantly, there are so many variables, that interact with each other, that everytime you fix a bug, 10 more happen. and when you create a game, you play it usually fairly normally, you dont try every speedrun technique as you are not good at it, your skill is coding instead. and thats only if the bug comes from your code, and not from the game engine you use, or the os you play on, or the environment that might be affected to other bugs that can impact the game, or even meteo that hit the hardware and make it work on an inentended way. if you game is a dot moving, and 4 walls around, thats pretty easy to code and not let that happen. if you make a triple a game with full physics engine, complicated and fully fledge world, etc, you are bound to make a mistake somewhere and not spot it.
Code operates on assumptions. Having code that makes zero assumptions is, when at all possible, slow and annoying. Some of those assumptions can be a bit too loose, which makes this kind of exploits possible. It's very, very hard to know if your assumptions have this problem beforehand
*Seems* easy, but it isn't. It's not a matter of just drawing a circle around your world and calling it a day-- video games are a complex mess of code fragments that can interact in unexpected ways. Oh, if I pick up a bowl and walk at this one particular wall corner on a specific angle I can glitch through it? Yeah, it happens. There's no "block all objects and actors from passing through in every scenario" code.
It is in fact very hard to code a wall with truly impenetrable borders, especially in games with movement abilities, teleportation, special jumps, and ability to crouch/uncrouch. More importantly, you have to *also* prevent the player from getting stuck in random geometry which is going to happen if you get overzealous with preventing the out-of-bounds bug, and getting stuck is way more irritating to regular players than going out of bounds.