LÖVE

What would be the best way of checking if an item is in a world? I might be missing something, but I don't see a straightforward way of doing it.

You are completely right. I had the same problem in a project I am doing, and I added it to my local copy of bump.lua, but forgot to include it on the main repo. Give me one minute ...

EDIT: Done - I've added a new method, world:hasItem(item), which returns true if item is inside the world, and false otherwise. I've also released v2.0.1. The only change is the addition of world:hasItem, and it doesn't affect the demos, so I am not updating them just yet.

Thanks!

That looks terrific!
I am tempted to write a jetpack powered platformer now! Too lazy for that though...

You know, that demo is only missing a machinegun and it would be release-ready.

Thanks!

I am trying to do more than just adding a machinegun. But we'll see

Could someone tell me what are the benefits of using this library (or HardonCollider for that matter) over the love.physics library?

Compared with love.physics:

Cons:

• bump.lua doesn't do physics - just collision. If your game needs physics, you have to would have to code them yourself.
• bump.lua only handles axis-aligned rectangles. If you need polygons, it wont work for you.
• bump.lua is gameistic. You move one object each time (you move the player first, then the bullets, and then the enemies, for example. You can do all of that on the same frame, just not at the same time). If your game logic needs all objects to be moved exactly in parallel, you might have issues (although this is very rare, games usually move one element after the other)

Pros:

• bump.lua doesn't do physics - just collision. Box2d provides a realistic physics model. But a lot of games are not realistic. When using box2d, you end up "needing a lot of tricks" to make the game work unrealistically. Programming those is actually harder than programming your own physics logic from scratch if your game doesn't need a ton of realistic physics.
• bump.lua only handles axis-aligned rectangles. If your game only needs those, you don't have to learn a complex interface prepared to work with polygons. That's why bump.lua has only 4 main methods and 3 collision resolution methods (plus some extra methods like world:hasItem).
• bump.lua is gameistic. If your game logic requires that you first move the player, then the bullets, and then the enemies, it'll be easier to do that with bump than with box2d

I haven't used HardonCollider enough to give you a comparison with a good degree of certainty, but I think it's the same except that HC, like bump.lua, doesn't provide a physics simulation (First pro/con can be removed)

Does this library provide a means of collision detection and resolution, or just the former?

Collision detection and resolution.

Here are the relevant bits in the docs:

• Detection: https://github.com/kikito/bump.lua#collision-detection
• Resolution: https://github.com/kikito/bump.lua#collision-resolution

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.

I'd like to use it for purposes of a generic AABB physics engine for a small component-entity engine thing I'm coding, but I'm really wondering if I can.... I honestly have no clue at all about how I could go about making some entities static while others aren't and allowing two-way bounces(both entities bounce, depending on their mass), or even implementing proper friction. 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....