You could plausibly implement some physics to deal with it. If the player is moving into a surface, move them along the part of their grapple movement component that’s perpendicular to that surface. This will allow them to slide along walls/floors/ceilings realistically. For the case where they need to move “through” a small object, you could treat their collision as a sphere and have it collide with the object; for small objects, this could let them pass by. Eg. for grappling sideways over a small rock on the ground, their point of collision would be mostly below them and a bit to the right, but they’re being pulled mostly straight to the right, so they would move perpendicular to the point of contact and move up-right over the rock, then continue their grapple path. Depending on your game’s physics system there are other solutions, but for a typical game engine, that should work well.
You could plausibly implement some physics to deal with it. If the player is moving into a surface, move them along the part of their grapple movement component that’s perpendicular to that surface.
That just is running into the problem the original comment was trying to avoid in the first place:
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.
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.
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.
…
Something possibly, sort of like what you’ve described, I think? but not really?.. another idea that might work would be:
Upon detecting a collision, before the player has gotten to the grapple end point… the grapple movement basically complexifies with more nodes.
So you use a pathfinding algorithm to draw, instead of just a line between two points… now you have a point of origin where the player is, the end point, and a third point that is off to the side of the obstruction.
Now for that first segment, now the grapple pulls the player perpendicular to the obstruction surface, so it isn’t constantly colliding and doing friction… and then when the player clears the obstruction, hits that midpoint, the movent vector changes.
This is basically what I described with doing the ‘draw a giant skinny box’ to check if a player can do an unobstructed grapple… but now more complicated as it involves 3D pathfinding…
This could possibly work, but it would take a good deal more work to optimize this, to make your entire world work with 3d path finding… normally, nav meshes are just done on more or less flat ground, up to some degree of incline… but now you also have to do this on literally all surfaces.
Again… this might work … but it would take a lot of game dev work to implement, as you’d have to fully 3d navmesh every level… and this potentially would not handle complex surfaces well.
3D, aerial pathfinding in a very complex environment … to my knowledge, still isn’t really a thing many games have done very well, efficiently, with a general system. It usually just a bunch of manually placed aerial nav nodes, particular to the level itself… very intensive, manual work.
…
This will allow them to slide along walls/floors/ceilings realistically.
You have an odd definition of ‘realistically’.
…
For the case where they need to move “through” a small object, you could treat their collision as a sphere…
Whoah whoah whoah wow ok gotta stop you there.
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.
This is a terrible idea.
There is a reason hitboxes… are called ‘boxes’.
…and have it collide with the object; for small objects, this could let them pass by.
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.
Like a uh, a small pile of trash or rock that doesn’t interact with the core player movement controller, but it might interact with an inverse kinematics system that slightly modifies the player’s animation so that their foot rests on top of the rubble or rock.
But uh… doing a ‘estimate everything’s size by bounding it with a sphere and then negating movement collision if its small?’
This is not something you’d want to call when the grapple attempt is started, it’d be a massive stutter or slowdown, you’d have to index every object in the level… and you’d end up with like, if you have a pile or array of many small things, all together… well individually they are all small, so you can phase through a pile of many small things that is in totality actually large.
This is the kind of thing you just design your whole game and level and objects around from the ground up.
Eg. for grappling sideways over a small rock on the ground, their point of collision would be mostly below them and a bit to the right, but they’re being pulled mostly straight to the right, so they would move perpendicular to the point of contact and move up-right over the rock, then continue their grapple path. Depending on your game’s physics system there are other solutions, but for a typical game engine, that should work well.
Again this ‘solution’ of yours (which just entirely abandons the concept of just not colliding with small objects, which you literally just described) 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.
… 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?
… 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.
… …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.
You have contradicted yourself and do not realize it. Every tick you attempt to move the player forward, and they encounter a wall… that is a collision, which must be handled by the physics engine, which is constantly running in a loop, which is computationally costly.
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 are again describing the scenario the original commenter is trying to avoid.
The player is constantly colliding with the wall in front of them untill they clear it… that is the process that occurs which negates the … going by your image, the x component of the player’s movement, and only results in the y component of movement being realized, untill the wall is cleared.
This causes a massive amount of constantly recurring collision physics calcs which slows down the entire game.
This is the situation you want to avoid via some kind of workaround.
What would be more efficient?
See my original comment, and the response to it from the other 3d game dev.
It’s really not that expensive to add this check;…
Yes. It is.
Because it literally is the computationally costly scenario we are trying to avoid.
It is realistic that…
Hookshot-like grapple hooks are not any kind of realistic.
They only exist in games and movies… they do not exist in the real world, unless you use a body rig with multiple attachment points, a seperate grapple hook launcher, and then also some kind of motorized system in a backpack which pulls you up after you’ve properly connected all the attach points and lines, and verified your grapple has a very solid hold.
For starters, a human with a hookshot style grapple is holding in either one or both hands a device that… lifts them.
Can you bench press your own body weight?
Do a continuous pull-up for 10 seconds, or even just a vertical hang?
Continuously, for the duration of the grapple travel time?
… With one hand?
Sure, a relatively small number of fairly strong people can do this for a short time without too much of a problem … but uh no, the majority of humans can’t even hold onto a bar and do pullups with their entire body weight for very long without becoming quickly tired or exhausted.
Especially if they are also wearing heavy armor and gear and carrying weapons on them.
Next we have the acceleration factor.
If your hookshot style grapple accelerates you quickly… well, chances are it’ll just fly out of your hands.
If you keep a grip on it, it could dislocate your arm.
Now we also have the impact velocity problem.
Does your hookshot grapple have some way of decelerating you as you approach the end point?
… No? Ok, enjoy impacting your target at car accident speeds, and breaking half the bones in your body.
And finally, the dragging or scraping problem.
Take your example image.
Put a human in a mountain climbing harness. Attach a steel linked chain to their chest, throw that chain over the wall, connect it to a pickup truck, and drive the pickup truck forward at 30 mph.
Congrats, your human is now a mangled, bleeding mess of severe friction burns, lacerations , potentially broken bones and torn ligaments, after being dragged up and over the wall, and that is still the case if you say that theres a bunch of pillows behind the wall and the truck stops accelerating once they clear it, so they dont’t fall after clearing the wall.
Again, you have a very strange definition of how a ‘realistic’ grapple hook works. Hookshot like grapple hooks are astoundingly un-realistic… they are a neat and fun gameplay concept, but they are not realistic in any way at all.
LMAO are you kidding me??
LMAO no!!!
First of all you could do a check using a proper sphere rather than a mesh with tris.
Ok, so by ‘proper sphere’ you apparently mean:
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.
A… point cloud made as an infinite number of rays going outward in all directions from the center of the sphere?
Your method here is something you can kind of get away with in 2d, but even then, you’d be defining a circle by a limited number of rays out from the center point… which is the same as just using like, an octagon or 12-gon or 16 or 32-gon or something, at which point you are not talking about a circle, but a polygonal approximation of one.
For it to be a perfect circle, it would have to be an… infinity-gon.
Now… in 3D, your ‘solution’ here is orders of magnitude less efficient… because you have to throw rays from the center point… in all kinds if directions… and unless you use an actually infinite number of rays, you do not have an actual sphere.
What you instead have is some 3d shape comprised of many, many tris that looks like a sphere if you don’t zoom in.
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.
It isn’t, because in 3d engines, 3d spheres that are made of tris are the only kind you can use for a collision mesh… ‘sphere-tri collisions’ are not a thing that exists, outside of something like a super intensive, requires a super computer to run, industrial grade simulator… but hey, you admit you don’t know what you’re talking about, so at least there’s that.
They’re called that because boxes are common, not because they’re the best.
No, they’re called boxes because people who want a performant 3d physics engines or hit detection system know that boxes and other very geometrically simple shapes are orders of magnitude more efficient to use in a main loop that is handling hundreds or thousands or tens of thousands of interacting and colliding objects per tick than it is to use astounding geometrically complex shapes… especially when you also consider a networked game with many players where such calcs need to be highly accurate and also very fast, and use as little bandwidth as possible.
This entire line of critique is invalid because I wasn’t saying that at all.
Fair enough, I was trying to be charitable and interpret your confused and contradictory nonsense as something that perhaps made sense and was worded poorly, but nope, it was indeed nonsense, thank you for confirming that.
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…
You answered your own question.
Yes, reading an entire written missive is… how reading works.
I don’t know if you’ve surpassed an elementary school level of literacy, but uh, sentences do not exist as a series of isolated and independent statements which have no connection to each other… they exist in totality as a larger body of text, they provide context to each other, they build upon what was said previously.
Maybe try reading a book or manual or news article instead of just a few quotes or a summary, maybe try detoxing from short form content, that might help.
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.
Nope!
Again, you are describing the entire calc heavy situation that we are attempting to avoid in the first place… as the solution.
It in fact is a lot of extra collision calcs that are problematic… which is why we are trying to workaround it.
You have been presented with a problem, asked to find a way to make it not a problem, and your solution is to simply declare the problem to not be a big deal, probably, idk.
You’d be perfect as an idiot middle manager; your commitment to not understanding anything you claim to understand is impressive, just add in some machiavelkian gaslighting social manipulation tactics and you’ll go far as a corporate middle manager or HR.
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.
I know buddy, I know you don’t know what you’re talking about.
But yes, I’m aware of how 3d engines handle physics as well.
No you are not aware of how 3d engines actually work. 3d engines are enormously more complex and complicated… adding the third dimension into every single physics calc makes everything vastly more computationally costly than physics calcs in only 2d, and this neccesitates an entirely different approach to designing and optimizing such 3d systems.
This perfectly explains what is going on: You’ve exceeded your area of knowledge, you’re in a whole different ballpark, but you assume ‘it can’t be that different!’
In summary, I was correct, you have no relevant experience with 3d engines and have no idea what you are talking about.
Maybe try learning how a well built, open source 2D game engine works by reading its code and watching tutorials if you want to progress with making a 2d engine or game… and maybe do the same for a 3D engine if you want to learn how they actually work, instead of talking out of your ass by assuming that 3d games and engines are no different from 2d ones.
You have contradicted yourself and do not realize it. Every tick you attempt to move the player forward, and they encounter a wall… that is a collision, which must be handled by the physics engine, which is constantly running in a loop, which is computationally costly.
Yes, so you do the calculations once per tick. This is the same looping behavior as the player’s ordinary movement, which is what I said. Not a contradiction. I’m not going to continue arguing with you if you keep intentionally misinterpreting me to try and win the argument (or, maybe worse, unintentionally doing it).
You are again describing the scenario the original commenter is trying to avoid. […] This causes a massive amount of constantly recurring collision physics calcs which slows down the entire game.
Again, this is once per tick like most other physics calcs / collision checks in the game. Not “massive”, and wouldn’t cause any slowdown.
See my original comment, and the response to it from the other 3d game dev.
Even if you implement pathfinding well (check for collisions with obstacles that have moved into the path, account for gravity in the path if not doing a straight-line graople, etc.), you’re doing any calculations all on one frame, which could cause a lag spike. Is this really better for performance?
Hookshot-like grapple hooks are not any kind of realistic. [explanation of IRL grapple hook problems] Again, you have a very strange definition of how a ‘realistic’ grapple hook works. Hookshot like grapple hooks are astoundingly un-realistic… they are a neat and fun gameplay concept, but they are not realistic in any way at all.
Pardon my language but this argument is always dogshit. Accepting one deviation from reality (eg. a grappling pack) does not mean you should accept all other deviations from reality (ie. “objects cannot usually pass through each other and basic collisions work like they do IRL”). All forms of (nonfiction) media have an accepted reality that contains some deviations. Should I expect the Milennium Falcon to show up in the third Lord of the Rings movie and blow up Sauron? No? Why not? Lord of the rings isn’t realistic, so we can do whatever we want!
I don’t even think this is a versimilitude problem. You just don’t understand how fictional media works.
Ok, so by ‘proper sphere’ you apparently mean: […] A… point cloud made as an infinite number of rays going outward in all directions from the center of the sphere? […] What you instead have is some 3d shape comprised of many, many tris that looks like a sphere if you don’t zoom in.
You don’t pre-define the rays or points that form the sphere at all. A sphere can be defined by one point and a radius. Two spheres are colliding if the following formula is true: dist(sphere1.center, sphere2.center) <= (sphere1.radius + sphere2.radius). That check works in 2d and 3d, takes an incredibly small amount of constant time, and is trivially easy to implement. I do it all the time.
It isn’t, because in 3d engines, 3d spheres that are made of tris are the only kind you can use for a collision mesh… ‘sphere-tri collisions’ are not a thing that exists, outside of something like a super intensive, requires a super computer to run, industrial grade simulator… but hey, you admit you don’t know what you’re talking about, so at least there’s that.
I’m a bit surprised that no game engines support spherical collisions. But if they don’t, then a collision mesh that only approximares a sphere could be used; it would be less efficient like you’ve been suggesting and less accurate too though. But simple Unity games use capsule colliders all the time, so it can’t be that expensive.
No, they’re called boxes because people who want a performant 3d physics engines or hit detection system know that boxes and other very geometrically simple shapes are orders of magnitude more efficient to use in a main loop […]
Fair, boxes are usually more computationally efficient. If the effect can be achieved using a box, it’s probably worth it to try using one.
Fair enough, I was trying to be charitable and interpret your confused and contradictory nonsense as something that perhaps made sense and was worded poorly, but nope, it was indeed nonsense, thank you for confirming that.
Bro is trying to transparently blame their misinterpretation on me. We’re the only two people here, we both know what’s happening, that doesn’t work. I could have been clearer but you could have recognized your mistake since I described exactly what I meant later. You chose to interpret it in a contradictory manner rather than seeing that your first reading was contradictory and reevaluating to see if there was an alternative, consistent explanation. This will cause you to argue badly.
[…] I don’t know if you’ve surpassed an elementary school level of literacy, but uh, sentences do not exist as a series of isolated and independent statements which have no connection to each other… they exist in totality as a larger body of text, they provide context to each other, they build upon what was said previously.
Maybe try reading a book or manual or news article instead of just a few quotes or a summary, maybe try detoxing from short form content, that might help.
You say this as if this isn’t exactly the point I was making to you? It doesn’t work in reverse though, because if you actually knew this you wouldn’t have made the related mistakes. So I’m not sure what you’re trying to do here…?
Also, ad hominem. ☝️🤓
Nope!
Again, you are describing the entire calc heavy situation that we are attempting to avoid in the first place… as the solution.
It in fact is a lot of extra collision calcs that are problematic… which is why we are trying to workaround it.
You have been presented with a problem, asked to find a way to make it not a problem, and your solution is to simply declare the problem to not be a big deal, probably, idk.
You’d be perfect as an idiot middle manager; your commitment to not understanding anything you claim to understand is impressive, just add in some machiavelkian gaslighting social manipulation tactics and you’ll go far as a corporate middle manager or HR.
You’ve made this point like 6 times already. I disagree that the extra collision checks are an issue. You want to call me an idiot middle manager? Prove that the collision checks would be problematic. Then you earn that right.
I know buddy, I know you don’t know what you’re talking about.
Do you think it makes your argument better when you insult people or is that just for fun? What it actually does is signal you aren’t knowledgeable enough in the subject to make your point without insults.
No you are not aware of how 3d engines actually work. 3d engines are enormously more complex and complicated… adding the third dimension into every single physics calc makes everything vastly more computationally costly than physics calcs in only 2d, and this neccesitates an entirely different approach to designing and optimizing such 3d systems.
This perfectly explains what is going on: You’ve exceeded your area of knowledge, you’re in a whole different ballpark, but you assume ‘it can’t be that different!’
In summary, I was correct, you have no relevant experience with 3d engines and have no idea what you are talking about.
So because I have more experience with 2d engines, I can’t also know how 3d engines work? Great argument bud. (Wow, calling people that is kinda fun! Really gives you an unearned sense of superiority. Why didn’t I think of this, it’s so easy!)
I’m aware of the differences between 2d and 3d engines. I said this already. I knew pointing out my experience with 2d engines would lead you to make this argument, but I don’t care because it holds no water. I pointed it out to give you an example of my background knowledge of physics principles. Most of those principles aren’t actually fundamentally different in 3d, they’re just more complex or costly. Can this lead you to make different decisions based on how costly the computations would be? Yes. But the principles behind how the physics work are not actually that different.
You’re also making a LOT of assumptions about the game engine in the first place. Did the original post even say the engine was 3d??? I made my original post talking in very general terms for a reason: because I know that depending on how the engine works, the splution will be different. This is not news to me. You know this too: eg. common 3d game engines not supporting spherical geometry, 3d and 2d engines having different considerations, the grapple system presumably being a straight-line grapple for your solution, etc. Pointing out that my solution does not work for your chosen parameters is not winning the argument, it’s making arbitrary decisions and using them to bludgeon the conversation towards your goals.
Maybe try learning how a well built, open source 2D game engine works by reading its code and watching tutorials if you want to progress with making a 2d engine or game…
Do you think I don’t look at existing solutions before building my own? What would be the point of making my own game engines if it wasn’t to learn how they work?
and maybe do the same for a 3D engine if you want to learn how they actually work, instead of talking out of your ass by assuming that 3d games and engines are no different from 2d ones.
Your bar is watching tutorials and reading physics engine code? Seriously? Why do you think I would be arguing about this if I hadn’t done that?
You could plausibly implement some physics to deal with it. If the player is moving into a surface, move them along the part of their grapple movement component that’s perpendicular to that surface. This will allow them to slide along walls/floors/ceilings realistically. For the case where they need to move “through” a small object, you could treat their collision as a sphere and have it collide with the object; for small objects, this could let them pass by. Eg. for grappling sideways over a small rock on the ground, their point of collision would be mostly below them and a bit to the right, but they’re being pulled mostly straight to the right, so they would move perpendicular to the point of contact and move up-right over the rock, then continue their grapple path. Depending on your game’s physics system there are other solutions, but for a typical game engine, that should work well.
That just is running into the problem the original comment was trying to avoid in the first place:
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.
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.
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.
…
Something possibly, sort of like what you’ve described, I think? but not really?.. another idea that might work would be:
Upon detecting a collision, before the player has gotten to the grapple end point… the grapple movement basically complexifies with more nodes.
So you use a pathfinding algorithm to draw, instead of just a line between two points… now you have a point of origin where the player is, the end point, and a third point that is off to the side of the obstruction.
Now for that first segment, now the grapple pulls the player perpendicular to the obstruction surface, so it isn’t constantly colliding and doing friction… and then when the player clears the obstruction, hits that midpoint, the movent vector changes.
This is basically what I described with doing the ‘draw a giant skinny box’ to check if a player can do an unobstructed grapple… but now more complicated as it involves 3D pathfinding…
This could possibly work, but it would take a good deal more work to optimize this, to make your entire world work with 3d path finding… normally, nav meshes are just done on more or less flat ground, up to some degree of incline… but now you also have to do this on literally all surfaces.
Again… this might work … but it would take a lot of game dev work to implement, as you’d have to fully 3d navmesh every level… and this potentially would not handle complex surfaces well.
3D, aerial pathfinding in a very complex environment … to my knowledge, still isn’t really a thing many games have done very well, efficiently, with a general system. It usually just a bunch of manually placed aerial nav nodes, particular to the level itself… very intensive, manual work.
…
You have an odd definition of ‘realistically’.
…
Whoah whoah whoah wow ok gotta stop you there.
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.
This is a terrible idea.
There is a reason hitboxes… are called ‘boxes’.
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.
Like a uh, a small pile of trash or rock that doesn’t interact with the core player movement controller, but it might interact with an inverse kinematics system that slightly modifies the player’s animation so that their foot rests on top of the rubble or rock.
But uh… doing a ‘estimate everything’s size by bounding it with a sphere and then negating movement collision if its small?’
This is not something you’d want to call when the grapple attempt is started, it’d be a massive stutter or slowdown, you’d have to index every object in the level… and you’d end up with like, if you have a pile or array of many small things, all together… well individually they are all small, so you can phase through a pile of many small things that is in totality actually large.
This is the kind of thing you just design your whole game and level and objects around from the ground up.
Again this ‘solution’ of yours (which just entirely abandons the concept of just not colliding with small objects, which you literally just described) 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.
… 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?
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.
You have contradicted yourself and do not realize it. Every tick you attempt to move the player forward, and they encounter a wall… that is a collision, which must be handled by the physics engine, which is constantly running in a loop, which is computationally costly.
You are again describing the scenario the original commenter is trying to avoid.
The player is constantly colliding with the wall in front of them untill they clear it… that is the process that occurs which negates the … going by your image, the x component of the player’s movement, and only results in the y component of movement being realized, untill the wall is cleared.
This causes a massive amount of constantly recurring collision physics calcs which slows down the entire game.
This is the situation you want to avoid via some kind of workaround.
See my original comment, and the response to it from the other 3d game dev.
Yes. It is.
Because it literally is the computationally costly scenario we are trying to avoid.
Hookshot-like grapple hooks are not any kind of realistic.
They only exist in games and movies… they do not exist in the real world, unless you use a body rig with multiple attachment points, a seperate grapple hook launcher, and then also some kind of motorized system in a backpack which pulls you up after you’ve properly connected all the attach points and lines, and verified your grapple has a very solid hold.
For starters, a human with a hookshot style grapple is holding in either one or both hands a device that… lifts them.
Can you bench press your own body weight?
Do a continuous pull-up for 10 seconds, or even just a vertical hang?
Continuously, for the duration of the grapple travel time?
… With one hand?
Sure, a relatively small number of fairly strong people can do this for a short time without too much of a problem … but uh no, the majority of humans can’t even hold onto a bar and do pullups with their entire body weight for very long without becoming quickly tired or exhausted.
Especially if they are also wearing heavy armor and gear and carrying weapons on them.
Next we have the acceleration factor.
If your hookshot style grapple accelerates you quickly… well, chances are it’ll just fly out of your hands.
If you keep a grip on it, it could dislocate your arm.
Now we also have the impact velocity problem.
Does your hookshot grapple have some way of decelerating you as you approach the end point?
… No? Ok, enjoy impacting your target at car accident speeds, and breaking half the bones in your body.
And finally, the dragging or scraping problem.
Take your example image.
Put a human in a mountain climbing harness. Attach a steel linked chain to their chest, throw that chain over the wall, connect it to a pickup truck, and drive the pickup truck forward at 30 mph.
Congrats, your human is now a mangled, bleeding mess of severe friction burns, lacerations , potentially broken bones and torn ligaments, after being dragged up and over the wall, and that is still the case if you say that theres a bunch of pillows behind the wall and the truck stops accelerating once they clear it, so they dont’t fall after clearing the wall.
Again, you have a very strange definition of how a ‘realistic’ grapple hook works. Hookshot like grapple hooks are astoundingly un-realistic… they are a neat and fun gameplay concept, but they are not realistic in any way at all.
LMAO no!!!
Ok, so by ‘proper sphere’ you apparently mean:
A… point cloud made as an infinite number of rays going outward in all directions from the center of the sphere?
Your method here is something you can kind of get away with in 2d, but even then, you’d be defining a circle by a limited number of rays out from the center point… which is the same as just using like, an octagon or 12-gon or 16 or 32-gon or something, at which point you are not talking about a circle, but a polygonal approximation of one.
For it to be a perfect circle, it would have to be an… infinity-gon.
Now… in 3D, your ‘solution’ here is orders of magnitude less efficient… because you have to throw rays from the center point… in all kinds if directions… and unless you use an actually infinite number of rays, you do not have an actual sphere.
What you instead have is some 3d shape comprised of many, many tris that looks like a sphere if you don’t zoom in.
It isn’t, because in 3d engines, 3d spheres that are made of tris are the only kind you can use for a collision mesh… ‘sphere-tri collisions’ are not a thing that exists, outside of something like a super intensive, requires a super computer to run, industrial grade simulator… but hey, you admit you don’t know what you’re talking about, so at least there’s that.
No, they’re called boxes because people who want a performant 3d physics engines or hit detection system know that boxes and other very geometrically simple shapes are orders of magnitude more efficient to use in a main loop that is handling hundreds or thousands or tens of thousands of interacting and colliding objects per tick than it is to use astounding geometrically complex shapes… especially when you also consider a networked game with many players where such calcs need to be highly accurate and also very fast, and use as little bandwidth as possible.
Fair enough, I was trying to be charitable and interpret your confused and contradictory nonsense as something that perhaps made sense and was worded poorly, but nope, it was indeed nonsense, thank you for confirming that.
You answered your own question.
Yes, reading an entire written missive is… how reading works.
I don’t know if you’ve surpassed an elementary school level of literacy, but uh, sentences do not exist as a series of isolated and independent statements which have no connection to each other… they exist in totality as a larger body of text, they provide context to each other, they build upon what was said previously.
Maybe try reading a book or manual or news article instead of just a few quotes or a summary, maybe try detoxing from short form content, that might help.
Nope!
Again, you are describing the entire calc heavy situation that we are attempting to avoid in the first place… as the solution.
It in fact is a lot of extra collision calcs that are problematic… which is why we are trying to workaround it.
You have been presented with a problem, asked to find a way to make it not a problem, and your solution is to simply declare the problem to not be a big deal, probably, idk.
You’d be perfect as an idiot middle manager; your commitment to not understanding anything you claim to understand is impressive, just add in some machiavelkian gaslighting social manipulation tactics and you’ll go far as a corporate middle manager or HR.
I know buddy, I know you don’t know what you’re talking about.
No you are not aware of how 3d engines actually work. 3d engines are enormously more complex and complicated… adding the third dimension into every single physics calc makes everything vastly more computationally costly than physics calcs in only 2d, and this neccesitates an entirely different approach to designing and optimizing such 3d systems.
This perfectly explains what is going on: You’ve exceeded your area of knowledge, you’re in a whole different ballpark, but you assume ‘it can’t be that different!’
In summary, I was correct, you have no relevant experience with 3d engines and have no idea what you are talking about.
Maybe try learning how a well built, open source 2D game engine works by reading its code and watching tutorials if you want to progress with making a 2d engine or game… and maybe do the same for a 3D engine if you want to learn how they actually work, instead of talking out of your ass by assuming that 3d games and engines are no different from 2d ones.
Yes, so you do the calculations once per tick. This is the same looping behavior as the player’s ordinary movement, which is what I said. Not a contradiction. I’m not going to continue arguing with you if you keep intentionally misinterpreting me to try and win the argument (or, maybe worse, unintentionally doing it).
Again, this is once per tick like most other physics calcs / collision checks in the game. Not “massive”, and wouldn’t cause any slowdown.
Even if you implement pathfinding well (check for collisions with obstacles that have moved into the path, account for gravity in the path if not doing a straight-line graople, etc.), you’re doing any calculations all on one frame, which could cause a lag spike. Is this really better for performance?
Pardon my language but this argument is always dogshit. Accepting one deviation from reality (eg. a grappling pack) does not mean you should accept all other deviations from reality (ie. “objects cannot usually pass through each other and basic collisions work like they do IRL”). All forms of (nonfiction) media have an accepted reality that contains some deviations. Should I expect the Milennium Falcon to show up in the third Lord of the Rings movie and blow up Sauron? No? Why not? Lord of the rings isn’t realistic, so we can do whatever we want!
I don’t even think this is a versimilitude problem. You just don’t understand how fictional media works.
You don’t pre-define the rays or points that form the sphere at all. A sphere can be defined by one point and a radius. Two spheres are colliding if the following formula is true:
dist(sphere1.center, sphere2.center) <= (sphere1.radius + sphere2.radius). That check works in 2d and 3d, takes an incredibly small amount of constant time, and is trivially easy to implement. I do it all the time.I’m a bit surprised that no game engines support spherical collisions. But if they don’t, then a collision mesh that only approximares a sphere could be used; it would be less efficient like you’ve been suggesting and less accurate too though. But simple Unity games use capsule colliders all the time, so it can’t be that expensive.
Fair, boxes are usually more computationally efficient. If the effect can be achieved using a box, it’s probably worth it to try using one.
Bro is trying to transparently blame their misinterpretation on me. We’re the only two people here, we both know what’s happening, that doesn’t work. I could have been clearer but you could have recognized your mistake since I described exactly what I meant later. You chose to interpret it in a contradictory manner rather than seeing that your first reading was contradictory and reevaluating to see if there was an alternative, consistent explanation. This will cause you to argue badly.
You say this as if this isn’t exactly the point I was making to you? It doesn’t work in reverse though, because if you actually knew this you wouldn’t have made the related mistakes. So I’m not sure what you’re trying to do here…?
Also, ad hominem. ☝️🤓
You’ve made this point like 6 times already. I disagree that the extra collision checks are an issue. You want to call me an idiot middle manager? Prove that the collision checks would be problematic. Then you earn that right.
Do you think it makes your argument better when you insult people or is that just for fun? What it actually does is signal you aren’t knowledgeable enough in the subject to make your point without insults.
So because I have more experience with 2d engines, I can’t also know how 3d engines work? Great argument bud. (Wow, calling people that is kinda fun! Really gives you an unearned sense of superiority. Why didn’t I think of this, it’s so easy!)
I’m aware of the differences between 2d and 3d engines. I said this already. I knew pointing out my experience with 2d engines would lead you to make this argument, but I don’t care because it holds no water. I pointed it out to give you an example of my background knowledge of physics principles. Most of those principles aren’t actually fundamentally different in 3d, they’re just more complex or costly. Can this lead you to make different decisions based on how costly the computations would be? Yes. But the principles behind how the physics work are not actually that different.
You’re also making a LOT of assumptions about the game engine in the first place. Did the original post even say the engine was 3d??? I made my original post talking in very general terms for a reason: because I know that depending on how the engine works, the splution will be different. This is not news to me. You know this too: eg. common 3d game engines not supporting spherical geometry, 3d and 2d engines having different considerations, the grapple system presumably being a straight-line grapple for your solution, etc. Pointing out that my solution does not work for your chosen parameters is not winning the argument, it’s making arbitrary decisions and using them to bludgeon the conversation towards your goals.
Do you think I don’t look at existing solutions before building my own? What would be the point of making my own game engines if it wasn’t to learn how they work?
Your bar is watching tutorials and reading physics engine code? Seriously? Why do you think I would be arguing about this if I hadn’t done that?