I haven't been here in ages, mostly because I've been playing around with the game library Gosu for the Ruby programming language. That said, I'm in the mood for some Löve again. I've come to ask about what is likely the bane of my entire existence in game development: collision detection and resolution.
I'm asking with an overhead Robotron-style shooter game in mind, where I'd want different types of collision responses. Characters slide along walls, around corners, and around each other (I figure I'd represent them with circles). Characters get damaged, but unmoved, by regular bullets. Characters get pushed back by big bullets (possibly into lava pools and chasms ). Bouncy bullets bounce off walls. Pushable puzzle blocks get pushed by characters moving against them. That sort of thing.
You know how love.physics is discouraged for non-physics games because it's a hundred-pound hammer? How there's now HardonCollider for simple collision detection? How do you handle collision resolution? As in, when you detect that two objects are overlapping, how do you move them apart without making them overlap other objects?
Handling collision resolution without love.physics
Forum rules
Before you make a thread asking for help, read this.
Before you make a thread asking for help, read this.
- kikito
- Inner party member
- Posts: 3153
- Joined: Sat Oct 03, 2009 5:22 pm
- Location: Madrid, Spain
- Contact:
Re: Handling collision resolution without love.physics
I'm by no means an expert, but if I were to solve that, I'd try going "back in time" with the affected bodies. Probably I'd store the last "safe" position for each body from frame to frame, and if an two bodies intersected, I'd "interpolate backwards" in the direction of their last safe position. If you also have information about their trajectory, you can use that to move backwards, too.
The resolution of that interpolation is an interesting problem in itself - how big do you make the step? One option would be making it gradually small, I guess - like in a quicksort search.
The resolution of that interpolation is an interesting problem in itself - how big do you make the step? One option would be making it gradually small, I guess - like in a quicksort search.
When I write def I mean function.
- Robin
- The Omniscient
- Posts: 6506
- Joined: Fri Feb 20, 2009 4:29 pm
- Location: The Netherlands
- Contact:
Re: Handling collision resolution without love.physics
HardonCollider can handle collision resolution, but not perfectly: applying collision resolution can result in objects intersecting other objects. This is noticeable if there is gravity and there are objects stacked on each other, or a series of objects lies next to each other and the first object is pushing the rest against a wall.VideroBoy wrote:You know how love.physics is discouraged for non-physics games because it's a hundred-pound hammer? How there's now HardonCollider for simple collision detection? How do you handle collision resolution? As in, when you detect that two objects are overlapping, how do you move them apart without making them overlap other objects?
Help us help you: attach a .love.
Re: Handling collision resolution without love.physics
I've used this before, however it can be tedious to do for sidescrollers/platformers, its good for top-down games. You can use bounding box, if you're just colliding with boxes(that aren't rotated) as illustrated here http://love2d.org/wiki/BoundingBox.luakikito wrote:I'm by no means an expert, but if I were to solve that, I'd try going "back in time" with the affected bodies. Probably I'd store the last "safe" position for each body from frame to frame, and if an two bodies intersected, I'd "interpolate backwards" in the direction of their last safe position. If you also have information about their trajectory, you can use that to move backwards, too.
The resolution of that interpolation is an interesting problem in itself - how big do you make the step? One option would be making it gradually small, I guess - like in a quicksort search.
HardonCollider can be a bit of a pain, but its probably the best solution not physics wise.
So I'd say, if you're doing a top down, try bounding box. If you're doing a side scroller use HardonCollider, if you're using any physics in your game then you might as well just use that. Its not as heavy as people make it out to be, just don't use it for gravity and collision only because then its an overkill.
Re: Handling collision resolution without love.physics
The collision callbacks receive the minimum translation vector as argument. This can be used to push two shapes apart so that they don't collide anymore:VideroBoy wrote: How there's now HardonCollider for simple collision detection? How do you handle collision resolution? As in, when you detect that two objects are overlapping, how do you move them apart without making them overlap other objects?
Code: Select all
function on_collide(_, shape_a, shape_b, dx,dy)
-- move both shapes
shape_a:move(dx/2,dy/2)
shape_b:move(-dx/2,-dy/2)
end
One simple (but slow) approach is to run the collision detection multiple times in one frame while moving colliding shapes byonly some fraction of the translation vector.
-
- Prole
- Posts: 16
- Joined: Mon Jun 25, 2012 7:17 am
Re: Handling collision resolution without love.physics
Is there any way of loading an image as a collision object, opposed to using, for example, addCircle()?
Who is online
Users browsing this forum: Ahrefs [Bot], Bing [Bot], Google [Bot] and 6 guests