Hi everyone! Hopefully you all know about the Development Updates that I post every week in the Phaser World newsletter. It's my weekly summary of what I've been working on, but this week has been such a good one, that I needed to write about it here too.

First of all you probably notice the video I added to this post. Please make sure you watch it in HD, or it gets a bit chunky from compression. Essentially what you're seeing is me running through a small selection of Phaser 3 renderer tests. The tests include the new PixelField Game Object, nested Container tests, multi-texture batched rendering, and also a new feature I added just last night: The ability for Game States to have their own custom shaders. This is why you can see the 'twirling' effect over the top of everything, because it has been applied on a State level.

Internally Phaser 3 is now using a Frame Buffer Object for each State. The State renders to the FBO, and that is then drawn to the main context at the end. There are hooks in place, so you're able to intercept the FBO from your own code, both pre and post rendering, to apply your own effects to it. Structuring the renderer like this has allowed me to now start work on parallel State support. Each State is essentially its own Display List, and has its own FBO. Phaser will render them, in the order you specify, and then composite the end result to the main context buffer at the end. This means you can achieve 'picture-in-picture' style effects with ease, and yes it works on both Canvas and WebGL.

One thing I still need to do is figure out how the Game World fits into all of this. In Phaser 2 there is one single World, and every Sprite (and other object) you create belongs to it. It's essentially a giant Group. The Camera is bound to the World, and the State is effectively isolated from those two things, acting more as a conduit to them, i.e. Sprites added in your State, are really just passed through to the World's display list. Equally State's down own any managers themselves (like a Tween Manager, or Sound Manager), they just hold references to the ones belonging to the Phaser.Game object.

However for Phaser 3 I wanted to evolve this into something more structured and flexible. The idea is that each State will now manage all of its own systems. So it's the State that will have a Tween Manager, or a Sound Manager. So you can effectively mute all sounds, or pause all Tweens, just for that State. The State itself is a Container, the root of its own display list, and Sprites created within it, are added to its own list. I believe that doing this will allow you to separate game objects much more cleanly, and avoid 'over crowding' of the World object.

This leaves a couple of interesting challenges though. The first is what happens to the Game World? I can easily see the situation where you may require two States to each be unique views into the same single World. For example imagine a split-screen game. I can also see the benefit of each State just being its own entirely separate thing, and the renderer just renders that one State. In this set-up, Sprites from one State couldn't interact in any way with Sprites in another though. There are lots of decisions to be made here, and I'm open to any ideas or thoughts you may have. You can catch me on the Phaser Slack channel every week day, or you can leave a comment here, or just email me.

As I create more videos I'll post them up here. I'm genuinely excited about the direction Phaser 3 is heading. It's a complete joy to be able to wake-up and work on it every day. My brain is positively buzzing about all the things it can do, and will do. It's been a real learning experience for me personally, and I can't wait until it's ready to be played with in anger.