arcade collision body vs sprite

[ageibert]

i need a way to set my player body smaller than its sprite/image representation, so it can overlap collision objects e.g. walls in a top down game.

 

is it possible to set the body of a sprite object smaller than the sprite (yes it is) but check the collision with enemy objects, in particular enemy bullets, against the player sprite (not the now smaller body)?

 

i hope this question is not confusing too much

 

[rich]

Like this?

 

http://examples.phaser.io/_site/view_full.html?d=arcade%20physics&f=offset+bounding+box.js&t=offset%20bounding%20box

 

[ageibert]

Hi @rich,

this would be the first step. I uploaded a visualization with what i want to achieve:

http://files.geibi.de/collision.png

 

The blue square is my player object. The body is set smaller to the green area. Now it's possible, that i overlap e.g. the barrel a bit (blue area) so that the player is not colliding with his/her head which would be wrong in this perspective (compared to the wall's perspective).

 

This works fine.

 

But i got enemies shooting bullets at the player. And these bullets should not only collide with the player's body, which would result in "headshots"beeing not possible, but with the whole blue sprite area.

[lewster32]

Because you've tilted the perspective, you'll have to offset the bullets' bodies too. It should be totally possible for a bullet to go behind a player in this perspective. If you draw the bullet at the 'height' of where it's being fired (I guess mid-way up a character) but offset its body so it's at ground level, you should end up with the results you're after. Think of your bodies as being where the objects' shadows are - if the shadows collide, the objects collide.

[ageibert]

Hi @lewster32,

that's an interesting idea for other scenarios i also need. Thanks for that!

But what i try to achieve here is that the bullet does not only collide with the body of the player (green area), but with the whole sprite representation so that the player can be hit anywhere. Although the player has it's body only set to a small part of the whole sprite.

[valueerror]

so you need a sensor shape that is bigger than the colliding body and check bullet collisions against that sensor..

[lewster32]

Unfortunately multiple bodies is clumsy and basically not supported in Phaser with Arcade physics. I think you have at least three options here:

 

1. You offset the Y position and reduce the height of the body by the same amount as you have for all of the other objects ('shadow' collision) - great if you want 'accurate' collisions between objects

2. You offset the Y position but set the height of the bullet body to the same as the characters ('full-width shadow' collision) - great if you want bullets to be more dangerous

3. You set the height of the body to the same as that of the characters and offset it so the top of the body lines up with the top of the sprite - this should allow the bullet to strike another character anywhere the character's sprite can be seen, but I warn you this will probably lead to frustrating scenarios where the player expected the bullet to go behind them, given the implied projection of the rest of the objects in your scene!

 

 

[ageibert]

Hi lewster,

thanks for your outstanding answer and visualization.

But i'm still not sure which solution to pick, because in all cases i'm missing something. Sorry.

Maybe this video helps:

 

https://www.youtube.com/watch?v=CAAxzC_KASg#t=138
At 2:18 you see the player running behind the boss.

This is possible, because the bosse's body is, i think so, smaller than it's sprite. As well in width, but also in height.

 

But: The player is able to hit the boss from top to button. The whole sprite area is listening for the players bullets/lasers to hit.

 

If i offset the body of the boss, there would be unexpected collision outside the sprite image. 

Also if i'd make my bullets/lasers body as high as the bosse's sprite, it would produce unexpected collision e.g. if it misses by flying some pixels under the bosses sprite, but then still hitting him, even if not really touching it.

 

Maybe i understood something wrong in your solutions?

[lewster32]

It's hard to tell what's going on, especially given the fact that it's a large hitscan weapon rather than a 'bullet' as such. I think you just need to experiment with offsets and sizes until it 'feels' right. I don't think you'll have much luck using Arcade physics 'out of the box' to get the specific functionality you desire, because as valueerror quite rightly says, this would be a job for two bodies, a flattened one for character-to-object collision, and a full size second 'trigger' body to detect collisions with weapons - and Arcade unfortunately isn't well suited at all to having two bodies attached to a single Sprite.

[ageibert]

ok, i see. so you think i'd better go off for p2 physics right now? not that i invest too much time in arcade physics and at the end have to refactor lot of code...

[ageibert]

edit: i played the game a lot myself and it's really also the bullets that behave like described above.

the bullets do hit the whole visible sprite of enemies/bosses, but the player is able to move "behind" the enemies.

it would be too frustrating for the player if he/she can't move behind a super sized screen filling boss - and if he/she could only hit the boss at some smaller physical body

 

maybe i can find a better video with bullets

[valueerror]

if your game is going to be more complex in the future you'll probably have to switch to a more sophisticated physics engine anyway..     

some are saying p2 needs so much more resources but this definitely depends on what features of p2 you use..  in my experience p2 is super fast and my bottlenecks are everywhere but not it the physics system..  i'm very very happy with p2.. ok.. complex things like my chain example (can be found in phaser examples) eat a lot of ram to be honest.. but you don't have to use this

[lewster32]

P2 is more CPU intensive but also more flexible. I'm no expert on it (I've not really used it at all) but I do believe it'll do the things you're needing, though I feel maybe it's worth exploring other Arcade-based options first if you can.