3 ms·

But why not model it with 1m thinness and put some trigger code if you touch the other side to reset you, same for objects. I am not a game dev, so at first lo

But why not model it with 1m thinness and put some trigger code if you touch the other side to reset you, same for objects. I am not a game dev, so at first look a level editor that is mostly drag and drop should solve this for the level designers, but for some reason you can still fall through floors.

umvi 5y ago
Scenario: - you have a 1m thick floor in your video game. - your video game has physics in it (like gravity, collisions, etc). - your game runs at 60 fps Given these assumptions, if any in-game object ever exceeds a velocity 60 m/s then on one frame it will be above the floor and on the next frame it will be below the floor without ever triggering a collision. Oops. Let me guess: "Just make the floor infinitely thick". Sure that would work but it sort of limits the kinds of maps and terrain you can make if the floor is always infinitely thick. One way to solve it without infinitely thick floors is to draw an imaginary line between your current position and previous position every frame and check if the line would have collided with anything . If it does - do something (make the player die, move them back above the floor, etc.). It gets more complex when it's not just the floor you have to worry about clipping through but the wall and the ceiling and all other objects.
adanto6840 5y ago
Oh we definitely try "simple" approaches like that, whenever we can. And if the entire 'level' is, well, level & there are no elevation changes (or elevation changes are restricted to '1 elevation per floor of a structure, for instance) then sure, that type of solution works. Otherwise though, the 'trigger' code you suggest ends up generally being some kind of math (ie physics, regardless of whether it's via a physics engine layer or a game/state layer); you essentially have to figure out "where" on the plane the object is, convert that to the proper coordinate system for your overall level, and then 'sample' the underlying terrain/mesh/ground covering to figure out if you're in a legal position. Typically this ends up being implemented as a "clamp" of sorts; you will pretty rapidly end up with oddities, floating point precision quirks, and the like. The "best solution" will vary, often drastically, from game to game. FWIW, I've been doing game-dev for almost 10 years now & have almost exclusively done "AI/NPC" agents. We've faced what I would classify as pretty much the same issue with AI agents, especially when you want them to follow nice, smooth paths while also realistically 'bumping into' each-other -- yet ensuring that they will never, ever, ever go through a wall. It sounds so stupidly-simple but, I can assure you, it is not! If you had unlimited resources (read: CPU), then it's not so bad, you can calculate for "optimal" every frame -- in reality, you never have unlimited resources, and seemingly-simple calculations like this have to run extremely fast and they cannot be allowed to fail (there's nothing more frustrating & game-breaking than NPCs that get 'stuck' behind a wall or in an area that they cannot vacate, etc). You can write code for agents to "detect stuck + get un-stuck" but, similarly, doing that fast is non-trivial; and ideally you don't want them stuck to begin with!! It's a massive can of worms. ;)

umvi 5y ago

Scenario: - you have a 1m thick floor in your video game. - your video game has physics in it (like gravity, collisions, etc). - your game runs at 60 fps Given these assumptions, if any in-game object ever exceeds a velocity 60 m/s then on one frame it will be above the floor and on the next frame it will be below the floor without ever triggering a collision. Oops. Let me guess: "Just make the floor infinitely thick". Sure that would work but it sort of limits the kinds of maps and terrain you can make if the floor is always infinitely thick. One way to solve it without infinitely thick floors is to draw an imaginary line between your current position and previous position every frame and check if the line would have collided with anything . If it does - do something (make the player die, move them back above the floor, etc.). It gets more complex when it's not just the floor you have to worry about clipping through but the wall and the ceiling and all other objects.

adanto6840 5y ago

Oh we definitely try "simple" approaches like that, whenever we can. And if the entire 'level' is, well, level & there are no elevation changes (or elevation changes are restricted to '1 elevation per floor of a structure, for instance) then sure, that type of solution works. Otherwise though, the 'trigger' code you suggest ends up generally being some kind of math (ie physics, regardless of whether it's via a physics engine layer or a game/state layer); you essentially have to figure out "where" on the plane the object is, convert that to the proper coordinate system for your overall level, and then 'sample' the underlying terrain/mesh/ground covering to figure out if you're in a legal position. Typically this ends up being implemented as a "clamp" of sorts; you will pretty rapidly end up with oddities, floating point precision quirks, and the like. The "best solution" will vary, often drastically, from game to game. FWIW, I've been doing game-dev for almost 10 years now & have almost exclusively done "AI/NPC" agents. We've faced what I would classify as pretty much the same issue with AI agents, especially when you want them to follow nice, smooth paths while also realistically 'bumping into' each-other -- yet ensuring that they will never, ever, ever go through a wall. It sounds so stupidly-simple but, I can assure you, it is not! If you had unlimited resources (read: CPU), then it's not so bad, you can calculate for "optimal" every frame -- in reality, you never have unlimited resources, and seemingly-simple calculations like this have to run extremely fast and they cannot be allowed to fail (there's nothing more frustrating & game-breaking than NPCs that get 'stuck' behind a wall or in an area that they cannot vacate, etc). You can write code for agents to "detect stuck + get un-stuck" but, similarly, doing that fast is non-trivial; and ideally you don't want them stuck to begin with!! It's a massive can of worms. ;)