I am working on a small platformer where the ground is a bunch of lines kept in a list. I'm trying to make it so that when the player touches a line, they get pushed out of it in the opposite direction that they were moving. The player has 5 variables, player attempt x, player attempt y, player velocity x, player velocity y, and player radius. I made a desmos graph to show what I'm trying to do if that helps: https://www.desmos.com/calculator/uliuzse9wr
Here's my script so far, but it sadly causes the player to violently teleport around the level. Does anyone have any ideas about how to fix this?

Just copy the gravity script from a platformer

qwertycodechamp90411 wrote:

Just copy the gravity script from a platformer

@qwertycodechamp90411, thank you for taking the time to leave a response, but this is not what I am looking for. I am trying to understand the process of mathematically calculating solid body collisions and simply taking other peoples work does not accomplish this.

you could use some triginometry to do this. for example if we had a diagonal wall rotated 45 degrees (like this: /) we would change x by the cos of the angle+90 degrees and change y by the sin of the angle and repeat that until it is no longer touching the wall

if <touching [wall v] ?> then
repeat until <not <touching [wall v] ?>>
change x by ([cos v] of ((angle) + (90)))
change y by ([sin v] of (angle))
end
end

also that +90 degrees may not be necesarry so if it still is glitchy try removing it, or do -90 degrees.

FunTech_Studios wrote:

also that +90 degrees may not be necesarry so if it still is glitchy try removing it, or do -90 degrees.

Hi @FunTech_Studios, thanks for taking the time to leave a response. Translating x by cos( angle + 90 ) is likely glitchy because it's the same as translating x by sin( angle ). If we correct that mistake, this solution works perfectly for colliding with a single wall, however at the corners of two steeply angled walls, it falls apart. To illustrate this, look at this diagram.

In this scenario, the walls towards the beginning of the list (which in this case is the red one) get “snapping preference.” We can see that this is problematic. because it causes unexpected jumping at corners. Now one might think, “Ah! Simply order the lists so that vertical walls get selected first!” While at first this seems to be the correct answer, we get the same behavior as before, only with walking on the ground. With this ordering, a player walking towards a corner will be thrown off the edge if they get too close. Because of this, this is unfortunately not what I’m looking for, but it’s a step in the right direction.

Just for reference, here is your solution with no touch sensors or repeat until's, where the players position is stored in player attempt x and player attempt y.

Also here’s a graph to show the snapping: https://www.desmos.com/calculator/zvxhw9i1yq

minekraftkid wrote:

Now one might think, “Ah! Simply order the lists so that vertical walls get selected first!” While at first this seems to be the correct answer, we get the same behavior as before, only with walking on the ground. With this ordering, a player walking towards a corner will be thrown off the edge if they get too close.

Could you sort by distance from player to the closest point on line, and select walls with the closest “closest point” first?
This page has the math for the closest point on a line to a given point: http://www.jeffreythompson.org/collision-detection/line-circle.php

nomos13 wrote:

minekraftkid wrote:

Now one might think, “Ah! Simply order the lists so that vertical walls get selected first!” While at first this seems to be the correct answer, we get the same behavior as before, only with walking on the ground. With this ordering, a player walking towards a corner will be thrown off the edge if they get too close.

Could you sort by distance from player to the closest point on line, and select walls with the closest “closest point” first?
This page has the math for the closest point on a line to a given point: http://www.jeffreythompson.org/collision-detection/line-circle.php

Hi @nomos13, thanks for pitching in! This idea has some merit, but I feel like it is a fairly expensive technique due to the lines needing to be sorted each tick. That could possibly be mitigated by pre collision work such as quad trees though. I’ll look into this, thanks!

minekraftkid wrote:

nomos13 wrote:

minekraftkid wrote:

Now one might think, “Ah! Simply order the lists so that vertical walls get selected first!” While at first this seems to be the correct answer, we get the same behavior as before, only with walking on the ground. With this ordering, a player walking towards a corner will be thrown off the edge if they get too close.

Could you sort by distance from player to the closest point on line, and select walls with the closest “closest point” first?
This page has the math for the closest point on a line to a given point: http://www.jeffreythompson.org/collision-detection/line-circle.php

Hi @nomos13, thanks for pitching in! This idea has some merit, but I feel like it is a fairly expensive technique due to the lines needing to be sorted each tick. That could possibly be mitigated by pre collision work such as quad trees though. I’ll look into this, thanks!

Hi again - I don't know what your levels will look like and I didn't look at your code enough to understand exactly how you're implementing anything, so sorry if I'm just suggesting a bunch of unhelpful things. :‪)
But maybe it would be a bit less expensive if you only sorted the lines that have vertices within 50 px of the player? (And you probably already know this, but when comparing distances, you don't need to take the square root, which make things marginally faster if you have a lot of lines on the screen.)

nomos13 wrote:

Hi again - I don't know what your levels will look like and I didn't look at your code enough to understand exactly how you're implementing anything, so sorry if I'm just suggesting a bunch of unhelpful things. :‪)
But maybe it would be a bit less expensive if you only sorted the lines that have vertices within 50 px of the player? (And you probably already know this, but when comparing distances, you don't need to take the square root, which make things marginally faster if you have a lot of lines on the screen.)

I haven’t decided on how levels will be loaded and handled yet, and I’m always open to suggestions. I’ve been trying to get a system that creates AABB trees working, but I’ll likely just end up breaking areas into zones, since it’s to much easier to implement. Regardless, I agree that broad scope collision detection would help lower the cost.

nomos13 wrote:

Could you sort by distance from player to the closest point on line, and select walls with the closest “closest point” first?
This page has the math for the closest point on a line to a given point: http://www.jeffreythompson.org/collision-detection/line-circle.php

Actually if I use the vector made from the closest point and the player to push the player out of the line segment, the snapping issue should resolve itself without any need for sorting. This would also allow me to implement double sided walls. Thanks for the help!

minekraftkid wrote:

nomos13 wrote:

Could you sort by distance from player to the closest point on line, and select walls with the closest “closest point” first?
This page has the math for the closest point on a line to a given point: http://www.jeffreythompson.org/collision-detection/line-circle.php

Actually if I use the vector made from the closest point and the player to push the player out of the line segment, the snapping issue should resolve itself without any need for sorting. This would also allow me to implement double sided walls. Thanks for the help!

Oh, cool! That's a nice solution, glad I was able to contribute.