Global Registry Added, State Updates and new Color Object
As usual we're back with another Phaser 3 update. It's a bit slimmer this week (as far as new features are concerned) because Felipe had the week off, and I had a few days off too, but progress was still made, there's a new demo for you to see, and some thoughts on how we're going to handle the input manager.
- There is a global game Registry. This is accessible from any State, and allows you to store common data in a single location, and then save that data out to a file system if needed.
- States can now pass data from one to another easily. The data will be passed in to either the States init or create functions (or both if you've both set). This allows you to do things like have a 'modal pop-up' State, where you pass in the coordinates and other game data to the modal, which it acts upon and then closes down again when done.
- I spent a good amount of time creating the new Color object, and associated functions. Available in the new Phaser.Graphics namespace, it's a way to easily create a unified representation of a color, for use anywhere within Phaser. It can parse most common formats (i.e. hex strings, css values, etc) and creates a single small object that can be used by functions such as 'backgroundColor', text color, and so on.
- Color functions include all kinds of useful features: from HSV color wheels, to hue component extraction.
- On a related note I started work on a new Gradient class, to handle easy creation of gradients and color ramps, with an emphasis on gradients that can change over time (such as a sky effect changing from blue skies to a sunset). Gradient objects will be able to be passed into Graphics objects, Text objects, and anywhere else that makes sense to support them.
Input Manager Research
We also made a start on dealing with the Input Manager. Interactive objects are always complicated to deal with in a game engine, because they expose so many potential issues off the back of their events. I.e. click handlers adjusting the camera, changing the state of an object, updating physics, etc. Over the years I've seen everything done in the handler, even causes where the entire game was destroyed. In Phaser 2 there are a lot of conditional checks all over the place, to cater for edge cases like this. Part of our research was in to ways to mitigate this, perhaps using an event queue, so we've direct control over when things happen, rather than assuming they could happen at any point.
Then there is the cost of actually detecting those input events. To ensure that when you click, or touch with your finger, that the test happens against perfectly accurate coordinates, we need to fully update the transforms of every object on the display list. With deep scenes this is computationally very expensive and not the sort of thing you want to do on a whim.
If it was confined to just click events it might be acceptable, but what if you want to detect mouse over events as well? Perhaps in order to give your game objects some tactile feedback such as displaying an effect while the mouse is over them. Mouse movement polling is high intensity, happens very frequently and produces a lot of data. Again we need to ensure that those input events always happen against the fully updated display list (otherwise you could start getting false positive responses).
We spent so long getting the game and render loop as tight as we could, that we have to be super careful not to negatively impact it again just by making the objects interactive. To that end we've been researching rendering hit masks to a hidden canvas, using dom elements, batched point conversions and all kinds of ideas. We're not there just yet though, so I'll write about this again next week after lots more testing.
Zoom
I'm going to end this update with a little demo. The screen shot above is showcasing a new Phaser 3 feature: the 'zoom' game setting. When passing in your game config you can set the 'zoom' value to any integer. This will upscale your game from the game size given. Used in combination with the new 'pixelArt' boolean it allows you to easily do things like this demo (cursors to move, space to shoot).
What you're seeing is a 160 x 144 sized game with a zoom setting of x4. All graphics are 'borrowed' from the Gameboy title Nemesis (aka Gradius.) - it works especially well for pixel art games, or games where you want to render them to a smaller canvas, but scale them up for display.
Please note that this isn't the new 'Scale Manager'. That is a different beast entirely. This is just a way to let you create games are small resolutions, then 'zoom' them to a larger resolution, from which the Scale Manager could then take over if required.
That's it for this issue. Next week we're both back full time, all guns blazing, so be prepared for more demos and news!
Phaser 3 Mailing List and Developers Guide
If you're interested in helping evolve the shape of Phaser 3, then please join the Phaser 3 Google Group. Discussions this week have included varying render loops. The group is for anyone who wishes to help shape what the Phaser 3 API and feature-set will contain.
The Phaser 3 Developers Guide is available. Essential reading for anyone who'd like to help build Phaser 3.
As usual we're back with another Phaser 3 update. It's a bit slimmer this week (as far as new features are concerned) because Felipe had the week off, and I had a few days off too, but progress was still made, there's a new demo for you to see, and some thoughts on how we're going to handle the input manager.
- There is a global game Registry. This is accessible from any State, and allows you to store common data in a single location, and then save that data out to a file system if needed.
- States can now pass data from one to another easily. The data will be passed in to either the States init or create functions (or both if you've both set). This allows you to do things like have a 'modal pop-up' State, where you pass in the coordinates and other game data to the modal, which it acts upon and then closes down again when done.
- I spent a good amount of time creating the new Color object, and associated functions. Available in the new Phaser.Graphics namespace, it's a way to easily create a unified representation of a color, for use anywhere within Phaser. It can parse most common formats (i.e. hex strings, css values, etc) and creates a single small object that can be used by functions such as 'backgroundColor', text color, and so on.
- Color functions include all kinds of useful features: from HSV color wheels, to hue component extraction.
- On a related note I started work on a new Gradient class, to handle easy creation of gradients and color ramps, with an emphasis on gradients that can change over time (such as a sky effect changing from blue skies to a sunset). Gradient objects will be able to be passed into Graphics objects, Text objects, and anywhere else that makes sense to support them.
Input Manager Research
We also made a start on dealing with the Input Manager. Interactive objects are always complicated to deal with in a game engine, because they expose so many potential issues off the back of their events. I.e. click handlers adjusting the camera, changing the state of an object, updating physics, etc. Over the years I've seen everything done in the handler, even causes where the entire game was destroyed. In Phaser 2 there are a lot of conditional checks all over the place, to cater for edge cases like this. Part of our research was in to ways to mitigate this, perhaps using an event queue, so we've direct control over when things happen, rather than assuming they could happen at any point.
Then there is the cost of actually detecting those input events. To ensure that when you click, or touch with your finger, that the test happens against perfectly accurate coordinates, we need to fully update the transforms of every object on the display list. With deep scenes this is computationally very expensive and not the sort of thing you want to do on a whim.
If it was confined to just click events it might be acceptable, but what if you want to detect mouse over events as well? Perhaps in order to give your game objects some tactile feedback such as displaying an effect while the mouse is over them. Mouse movement polling is high intensity, happens very frequently and produces a lot of data. Again we need to ensure that those input events always happen against the fully updated display list (otherwise you could start getting false positive responses).
We spent so long getting the game and render loop as tight as we could, that we have to be super careful not to negatively impact it again just by making the objects interactive. To that end we've been researching rendering hit masks to a hidden canvas, using dom elements, batched point conversions and all kinds of ideas. We're not there just yet though, so I'll write about this again next week after lots more testing.
Zoom
I'm going to end this update with a little demo. The screen shot above is showcasing a new Phaser 3 feature: the 'zoom' game setting. When passing in your game config you can set the 'zoom' value to any integer. This will upscale your game from the game size given. Used in combination with the new 'pixelArt' boolean it allows you to easily do things like this demo (cursors to move, space to shoot).
What you're seeing is a 160 x 144 sized game with a zoom setting of x4. All graphics are 'borrowed' from the Gameboy title Nemesis (aka Gradius.) - it works especially well for pixel art games, or games where you want to render them to a smaller canvas, but scale them up for display.
Please note that this isn't the new 'Scale Manager'. That is a different beast entirely. This is just a way to let you create games are small resolutions, then 'zoom' them to a larger resolution, from which the Scale Manager could then take over if required.
That's it for this issue. Next week we're both back full time, all guns blazing, so be prepared for more demos and news!
Phaser 3 Mailing List and Developers Guide
If you're interested in helping evolve the shape of Phaser 3, then please join the Phaser 3 Google Group. Discussions this week have included varying render loops. The group is for anyone who wishes to help shape what the Phaser 3 API and feature-set will contain.
The Phaser 3 Developers Guide is available. Essential reading for anyone who'd like to help build Phaser 3.