[library] bump 2.0 – Collision Detection

[kikito]

Ugh... looking at player.lua... is it possible to use this library without multiple dozens of lines of cryptic code spanning multiple functions? I sort of grasp the general structure of how it all works, but I am in no way even close to being capable of understanding it well enough to be able to modify it.

Have already looked at the simple demo?

I honestly have no clue at all about how I could go about making some entities static while others aren't

If I were doing what you are doing I would use an attribute for the items - and then do something like if item.is_static then .... Or maybe I would have two sets of objects, one static and one dynamic. Or maybe a combination of both.

allowing two-way bounces(both entities bounce, depending on their mass), or even implementing proper friction.

Friction can be modeled easily, but two-way bounces can be tricky; in bump, objects move one-at-a-time, as they do in games, not all-together-at-the-same-time, as they do in physics simulations.

Not to mention I don't want to have to somehow guarantee that the updates happen in the right order which seems to be an absolute necessity in the demo....

I confirm that updating things in a fixed order is a requirement. That is the way things are done in lots of videogames; entities are updated in order, and they react to collisions in order.

If you need something more simulation-y, I'd investigate [wiki]love.physics[/wiki] or HardonCollider

[tacospice]

Is there some easy way to replicate the behaviour of bump 1.0, where you only set up a handful of callbacks and then call bump.collide()?
The ease of doing that was the main reason I went with bump originally, and looking at 2.0 it doesn't seem that simple anymore..

[kikito]

No, sorry.

In my opinion the "ease" of bump 1.0 was misleading. Sometimes things are overcomplicated; the reality is less complex than the design. A car with 6 wheels would be an example - you only need 4 or even 3, to make it stable.

Other times it's the opposite: things are made too simple, while the reality is more complex. (A car with only one wheel is too unstable).

After studying and reflecting over collisions for more than 2 years I came to the conclusion that my initial attempt was the latter. Collision detection can be done simply, but not as simply as I did on my first try. I was treating the problem as if it was simpler than it really is, and there were weird behaviors cropping out as a result. The most obvious one is that a player walking on a flat tiled surface would sometimes collide with the tiles, and stop. This was not a bug; it was a manifestation of that oversimplification. I could not think about a way to solve that issue with the old implementation.

There's also the fact that I know think that libraries should never store information themselves. That's why I return a "world" instead of doing things "inside the library". I think this is The Right Way to do things.

I am sorry that you don't like the new interface. It's the best one I could come up with for dealing with these problems. If I find a way to make it simpler, I will. You can still use bump 1.0 if you want, but I think some of the bugs that you'll experience are just not solvable with that architecture.

[Kingdaro]

I love the library and its efficiency, and it does work so much better than version 1.0, but I too find it a bit annoying that, relative to just normal collision detection, standard collision resolution for platformer games or even just top-down games require so many lines of code, and I feel as though there must be a way to simplify that.

Perhaps you could add an iterator function for convenience to world objects, to allow the seamless and elegant resolution of items? I suggest an iterator instead of just a flat utility function so that the player can do what he/she needs to do to move their objects, instead of the library doing it for them. To elaborate further, I've taken this bit out of the player class in the demo, which is what I've used as a reference to resolve collisions my own way. I've rewritten the code as though there were such a mathemagical function.

Code: Select all

function Player:moveColliding(dt)
  self.onGround = false
  local world = self.world

  local future_l = self.l + self.vx * dt
  local future_t = self.t + self.vy * dt

  local cols, len = world:check(self, future_l, future_t, playerFilter)
  if len == 0 then
    self:move(future_l, future_t)
  else
    for col, tl,tt,nx,ny,sl,st, clear in world:resolveSlide(cols, len) do
      if clear then
        self:move(sl, st)
      else
        self:changeVelocityByCollisionNormal(nx, ny)
        self:checkIfOnGround(ny)
        self:move(tl,tt)
      end
    end
  end
end

The function would keep it's own internal visited table, and would continue to run while there were collisions. If len were 0, it would run once more, making the "clear" variable true to let the code know that this is the case in which there are no more collisions to resolve, and that the player is free to continue forward.

I'm not sure if something like this would work, but if you can figure something out, a solution like this would be quite nice.

[kikito]

You are not the first ones to complain about the complexity on the library, and to certain extense, it bugs me too.

I will pass the rest of the week travelling and in conferences, but I will at least try to give this some thought. Thanks for your feedback.

EDIT: I have been pondering at this problem longer than I wanted, but I think I found a solution last night - it will require some heavy rewiring. Only "detail" missing now is writing the code.

[Jasoco]

Any progress on the rewrite? I've been using Bump for my platformer and was wondering if you'd done anything with the next version?

Anyway, I am having trouble figuring out how to do "one way" platforms. i.e. like in Super Mario 2 and 3 where the platform only becomes solid from the top, but you will pass through the left, right and bottom with no problem. I've tried everything. Maybe I'm just not seeing it. The demos don't show off this behavior sadly so I have no idea the best way to do it.

[undef]

Just check whether the feet of your character are inside the platform, and if so you put them on the platform.
I don't know how this works with bump, because I've never used a collision libary, but in generally speaking you just make an extra collisionbox which is a part of the players normal collisionbox (just the part where your players feet are), and check it against the plaforms.

[kikito]

Any progress on the rewrite? I've been using Bump for my platformer and was wondering if you'd done anything with the next version?

Hi there! Yes, there is advancement, but it is still not ready. I've got a semi-important event next thursday that is taking all my available free time. I tried to make a complete release before that, but I didn't succeed. What I have done is in the "dev" branches of the repo (library, simpledemo, demo). It now can do the collision resolution almost automatically, without so many "manual loops". I am still not satisfied with the interface completely, and I will probably change some names, but it works and it's less cumbersome.

Anyway, I am having trouble figuring out how to do "one way" platforms. i.e. like in Super Mario 2 and 3 where the platform only becomes solid from the top, but you will pass through the left, right and bottom with no problem. I've tried everything.

I can think of two ways of doing this. The first one is: when the player is moving "up", filter all the 1-way platforms. You can do that using the "filter" param. That's probably the simplest way to do it. The second way I can think of is: calculate the collision, but only "respond to it" when the collision normal goes "up" for platforms. If you get a platform and the normal is not up, just skip it and continue with the next colision.

If you need code for that, let me know. You may also want to hold off for a bit until I release the new version.

Just check whether the feet of your character are inside the platform, and if so you put them on the platform.
I don't know how this works with bump, because I've never used a collision libary, but in generally speaking you just make an extra collisionbox which is a part of the players normal collisionbox (just the part where your players feet are), and check it against the plaforms.

That "frame-based" way of thinking can have very nasty consequences in a fast-moving, non-constant framerate game. They will manifest more or less randomly, and depend on things like the CPU speed, and sheer luck.

For example: if the player is falling fast enough - so fast that in 1 frame near, but not touching the platform, and on the next frame his feet have already traversed it completely - he may fall through the platform.

Bump works in a "continuous" way - it does not only check if things are "currently inside others" - it also checks that "things have gone through others" (even if they are not currently colliding at this very instant). Figuring out how to do that was what took me the most time.

[Kingdaro]

Anyway, I am having trouble figuring out how to do "one way" platforms. i.e. like in Super Mario 2 and 3 where the platform only becomes solid from the top, but you will pass through the left, right and bottom with no problem. I've tried everything. Maybe I'm just not seeing it. The demos don't show off this behavior sadly so I have no idea the best way to do it.

Basically, you'll need to store the position of the player's previous frame. Then, when it collides with the one-way platform, you check if the position of the player's bottom bound on the previous frame was above the position of the top bound of the platform. And if so, resolve. Otherwise, let him/her fall through, because if they weren't above the platform on the previous frame, in all circumstances, they are falling through it, whether they are going up or going down.

Something like this:

Code: Select all

function Player:collideWithOneWay(platform)
	if self.prevY + self.height < platform.y then
		self:resolveCollisionWith(platform)
	end
end

function Player:update(dt)
	-- ...

	self.prevX, self.prevY = self.x, self.y
end

I can think of two ways of doing this. The first one is: when the player is moving "up", filter all the 1-way platforms. You can do that using the "filter" param. That's probably the simplest way to do it. The second way I can think of is: calculate the collision, but only "respond to it" when the collision normal goes "up" for platforms. If you get a platform and the normal is not up, just skip it and continue with the next colision.

Just check whether the feet of your character are inside the platform, and if so you put them on the platform.
I don't know how this works with bump, because I've never used a collision libary, but in generally speaking you just make an extra collisionbox which is a part of the players normal collisionbox (just the part where your players feet are), and check it against the plaforms.

The problem with both of these approaches is that, when the player is inside of the area of the platform but is moving down, you'll get this effect where the player "pops" to the top of the platform. Without some kind of threshold in place, it can look a little unnatural.

[kikito]

The problem with both of these approaches is that, when the player is inside of the area of the platform but is moving down, you'll get this effect where the player "pops" to the top of the platform. Without some kind of threshold in place, it can look a little unnatural.

Yes, you are right. Filter out one-way platforms whose base is above the feet of the player when the movement started.