Jump to content

Does Phaser 3 need Containers?


PhaserEditor2D
 Share

Recommended Posts

Hi,

So finally Phaser 3 is going to provide containers? I am a bit confused about it, I remember that to keep a flat display list is a design desition that allows a lot of performance and simplicity. At the same time, we need something like containers or bones, something like a transformation tree. In this Phaser 3 google group I mentioned it:

https://groups.google.com/forum/#!topic/phaser3-dev/jNb_9i0_EpE

...and proposed something like Joints, this was the Richard answer:

 

Quote

 

You cannot add a child to anything beyond the root display list, which is entirely flat with no hierarchies anywhere. This allows us to avoid deep branching during rendering, the pain of nested transforms, issues with getBounds and offer extremely simple and fast depth sorting.
 
I quite like the idea of a Joint object though. I feel it makes more sense than calling it 'Container', because that implies control over ordering too, whereas Joint just implies two (or more) connected objects, and the depth of those could be anything. Indeed they could even be in entirely different Groups and it wouldn't matter.

 

 

 

2

 

So, if now containers are introduced, how much is it going to affect the internal Phaser 3 implementation? Is it going to affect performance? is it going to use two different display list, one flat and other nested? Why are we considering containers again?

 

Best regards,

Arian

 

Edited by PhaserEditor2D
regards
Link to comment
Share on other sites

I think now we only need a better API to support transform tree, and that does not require any changes to the internal implementation. This feature is usually used for UI elements but not much in the other area, and a flat object list will provide way better performance. If you ever used impact.js (which uses flat render list) and want to have some move in/out animation on your UI elements, the general way is to update their transform every single frame from the top most entity class, and that is just chaos. We have to do the same thing right now in Phaser3 due to the lack of such functionality.

The idea of joint sounds great, further more it may even have configs to support syncing of alpha, tint and other visual properties. In Godot there's a node called RemoteTransform, you can use it to transform a node as child while that node is not really a child. That concept looks just like the joint you proposed as. There are properties like `update_position`, `update_rotation` and `update_scale` that can be used to control how the remote node should be transformed.

I vote for Joint instead of Container.

Link to comment
Share on other sites

To be clear: we're not changing how the display list works in v3. Containers will be top-level objects that immediately update the properties of their children (you will not be able to nest containers), which gets around the issue of bounds calculations, branching, etc.

However, I had completely forgotten about the Joints / RemoteTransform suggestion and it sounds better imho.

re: UI layering, don't forget the power of the Scenes! I've literally just implemented a fully responsive UI system into a v3 game using its own Scene, and it's so much easier than even Containers would make it.

Link to comment
Share on other sites

2 hours ago, rich said:

To be clear: we're not changing how the display list works in v3. Containers will be top-level objects that immediately update the properties of their children (you will not be able to nest containers), which gets around the issue of bounds calculations, branching, etc.

However, I had completely forgotten about the Joints / RemoteTransform suggestion and it sounds better imho.

re: UI layering, don't forget the power of the Scenes! I've literally just implemented a fully responsive UI system into a v3 game using its own Scene, and it's so much easier than even Containers would make it.

When it comes to a UI with multiple windows that can be dragged around, each with dynamic amounts of sprites/sub-containers, would something like a Scene for each individual window make any sense?  Or would it be better to have the one UI scene and Containers for each window?

In v2, I had a windowGroup that contained all the primary windows as Groups, and some of those windows contained dynamic numbers of Groups that were like slots with additional information per existing character.  If containers can't contain other containers, I think I can adjust these slots to be v3 Groups, then call Group.each to re-position the entire slot.

Link to comment
Share on other sites

In recent voting for next feature to be implemented, I voted for Containers. I thought it will be possible to nest them...

Did I make it right, that for now all objects in fact have only their world space position and rotation? I think that some way to build object hierarchies and place some objects into local space of other objects is essential for making games. Imagine this example: some sphere orbiting main character. In Phaser v2 I would put sphere as child of player in some distance from 0,0 position, so I will have hierarchy chracter->sphere. In sphere update I will care only about orbiting position. Following player when he moves is provided by hierarchical transforms. If I wanted to offset center of orbiting I could simply put empty group between character and sphere and change hierarchy like this: character->empty_group->sphere.
 How can I do thing like this in Phaser v3? Does it mean, I have to check in sphere update every frame new position of character and update sphere position to it?

Link to comment
Share on other sites

That’s exactly what a transform does anyway - checks and updates all properties of all children and iterates them every frame, so that element of it is going to happen regardless of approach, no matter if the Container does it, or you do it manually. Making this about convenience, not performance.

Link to comment
Share on other sites

4 hours ago, rich said:

Making this about convenience, not performance.

Thanks for answer. Yes, I understand this. If engine cares, you can keep your code smaller and better maintainable (not repeating this basic transform stuff all the time) and focus more on game itself...

Link to comment
Share on other sites

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...