Collision detection without physics?

[Мэтю]

I need a help to create a system do detect collision in sprites. Example:

Walls with player, zombies
Bullet with zombies, and on collide, zombies take damage

ETC ETC

Someone have any idea about that?

Prototipo1.png (20.09 KiB) Viewed 20772 times

My love file:

lel.love

(209.73 KiB) Downloaded 590 times

Any help is welcome

[lachlaan]

I'd suggest giving every entity a hitbox and checking out http://www.love2d.org/wiki/BoundingBox.lua for lightweight collision detection. Should be what you need. Alternatively check how they do it and implement it yourself with circular hitboxes for more accuracy when it comes to dealing damage and so on.

[Plu]

You could also consider using Hardon Collider:
http://love2d.org/wiki/HardonCollider

It does the collision detection minus the physics.

[veethree]

I posted a little bounding box collision detection and response demo a few days ago you could check out. I'd link to it but I'm on my phone so I don't feel like it. Should be on the 1st page in the projects and demos section.

It's worth noting it not very well optimised but could give you an idea on how to implement it.

[Мэтю]

sorry, i don't use the computer by some days, now i used the hardoncollider, i did the collisions ,etc, but now i'm having some issues, like the collisions shapes are changing on load game. Ex: some times the wall shape assumes the zombie functions or bullets function. I'll post my .live file and you will see

Protótipo1.love

(33.32 KiB) Downloaded 443 times

[Inny]

Okay so here's a quick primer on different collision detection techniques and what you can rig yourself without the need of love.physics. So, lets first make a distinction, there's Collision Detection and Collision Response. Not only do you have to detect that a collision has happened, you also have to respond to that collision somehow.

Collision Detection has two types: Broad Phase and Narrow Phase. Broad Phase is where you keep some data on the objects to know which objects are near which other objects. This is where you hear terms like "Binary Space Partition" or "Spatial Hashing" thrown around. These are more advanced topics and are only necessary when you get into the hundreds to thousands of entities all banging around at once. We can skip it.

Narrow Phase collision detection is where you compare every object to all of its nearest objects to see which ones it may be colliding with. In its simplest form, you can do a comparison of the two rectangles to see if they overlap, and bam, that's a collision. The problem with that form is that you may have some very fast moving objects and in a given frame, their change in position can go completely through each other and the overlap check would not catch it. So, what you do here is that you don't just move an entity to where it's going every frame. Instead, you move it through the space towards its destination, and check for collision at each step. Consider it a game of Mother-May-I going at high speed.

Lastly, you have to do a Collision Response. There's two types here: Elastic, and Rigid (also called Inelastic). Rigid is easy to understand. A car slamming into a brick wall. It just stops dead. In your math, that means the motion vector gets zeroed out. Elastic collision is where you have two billiards balls hitting each other on top of a pool table, and they bounce in opposite directions after the hit.

So, now that you know what collision detection is. Here's how you do it:

1. Each frame, treat the world as a turn-based game, and each entity gets its turn to move.
2. Compare each entity's motion to the world and other entities to see if a proposed movement is valid, and you do this by doing collision detection with where the entity is going against where everything else is.
3. Where the entity is going should be treated as a sliding motion. With a high enough frame rate, that motion will be a few pixels and you shouldn't have to worry too much, but when you have a lot of bullets, those bullets will have to slide along by at least the size of their smallest possible target, to make sure you catch it.
4. When you slide an entity along, each spot that doesn't have a collision is a valid spot to move to. When you have an invalid spot due to collision, then the previous spot that was valid is where the entity should show up. This can be greatly refined so that you can find the exact pixel, by subtracting the difference of the bounding boxes of each entity to find where they'd be side-by-side after the collision response.
5. Things like bullets can respond to collision by disappearing.
6. A good trick is to do the collision detection in two phases: horizontal and vertical. As in, slide the entity along in a zig-zag shape. In a jumper, this allows for easy sliding against walls, as only your horizontal vector gets zeroed, by the vertical doesn't have to be.

So now that you know all this, maybe look around at some of the libraries others have written to see what they do.

[thedarkcoder]

Few years old, but here's a handy little function to detect collision between two images Where "a" and "b" are the variable name of two images.

function collision(a, b)
aw, ah = a.img:getDimensions()
bw, bh = b.img:getDimensions()

return a.x < (b.x + bw) and
b.x < (a.x + aw) and
a.y < (b.y + bh) and
b.y < (a.y + ah)
end

[ivan]

Good summary by Inny, just a slight correction in his terminology:

There's two types here: Elastic, and Rigid (also called Inelastic)

The degree of "relative kinetic energy retained after a collision" is called the restitution coefficient.
The restitution coefficient determines whether collisions are elastic or inelastic.

More broadly speaking, bodies can be categorized as rigid or deformable.
love.physics (or Box2D) supports only rigid body physics!

Implementing your own collision system can be quite hard. The simple way (called discrete) is to just move all bodies based on their velocity. Next you iterate all pairs of intersecting bodies and separate them so they no longer overlap. Continuous collision detection is where you "sweep" each body so that you can find the exact time of the collision. The latter can be pretty complicated, so at that point you might as well use love.physics.

Here are a couple of relevant tutorials:
https://2dengine.com/?p=intersections
https://2dengine.com/?p=collisions

Going back to the original post: love.physics allows you to have collision detection without any response by using "setSensor".

[Przemator]

I'm trying to rewrite a 20yo racing game, which is using black&white mask PNGs for collisions. Black = Track, White = Wall. And the car is also White. I'm trying to figure out how to implement it with löve. How would I even detect a collision using images? And if there are many cars, should I check every collision bilaterally? That means if there are 5 cars, there will be 25 checks + 5 checks against the track. And what if I want car to push the car it collides into? And what if all cars go next to each other into a wall? It could result in pushing them all off the track.

Box2D would be an option, but how do I convert a black-white mask into box2d objects? There are hundreds of tracks!

[raidho36]

I suggest replacing the sprite masks with physics geometry. You could write a program that generates the geometry from sprites automatically, or create geometry by hand to get best results.