[library] bump.lua v3.1.4 - Collision Detection

[kikito]

Wonderful. I will pack this fix with a couple performance improvements I have been planning for a while and will release 3.1.3.

Your game looks rad, I like the playable map editor

[kikito]

I have updated and released bump 3.1.3

This new version includes the fix I did for Fenrir as well as a slightly faster and less memory-intensive implementation of world:update.

It is available on github:

https://github.com/kikito/bump.lua

I didn't bother updating the attached examples on the OP, but the code for demo, simpledemo and platforms is updated to 3.1.3 on their respective branches in the repo.

[kikito]

I have released bump 3.1.4

The changes on this version are really small: I made a mistake which was leaking a global variable (called _) in one line. I have put some automated testing in place (using luacheck) which will warn me if I make the same mistake again in the future.

This change is totally backwards-compatible with the 3.1.x branch, so you can update safely.

Appart from that, I have been thinking about how to implement slopes in bump. There are several things I have considered.

The first consideration is that in my opinion at least, slopes should "collide with the center of the feet of the player", not with their "corners". Example from Mario:

bump-ramp1.png (45.15 KiB) Viewed 3350 times

This makes things difficult when getting to the "top" of a ramp: the "solid tiles" next to the ramp would collide with the player's corner and not let him move completely up (because he would collide left or right):

bump-ramp2.png (45.75 KiB) Viewed 3350 times

One option would be adding some "horizontal extra space on the ramp". So they would look like this:

bump-ramp3.png (45.53 KiB) Viewed 3343 times

The inconvenient of this solution is that it makes specifying a ramp a bit more complex. It also doesn't work for all kinds of players (a Mario which is wider than the extra space will still collide with the tiles after the ramp)

Another option would be making the horizontal tiles not collide with the player when they are using a ramp. The simplest way to do this would be a filter. This also has issues: the "ramp logic" would be split between a "new collider" and "a specific filter". Also, newbies in particular seem to have trouble with filters.

That is my state of mind so far. What do you guys think? (Especially Jasoco, who seems to be the most interested one in ramps).

EDIT: changed the third image

[Kingdaro]

How about this: treat the ramp initially as just a regular AABB, but after everything is resolved that way, "bump" the box colliding against the ramp down where it's actually supposed to be. If something is colliding against multiple ramps, "bump" it down to whichever has the highest position. I imagine there's a way to make this all work with multidirectional ramps, but with ramps against ramps... seems a little screwy.

[ivan]

One option is to represent slopes as 'segments'.
These are well suited for continuous collision detection.
I tried to implement this in "FizzX"
and I was pretty successful with circle vs segment
but with aabb vs segment I couldn't find an elegant solution.
The basic technique I used is:
1.get the collision normal of the slope/segment by rotating it 90 degrees
2.a)project the center of the colliding shape on the normal axis
b)project the extents of the shape (radius or width/height) on the normal axis
c)project the distance traveled (velocity*dt) parallel to the normal axis
3.using the projected values in step 2, check if the shape has crossed the slope,
this gives you the 'penetration depth' or the 'time of impact'
The nice thing about line segments is that you can make them one-sided
(by checking if the velocity parallel to the collision normal).
So this way you can support both slopes and one-sided platforms.
With circles it worked great, but for AABBs - I couldn't come up with a good way to deal with the corners of the slope.

[kikito]

@kigdaro: resolving things like that will probably have undesired effects. The one I am thinking about is: imagine that there is a solid block "on top" of the ramp bounding box. Even if Mario "fits vertically" below it, he will collide with the top block if I treat the ramp as a block. I don't think I will go that way, but I applaud your resourcefulness.

@ivan

Even if I treat the slope as a segment, I will still have an issue when mario is "going up" and arrives next to the block at the top, he'll still get stuck. Unless you are suggesting that I replace all the AABBs by segments (I don't think I can pull that off).

I thought of a possible workaround. It is ugly and horrible. It basically involves not using the "center" of Mario, but instead using his "corners" ... and then "miss-align" the ramp drawing by half of mario's width. Something like this:

bump-ramp4.png (46.93 KiB) Viewed 3304 times

It is a hack and I don't like how it looks. It "feels wrong". But so far it's the solution which presents the least issues, at least that I could think of.

[I~=Spam]

Yeah.. I wish there was a better way but that seems like the only sane way... maybe you could have the ramp be modified based on the object being checked for collisions with. That way different things can walk up the ramp at the same time and have it look convincing.

[Jasoco]

It seems you are thinking exactly as I do about this issue. The slopes thing that is. While I agree the added buffer at the edge would be hacky, it would probably be the easiest way to handle it given the methods you use. Problem is, it won't take into account entity bump objects that are wider than twice that buffer width. Say the buffer is 8 units wide, it would only work on entities that are up to 16 units wide. But something 17 or more might end up getting caught on the lip of the slope top without warning. So as long as you offer a way to configure how wide the buffer should be there won't be a problem. (And let us enable or disable the buffer for each axis as well as customize its size for both axis' too.)

But it needs to be done. I would really love to see slopes. Even if it does feel hacky. But if you don't use buffers, I'd still work with the "workaround" if needed to. Actually, in some cases it might be the preferred method. (Or just make buffers optional? I dunno. Method 2 would be good for top down games.) Just make sure it's easy to make it so when we push against a slope, we can slide along it.

Also, now I understand why my global log was reporting a stray variable called "_". I thought it was my fault. Eventually I gave up trying to find it.

[Fenrir]

I thought of a possible workaround. It is ugly and horrible. It basically involves not using the "center" of Mario, but instead using his "corners" ... and then "miss-align" the ramp drawing by half of mario's width. Something like this:

I would totally go for this solution, I don't find it ugly or horrible! You let the responsability to the developer to align accordingly his art, or when detecting a collision with a ramp he can move the character sprite (or use a specific sprite aligned accordingly). And at least with this solution it keeps the ramp definition and representation simple (and I must admit I'm quite concerned by this aspect for tool development).

EDIT: and yeah I forget, for top down games it makes also more sense to go for this solution.

[Positive07]

I thought of a possible workaround. It is ugly and horrible. It basically involves not using the "center" of Mario, but instead using his "corners" ... and then "miss-align" the ramp drawing by half of mario's width. Something like this:

I would totally go for this solution, I don't find it ugly or horrible! You let the responsability to the developer to align accordingly his art, or when detecting a collision with a ramp he can move the character sprite (or use a specific sprite aligned accordingly). And at least with this solution it keeps the ramp definition and representation simple (and I must admit I'm quite concerned by this aspect for tool development).

EDIT: and yeah I forget, for top down games it makes also more sense to go for this solution.

Yeah I would go for a normal ramp, no miss alignment or something like that, just a normal ramp, if the user wants to offset the character he can do so, by adding an extra box inside of his player and filtering collisions with that box instead of with the character

bump-ramp1.png (112.57 KiB) Viewed 3232 times

Yeah maybe to get the desired effect you will need to extend the ramp a little as you described, but that is pretty simple actually, just leave the decision to the programmer because you cant satisfy all otherwise