Phaser Group - add and addChild - what is difference?

[game-dev-monkey]

I understand that a group functions as a pooler as well as a DisplayObject container, but I want to make sure I am understanding this correctly.

If I use addChild, am I only adding the sprite to the DisplayObjectContainer? 

For example :

I create a group called enemyPool for my enemies for the purpose of pooling

I create a group called gameLayer that I intend to use as a DisplayObjectContainer for all my active sprites in the game

If I get a sprite from the enemyPool and then use addChild as follows :

gameLayer.addChild(sprite);

 

Am I correct in assuming that the sprite still exists in the enemyPool for the purposes of pooling?

Am I also correct in assuming that the sprite exists as a child of the enemyLayer DisplayObjectContainer , but is NOT a part of that group in regards to pooling?

If so, does the children property contain group members or DisplayObjectContainer children?

Is there a property that contains only group members? The group members that would be used for forEachExists() and other iterating methods?

Or.... Am I completely understanding this topic incorrectly and the add(child,silent) and addChild(child) method essentially the same thing?

 

 

 

 

 

 

[game-dev-monkey]

Sorry to bump this, I won't again if no one answers. But hoping to get some clarity on the intended usage for add and addChild.

 

I notice that Pooling being abstracted from Group is a potential feature for next update, is this the reason why?

 

[drhayes]

To the source! https://github.com/photonstorm/phaser/blob/a29cc649327fe57e4eb0c2b89813aadf33ab6e5b/src/core/Group.js#L286

Here is the definition for "add" in Phaser.Group. You can see that it does a bunch of stuff on top of calling "this.addChild". Use "add", not "addChild". ( =

This isn't the reason why Pool and Group are getting split, though. My understanding is that Groups are serving double-duty right now: they are both a node in the display tree *and* they have methods like "getFirstExists" that are more like a traditional object pool. Sometimes you just want one without the other.

[game-dev-monkey]

Thanks so much for that.

 

So that means if I have multiple pools for different types of sprites that all need to be layered on a given Group that I am using as a display object container, when I kill them I need to return them to the appropriate pool. 

Or it makes sense to have them all in the same Group and use a key of some sort to get the appropriate type of sprite. In that case I'd have to use forEachDead to check for the appropriate key when getting a new sprite from the children.

So this does seem like it might be the reason for the split, by what you just said. Or would the children of the DisplayObject container still be used as the collection of pool sprites?

The reason I was asking about add and addChild is because I was trying to determine if there was one or two arrays used for pooling/display tree. With only one array which is the children property of the DisplayObjectContainer, they are one in the same. 

 

Thanks so much again for pointing me to the code. Should have done that in the first place. 

I think I am going to go with a Group that has all different types of sprites so I can order correctly. So I'll need to write some code to grab sprites from the pool based on their key.