Jump to content

Question about arcade.overlap - specifically the overlap callback


Recommended Posts

I'm just starting to experiment with Phaser - and I'm been examining the Tanks example here:



I noticed that the enemy tanks basically move in a pinball mode - bouncing off the player tank and the world boundaries.

My goal is to give the enemy tanks a little smarts so they actually pursue the player.


The first thing I wanted to do was to stop them from bouncing off the player tank - and completely ignoring each other.


I figure that I need to implement game.physics.arcade.overlap for the enemy tanks vs themselves and the player tank - instead of the current

.collide method - which just pinballs them around.


I decided to examine a current implementation of .overlap in the game - specifically - this line:


game.physics.arcade.overlap(bullets, enemies.tank, bulletHitEnemy, null, this);


Now - this line has the overlapCallback function:


function bulletHitEnemy(tank, bullet) {


So - far so good.


What was (and still is) confusing to me was - where the values for "tank" and "bullet" were coming from.


So - I looked up the .overlap method here:




And saw this:


overlap(object1, object2, overlapCallbackprocessCallbackcallbackContext) → {boolean}


and this explanation of the fields:




overlapCallback function <optional> null

An optional callback function that is called if the objects overlap. The two objects will be passed to this function in the same order in which you specified them.

All seemed clear - except for one major incongruity:


In the original overlap call:


game.physics.arcade.overlap(bullets, enemies.tank, bulletHitEnemy, nullthis);

the first object is "bullets" and the second object is the current enemy "enemies.tank"
In the overlapCallback function
THIS is the order:

function bulletHitEnemy(tank, bullet) {



So - my newbie question is - why is the callback function expecting the objects in the reverse order they are being delivered?!


Any enlightenment would be appreciated.








Link to comment
Share on other sites

  • 6 months later...

Actually I have just stumbled across this too, and was curious about the same thing. Googled it, and this post was the first reply. 



Found this "issue" on Github - For me it was the subtle use of groups throwing the order. So not really an issue

Edited by cjke
Link to comment
Share on other sites

So, yes, it's a little weird. But when you call collide/overlap with a group and a sprite, the single sprite comes before the sprite from the group in the collide/overlap callback.


E.g. this: 'arcade.overlap(group, sprite, overlapCallback, null, context);' will call this 'overlapCallback(sprite, spriteFromGroup);' every time.

Link to comment
Share on other sites


  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...