LÖVE

Hi.


This is an older version of bump. Click here to go to the new version

Some of you have been asking how to do collision detection in LÖVE. This might interest you.

But first, do you like eye candy? Me too. Here:



What you see above is the demo of bump 2.0. It is attached at the end of this post. (Go try it, I managed to add some nice music).

bump is a collision detection library. It has changed so much since bump 1.0 that I decided to open a new thread instead of continuing with the old one.

bump only works with axis-aligned bounding boxes (rectangles). If your game needs polygons instead, I recommend giving a look to HardonCollider. If you need complex, realistic physics, then use [wiki]love.physics[/wiki].

In order to use bump 2.0, you first create a world:
Then you populate the world with "items". Items are "your game objects", like the player, the scenario tiles, enemies or missiles. You add them to the world with world:add. For each item that you add, you must provide the coordinates of the {left,top} coordinates as well as the width and height of each item. Usually, items are tables.
If you want to tell the world that an item has moved, you can do so with world:move(item, new_left, new_top).
world:move always moves the item to the new coordinates, ignoring all collisions. If you want to detect collisions, you must call world:check(item, new_left, new_top) before moving. It returns a list of collisions, and its length. There are various ways you can operate with that list of collisions. Here's an example that will move the player only until it "touches" the enemy:
You can remove items from the world with world:remove(item).

That's the basics. The README on the github page has much more information:

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

You can see the source code of the demo in the "demo" branch:

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

Also, there is a simplified example called "simple demo". Here's the branch:

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

I have included a .love for it, too.

Enjoy!

Amazing! I never used the old one since I didn't understood how to use it but now it actually looks more easy to use than HardonCollider.
Now the hard part will be changing my game to use bump.....

PS: That demo is quite good

A question about the demo, what is the advantage to requiring scripts locally in the entity scripts as opposed to requiring everything globally in love.load, other than speed?

Beautiful. I love its simplicity. Just reading at the description of the main function let me know of it works, and how to use it.
And, as the Great Lalorobot said, the demo is stunning.

I would link to point a minor mistake, you probably forgot to add the description of the first argument of world.move

kikito wrote: If you want to tell the world that an item has moved, you can do so with world:move(new_left, new_top).

Code: Select all

world:move(player, 100,300) -- tell the world that the player has moved to 100,300

lalorobot wrote:Now the hard part will be changing my game to use bump.....

Make sure you understand the implications. HardonCollider is able to deal with polygons, while bump isn't.

lalorobot wrote:PS: That demo is quite good

Thanks! It took me a while to make something that was fun, and at the same time I needed to make the code easy to understand.

Roland_Yonaba wrote:I would link to point a minor mistake, you probably forgot to add the description of the first argument of world.move

Thanks, fixed!

Kingdaro wrote:A question about the demo, what is the advantage to requiring scripts locally in the entity scripts as opposed to requiring everything globally in love.load, other than speed?

The execution speed is similar. The main advantage is that the code is more explicit.

By requiring everything needed at the top of a file, I'm comunicating the dependencies of that file. You can read it and know everything that is needed to know.

If I put everything in global variables, you have to work harder. For example: if you want to make a change on entity.lua, will explosion.lua be affected? Since I put the requires at the top of the file, you can know immediately (no, explosion.lua doesn't require entity). Without them, you'd have to manually "scan" the whole file looking for references to Entity.

It's a bit like the difference between passing parameters to a function or using global variables. This:
vs this:
On the first case, the function is telling you everything you need to know about it - all its dependencies are explicit. On the second case, name is an implicit dependency. On this case is very trivial to see, but with longer functions those are very easy to miss.

A small update:

I just introduced a speed optimisation on the world:move function that makes it both faster and less memory-intensive at the same time. The new source code (for the library and the demos) is on github. I didn't bother updating the demos on the OP because visually they behave the way (memory just gets consumed more slowly on simpledemo).

Kikito, I like this so much that actually I'd encourage you to turn this into a game! I really like the movement, its overall style, and especially the sounds. It feels good to move around, and I think it's fun to beat the guardians. So, what do you say?

Hi,

Funny that you mention that. You are the second person to bring this up since last weekend. I might, I don't know yet . Thanks.

I found a typo on the README in the example on this line, it's missing a bracket:

Thanks! Fixed.