Struggling with Arcade physics collision

[jeancode]

Hello all,

 

I'm having a hard time to fix my collision bug, so I'm asking you for assistance.

 

Here's what I'm trying to do : (see the attachment for an ugly sketch)

 

I have a tilemap (created with tiled), and I created a group of sprites on it (blue squares). I can move this group of sprites by pressing an arrow key, in this example let's say I press 'up', then all the blue squares move up (by changing their body.velocity.y). I have several collisions check in my update loop, using the arcade.collide() method, some of them are tilemap layers, others are a group of immovables sprites. (all represented by brown squares)

 

I have one more collision check, the blue squares group with itself, so they can't go through each other. And this is the collision giving me troubles. When there are too many blue squares, some of them go through other ones. In the example provided, the 4 blue squares on the left should end up l vertically aligned on the top brown block, but chances are the lowest blue square will go through and end up in the next one.

 

FYI the map is kinda big :20x30 tiles, 32px each tile

 

I've done quite a lot of researches about this problem here, most of the time the solution provided is to not use the arcade collide system and build a system which calculate the path for each sprites, but I don't think this would work well with my project because It would be too laggy if I have to calculate this path for each blue square after each input. The path could be difficult to calculate quickly with all those differents type of blocks.

 

I've tried a lot of hacky things, but none worked consistently so far.

 

I hope I was understandable !

[jeancode]

Any idea about the problem and a possible solution to this ? I'm still quite unsure on what's actually happening and why those particular collisions are messy, so I don't really know how I could fix it or adapt my code around it. (Or if I have to write something from scratch, not reproducing the same bug)

[drhayes]

One thing to check is the relative velocity of each of those blue sprites with their sizes, i.e. if the size of the sprite is small vs. its velocity the collision system can make one sprite "overshoot" another. Does this happen if the blue sprite velocities are very small?

[jeancode]

I guess it's quite fast, I'd like a velocity of 500 while my sprites are 32x32. I noticed if I lower the velocity, the maximum number of sprites without a collision bug is higher, but it still happens at some point. Isn't there a way to get rid of this behaviour ? Because what If I want a fast game with several sprites ? (and I do ! ). Basically I'd like something consistent for like 20 sprites at most.

[MichaelD]

Have you tried the tilePadding property?

 

http://phaser.io/docs/2.3.0/Phaser.Physics.Arcade.Body.html#tilePadding

 

my guess is that somewhere a frame is lost and the calculations of the collision skip a calculation, adding some padding might solve this.

 

Other than that you might want to play with the .y attribute rather than velocity, that way your calculations would only affect the possition of the element.

[jeancode]

Well, the tilePadding property didn't do anything but It doesn't surprise me, because the only collision giving me troubles is the group of blue squares vs itself, not with anything from the tilemap. (Or I'm missing something)

 

About the latter solution, not playing with the velocity will break the arcade physics collision system If I'm not mistaken, that means I will lose my collisions vs tilemap elements, which is working well at the moment.

 

I'm out of ideas unfortunately.

[MichaelD]

You could run multiple checks not only for collisions but also for touches or overlaps, this way you could make a "self-correction" algorithm of the ones that overlap so they correct themselves.

 

It all comes down to processing unfortunatelly, if the speed is too high the collision calculations miss a bit and the overlap occurs, and with more sprites this becomes even worse because the number of calculations increases.

[drhayes]

I think you're going to have to write this collision routine yourself, then. The good news is that it's pretty constrained since this is VERY special case: those blue squares all move together and only have to check against each other, right? (although you'll have this problem with them colliding with the map too if they move too fast, but you said that's working alright?).

 

If one of the blue things is "stuck" against some item of the landscape, you now know to check it against the ones that aren't "stuck". Or something. It's a good place to start. Depending on how many of the blue things there are you won't get into TOO much performance trouble if you check each one against the other. Alternately, you could maintain a spatial hash of blue things so you know which ones are near which other ones.

 

Or something. ¯\_(ツ)_/¯