Performance impact of putting collide in bullet update vs state update

[ghclark2]

In my platformer, the player has a number of different weapons (gun, energy blast, homing missile) and there may be a number of enemies (up to maybe 6) who will have one of the same weapons. From my understanding of the weapon plugin and tutorials, I should then be making a different weapon object for each of the players weapons and for each enemy. As I am wanting to attach a particle emitter to missiles I'm then going to extend the bullet class to make a missile. 

Question 1: I want autofire from enemies to fireAtSprite rather than just fire, I'm assuming the best way to do this is to extend the weapon class and overwrite the fire() method to call fireAtSprite() instead? Or is there a better way?

Question 2: Where do I put the collision checks for the bullets? I can see a couple of options but would really like to know the performance implications as to which would be better.

1) Put an arcade collision call in the extended bullet update method to handle hitting scenery and hitting enemies - this seems neat in some ways as the code for the bullet hitting something sits with the bullet itself, however it feels like I'm going to end up with a lot of separate collision calls.

2) Put an arcade collision call in the state update along the lines of:

this.enemies.forEach(function(enemy){
    this.game.physics.arcade.collide(enemy.weapon.bullets, this.collisionLayer, this.shotCollisionLayer, null, this);
    this.game.physics.arcade.collide(enemy.weapon.bullets, this.player, this.shotPlayer, null, this);
}, this);

3) In the custom bullet constructor, add all enemy bullets to an enemyBulletsArray and collide this in the state update method

this.game.physics.arcade.collide(this.enemyBulletsArray, this.collisionLayer, this.shotCollisionLayer, null, this);
this.game.physics.arcade.collide(this.enemyBulletsArray, this.player, this.shotPlayer, null, this);

Many thanks,

Gordon

[DanielKlava]

Hello!

I think there are no right answers for these topics, but let me add my two cents:

Quote

Question 1: I want autofire from enemies to fireAtSprite rather than just fire, I'm assuming the best way to do this is to extend the weapon class and overwrite the fire() method to call fireAtSprite() instead? Or is there a better way?

You could do that, of course, but you could also add a loop event that will run your custom logic that may call fireAtSprite(). The advantage would be that you may also call other functions, like animations and sound effects. Sure, you could also call that in your overridden function, but I think it would mix different concepts in your "fire()" function.

Quote

Question 2: Where do I put the collision checks for the bullets? I can see a couple of options but would really like to know the performance implications as to which would be better.

I would go with option 2)! Although it will have the same effects as 3), you would have more control over the behavior of the collisions. For example, let's say that for some reason you don't want to collide the player with the enemy 1's bullets, but with 2's and 3's only, you could add logic inside the foreach loop to skip it. And, inside the collision callback function, you can call your bullet collision method that you declared in your extended bullet update. Like that you let the Game handle all collisions, but collision logic/action will be inside each class.

It's really a gray area of which is the best way to go, I think.

[samme]

On 11/30/2017 at 12:54 PM, ghclark2 said:

Question 1: I want autofire from enemies to fireAtSprite rather than just fire, I'm assuming the best way to do this is to extend the weapon class and overwrite the fire() method to call fireAtSprite() instead? Or is there a better way?

You could, or you could just modify the weapon:

var weapon = this.add.weapon(/*…*/);
// …
weapon.fireAtSprite = function () {/*…*/};

 

On 11/30/2017 at 12:54 PM, ghclark2 said:

Question 2: Where do I put the collision checks for the bullets? I can see a couple of options but would really like to know the performance implications as to which would be better.

(2) is best. Collision checks are more efficient when made against the whole group. You can still call a method on the bullet from there.

[ghclark2]

Many thanks Daniel and Samme - have gone with option 2 for the collision checks. To sort out the autofire issue, I have ended up giving the weapon an extra property of 'target' which is a reference to either the player or enemy that is beign fired at and then hacking the weapon's update method to:

// this is a hack of a protected method in order to make the weapon autofire at the target.
ZPlat.WeaponBlast.prototype.update = function () {

    if (this._bulletKillType === Phaser.Weapon.KILL_WEAPON_BOUNDS)
    {
        if (this.trackedSprite)
        {
            this.trackedSprite.updateTransform();
            this.bounds.centerOn(this.trackedSprite.worldPosition.x, this.trackedSprite.worldPosition.y);
        }
        else if (this.trackedPointer)
        {
            this.bounds.centerOn(this.trackedPointer.worldX, this.trackedPointer.worldY);
        }
    }

    if (this.autofire)
    {
// ONLY LINE CHANGED
        this.fire(null, this.target.x, this.target.y);
    }

};

 

Since weapons already have the ability to track a Sprite to get the fireFrom position, I wonder if it would be useful for them to have an optional targetSprite / targetPointer property so they can track for the fireAt position as well...

Thanks, Gordon