Platformer collision issues

[supagu]

I've been working on a platformer and I am having issues where my player can't slide along the platform which is getting stuck on the edge between tiles.

Source code available here: https://github.com/bit-shift-io/fido-and-kitch

inn map.lua:138 I print out the rectangles for my tile collisions which looks like this:

Code: Select all

print('rect:', quadX, quadY, width, height)
				local col = Collider{
					shape_type='Rectangle', 
					shape_arguments={quadX, quadY, width, height}, 
					body_type='static'
				}

Code: Select all

rect:	752	48	32	32
rect:	784	48	32	32
rect:	816	48	32	32
rect:	848	48	32	32
rect:	880	48	32	32
rect:	912	48	32	32
rect:	944	48	32	32

you can see width and height is always 32, and the spacing is always 32 between each tile so there should be 0 gap between tiles.

My player is setup a a fixed rotation, dynamic body rectangle (player.lua:71) and I use setLinearVelocity to apply the player movement (player_states.lua:116)

Yet for some reason the player occasionally gets jammed on the corner of a tile, but not always.... and I'm not sure why!?

If you run for you self, test the map "ll1.lua"

[MrFariator]

This is a little issue that can happen with a fair few physics implementations that do not correctly handle "gliding" along the surface where multiple collision boxes might meet. I've had this exact thing happen with bump.lua, though you seem to be using box2d (love.physics). In principle, it's got something to do with the diagonal movement when you're applying both gravity (player going down) and horizontal movement (walking, running, etc). The physics try to apply that diagonal movement, then detect a gap, basically cutting the movement on one of the axes short.

A fairly simple fix is to simply step the player and objects first on one of the axes, and then the other. Personally I move on X axis first, then Y. If you're dealing with tile-based geometry, this ensures that the player always moves over the seams between tiles when grounded, and similarly doesn't get stuck on any corners when jumping/falling and hugging a wall. Handling collision responses can become a bit awkward, though, if both X and Y collisions detect things like pickups, hazards or enemies. You'll just have to be careful to treat every one of those instances just once.

[supagu]

Thanks for the help but it is a bit unclear how you step on X then Y? Can you do a bit of pseudo code or modify the sample program I have attached?
I've built a simplified love example of the problem I am having (see attached zip file)

[pgimeno]

This is a pretty annoying and also ubiquitous problem. I've experienced it even in games made by big companies, such as NFSMW where I crashed against a non existing wall in the border of the road, and when passing the same area again it was no longer there.

The problem here is that the physics engine checks collision between the player and the far box first, and it detects that the player would collide with one of the vertical sides (because of gravity) therefore it stops the player; the collision check with the box at the bottom, which is what keeps the player levelled on the ground, comes too late.

With Box2D, the engine itself behaves that way and there's little that can be done. One idea is to expand the boxes so that they have ramps, but I can't guarantee how well it will work. The idea is to make the floor collision be made of polygons like this:

bitmap.png (4.78 KiB) Viewed 4083 times

(top: basic shape; middle and bottom: two and three shapes together, respectively)

The ramp should prevent collision with a vertical wall in theory, but it might not work in practice.

If you can get rid of love.physics and implement your own physics, then you have control over the collisions. Note however that bump suffers from this same problem, so you'd have to implement your own collision system that avoids this problem.

[supagu]

I see here it looks like a similar issue has been discussed
https://love2d.org/forums/viewtopic.php?f=5&t=81075
I think the problem *might* have been solved in bump or splash physics engines?

[pgimeno]

With Bump I've seen problems of that kind, despite the author's efforts.

As for Splash, I'm not sure if it implements collision resolution.

I forgot about something. Instead of making boxes for the platforms, you can make the player's collision box be capsule-shaped (capsule as in pills). That implies having three fixtures in the player's body: two circles and a box.

[MrFariator]

Thanks for the help but it is a bit unclear how you step on X then Y? Can you do a bit of pseudo code or modify the sample program I have attached?

It's a fair bit more difficult with box2d, because of how the engine is set up to basically step everything at once, as opposed to one-at-a-time like how bump (and couple other collision libraries) do it. pgimeno's advice is probably more relevant for box2d (using different collision shapes etc).

In bump terms though, the pseudocode is something akin to:

Code: Select all

-- calculate new destinations in whatever manner you prefer
local goalX = x + currentXSpeed
local goalY = y + currentYSpeed

-- step the axes separately
local newX, _, colsX, lenX = world:move ( obj, goalX, y,     filter ) -- step on x
local _, newY, colsY, lenY = world:move ( obj, newX,  goalY, filter ) -- step on y

-- ...resolve collisions for x and y steps
-- watch out for duplicate collisions!

This is what I do in my code, and it resolves the "getting caught on tile gaps" issue for me, though it does complicate looping through collisions a bit. I guess I could've modified bump to return a single collisions table for handling stepping an object like this, but oh well.

[supagu]

Thanks guys. I now have this working by changing away from box2d.
I tried bump (love-physics-test-2.zip) and that was the easiest to get working. It didn't need to split x and y components, it just worked out of the box.
I also managed to get HC working with some extra code (love-physics-test-3.zip).