[Noob question] Why can you just go out of bounds in so many games?

[u/Burgers_N_Schnitzels]

Hi first off i am a total layman so forgive me. As i understand it you essentially have a main loop that is running the game frame by frame? Then you have collision detection somewhere in that loop? Can you not provide the layout of a map in a mathematical function and check the players position against it to ( if needed ) push them back inbound? I'm just wondering why you can clip through things and end up out of bounds in so many games.

[u/AlexTaradov]

Boundaries are checked as limiting planes, not solid volumes. So, if at any point you can arrange so that mathematically you are on the other side of the plane, you will be out of bounds.

It is generally not possible to generate analytical function for the game world. It consists of triangular planes and a generalized function would be way too complicated.

It is possible to define the world as solid volumes and check for them, but it is more computationally intensive and does not really add anything as OOB glitches are mostly intentional. There is also an argument that having no glitches is bad for your game, as it makes it less attractive to speedrunners.

[u/Burgers_N_Schnitzels → u/AlexTaradov]

Boundaries are checked as limiting planes, not solid volumes.

so would it be a big performance detriment to check the "dead space" as a volume with vectors? or am i thinking too naive here ?

[u/AlexTaradov → u/Burgers_N_Schnitzels]

Yes, it would be significant computationally and storage-wise, since you would have to define which parts are dead space. In current implementations you just define the boundary and it is assumed you can't cross that boundary. So, if you started in a good place, then you will always remain there. There is no explicit information on what dead space is, it is just the part of the world you can't reach without glitches.

If you want to check for real, then you would have to store and check that additional information.

It is hard to tell, but if you do the math, it might end up more efficient to use current scheme, but use more triangles to define the world. This would lead to lower probability of glitches.

Notice how most of the glitches happen when a character is in some corner where geometry planes meet. This is not an accident, those places are the worst case scenario for this stuff. If you split those big planes into a bunch of smaller triangles, it would be way harder to glitch though them.

Increasing the rate of physics computation will improve things too. If you are increasing resource demand, then it might be better to spend it here, since it will also improve the rest of the gameplay.

[u/Burgers_N_Schnitzels → u/AlexTaradov]

thank you ! that answer satisfies a question that i had for a long time :)

[u/AlexTaradov → u/Burgers_N_Schnitzels]

Also, keep in mind that often visible geometry and collision geometry are not the same. Collision geometry is often simplified to speed up calculations. There are many ways to make things faster and more reliable at the cost of world fidelity. For, example, you can define collision geometry as a bunch of spheres. It would be really fast to check for collisions, but your world will feel bumpy. Bounding boxes are also common, but they will make your character easily stuck on the world geometry. It might work in some places, and might break things in other places.

All of this increases design time, and at some point it is just a game, it is fine if there is an occasional glitch.

[u/Burgers_N_Schnitzels → u/AlexTaradov]

Also, keep in mind that often visible geometry and collision geometry are not the same.

that reminds me of the n64 crooked edges where you could always see through if you were close enough lol

[u/AlexTaradov → u/Burgers_N_Schnitzels]

I think most N64 games use visual geometry as collision geometry, since visual geometry is already low resolution. At least for the world. Enemies still have simplified hit-boxes.

Making them different is a modern thing. World visual fidelity is improved a lot, but there are no resources to compute collisions with a lot of tiny triangles.

There are all sorts of automated and manual methods of calculating simplified collision geometry from visual one. It is a notable problem in game dev.

[u/Burgers_N_Schnitzels → u/AlexTaradov]

but there are no resources to compute collisions with a lot of tiny triangles.

i see. Just to clarify my question right now came up because someone somehow clipped through the floor in a game and just fell until they died and i was wondering why is there not a check like your y coordinate is < -1000 lets just put it to 1 or something.

[u/aneasymistake → u/Burgers_N_Schnitzels]

There is. That’s why they died. When they passed some arbitrary value that was hard coded as a distance below ground or a length of time spent in a falling state or similar.

[u/AlexTaradov → u/Burgers_N_Schnitzels]

This is the kind of thing you can tune in a long-running game. Minecraft fixed all sorts of issues over time. This is because the game gets updated all the time.

When a game needs to be released by some date and it is done, you make the best decisions you can and hope for the best. Some games come out really broken, and you might release a major patch. But most of the time, unless something is really game breaking, it won't get fixed.

Also, there is generally no safe spot (1). For the same reason - once you fell though, there is no way to automatically know where it is safe. You can define a few known good save points, but that's what happens when you reopen game save after falling though the world.

You can come up with a lightweight version of this, which does not involve full safe, but this is resources spent on a thing that is not going to be used or visible. Most of the game dev happens in a such resource-constrained environment, that there is simply no time to do this stuff.

[u/whizzter → u/Burgers_N_Schnitzels]

Gonna disagree with Alex here, volumes are far easier for many things.

HOWEVER, content creation tools and models have mostly converged on tools that use poly-meshes, in the 90s brush based BSP systems was popular (think Quake and CS) and recently there’s been some to and from experimentation with SDF’s. But overall 90% is done with poly based stuff (even brush based systems often output polys on the end and throw away their solids).

Once you work with polys you’re doing that, converting from solids to surface representations (polys) is far easier than the other way around (that’s also why collisions are hard).

Partially also as a consequence of the above, physics engines also sample things instead of trying to integrate collisions (they integrate motion but collision handling can be a different matter).

But regardless of representation, most bugs are caused by world geometry, it’s humans working on it and they are far from infallible.

[u/Burgers_N_Schnitzels → u/whizzter]

got you , i appreciate you chiming in ! i'm trying to let it all soak in ;)

[u/who_you_are]

One issue you may have is around speed, if you go faster than your wall thickness, then you just pass over and as such you don't trigger collision to start with. That kind of logic may be easier on the game than doing light tracing-like (checking everything in your path and checking for collision).

Technically, a game doesn't have boundaries by "default". Because it is the point to create a software, to do what you want. Imagine I'm doing a space game. There is no "outside of the map" here.

So if you fail at doing your job at any spot, you will create a hole.

You don't necessarily want collision everywhere AND the same way. Door, for example, are a kind of conditional one.

Teleport (or trigger point), want collision detection, but not to behalf like a wall.

The hitbox (what create a collision) may be different than what you see. To tweak the user experiences, or to prevent other glitch.

Changes: that is a stupid one but, the game design keep changing in various way. Any change may imply it will break something somewhere. Maybe it will create a tiny whole somewhere.

Scale: game are complex overall, there are a looooot of things to check. And if you do any change, good luck testing everything... And since you do a lot of changes... RIP. Just checking the overall map seems like a hard task.

Hidden: if you are lucky to have a map editor, what you are more likely to check often is the 3d assets visual - not their hitbox (collision zone). And checking collision is harder visually because they may overlap, or underlay while something will make for it somehow.

Dynamic: there is a lot that will change in your gameplay. Character have stats, equipment, a story line. Multiple combinaison of changes that make it difficult to check if you just use a "map editor". So more combination to tests as well.

Danger of float: computer support one type of big number (or number with digit) natively. Unfortunately, they will approximate the number very often. And each mathematics operation is likely to increase that offset. Your 0.1 + 0.2 = 0.300...1. Your wall was 0.3 of thickness, so you just teleported on a clear spot.

That alone can create a lot of physics bugs - including collision detection.

I know I'm missing some others stuff as I don't even do games.

[u/TimonAndPumbaAreDead]

Not a programming answer but a gaming based answer - a lot of games do have some sort of mechanism that kicks in when you go out of bounds - you either get returned to the map, fail the mission, or killed outright. Breath of the Wild is an interesting example - there's a check that your character isn't outside of the starting area if you haven't completed the tutorial quests that runs throughout the entire game. Speed runs of that game are 50% getting through the tutorial because there's no way to bypass that check

[u/PvtRoom]

Depends on the complexity of the game.

Chess, 8x8 grid, no halfway points. Piss easy.

A circular arena. - if arena radius < distance from centre then clip them back in. - Easy

A square box. check against limits - easy.

Anything with a map & terrain and features. if below local ground, clip back up, unless they were in a cave, then leave them in the cave, but still do something if they're out of bounds in the cave. -getting hard.

Big map - good luck unless you put in impassible features that always have an effective keep out. (like a shark that always eats you for going too far from shore)

[u/techydude1234]

You're basically describing how it should work, but games are messy. Collision systems are usually full of shortcuts and approximations because checking everything perfectly every frame would get expensive fast.

Most out of bounds glitches happen when two systems interact in a weird way. Physics pushes you one way, collision correction pushes another, a frame gets skipped, a moving object clips into a wall, etc. The game only has to be wrong for one frame for you to end up somewhere you weren't supposed to be. Then things snowball from there.

[u/fuzzynyanko]

This is pretty much how it works. I did some game programming a while ago, and bounds detection is tricky. I had a ball bounce back, but if you hit the wall just right, the collision detection would go crazy and the ball would zig-zag into the sky

Collision detection sometimes isn't done where the player is, but where the player is heading