Newsletter
Welcome to Issue 123 of Phaser World
And we're back with another bursting issue! Thank you for all the kind words after 122 finally landed in your mailboxes last week, after a few months absence. Guess you really missed it :) We've some great new games and tutorials and the new Dev Log covers scaling, resolutions and a powerful new game object.
Until the next issue keep on coding. Drop me a line if you've got any news you'd like featured by simply replying to this email, messaging me on Slack, Discord or Twitter.
Emanuele Feronato is easily the most prolific author of Phaser tutorials on the planet. He has published over 250 of them in the past few years and started writing Phaser 3 tutorials before most others. As the framework has evolved, his tutorials have kept pace. So it's great to see that he's been busy writing a book and it's now available.
It's 155 pages long, with 28 source code examples, taking you through the process of creating a full cross platform game. What's more, buying a copy actively contributes towards funding my work on Phaser too!
The Latest Games
Game of the Week
Start your engines and get ready to race in this visually stunning kart racer, with 3 different cups to complete.
Staff Pick
Walk through the dark witch's forest and solve the crossword puzzle! Do you dare?
A simpler multiplayer shooter. Fire flames at the other players, collect health and last as long as you can.
Match the same balloons as they float up the screen, but be quick, they move fast!
A turn-based puzzle rogue-like. Delve through the dungeon, fight the monsters and plunder their treasure!
What's New?
A great blog post about developing this iOs and Android game using Phaser and Cordova.
Quickly prototype and build the Phaser game you want to make! Develop in Phaser faster than before.
Draw and edit Lines, Bezier Curves, Splines during runtime and export them for path tweens and PathFollowers.
Programação Multiplataforma Com A Biblioteca Phaser.
Multiplayer Blockchain Game Tutorial
A tutorial on creating a multiplayer blockchain game using Phaser, NodeJS and Ethereum.
Phaser 3 Game Development Course
A complete Phaser 3 and JavaScript Game Development package. 9 courses, 119 lessons and over 15 hours of video content. Learn to code and create a huge portfolio of cross platform games.
Thank you to these awesome Phaser Patrons who joined us recently:
Olof Larsson
pierreh37
Andrew Groff
Max Panzer
also, thank you Daniel Birlem and Richard Farrell for the PayPal donations.
Patreon is a way to contribute towards the Phaser project on a monthly basis. This money is used entirely to fund development costs and is the only reason we're able to invest so much time into our work. You can also donate via PayPal.
Backers get forum badges, discounts on plugins and books, and are entitled to free monthly coding support via Slack or Skype.
Dev Log #123
It's been a busy week. I mean all weeks are busy weeks, but you know how sometimes you're non-stop, yet it doesn't feel like you actually achieved all that much? And sometimes you're non-stop and the progression feels positive and tangible. It was one of those sorts of week.
Game Resolution
As mentioned last issue I'm now focusing on the new Scale Manager and Facebook Instant Games integration. The first task in that journey was to sort out the issue with the resolution game config setting. Some of you may be aware you could set the resolution of your game like this:
However, had you done so, you'd have found various things then either broke or didn't work as expected. For example, input detection would now be wrong if the Camera was zoomed or rotated, the canvas itself wasn't properly resized and even with the resolution set you still got 'low res' Text rendering on High DPI devices. The first part of my week began by resolving all of these issues. The canvas is now scaled properly, input works across Cameras and you can get super-crispy Text, should you require it:
It's perhaps worth talking about what setting the resolution higher than 1 actually entails internally. The first, and perhaps most obvious thing, is that the canvas element that is created has its size set to be width & height * resolution. If you've a game size of 800x600 and a resolution of 2 it's going to create a 1600x1200 sized canvas. The canvas will be visually displayed at 800x600 due to CSS, but it'll actually be rendering twice as many pixels as that.
On a High DPI display this is noticeable in that it makes everything appear crisper (well, now that it's been fixed it does!). If you've ever seen comments such as 'why is my text blurry on an iPad?', this is the reason. So, setting the resolution to match the devices pixel ratio is surely always a good idea? Well, as with most things when it comes to games, "it depends". For a start, you are now asking the GPU to do twice the amount of work it was doing before. The base canvas now needs twice as much memory, as it contains twice as many pixels. If you create a lot of Text Game Objects, each of those is now using textures twice the size they were before as well.
This is assuming a device pixel ratio of 2. 2 isn't the limit, it can actually be any value. The LG Nexus for example has a DPI of 3 while the Samsung Galaxy S6 has a DPI of 4. That's literally 4x the amount of pixels required. With advancements in desktop and mobile displays, such as the new range of 8k UHD monitors, we're easily on the verge of extreme DPIs. And it's not likely to slow down either. The higher it is, the more memory is required. And when the browser is having to push twice, or maybe four times, as many pixels as before, it naturally takes longer and more power to do so.
It's the eternal battle between performance and perfection. For some games you don't even need to worry about it. If your game doesn't require a significant amount of on-screen movement, or isn't overly heavy on graphics, then you can go for visuals without too much worry. As with everything it comes down to testing. Just be aware that you can't invoke the power of high resolution with impunity. There are real costs involved and it's worth being aware of them early in the build process.
DOM Element Game Object
With the resolution issues resolved it was time to move on to a feature that Phaser would need in order to make working with Facebook Instant Games that much easier. The introduction of the new DOM Element Game Object. The concept behind it is simple. You create a Game Object that is directly linked to a DOM element. Once created you can move the DOM Element Game Object around as normal. It will respond to Cameras, have its own scroll factor, can be tweened or even have a Physics Body. But instead of using a texture to render you're actually manipulating an element within the DOM.
The following code demonstrates a simple use-case:
Here we create a new \<div> tag and give it a style and some content. It's then passed to the `add.dom` factory method, which returns a DOM Element Game Object. You can now manipulate this as you would any other Game Object. Tween the alpha, bounce it around the screen, scale it, rotate it and so on. The div isn't being rendered to the canvas, it's actually a proper element in the DOM stored in a special container one level above the canvas. Manipulations to it are handled by a CSS transform matrix and a special renderer.
Of course, you're not limited to just div elements. Literally, any HTML can be used. To make it easier I've added in the ability to load HTML snippets directly in the loader:
The HTML can be as complex or as simple as you need. In the following example, you'll see a login form appear. The form, its background, and button are all pure HTML and CSS. Try entering something to 'login' (make-up whatever credentials you like):
I have added some helper methods into the API to allow you to easily select any of the elements children by ID or name and to listen for events from it. You can listen for any event the browser can emit and it'll come through via the normal Phaser event system:
Which is a powerful way to hook into the HTML being displayed.
You don't have to use Phaser to query the DOM element though. Use whatever framework you like, even jQuery. I'll provide an example showing how to get a reference to the Phaser DOM Element from your HTML, so you can control the process from both ends.
If you've run the login form example above you'll notice that the form slides away with a nice 3D perspective effect when submitted. This is handled via the `rotate3d` property available. In the code below you can see we're tweening the elements of the property directly, after setting the perspective value:
You can also skew the elements. Again, this is all handled with CSS, so it'll work as long as the browser supports those transforms, which most do these days.
The elements even render in relation to the main camera. In the following example, I've created 250 divs and injected a random emoticon into each one of them. Use the cursor keys to move the camera around and notice how the divs all respond based on their scroll factor:
I picked the value of 250 because on my development system it ran well. On an older laptop it struggled a bit, where-as on my gaming rig I could push it up to 500 before it started to slow down. So the quantity of elements you can handle is based entirely on the device and browser you're targetting, as well as the content of each element. The more complex they are, the more work the browser needs to do to render them.
Stress tests like these aren't all that useful beyond just testing a concept. This feature wasn't created so you could make games with the dom elements themselves, although I guess there's nothing actually stopping you. It was created to allow you to easily ingest html into your game and display it over the top of your game content, accurately, and control it from your game code. So the same code you use to tween your sprites can also tween out your forms or social sharing buttons or whatever.
The use-cases are pretty vast, especially in the realm of IO games. Login forms, high score name entries, sharing buttons, branding links, ad displays and so on. This will be really important when it comes to pulling in the more advanced features of the Facebook Instant Games API too.
There's another area where this could be really useful as well. Remember back to earlier in this Dev Log where I talked about using high dpi text objects to keep your text nice and crisp? If you use a DOM Element instead to render your game text then it will be as crisp and clear as the browser can manage it, without having to force your entire game canvas to be high resolution as well. So you can overlay a visually beautiful UI on your game, benefiting from all the advances browsers are making when it comes to text rendering, especially with the new variable fonts, without the cost of doubling, or more, your canvas size. And those UI elements? They'll still respond to events like your camera shaking :)
There are limitations of course. The most obvious one is that all the DOM Elements are positioned over the top of your game canvas. They have their own display list and you can manage it like you would any other display object, using the setDepth method as well. But they will always appear over the top of anything in your canvas. You cannot insert them between canvas rendered Game Objects.
They also can't be masked via Phaser masks, although you can mask them using CSS. They will also only render to the main camera. I'm not yet decided how to handle the cameras. I may create a special camera specifically for DOM Elements, as right now if you have multiple cameras in your game the elements will re-position themselves for each one.
I'm very happy with how powerful they are though. They are entirely optional. If you don't enable them using a special game config flag they won't even be available, and they're easy to exclude from a custom build just like any Game Object (although they are very light-weight, not taking up much KB at all.)
Again, I cannot stress enough that these are meant to be used for UI, forms, banners and so on, not actual game "sprites". But hey, eat your heart out :) You're an inventive lot, I'm sure you'll think of interesting and varied ways to use them! They'll be available in the full 3.12 release. You can track development in the main repo and the examples being uploaded to the labs.
Forthcoming changes to Containers
This is just a heads-up that support for nested Containers will be removed from Phaser after 3.12 is released.
Let me be clear: Containers, and all of their current functionality, will remain. What will be removed is the ability to add a Container as a child of another Container.
The reasons are two-fold:
1) It will improve speed as we'll no longer need to do any iteration during matrix or bounds calculations. It will boil down to a simple boolean check and then some straight forward math if needed.
2) It will reduce API complexity internally - there are edge-cases where, for example, a deeply nested Game Object doesn't inherit the correct blend mode. Or issues like input handling needing to crawl up a container tree to find its ultimate position, all of which are adding un-needed code into the API and causing issues (both for you and me).
Containers have caused so much branching and additional work in the API that I really question their value as they currently exist. At the same time, I know some devs like using them. I think there is room to explore recoding the feature entirely, but in the meantime stopping the use of nested Containers will help mitigate a number of problems and streamline the internals a lot.
Feel free to add your thoughts to the GitHub issue. I'm still seriously contemplating rewriting Containers completely, so there's plenty of room for suggestions on how they could be implemented.
This shader-based half-tone effect is just lovely! Anyone fancy porting it to Phaser? :)
Sonar is a platform for debugging mobile apps on iOS and Android. Visualize, inspect, and control your apps from a simple desktop interface.
One of the world’s most chilling ruins is the Ploutonion at Hierapolis, “the Gates to Hell”.
Phaser Releases
Phaser 3.11.0 released July 13th 2018.
Phaser CE 2.11.0 released June 26th 2018.
Please help support Phaser development
Have some news you'd like published? Email support@phaser.io or tweet us.
Missed an issue? Check out the Back Issues page.
©2024 Phaser Studio Inc | 548 Market St PMB 90114, San Francisco CA 94104