Why does sprite.kill() not halt the update loop?

[JTronLabs]

Add a console function to a sprite's update. kill the sprite. The console will be logged indefinitely. Why was this design decision made? I doubt it's a bug, as it seems like a really basic behavior, but sprite pooling is a super common paradigm and needlessly running the update loop seems wasteful.

http://phaser.io/sandbox/edit/htyDEbYq

(note for the sandbox, you have to click on the game in the 'play' tab for the game to have focus & do the logging)

[rgk]

You could use .destroy() and then remake them, but that does seem inefficient.

[tips4design]

It's a zombie, runs while being dead.

[darkraziel]

I asked this to Rick some time ago, specifically why is it that setting exists to false (which kill() also does) won't stop the update method.

This was his answer:

Quote

`exists` bails out of `preUpdate`, but `update` will still be called because it’s entirely empty, there just for >over-riding, so you can set it to ignore if exists is false as needed

 

[JTronLabs]

@tips4design  I lold at the zombie comment. @rgk I think destroying would be really inefficient, and make it hard to pool as it auto-removes the sprite from its Group.

 

@darkraziel are you suggesting overriding/editing the base Phaser engine to achieve this behavior? Currently I am including `if(!this.alive) return;` at the beginning of every one of my game loops, but it's messy code and I am not a fan. Over-ridding the base engine would be a lot cleaner, but would require manual, annoying setup after downloading/pulling from an NPM package. Do you have a link to Rich's original answer?

[darkraziel]

3 minutes ago, JTronLabs said:

@tips4design  I lold at the zombie comment. @rgk I think destroying would be really inefficient, and make it hard to pool as it auto-removes the sprite from its Group.

 

@darkraziel are you suggesting overriding/editing the base Phaser engine to achieve this behavior? Currently I am including `if(!this.alive) return;` at the beginning of every one of my game loops, but it's messy code and I am not a fan. Over-ridding the base engine would be a lot cleaner, but would require manual, annoying setup after downloading/pulling from an NPM package. Do you have a link to Rick's original answer?

The update method itself is empty and meant to be overriden, either by assigning a function to the sprite update (like in your example) or by extending the Sprite class for personal use. So if you ever add override the update method you can then set it to return if exists, alive or visible is false, depending on what you need.

[JTronLabs]

Ah ok yes that is what I am doing currently. It's a bit annoying when I have a long inheritance chain, as each parent & child needs to have this check at the beginning of their update loop. Works, but makes the code a bit messy. It would be nice if the update signal for sprites/groups/text/displayObjects would only ever be triggered if they were alive. That way it not have to call the function or check alive/exists conditional. I posted about this issue here for Rich to take a look at https://github.com/photonstorm/phaser/issues/2776

[samme]

On 9/29/2016 at 0:12 PM, darkraziel said:

Over-ridding the base engine would be a lot cleaner, but would require manual, annoying setup after downloading/pulling from an NPM package.

You can just include after Phaser:

Phaser.Group.prototype.update = function() {
  var child, i;
  i = this.children.length;
  while (i--) {
    child = this.children[i];
    if (child.exists) {
      child.update();
    }
  }
};