It’s very strange. You can try stepping through Stage#update.
I stepped through Stage#update. Assuming I’m reading this correctly, here’s what seems to be happening:
The emitter’s great-great-…great-grandparent is the sprite for the game’s background, which is found in a group named “__world”, which in turn is a child of the stage. I added this background sprite to the game using game.add.sprite(0,0,“assets”,“background.png”); I’m not exactly sure how it ends up as a child of __world, but that’s where it is.
In Phaser CE, this background sprite has some generic Component class as its prototype, which does not have an update method. So when the group calls the sprite’s update method, nothing happens, and none of its childrens’ update methods are ever called.
1 Like
In that case you just need to avoid using the background sprite as a parent container. Or else override its update() method so it updates its children as well.
What was the reasoning behind this breaking change in Phaser CE?
I can’t recall such a change. I think http://phaser.io/docs/2.6.2/Phaser.Sprite.html#update works the same as in Phaser CE.
The implication here: phaser/Stage.js at v2.6.2 · photonstorm/phaser · GitHub is that in 2.6.2, particles are updated separately, not via the stage. See comment for Stage’s update: “This is called automatically after the State.update, but before particles or plugins update.”
Yeah, take a look at the updateLogic method in 2.6.2: phaser/Game.js at v2.6.2 · photonstorm/phaser · GitHub
The particle system’s update method should be invoked directly by the logic loop. I can’t find anything comparable in CE, which would explain the problem. Any idea why this breaking change was made? Was it simply an oversight/mistake when the logic loop was rewritten? Where does the logic loop reside now? I’m having trouble finding it in the CE source.
1 Like
particles.update() was removed because it was (usually) double-updating the particles after the stage had already done so:
Technically I guess it was a breaking change, but the previous behavior seemed incorrect as well.
So now in Phaser CE particle emitters receive updates only from the stage, like any other game object.
You could either move your emitter in the display list so its ancestors are only groups, the world, or the stage, or you could call emitter.update() yourself from state update().
Philosophically, what is the reasoning behind allowing sprites to have children, but not have the sprite’s update function call the childrens’ update function? It seems to me that if the goal is to have everything update through the stage’s hierarchy, it’s important to make sure the update function call percolates through the entire family tree. When sprites don’t do that, it breaks that assumption.
I think we’ve isolated the problem well enough that I can build a workaround for my specific use case, I’m just thinking about the bigger picture.
I think the reasoning is that all update() logic is game object dependent.
- Authors need a method to add custom logic to their sprites, which is
update() - Authors will put sprites in groups
I see your point, but since Sprites can have children, if I am creating a character carrying a gun, for example, my instinct is to make the gun a child of the character, not to add a level of indirection by putting character and gun inside a group. And I would expect that gun to get update calls, since it’s part of the hierarchy. It feels misleading to me to even allow sprites to have children if updates don’t percolate through them.
If this were perceived by the general community to be a problem, there are a couple viable solutions.
Solution 1: Change Sprite’s update function to call update on its children. If authors want to override the update method, they can always call Sprite.prototype.update.call(this) in their custom logic. This change likely wouldn’t break existing games because if someone is currently overriding a Sprite’s update method in their game, they currently aren’t getting any percolation of updates through to the sprite’s children, so nothing would change for them. The only problem would be if someone has already written a workaround for a child of sprite not getting updated through the hierarchy, for example, adding a call to the child’s update to the state’s update function – now the update function is getting called twice.
Solution 2: If you don’t want people to have to remember to call the prototype’s update function when overriding the Sprite’s update in order to maintain percolation of updates through the entire hierarchy, another approach would be to separate the role of propagating updates and having something to easily override for custom logic. In other words, every group/sprite/etc. now would have an updateSelfAndChildren method whose code is simply to call this.update() and then children[i].updateSelfAndChildren() on all of the children. The update method would be empty by default on everything, and would exist to be overridden with custom logic. As with Solution 1, this shouldn’t break anything, unless someone’s already implemented a workaround for the existing way.
Solution 3: Don’t allow sprites to have children, to force game creators to use groups for hierarchical organization. This isn’t really practical because it is a hugely breaking change, but it’s interesting to think about if one were designing a new game engine from the ground up with this philosophy that groups should only be the nodes of the hierarchy tree and sprites should only be the leaves.
I haven’t looked at Phaser 3, so I’m curious, how does Phaser 3 handle this? Does it also give groups a privileged status with respect to updating children, or does it have a more unified view of groups and sprites?
Moving along with trying to patch the problem, the obvious thing to do was to add a line to my state’s update method to call game.particles.update(). A simple fix, right?
Not so fast… the Particles update method was ripped out of Phaser CE. Particles used to have an update method in 2.6.2, but it no longer exists.
To end on a positive note, I’ll mention that I got the particles working by copying over the behavior of the 2.6.2 particles’ update method into my state’s update method (i.e., iterating through the values of the particles.emitters map and calling update on every emitter that has exists set to true).
So, thanks @samme for all the help troubleshooting the original slow animation issue, and the problems I experienced upgrading to the test build of CE. I’m happy to have a working solution. Please let me know if/when a minified build of phaser-test.js is available so I can drop it into my project.
And if you do consider changing sprites to percolate through updates to their children, let me know so I can remove my workaround.
Phaser CE v2.17.0 should be released this week.
Hi everyone and thank you for the thread!
Is there any solution to the problem that doesn’t include updating from 2.6.2 to CE?
I can’t think of another way. 
Well, we’ve made a little hack:
game.time.slowMotion = .5;
It seems to work well in our game for both classic and fast screens.