Welcome to Dev Log 111. Phaser 3.0 Beta 15 is now available for download and all of the examples this issue were built against it. So please upgrade to Beta 15 if you're testing things out at the moment. Without further ado, let's dive right in ...

Sound Manager Updates

Pavle is back with a new update on the Sound Manager. A huge amount of work has been put into it recently but we're only going to focus on one feature this issue, so don't let the brevity of this segment fool you!

"Hey all, hope you enjoyed the holidays!

A lot of work has been done in the past few weeks since the last Sound API update and I’m happy to say that it is very near completion.

One huge feature that is now available in v3 is the ability to loop sounds and it has been implemented in a way that it works perfectly regardless of the playback rate and enables you to have gapless looping out of the box.

Another added feature is support for delayed playback that you can now define as a config setting when playing sounds.

In combination, they can be used to chain different sounds playback or alternate differing looping sounds to avoid things becoming monotonous.

Check out this cyberpunk street party example to get yourself familiar with the full potential of using these features in Phaser v3!"

Input Manager Updates

As part of preparing for release, I've been clearing out issues in GitHub and knocking tasks on the head. One such task was sorting out input events in a multi-camera environment. We had already done quite a bit of work towards this but it was never 100% until now.

On the surface it doesn't sound like a significant problem to solve: Did you interact with a sprite? and left at that, it isn't hard to solve. But of course we added the ability to modify the game camera in V3, so it can zoom, offset itself and rotate. This immediately adjusts what needs to be done when detecting input on sprites. And then we added support for multiple cameras. So the very same sprite could be rendering once for as many cameras as there are, all in totally different places on-screen. And the cameras can overlap each other. And scroll. And game objects can be locked to the camera or scroll with them, or scroll at their own speed offsets which all adjust where they visibly end-up on the screen.

All of a sudden something that started out so simple becomes an awful lot more complex. It's no longer a case of a pointer interacting with a sprite, it's a pointer knowing which camera its over, translating down through the stack and how the sprite should react based on those cameras before you can even determine if it's interacting or not.

Needless to say, what on the surface appeared to be a simple feature instead turned into several days worth of code deep diving to get working properly. Thankfully though, it now does:

In the example above you can use the cursor keys to pan the camera, Q and E to zoom in and out, Z and X to rotate and press Space Bar to change the active camera. You can also use the UI controls too, but the important part is that the input events work regardless of which camera and where the pointer is.

As part of this work, I was able to completely recode the hit test routine we were using to avoid the need for any kind of matrix operations or calls to the TransforMatrix, which is great! All it needs is a temporal point which saves a bunch of processing time, especially in input heavy scenes.

Top Only and Event Flow

As well as fixing this I also spent a good while testing across mobile and desktop. The Input Manager is now using passive handlers and this stopped various bugs like the double-down event bug on iOS. I also adjusted the event flow of the over, out, up and down pointer events, which in turn fixed the Flood Fill game so it now works on mobile properly.

I also fixed the way the "Top Only" setting works. This is a setting within the Input Manager that, when enabled, only considers the top-most Game Object on the display list as being interacted with. So with "topOnly" enabled if you had 3 interactive sprites all on-top of each other and clicked them, only the top-one would respond to the input events. With topOnly disabled, all 3 will respond. It's easy for you to tweak this setting at run-time as needed. Here's an example showing the difference (click to toggle the setting):

Updates Galore

There are lots of other API tweaks that landed in Beta 15. From things like you now being able to set the image type and encoder options when taking snapshots from the renderer, to fixes to the Camera bounds checks. Felipe has been deep in RenderPass land, sorting out some gnarly renderer issues that happen when passing from one RenderPass into another.

I'm pleased to say that Mike will be rejoining us this week too, to get Tilemap collision implemented! It's literally all hands on deck right now.

Scale Manager

With Beta 15 out I can now focus on the new Scale Manager. I've been planning this out for the past few weeks and now can start to build it. One thing I felt that the Scale Manager in v2 got wrong was that it tried to do too much. It's a bit of a black box, to say the least, and is tricky to navigate, from a code point of view, never mind from an API point of view.

So my aim with the V3 Scale Manager is to make it much more simple and give it a lot smaller surface area. I think realistically there are only usually a couple of core requirements when scaling your games and all of the edge cases and site-specific implementations need to be handled directly yourself. Fundamentally, you need to be able to say "This is the size of my game, I want it to scale following these restrictions" and from that point on you respond to events as you need.

It's foolhardy to think that V3 can handle doing a fully responsive game for you. It can't. There are just too many different requirements to address. I don't want to end-up dictating how your game should adjust given shifts in canvas size. But what it can do is ensure you get all the events and hooks you need to be able to deal with size changes quickly and easily, and the renderer will adjust itself as needed too.

One of the big differences from V2 is that there is no longer the concept of a 'Game World' with a fixed size. In fact, there isn't a 'world' object at all anymore. This means that the placement of your game objects is entirely up to you and the relationship between them and the size of your game canvas is for you to define, not Phaser. Part of this will be easier to explain with examples and others when the Scale Manager is added in the next release.

Please send your feedback

On that front, though I'm very keen to hear your feedback on this. If these are any features you have always longed-for in the Scale Manager, or equally things you wish it didn't do! then now is the time to make your voice heard.

You can either reply to this email (if you get the newsletter via email) or drop a line to support@phaser.io with 'Scale Manager' as the subject and simply tell us what you'd like (within reason :)). I really want it to achieve the right balance between "hands off" and "does what you need", so any suggestions you've got on that front would be greatly appreciated.

With that said it's time to get back into the code and crack on with nailing this 3.0 release down. Keep an eye on the GitHub commit log if you want to see what's happening before the next Dev Log :)

Phaser 3 Labs

Phaser 3 Beta 15 is out and ready for testing.

Visit the Phaser 3 Labs to view the API structure in depth, read the FAQ, previous Developer Logs and contribution guides.

You can also join the Phaser 3 Google Group or post to the Phaser 3 Forum - we'd love to hear from you!