… You speak as if you know what you are talking about, but you clearly do not.
You are constantly jamming into the surface and doing a whole bunch of collision checks to basically scrape the player across the surface… …because you have to keep doing those checks in a loop untill you determine the obstacle is finally cleared, and then switch back to unrestricted or ‘normal’ grapple-movement.
Unnecessary “…”, and no, you don’t loop the check until the obstacle is passed any more than you would “loop” the player’s ordinary movement. As normal, each tick you attempt to move the player forward some distance. If there is an obstacle in the way, they’ll move less distance, which is fine-- this prevents them from rocketing up walls if they’re slightly below a target grapple point beyond the wall, as in the below scenario.
You have to keep doing 3d vector collision mesh check calculations for the whole time the player is being ‘scraped’… because you don’t know when to switch ‘perpendicular movement only’ mode off, otherwise… so this is inefficient.
What would be more efficient? Depending on how the game physics work, the player’s collision mesh is probably a capsule, simple box, or sphere. It’s really not that expensive to add this check; the player is presumably already doing collision checks using their mesh every tick for like, standing on the ground and touching walls.
Assuming this is a 3D environment… there’s no way you can just totally null out one dimension of the movement vector unless the player is perfectly perpendicular hitting a perfectly perpendicular surface.
If your level design is any degree of complex, with objects beyond basically perfect boxes that are all perfectly orientes to the world grid… and if the player is allowed to rotate… this doesn’t work, your calcs still always involve 3 dimensions.
What you’re saying might work in a 2D game… or I guess 2.5D, maybe?.. but it wouldn’t work in a 3D game.
When did I ever say that you would accomplish this effect by nulling out one component of their movement vector? That idea is a fabrication of your own delusions. It’s pretty easy to do a mesh collision check, get the normal of the tri the player collided with, and use that to remove all the player’s movement in that direction.
This is probably already part of the engine’s physics calculations anyways!
[the 3d pathfinding idea]
This could work, especially if the grappling hook is one of those ones where gravity stops affecting you (could be good for gameplay, that’s valid). But to construct this path in a realistic manner, you would need to do similar calculations to what you’re saying are inefficient, except all at once instead of spread over multiple frames. If you simplify the pathfinding checks to make the movement simpler, you could in most cases do the same thing with the player collision checks. Depends on how you implement it though I suppose. Too specific to cover all cases in a general discussion.
You have an odd definition of ‘realistically’.
It is realistic that if I grapple into a surface I will move a shorter distance than if I was grappling freely, yes. This is true without friction etc. as well. Think of the extreme case: grappling directly downwards into the floor, in which case I would not move at all.
Spheres tend to be the absolute worst objects to use in a collision mesh or hull, because they are comprised of far, far more tris or rects than a box.
LMAO are you kidding me??
First of all you could do a check using a proper sphere rather than a mesh with tris. This can actually be faster than using a box-- eg. checking if two spheres (or a sphere and a point) collide is literally just a distance check compared to their combined radii. I bet even sphere-tri collision is easier than tri-tri, although my game engine knowledge doesn’t extend far enough to say for sure in that case.
There is a reason hitboxes… are called ‘boxes’.
They’re called that because boxes are common, not because they’re the best.
I think what you are trying to describe is a common concept in games where many objects that are basically… clutter, vegetation, extra fluff… they just do not interact with the player collision mesh/hull at all, for many parts of the engine/game. […]
This entire line of critique is invalid because I wasn’t saying that at all. I’m saying that as a consequence of the collisions, they could pass around an obstacle; not that they could go through it. A rock under the player as they grapple sideways would push them upwards and slightly away due to the angle of the collision, and they could then continue moving sideways as before.
Again this ‘solution’ of yours (which just entirely abandons the concept of just not colliding with small objects, which you literally just described) […]
How on God’s green Earth could you possibly, after I literally just described the precise mechanism by which the player would interact with small objects, still believe that I meant they should simply pass through them??? Maybe if you read the whole post instead of replying to each sentence individually you would’ve made that connection. Yes, I see the irony; I did read your whole post first though.
[…] just causes the problem the original comment was trying to avoid: having to do a whole bunch of collision calcs every time any obstacle is encountered.
If you apply the grapple as a force it’s literally the same collision calcs the player makes every single tick. If you can’t due to engine/game/etc. limitations, it’s still not that much extra collision calculation.
… You speak as if you know what you are talking about, but you clearly do not.
Have you ever actually mocked up a 3 physics scenario in a game engine, or modded an existing game in a manner that is very reliant on or interactive with its physics engine?
Try me. I am extensively aware of the way physics is typically handled in games. I will admit I don’t often use game engines, because I usually try to make 2d games from scratch and implement my own simple physics. But yes, I’m aware of how 3d engines handle physics as well.
Unnecessary “…”, and no, you don’t loop the check until the obstacle is passed any more than you would “loop” the player’s ordinary movement. As normal, each tick you attempt to move the player forward some distance. If there is an obstacle in the way, they’ll move less distance, which is fine-- this prevents them from rocketing up walls if they’re slightly below a target grapple point beyond the wall, as in the below scenario.
What would be more efficient? Depending on how the game physics work, the player’s collision mesh is probably a capsule, simple box, or sphere. It’s really not that expensive to add this check; the player is presumably already doing collision checks using their mesh every tick for like, standing on the ground and touching walls.
When did I ever say that you would accomplish this effect by nulling out one component of their movement vector? That idea is a fabrication of your own delusions. It’s pretty easy to do a mesh collision check, get the normal of the tri the player collided with, and use that to remove all the player’s movement in that direction. This is probably already part of the engine’s physics calculations anyways!
This could work, especially if the grappling hook is one of those ones where gravity stops affecting you (could be good for gameplay, that’s valid). But to construct this path in a realistic manner, you would need to do similar calculations to what you’re saying are inefficient, except all at once instead of spread over multiple frames. If you simplify the pathfinding checks to make the movement simpler, you could in most cases do the same thing with the player collision checks. Depends on how you implement it though I suppose. Too specific to cover all cases in a general discussion.
It is realistic that if I grapple into a surface I will move a shorter distance than if I was grappling freely, yes. This is true without friction etc. as well. Think of the extreme case: grappling directly downwards into the floor, in which case I would not move at all.
LMAO are you kidding me??
First of all you could do a check using a proper sphere rather than a mesh with tris. This can actually be faster than using a box-- eg. checking if two spheres (or a sphere and a point) collide is literally just a distance check compared to their combined radii. I bet even sphere-tri collision is easier than tri-tri, although my game engine knowledge doesn’t extend far enough to say for sure in that case.
They’re called that because boxes are common, not because they’re the best.
This entire line of critique is invalid because I wasn’t saying that at all. I’m saying that as a consequence of the collisions, they could pass around an obstacle; not that they could go through it. A rock under the player as they grapple sideways would push them upwards and slightly away due to the angle of the collision, and they could then continue moving sideways as before.
How on God’s green Earth could you possibly, after I literally just described the precise mechanism by which the player would interact with small objects, still believe that I meant they should simply pass through them??? Maybe if you read the whole post instead of replying to each sentence individually you would’ve made that connection. Yes, I see the irony; I did read your whole post first though.
If you apply the grapple as a force it’s literally the same collision calcs the player makes every single tick. If you can’t due to engine/game/etc. limitations, it’s still not that much extra collision calculation.
Try me. I am extensively aware of the way physics is typically handled in games. I will admit I don’t often use game engines, because I usually try to make 2d games from scratch and implement my own simple physics. But yes, I’m aware of how 3d engines handle physics as well.