Need some ideas for a name for a new Game Object Group

[Skeptron]

I like Bag. It's very short and explicit. But pool is fine too

[Harissa]

If this collection is just like a group but its not attached to the display list then surely the name should reflect this?

 

Something like FreeGroup or FloatingGroup.

These names are a little longer than the others which have been suggested but IMHO give a better idea of what it does.

 

Of course the other option is just to stick with the Group class but add an attached property which indicates whether its on the display list or not.

This could make it much easier when you're moving a group of objects from the display list and back. You wouldn't have to convert it to a object type

you'd just call a detach method and away you go.

I could see that this would be an issue because of the existing PIXI group inheritance but this may mean that the inheritance shouldn't have been there and it

should be replaced by some cunning composition / interface rather than making a whole new class.

[wayfinder]

A major difference between this new thing and the current groups (which I still think should be renamed to layers) is that an object could be part of multiple NewGroups, but just one layer.

[markergreen]

I vote for List, Set, Pool, or Cast. 

 

I'm thinking that this is still a type of Group though, just with a "false" flag for adding to the display list.

[MichaelD]

what about

 

*Registry

*Reg

*Box

*Cage

*Stack is nice

*Trunk

[rich]

I did consider adding a 'not on display list' option to Group, but all of the methods within Group assume that Group children are restricted to being in just one Group at any one time, which isn't the case for what this new class will do.

 

Frustratingly I keep circling back to wanting to rename the current Group to Layer, and then using Group for this new system. But I simply cannot do that in Phaser 2, which now makes me think maybe this feature is best reserved for Phaser 3 anyway, where we do have the luxury of being able to make changes like this.

[MichaelD]

That actually make a lot of sense, since this is a "grouping" function and the Layer is something that gets rendered so yeah that would be a good convension, however is about to give many people strokes when trying to port code from 2 -> 3

[rich]

Yeah it will definitely confuse devs going from 2 to 3 - but I'm thinking so much will change it may not be a bad thing to have to do anyway

[tips4design]

Yeah it will definitely confuse devs going from 2 to 3 - but I'm thinking so much will change it may not be a bad thing to have to do anyway

As long as the examples will be updated accordingly I'm sure everything will be ok.

[codevinsky]

Make the change to group/layer.. release it alongside 2.5

 

It's ok to have API breaking changes at milestones like that.

 

Lord knows Angular did it.

[cjke]

If this is still open for discussion, I vote collection. Brevity of variable/methods/structures shouldn't take precedence over clarity. I feel like pool implies a certain level of cermantics.

In terms of functionality, lodash method set is amazing for collections. Curious if it's possible to simply leverage that. The team there seems to pride themselves on speed and staying current.

[PhaserEditor2D]

SpritePool

[Berzee]

Bundle and Roster occurred to me, but they both have issues. I think Bundle and Roster are my favorite so far among the words that aren't Pseudo-reserved (i.e. List, Set, Collection). Doing the group/layer reorganization thing is possibly that one that will sound most sensible five years hence, though. =)

 

In my games so far I just keep an array of, say, enemies alongside the group of enemies. I call the nondisplay array "enemies" or "enemiesList" and the group, "enemiesGroup".