Greetings everyone! We’re back with another round of news from the wider Phaser community. This issue we have got the release of Phaser v3.88.1, three games, and two advanced tutorials. Plenty to keep you busy 😄

There’s no Dev Log this week because we’ve several very significant projects all nearing completion together, so we’ve just not had time to write about them. Dev Logs shall commence regular service in the next issue. Until then, please dig into a smaller but no less tasty treat of an issue …

🥳 Phaser v3.88.1 Released

We are excited to announce the release of Phaser v3.88.1, codenamed 'Minami'. This latest version of our open-source HTML5 game framework brings lots of important fixes and improvements that we know our community will benefit from.

Our mobile and web audio systems have received vital updates. We've improved audio unlocking on mouse-enabled devices, and implemented crucial fixes for iOS 17.5.1+ and iOS 18+ to prevent audio interruption during focus changes in Safari.

We've merged a community PR that adds a handy new Transform.getWorldPoint method that lets you accurately retrieve world coordinates for game objects, even within nested hierarchies. Plus Dynamic Textures have had their rendering quality substantially improved by ensuring even-numbered dimensions.

For our physics-focused developers, we've enhanced Arcade Physics collision handling, particularly for circle-to-circle and circle-to-rectangle collisions. We've also fixed a critical issue with Matter.js physics that could cause browser crashes when handling large delta values in background tabs.

The update includes many more improvements, from better tilemap handling to enhanced tween management and DOM element scaling fixes. We've worked hard to ensure these changes maintain backward compatibility while improving your game development workflow. As always, please see the full Change Log for details.

Phaser v3.88.1 is available now via npm and GitHub and in the Phaser Sandbox. We've also updated all of our framework templates too. We encourage all developers to upgrade to this latest version to take advantage of these improvements. As always, we're grateful for our community's continued support and feedback that helps make Phaser better with each release.

Download from GitHub

🧠 Memory Game with Phaser and React

If you're interested in game development with JavaScript, why not try building a memory game using Phaser and React? This tutorial walks you through the entire process, showing you how to integrate these two technologies to create an interactive card-matching game.

Read the Tutorial

😽 Magical Cat Rescue

If you love puzzle games and adorable cats, Magical Cat Rescue is a game you don’t want to miss! Built using Phaser, this delightful adventure challenges players to solve puzzles and rescue lost cats in a magical world.

Play Magical Cat Rescue

🧠 Continuous Collision Detection in Phaser

This tutorial is part of an ongoing series and provides an in-depth look at:

Handling high-speed object collisions with line segments Detecting vertex collisions for more precise interactions Preventing the notorious tunneling effect caused by fast motion Implementing mathematical techniques to achieve accurate physics.

Read Tutorial

☕ Brew Perfect

Love coffee and casual games? Then Brew Perfect is your next caffeine fix! Created by PlayGood Games in partnership with Chemex Coffeemakers, this engaging browser game lets players experience the art of brewing the perfect cup of coffee.

Play Brew Perfect

⚔️ 风尘三侠传 The Legend of Three Heroes

As game developers, we often come across titles that pique our interest, even if they're beyond our linguistic reach. One such game is 风尘三侠传 (The Legend of Three Heroes), developed and published by Dai Jin. Released a year ago, this Phaser created game is available exclusively in Chinese on Steam.

Read about Legend of the Three Heroes

Phaser YouTube Channel

New readers may not be aware that Phaser has its own YouTube channel! We’ve been posting a steady collection of updates, recaps, and game showcases there for a while now, and it’s growing nicely. Our aim is to start trying some short-form tutorials and see how those go down, but if you’ve any other ideas, please let us know in our Discord. Here are some of the latest videos:

Subscribe to us at https://www.youtube.com/@PhaserYouTube

Share your content with 18,000+ readers

Have you created a game, tutorial, code snippet, video, or anything you feel our readers would like?

Please send it to us!

Until the next issue, happy coding!

Oh boy, we have a good one for you this week! A new beta release of Phaser 4 that introduces some groundbreaking GPU tech for rendering millions of sprites, plus a comprehensive guide on Shader development, cool new games, and a massive team developer log.

🤯 1 Million+ Animated Sprites? Yes, please!

Here's something a little special - the final part of our new renderer just landed and Sprite GPU Layers are now available in Phaser v4 Beta 5. What can they do? For a start, they can easily handle rendering 1 million+ background sprites!

SpriteGPULayer is a new game object designed for ultra-high performance in background layers. Leverage the power of the GPU to render a hundred times faster than conventional sprites. And use tween-like animations to add life to "static" backgrounds. This allows for behaviors like animated characters, crowds of moving people, trees swaying in the wind, fading smoke rising from chimneys, raindrops falling, and many more.

We just published an article all about them, which includes 4 demos to play with.

Read about Sprite GPU Layers

📕 Phaser 4 Shader Guide now Available

Phaser 4 updates the WebGL rendering system to become more powerful and reliable than ever before. This guide explains the core concepts and how to use shaders in the new system.

We're excited to announce the release of our detailed guide on creating shaders in Phaser 4! This comprehensive resource walks you through everything you need to know about working with Phaser's new WebGL rendering system, "Phaser Beam"

Read more about the Shader Guide

🔠 Word Rummy

Word enthusiasts, get ready for a fresh take on letter-tile gaming! Stone Fruit Studios has just launched Word Rummy, an engaging new word game available exclusively as a Discord Activity. This clever mashup of beloved classics like Wordle, Scrabble, and Bananagrams brings strategic word-building directly to your Discord server.

Play Word Rummy

🐍 Full Stack Snake Tutorial

In this episode of the 12-Minute AI Game Development Challenge, we’ll build a full-stack Snake game with Cursor IDE, Supabase, and Phaser.js — all in just 12 minutes and with just prompts (NO coding) Watch and learn how to use AI to build and develop games with Cursor.

View the Video

🔨 Hammer Time

In a standout entry from the 16th Pirate Software Game Jam, developer drewhjava brings us Hammer Time, an intense survival game where you play as a trusty hammer that is both your lifeline and your greatest weapon. Created in just 16 days under the theme "You are the weapon," this game stands out among the jam's 1,772 submissions with its unique combat mechanics and strategic gameplay.

Play Hammer Time

Phaser Studio Developer Logs

Things are getting hot in here! This is what the Phaser Studio team was up to last week…

👨‍💻 Rich - CTO & Founder

Part of my job includes talking to new potential customers. In addition to finding out about their companies, it also allows them to ask what features Phaser and Phaser Editor have. A reoccurring question, which was posed yet again today, is: How are you going to integrate AI into your products?

And it's a perfectly valid thing to ask of a software vendor now. Of course, there's no need to have it within Phaser itself. I'm not sure how that would even be possible anyway. But within Editor? That's a different matter. Developers are becoming so used to having co-pilot and Cursor-like interfaces at their fingertips that it's becoming almost painful when they're not present, and purchase decisions are now based upon it. Code-level assistants are one thing. This would be relatively easy for us to add if we wanted to. Because Phaser has always been open-source, the models are full of a decade of learning material. They don't always appreciate the nuances of just how the API fully interacts - but, given enough prompting and patience, they can all muster-up a decent quality Phaser game in next to no time.

That doesn't mean we should stop learning to code and let the tools take over, far from it. Yet it would be idiotic to bury my head in the sand and pretend this seismic shift isn't taking place because it is. And it's happening right now. So, what are we going to do about it? The short answer is: I'm not entirely sure yet, but it's something as a team we need to focus on very closely and carefully in the coming months. Right now, though, we've got the massive Phaser v4.0 release to focus on, the lesser, but no less important v3.88 release, and of course, Phaser Launcher and Phaser Editor updated to reflect all of this innovation.

Make no mistake, Phaser 4 is a superb release, and I cannot wait for it to be released this month. We've spent over a year working full-time on the brand-new renderer, and it shows. It's a giant leap forward in terms of performance and features - look at the Sprite GPU Layers we released in this issue for proof. Having that live, along with the other projects all coming to completion, will be truly exciting for us and the community.

In the meantime, I will keep talking to customers, listening to their needs and trying to find ways to make their lives easier. And if that means integrating AI into our products, so be it. It's not something I'm going to rush into. It's something that needs to be done right and done well. And that's going to take time. But it's also going to be worth it. Because the future of development will be very different from now. And we need to be ready for it. Thankfully, with all the tech we've been developing and releasing over the past year, we're in a perfect position to do just that.

👨‍💻 Francisco - Phaser Launcher

Welcome everyone to another week!

We're getting closer and closer to the first release of our Phaser Launcher. As you may know, "Phaser Launcher" is just our project name and not the final name of the software. Our team has been brainstorming potential names, and we've come up with some interesting ones:

• Phaser Launcher

• Phaser Editor Lite

• Phaser Taco Blast Processing

• Zero (this one is really solid!) We haven't made a final decision yet, but we hope you'll like the name we will choose.

The Launcher is designed to be a tool that helps developers create games with Phaser, as well as an entry point for those who want to step into the world of game development. With that in mind, we've added the Phaser by Examples book to the launcher. We've even dedicated a section on the landing page to make it easier for you to access the book.

The Launcher features a Game Viewer, a component that allows you to preview your game’s progress. However, we encountered a small issue: to see any updates, you had to close and reopen the window manually.

After diving deep into how Tauri’s window management works, I discovered that I could inject code into the game server, allowing it to emit an event that requests an update for this component. Thanks to this, we now have a much faster update process—without needing to close the window!

Thanks for reading about the Launcher’s progress—stay tuned! 🚀

👨‍💻 Arian - Phaser Editor

Hello!

These have been some hard work on the Box2D tools for Phaser Editor. Here is a summary of some of the most important features we have made progress on.

Body bounds

Since Box2D is not part of Phaser, I have had to implement some utilities to delimit the area that a body encompasses. This is used to determine when the user clicks on a body and also to highlight the object when it is selected.

New shapes

I have added two new shapes: Offset box and Circle.

Box2D glue-code generation

In a game, to create scenes with Box2D support, you have to write some code related to setting up the world, advancing the simulation, updating the sprites, displaying debug information, etc... All this code is now generated by the editor. You just have to activate the parameter Generate Box2D World Code. This means that the editor is now able to automatically generate all the code needed to get your Box2D scenes ready to run. Along with this parameter I have added others to further detail some optional aspects of the scene, such as implementing the "update" method and generating debug code.

World parameters

If you enable the code generation of the Box2D world, then the editor shows you the world parameters:

Auto import

All Box2D construction is made by calling the Box2D API functions. The editor will generate the "import" statements of all the functions. For now, it will look at the "PhaserBox2D.js" file in the project and will use it as the source of the API.

Prefabs

I started working with adapting the editor's prefab system to the Box2D particularities. In the next scene, all of the elements are made of prefabs that contains a Box2D body:

There is a lot to do with the prefab system, since I should implement a new way to configure the nested prefabs by setting the parameters via constructor arguments instead of object properties (as it is now).

Finally, here I let you with a small video of a demo I'm making, inspired on Angry Birds. In the next weeks we are going to make a release of the editor with an early version of the Box2D tooling. This version is not going to be feature-complete, but you will be powerful enough to make an Angry Birds-like game, all with in-scene visual tools.

👨‍💻 Can - Discord Activities

I wrapped up work on the guide and the template itself, providing a clear step-by-step approach. Dealing with all the details is not a straightforward experience, we wanted to make the process as simple as possible. You have to go through steps like app creation, setting your development environment, payout settings, dealing with proxies, verifying your app, creating your store, testing, debugging via the Discord app itself, bot settings, getting into production, and many more! If you get stuck on any part through it, or any part we can improve with the guide & repo - share with us in #discord-activites on Phaser Discord.

Now, I'm switching to Phaser Launcher to join forces with my great teammate, Francisco. I'll be focusing on the deployment part of the app for the moment being.

Till the next one, keep sharpening your pixels!

Tales from the Pixel Mines

3rd February, 2025 - Ben Richards

We've released Phaser 4 Beta 5, and it's a big one. This release introduces SpriteGPULayer, a game object which uses WebGL to render lively backgrounds a hundred times faster than anything else in Phaser. I've had this in the works for some time, and it's great to finally have it out!

As if that wasn't enough, I released the first draft of the Beam Shader Guide, to help you write your own shaders and filters. It's available for logged-in Phaser members at https://phaser.io/tutorials/phaser-4-shader-guide.

I also made changes to internal texture orientation, and fixed lots of bugs.

SpriteGPULayer

SpriteGPULayer is a new game object designed for ultra-high performance in background layers. Leverage the power of the GPU to render a hundred times faster than conventional sprites. And use tween-like animations to add life to "static" backgrounds. This allows for behaviors like animated characters, crowds of moving people, trees swaying in the wind, fading smoke rising from chimneys, raindrops falling, and many more.

This means you can get over 1 million sprites running on modern devices. That's a lot! A 4K display only has 8.3M pixels, and a more common resolution of 1280x720 has less than 1M pixels - one pixel per sprite. That quickly dissolves into meaningless noise if you try to push the limits. I know, I've done it.

You can actually get more than a million sprites. The maximum buffer size seems to be around 8 million, but if you run out, just make a second SpriteGPULayer. High-end machines can handle it.

The SpriteGPULayer is designed for high efficiency backgrounds. The expected use case is for developers to create static background or foreground layers containing high detail and limited animation. This is common in video game worlds, so we think it's going to be very useful.

The "Big Forest" demo shows just how much you can do with this technology. It consists of 1.4 million sprites, set up with parallax and cyclic animation. Grass and trees sway, clouds drift by, grains of pollen glint in the light, and plenty more. But this is overkill: the scene is a thousand screens across. It would take you 60 minutes to scroll from one side of the game world to another. 1.4 million sprites is a lot, and every grain of pollen in the entire world is being recalculated every frame. It still runs smoothly.

(The Big Forest demo also uses basic procedural generation to place parallax ground layers, alter the weather, grow trees etc. if you like that sort of thing.)

My advice for SpriteGPULayer is to use it efficiently. Don't render a thousand screens of off-screen content - that wastes device power. Consider splitting the scene up into smaller regions which can render efficiently, and use multiple SpriteGPULayers to handle foreground, background, and far background parallax elements. Use it to shift computation off the CPU, to free up processing power for other tasks like physics and AI.

How It Works

SpriteGPULayer is designed to fix a major performance bottleneck: the CPU-GPU update cycle.

Most Phaser game objects are calculated in the CPU, packed into buffers, and sent to the GPU to render. The problem is, CPU computation is very limited in JavaScript. We're limited to a single thread, so we have to do every calculation one after the other. Then when we're done, we have to send the data to the GPU, a process which takes more time while we just wait. This all adds up to a lot of time per frame, limiting how much we can render.

These problems have solutions. JavaScript has access to WebWorkers, and GPU updates are far more efficient with APIs like WebGPU. Unfortunately, WebWorkers have too much overhead for our current architecture, and WebGPU is not yet optimized enough to meet our performance needs.

What if we didn't have to use the CPU?

SpriteGPULayer packs data into buffers and sends them to the GPU at construction time. The data doesn't need to be updated. All the computations which are normally done on the CPU are instead handled by a vertex shader on the GPU. Because shaders are highly parallelized, all the work that takes a long time gets split up and run at the same time. This means we can run orders of magnitude more rendering work, and never run out of time.

You can update SpriteGPULayer data at runtime. It's just as efficient as ordinary Phaser objects. But because SpriteGPULayer can use so many more sprites, you may find that updates take so long the game stutters. The object has some optimizations for quickly updating contiguous regions of buffer memory, but even so, you should be cautious with updates to large layers.

Parallel GPU shader operations are so efficient that they will never be a bottleneck. The actual bottleneck is fill rate: how many pixels are drawn to the screen. The GPU has to handle every pixel on every sprite on the screen, even if it's behind another sprite. (Pixels not on the screen are not calculated.) Don't draw too many overlapping sprites, or performance will drop.

This all comes at a cost. If we don't update the data, we can't change it in response to input, physics, or other "dynamic" systems. A highly detailed background that doesn't move is pretty boring, even if it has parallax.

So I implemented an animation system. In fact, SpriteGPULayer supports two kinds of animation: frames and properties.

Frame animation is the ordinary kind of animation you see on sprites. A series of frames are displayed in sequence. SpriteGPULayer supports basic frame playback: it cycles frames at a fixed interval.

Property animation is more like tweens. You set the base value of properties like x, y, alpha, or tintBlend. You can also set values like amplitude, duration, delay, and animation type. The SpriteGPULayer vertex shader uses these values to calculate the vertex positions at a given moment in time, without recording state or computing multiple steps. THis is enough to support a great variety of lifelike animations.

I added animations which correspond to most tweens in Phaser. Because Elastic requires more parameters, it had to be left out. The Stepped tween supports extra parameters, but we skip them for the same reason. Also check out the unique animation type, Gravity, which simulates objects falling - perfect for effects like fountains, explosions, etc. You don't have to use Gravity just for the Y position; you could apply it to other properties to simulate some process which accelerates or decelerates over time.

There are a lot of technical details in how this fits together, but I don't want to be here all week, so I'll just skim the surface.

WebGL has some hard limits on how much data we can use per vertex. We assume that we have access to 16 vertex attributes. An attribute is a vector of 4 32-bit floating-point numbers, so in practice we can use 16x4=64 numbers to describe a sprite. As you saw above, we define a property with base, amplitude, duration, delay, animation type, and a 'yoyo' flag to control how animation repeats. That's 6 numbers per property, so we could have up to 10 properties in our program. We have (let's see...) 14.

Obviously we're doing something clever to exceed the hardware limitations.

Many properties aren't animated. For example, we have per-vertex color tint, just like regular Sprites; but we don't animate it. Animating 4 8-bit color channels inside a 32-bit value is pretty complicated! Instead we have a single animated tintBlend property which controls how much tint every vertex receives. This is enough to give decent control of colors.

And many properties are packed together, using the 32-bit number space to store more data than intended. For example, when you use the Gravity animation, we replace the animation amplitude with velocity and acceleration. How do we fit two numbers into a single number? Well, we make some precision trade-offs. We round down the velocity to an integer value, which is almost always good enough. Then we store acceleration as a fraction. There's a global gravity value for the whole layer, and this fraction multiplies that to get an individual gravity value for the sprite. Then we just add the integer and the fraction together to get a single number, which we store. On the GPU, we reverse the process to turn one number back into two. This might not be super efficient, but it's fast enough and gives us all the functionality we need! While there are limits on floating-point number precision, you've still got 23 bits to split between velocity and acceleration.

I haven't even mentioned how we use texture data to store frame animations. We really squeezed every drop of functionality out of this system. I'm pretty proud of the result, and I hope it helps you make better games.

Shader Guide

The Shader Guide draft tells you all about shaders and filters in Phaser 4. Log into the Phaser site and give it a look! This is a very powerful system for managing shader code. It also gives solid examples to get you writing your own shaders. We've already seen developers creating cool experiments, so I guess it works!

Texture Orientation

After examining various factors around external renderer compatibility, it became clear that we were handling textures wrong. GL texture coordinates start in the bottom-left, unlike the top-left of web standard image formats. We previously handled this with some options inside the render system, storing images in top-left format and doing a "final flip" to present the frame to the player. But when using the Extern object to add renders from ThreeJS and other engines, it was no longer quite good enough.

So I flipped texture representation. Now all our texture systems are bottom-left oriented.

This should not change anything for the user. Only if you're handling texture coordinates within the render system do you need to invert your Y axis.

However, for users of compressed textures such as PVR or KTX files, you must invert your texture coordinates for them to work properly in Phaser 4. This is a simple option in the software used to create these files. If you are using assets created for other systems, they are probably oriented this way already, because it is the default. We don't want you to have to create non-standard textures just for Phaser!

A summary of steps for creating high quality compressed textures for Phaser 4:

• Generate a texture atlas in TexturePacker, and save it as PNG.

• Use ImageMagick to lighten the image for hardware compression on the Web: magick input.png -set colorspace RGB -colorspace sRGB output.png

• Use TexturePacker or PVRTexTool to save the lightened image as the following texture formats, in a PVR or KTX container, ensuring that the Y axis is flipped:

  • ASTC sRGB UNorm 4x4 (or another sample level - don't select a "signed" variant!)

  • ETC2 sRGBA

  • PVRTC v1

  • S3TC DXT5 sRGB (also known as BC3)

Fixes and Tweaks

In Beta 5, I fixed DynamicTexture. It broke after we removed some theoretically dead code in Camera.

After the Beta 5 release, I added destroy handling for filters, including a setting to preserve filter controllers for reuse (not recommended, but possible if you know what you're doing). I also removed more dead code, this time from places where it was interfering with nested transforms, helping apply filters to objects inside Containers. The last thing I did was add filter support to Layer, which slipped through the cracks because it's the only game object that's not a GameObject. This is why code duplication is bad, kids! It's not just extra package size; it's a maintenance issue.

Next Week

I've got a pile of bugs and tweaks to work through to get Phaser 4 ready to roll. But we're close! We had an absolutely titanic week last week, and beta feedback continues to be excellent. Thanks to all the people who are helping us create the best Phaser there's ever been.

Share your content with 18,000+ readers

Have you created a game, tutorial, code snippet, video, or anything you feel our readers would like?

Please send it to us!

Until the next issue, happy coding!

We’ve a feature-packed issue to round out the month of January. Let’s go …

🚀 Phaser v4 Beta 4 Released

The fourth beta release of Phaser 4 delivers essential fixes to the Arcade Physics and sees multiple improvements in the rendering engine with a streamlined RenderSteps initialization process and corrected Layer implementation.

We're on the final path to the full Phaser 4 release. We've identified a couple more issues that need resolving, but aside from this it's mostly tidying up and lots and lots of testing left. If you find anything broken, please tell us in Discord or open an issue on GitHub. As it stands, we will have the final version out during February 2025.

Read More

📺 Multiplayer Connect Four Game with Phaser

Scott writes: “Welcome to another exciting tutorial where we combine coding and fun. Today, we’ll learn how to build a real-time multiplayer Connect Four game using the powerful Phaser 3 framework and Playroom Kit.”

Watch Tutorial

🐸 Memoriki

Evgenii Starostin emailed to tell us all about their new game for kids, Memoriki. The concept is simple: Tap the matching pairs to remove them from the board and try to clear it before the timer runs out. With each successful round, you reveal a little bit more of a cute animal, such as a frog or octopus. And, of course, with each round, more pairs are added, making it harder to finish on time!

Play Memoriki

🎥 Smooth Pixel Art Cameras in Phaser

Josh Morony has been making Phaser content for years and is currently working on a really interesting-looking bushcraft survival game. In a recent video dev log he explains how he managed to achieve perfectly smooth camera scrolling, while still maintaining the pixel art effect he wanted for his game.

Watch the video

🔥 The Wildfires

A new indie game puts players in the cockpit of firefighting aircraft, challenging them to protect communities from advancing wildfires. Developed in Phaser by the Home Team Game Dev team, with Victor Debone as lead developer, The Wildfires offers an engaging mix of resource management and aerial firefighting action.

Play The Wildfires

Phaser Studio Developer Logs

Another week, another team Dev Log!

🧑‍💻 Rich - CTO & Founder

Right now, the Studio feels like a kitchen with multiple dishes in the oven, all about to finish baking at the same time. Phaser v3.88 is shaping up to be a nice bookend to the v3 legacy, a version that has served us well for many years but has served its time. Phaser v4 is also in the final stages of prep and we released another new beta version this week for you to use.

Ben also wrote a truly massive Phaser 4 Shader Guide. This is still in draft mode and needs some proofreading and technical checking. Still, it will otherwise act as an invaluable resource for anyone who wants to make the most of the powerful new filter system inside of Phaser Beam. Our aim is to have this ready for you all next week.

Phaser Editor (as you’ll see below) is having a bunch of great Box2D tools added to it, so you can visually lay out Box2D bodies and shapes and then experiment with them directly in the Editor.

We’re also very close to the release of Phaser Launcher. You can see a sneak peek of this in Francisco’s dev log this issue. I’m really looking forward to this as it addresses a massive and constantly reoccurring theme we hear time and time again: “I’ve downloaded Phaser, now what?”. Typically you have to tell them to go away and install VSCode some variation of LiveServer and then grab a template to start from, plus have the docs open, maybe a tutorial or book and to just ‘figure it out’ themselves. And that’s just to get started with Phaser dev.

We’ve encountered this problem so many times in our Discord that we decided to do something about it. How many times, exactly? Well, during Q3 2024, we exported all of the text from our Discord server and then pushed it through some custom scripts to analyze it. And we were shocked at how many beginners didn’t have an IDE or server or clue what to do. Hundreds upon hundreds of them over the past few years. When you factor in that those who come to our Discord asking for help are a tiny % of those trying to get started and failing at the first step, that’s a massive signal that shouldn’t be ignored and cannot be solved via documentation alone.

Phaser Launcher is our solution for beginners to be able to start coding without having to worry about setting up anything, plus have all the resources they need at their fingertips. Once they’re proficient, they can level up to VS Code and/or Phaser Editor, but beginners, too, should be afforded an easy path to web game dev, and Launcher will provide that.

Aside from all these projects, most of my development time has been spent working flat-out on the Responsive Game Plugin. This has evolved through several internal iterations but is starting to take shape and will hopefully address another one of the frequently asked topics we see in our Discord: How to create a mobile/desktop responsive game! More details on this next week.

🧑‍💻 Zeke - Phaser v3.88

Happy Chinese New Year of the Snake (if you’re celebrating). I will be skipping the coming week’s dev log due to being away for the week to celebrate Chinese New Year with my family.

On to the dev log =) Last week, I focused my attention on resolving as many GitHub issues as possible before Phaser 3.88 release.

Rather than a long list of single resolved issues, I’ve grouped together the issues into categories:

Physics bodies

Both arcade and matter physics had slightly different issues when setting its body size. Matter physics bodies now has a proper getter / setter function to scale its game object attached physics body.

With arcade physics, adding an existing DOM element to the physics world initially uses the getBoundingClientRect() native browser function to accurately calculate the size of the DOM element (including padding and border). While this works fine if the goal is to create a precise user interface, it doesn’t quite work so well when it comes to physics bodies. To resolve this, the clientWidth and clientHeight is used instead to return only the element's content box.

• Left: Using clientWidth and clientHeight to generate the physics bounding box

• Right: Using getBoundingClientRect() to generate the physics bounding box

Tweens

Adding a persist: true to a Tween configuration object does not guarantee a Tween would not be destroyed after it completes. This has been fixed and all Tweens with persist set to true can be replayed infinitely.

Text letter spacing

Adding custom letter spacing when a text game object had wrapping enabled showed text going beyond the width of the set boundary. I reworked the letter spacing calculation to take into account the wrap width so it works correctly.

• Top-left: Without letter spacing

• Bottom-left: With reduced letter spacing

• Top-right: With added letter spacing

• Bottom-right: Word wrap after letter spacing calculation correction

Tilemaps

TiledImageCollection

TiledImageCollection has been improved to take into account different sized images in a collection. Also improved are the positioning of the rendered images and debug rendering of tiles to correctly show which tiles are being occupied by each tile image.

Layout done in Tiled Map Editor

Tiled Image Collection in Tiled Map Editor

Result in Phaser 3 with RenderDebug enabled

Hexagonal maps hexSideLength

Final issue addressed is the positioning of tiles in hexagonal maps. Previously, for each tile you had to manually set the hexSideLength value and force each tile to update by calling updatePixelXY(). Missing this key step would cause tiles to be placed incorrectly as in the screenshot below:

After some tweaking, each tile automatically inherits the hexSideLength property from the loaded map data file and correctly calculates its own position:

That’s all the major updates for the past week. Catch up in 2 weeks time! Have a good week ahead.

🧑‍💻 Can - Discord Activities Tutorials

This week felt like a martial arts match with Discord and server connections. Integrating monetization in a sandboxed environment while preparing for production brought hurdles like port management, proxy issues, permissions in a test/production mode, and the difficulty of debugging in a sandboxed environment for production. Logging proved essential in navigating these challenges.

Key Takeaways:

• Sandbox isn't perfect: Testing real-world conditions earlier is crucial.

• Logging is essential: Detailed logs made troubleshooting manageable. Despite using Discord's developer edition, you might not get all the response that you will need! You need to think alternative ways to manage.

• Automation saves time: Automated scripts for testing ports and URLs were invaluable. Tools are our biggest friends!

The core monetization flow is now functional, which soon to be released!

Next Steps

The next step is making sure it works for everyone and polishing the app further. A tough week, but progress feels rewarding!

Till next week, keep your pixels pristine and your sanity intact everyone!

🧑‍💻 Francisco - Phaser Launcher

Hello everyone,

This week, I've been focused on adapting Phaser Launcher to the new design. There isn't much to say about this task since the adaptation process is quite repetitive for each component.

After laying the groundwork last week by installing new packages such as Tailwind and other animation libraries, the focus now is on reviewing each component individually.

The process involves:

Analyzing the new design compared to the existing one. Discussing how the new design interacts with the current implementation. Integrating the new design into the application. Verifying that everything works as expected. Although it may seem like a straightforward process, ensuring a smooth transition while maintaining functionality requires attention to detail.

Here is a sneak peek of Phaser Launcher in action!

🧑‍💻 Arian - Phaser Editor

Hello!

I've already broken the ice with Box2D! This week I've made significant progress with implementing the Box2D tools for Phaser Editor. This is a particularly difficult task, since Box2D's API is independent of Phaser and has a very different style. The editor's scene editor is very closely tied to how Phaser has designed the interface and object hierarchy, so we've had to make some adaptations to incorporate the Box2D API.

In order to incorporate the Box2D API into the editor, you have to affect several aspects of the scene editor, such as code generation, serialization, and object modification tools, such as Translate, Rotate, Resize, etc... However, after several days of mulling over the Box2D API, reviewing other editors such as Unity, Cocos, and Godot, I've got a clearer idea of ​​how we can implement it in Phaser Editor.

Object Hierarchy

In the editor you can attach a physical body to any Phaser game object, but you can also place separate bodies in the scene. You can add shapes to each body. So far, I've only implemented a box-shaped shape. Unlike the other scene elements, Box2D elements are simulated. We don't use Box2D itself in the editor, so we can use a model that is more in line with the editor's internal interfaces.

Code Generation

Phaser Editor uses a JSON format to represent scenes in the editor, from which it generates JavaScript code that will be part of your game. With Box2D it's no different, the editor generates the code to create the bodies, shapes, and other elements of the Box2D API. Here's an example of how to generate a body with a shape that is attached to a "platform" game object:

As you can see, it's not a small amount of code, but it's readable and understandable once you get to know the Box2D API a bit more. Of course, this is all in an early stage of development and can change.

A huge challenge for code generation is adapting the Box2D API to Phaser Editor prefabs. Phaser objects are based on properties that can be changed at any time, and this is essential for the editor's prefab system. In the Box2D API, this is not so much the case, and rather the objects are configured initially. This different form of API will require more work in the code generation of the prefabs. This is something I'm still thinking about, but in the end we'll get a much more flexible system.

There's still a lot to do, but the hardest part is over, which is having a clear idea of ​​what we want to do and how we're going to do it. Here is a quick screenshot of the tool in action. See you soon!

Tales from the Pixel Mines

27th January, 2025 - Ben Richards

Last week the release of Phaser 4 beta 4, and several bug fixes.

I fixed an issue where padding in internal filters would cause the framebuffer to be oversized. This was ultimately due to a mistake while handling rectangle data. You can represent a rectangle in one of two ways. Use the top left corner and the bottom right corner; or use the top left corner and the width and height. When the top left corner is 0x0, which is the default situation, these representations are the same. But when the corner changes, the representations start to describe different sizes. I was using the wrong representation. I've improved documentation to prevent this from happening again.

I fixed an issue where TilemapLayer and TileSprite would interfere if they were together in a scene. This was due to an oversight in the shared shader that these game objects use: it failed to recognize a change in settings, so it kept using a single version of the shader. This was only suitable for one of the two object types, so the other would break. I fixed it to recognize changes and use the correct shader variant for each object.

The following updates were made after the release of beta 4.

I added smart handling of round pixels. The roundPixels option snaps vertices to integer values, ensuring that texture filtering does not apply unwanted sub-pixel blending to pixel art. We've put in a lot of effort to get this as accurate as possible, including vertex bias and the smoothPixelArt game option. However, it only makes sense for axis-aligned, unscaled graphics. When an object is rotated or scaled, its vertices do not naturally align with integer values. Forcibly rounding the coordinates causes the object to warp and flicker by a single pixel, which is very noticeable.

So I added logic to check whether an object would be axis-aligned and unscaled, and only activate roundPixels if it met the criteria. This was not quite as straightforward as checking rotation and scale! An object can have a "parent transform" which alters its transformation matrix. For example, a transformed camera, or Container, can combine their transforms with that of the object. My final check looks at the values of the transformation matrix itself, which should be in the identity state:

1 0
0 1

That matrix looks very simple if you're used to 4x4 matrices used in 3D graphics! And it is. We actually use a 3x3 matrix for 2D work, but the other parts are relevant only to translation.

Finally, I added support for the resolution property on TextureSource. This property exists in Phaser 3 but is not connected to anything. In Phaser 4 it is now connected to the resolution property of TextStyle, so when you increase text resolution it simply increases sharpness instead of increasing the size of the text.

Coming soon: The Phaser 4 Shader Guide! This is currently already over 4000 words and in draft review. It will cover all the important steps, rules, and suggestions for making powerful shaders and filters in Phaser 4. More details about this next week.

Share your content with 18,000+ readers

Have you created a game, tutorial, code snippet, video, or anything you feel our readers would like?

Please send it to us!

Until the next issue, happy coding!

Welcome to the latest issue of Phaser World. We’ve some great community tutorials and games in this issue. It’s always inspiring to see developers achieve their dream of releasing their game on Steam (even in beta form), and we’ve another banger this week in the shape of Veliri, the awesome work of a solo dev.

♥️ Create TriPeaks Solitaire with Phaser

Discover how to build a TriPeaks Solitaire game using Phaser JS, the powerful HTML5 game framework. This step-by-step tutorial guides you through the process of creating a fully functional card game, complete with smooth animations and interactive features.

Watch Tutorial

👸 Himegotchi

You are a rich, ferocious dragon, and you have just kidnapped the most beautiful princess in the kingdom; what a great position to be in as a dragon.

The princess is a feisty one and has a lot of demands, keep her happy and don't let the princess escape!

Play Game

🧱 Tile Based Platformer Tutorial

Emanuele Feronato is back with a new tutorial all about building a tile-based platformer with slopes and no physics engine in Phaser.

Read Tutorial

🤖 AI for Texture Generation in Phaser

A recent article on Restack.io explores the integration of AI-driven texture generation within Phaser games. The piece delves into how AI can dynamically adjust game difficulty, generate procedural content, and enhance non-player character behaviors.

Read Tutorial

🚀 Veliri: Planet of Machines

TrashPony's new game Veliri offers players a unique blend of economic simulation and sci-fi warfare in an ever-evolving online world. Set on a distant planet, players take control of synthetic war machines competing for resources and influence across a dynamic battlefield.

Play Game

📺 Phaser Box2D

In case you missed the announcement, our new video covers what’s possible with the new Phaser Box2D release:

Phaser Studio Developer Logs

A brief Dev Log this week as most of the team had Monday off and forgot to write their entries! Normal service will resume next issue 😅

🧑‍💻 Rich - CTO & Founder

Zeke and I have been cracking through the Phaser issues on GitHub, preparing the v3.88 release. We’ve closed loads of them, and it’s shaping up to be a nice little ‘farewell’ version before we join Ben in completing Phaser v4. We will continue to resolve issues in v3 going forward as long as they aren’t rendering-related, which is what v4 is for, so it won’t be the final release of version 3 ever, but we really do want people to move to Phaser 4, which is why we’ve kept the API as in-sync as we possibly could.

I started the week by tidying up the Phaser Discord. Various old, zombie-like channels have been removed, some others have been renamed, and I have tidied up the channel categories a lot. Also, I ditched the emojis at the front of the channel names. It makes it look a bit less colorful, but it also makes it much easier to read on the Discord mobile app.

If you’re not part of the Phaser Discord, please join here!

I’ve also been busy working on the new Responsive Layout Template. This is a comprehensive Phaser template with a set of powerful additional functions that make it significantly easier to work across varying mobile resolutions. It supports full-screen displays, the ability to pin the UI into the corner of the screen, as well as a ‘base game size’ which you can, well.. ‘base’ everything on.

We’ve seen this question come up so many times in our Discord and from our customers that we figured it made sense to create an official response to it. There are lots of different ways to solve it, too, so I had to pick one that felt flexible enough to cater for the most common game types. It was also somewhat depressing to see that even with the Screen Orientation API that browsers provide, there is no consistency between them. And, as always, iOS makes the API next to useless by reporting incorrect dimensions during the event and not implementing the rotation locking part of the API. Such is life.

This template should be ready within the next few weeks and free to all subscribers.

🧑‍💻 Francisco - Phaser Launcher

Hello everyone,

This week, we received a new design for the Phaser Launcher, and I've been working on analyzing the code for the new design and preparing our application so it can integrate the new design without needing a complete rewrite.

Additionally, as we move closer to wrapping up the software to prepare for version 1, I’ve added a split panel to the editor, something that allows users to dynamically resize the panels, which is common in this type of software.

I’ve also been thinking about the first template we’ll provide in version 1. We believe this structure is quite user-friendly for the initial release (though it might change in future versions).

The structure is as follows:

-assets
|   |-src
|   |   |-scenes/
|   |   |    |-Main.js
|   |-main.js
-index.html
-project.zero

In the assets folder, you’ll store all your assets, and this folder will be read by the browser media. Inside src, you’ll find your game’s code, and within src/scenes, you’ll have your scenes. In src, there’s a file named main.js, which will serve as the entry point for your game’s configuration. As you might have noticed, there’s also a file named project.zero. This file is meant to be a metadata file used by our editor. We might also include a file for your game’s icons, but that’s still under discussion with the team.

Tales from the Pixel Mines

17th January 2024, Ben Richards

This week: Bugfixes! I've been working through issues with Phaser 4 beta, eliminating some interesting problems.

Bugfix 1: Filter Camera Size

The inimitable Rex Rainbow identified an issue with filters. When an object was placed at a non-integer position, sometimes its camera was 1 pixel too large on the X and/or Y axis. This was visible as a flicker as filters turned on and off: undesirable!

This turned out to be due to the getBounds() method. I was relying on this to generate a rectangle describing the object, and fit the camera to that size.

Why not simply use the object's width and height? Well, not all objects have width and height. For example, ParticleEmitter does not. It has a getBounds() method, however, which measures the region in which particles exist. For this reason, I initially chose to use getBounds() for camera focusing.

However, getBounds() isn't quite correct for this task. It's supposed to be used for axis-aligned bounding boxes, a non-rotated rectangle which contains the entire object. To measure game objects, I was setting their transforms back to default, getting the bounds, and re-transforming them back into place. In retrospect, this was a sign that it was a poor fit.

The bug itself came from floating point calculations. A sprite which should be 64x64 was sometimes measured as 64x64.000000003 (or some large number of 0s), and this was rounded up to 64x65. This can happen when the position is not comfortably aligned with integers.

I experimented with more temporary transformations, attempting to zero out the position as well. But this didn't work for all game objects - again considering ParticleEmitter, moving the emitter doesn't move the particles, so the bounds don't move. But with a sprite, the bounds do move when the position changes. This means that different objects behave differently - and that makes everything unpredictable. We can't produce confident results like this.

So I changed my approach completely. I started using width and height instead.

Didn't I just explain why those are no good? Yes. But everything is a compromise, and here I was able to find a workable trade-off. Width and height are no good for game objects like ParticleEmitter - but they are perfect for ordinary sprites, with no floating point errors.

For objects that cannot use width and height, we use a fallback: the "external context". This was already implemented for objects that have no getBounds() method. The external context is just the camera in which the external filters are rendered, often the base game screen itself.

This has two consequences.

First: objects without width and height now have no practical difference between internal and external filters, as they use the same context.

Second: some objects which used getBounds() to get a precise internal context will now use the fallback, losing that precise internal context. ParticleEmitter is affected. We don't think this will have a major impact. In fact, it may improve visual consistency, as these are usually dynamic objects which change size rapidly, and many filters take effect in steps based on the size of the context. The external context is generally of fixed size, so these filters will behave consistently.

The update also removes several function calls from the filter camera focus method. This simplifies and improves performance in the function. Performance isn't important here: filters initiate one or more draw calls, which are vastly more expensive than a single function of this kind. But the simplification is always good.

Bugfix 2: Camera Zoom Reversion

The equally inimitable Samme identified an issue with scaling filtered objects. When an object scaled on a single axis, the filter render process rendered it inaccurately. It cut off the sides on one axis, and opened margins on the other axis.

At first, I had no idea what was happening. I thought I might have overlooked something in the filter camera zoom settings, or made a mistake in multiplying matrices in the correct order. Some of my tweaks fixed one axis, but for no apparent reason, and the other axis continued being wrong.

Once I started looking at the raw matrix data, however, I noticed something. The transform matrix for the filter camera was symmetrical.

That didn't seem right. If I scaled an object by 2x1, I shouldn't see a matrix like this:

1.5 0.0
0.0 1.5

Where does 1.5 come from? Those positions in the matrix are supposed to be scale factors (when there's no rotation or skew). When scaling by 2x1, I should see 2 and 1 in those slots.

Then I remembered an old commit. Years ago, camera zoom was a single value - but then it got split up into X and Y components. The single value still exists, but it's not a permanent value; Camera.zoom just returns the average of the X and Y components.

And the average of 2 and 1 is 1.5.

Obviously, the camera was using zoom somewhere, not zoomX and zoomY as intended. And indeed, it was right there.

When we merged the new Beam renderer into Phaser a couple of months ago, we accidentally introduced a regression in the Camera code. One specific function started using zoom again. This meant that all cameras could no longer scale on X and Y axes. Fortunately, this is rare, which is why we hadn't caught it yet.

So I fixed the regression, and everything worked again.

Next Week

I've got a few more bugs to squash. Then it's time to write the Renderer Guide.

Living in Aotearoa New Zealand, I'm currently enjoying summer. But the holidays are over, and I'm picking up steam again. Phaser 4 is almost ready - and that gives us the foundations for a whole lot of cool new stuff!

Share your content with 18,000+ readers

Have you created a game, tutorial, code snippet, video, or anything you feel our readers would like?
Then please send it to us!

Until the next issue, happy coding!

Happy New Year! It’s not too late to say that, right? This is our first issue of 2025, and we’ve got some great games and tutorials lined up for you, as well as a chunky Dev Log. Dig in …

🤯 Unity-like coroutines in Phaser

SBC Games has published a great new tutorial that will be of special interest to those who straddle the Unity / Phaser developer line: "If you are familiar with Unity, you may be used to work with coroutines. These are special methods whose execution can be suspended at specific points and resumed after a condition is met. They are handy for executing a sequence of steps.

Read More

🎮 2048 Match Balls

Imagine a world where numbered balls collide and merge, each combination bringing you closer to the magical 2048. This isn't just another matching game – it's a strategic puzzle that tests your aim and planning skills.

Play Game

⛓️ Onchain Game Jam

The Onchain Game Jam by Bario Entertainment System umbrella is designed to bring talented indie game developers into the onchain gaming economy.

This jam bridges the gap between traditional game developers and decentralized gaming, encouraging creators to explore onchain possibilities while staying true to the creativity and freedom that indie games embody.

Read More

📺 Infinite Jumper Tutorial

Scott Westover is back with a brand new YouTube series: "Today, we’re diving into Phaser Editor v4 to create something really exciting: a retro-inspired infinite jumper game! Think of the classic pixel-art vibes of games like Metroid and Super Metroid—but now, you're building it yourself.

Read More

🎮 Bubble Town Quest

It was another idyllic day in Borb Bay. Birds chirped, Borbs laughed and played. Suddenly, a shadow fell over the town. It was a spaceship from outerspace. The Lumps had arrived! And Borb Bay would never be the same again. But who was behind the insidious invasion? It is up to you to find out. Only YOU can banish the Lumps and save Borb Bay from catastrophe!

Play Game

Phaser Studio Developer Logs

The whole team is back working again, which means we have a nice big Dev Log for this issue!

🧑‍💻 Rich - CTO & Founder

This week has been its usual mixed bag of contents! Mostly, I’ve been working on Phaser v3.88, which has been a nice change of pace for me. An interesting side-effect of v3 being so well established is that the issues that come in now are quite esoteric in nature. Some require intense debugging to emulate, others only trip under particular conditions. It makes each one of them more of a challenge but equally more rewarding to close. Hopefully we should only need another week or two of dev before releasing. As with most v3 updates, these primarily address issues rather than dropping big feature bombs.

I also updated the Phaser API docs, so they contain all the current versions, which are available via a drop-down list. This makes navigating specific versions possible.

I’ve also been working on updating Phaser Box2D. There has been one new release, which fixes a minor issue but mostly continues the path of merging upstream changes into the core. This is an interesting process because the official box2d repo is a live, breathing, experimental bed of work. Ideas are tested, sometimes kept, sometimes dropped, and often mixed into the same commit as bug fixes and benchmark tweaks. Atomic, box2d commits are most certainly not, and unpicking those commits is often a real challenge. Still, that’s the price you pay when you hook onto an existing library of any kind. You have to match their style and processes, or you just cause a world of pain for yourself later on if you deviate too far.

Once v3.88 is out, the next objective is the release of Phaser v4.0.0 and Phaser Launcher, as well as building out the future roadmap. 2024 was a massive year for us. We shipped an incredible amount of products. We know what we want to achieve this year, and right now, all tasks revolve around making that happen.

🧑‍💻 Francisco - Phaser Launcher

Happy New Year, everyone!

This week, a bunch of stuff happened in Phaser Studio and Phaser Launcher.

In Phaser Launcher, I’ve been focused on improving the editor workflow, making sure everything works as smoothly as possible to get ready for the V1 release. I fixed a few annoying issues with folder creation—one of those "small but important" kind of fixes.

I also made a game! I followed the awesome guide by Emanuele Feronato: "Quick HTML5 prototype of ‘Vampire Survivors’ built with Phaser (like the original game).” The process was super fun, and it really highlighted how smooth creating a game feels now with the editor. The results look great too, which is always a nice bonus.

We’ve also been talking about adding new channels to the launcher, such as the channel for the tool Richard created to generate images using artificial intelligence and the Phaser Explorer to make browsing Phaser’s documentation much easier.

(don’t worry, it won’t look a thing like this when released! Simon is busy crafting the UI right now)

On top of that, I’ve been dealing with some Tauri V2 permission issues. During internal testing, Richard noticed that it wasn’t possible to create files or folders on a different drive from the system drive. To solve this, Can, Richard, and I discussed the issue, and the solution turned out to be simpler than it seemed.

Tauri V2 provides fs:scope, which helps us grant access to specific folders. So, the configuration now allows reading and writing on different drives. This means everything should work smoothly for V1.

Possible Future for the Tool

This week, I’ve also been exploring new Rust tools for creating builds. I’d like to incorporate this into the launcher so that when users hit "Play," a new build can be generated automatically. We might even be able to use TypeScript in the tool.

Additionally, I’d like to add more helpful features to the tool. For example, when you right-click on a .png file, it could automatically generate and copy the import code for that file, or even handle the import process automatically. Another idea is to make the scene generator fully automated as well, so when you create a scene, it’s imported right away. These features could save users a lot of time and streamline the workflow even further.

That’s it for this week! Catch you all next time with more updates on Phaser Launcher.

🧑‍💻 Zeke - Phaser v3.88

A very happy new year =)

After some good time off at the end of 2024 of rest, relaxation and refreshing, I’m back on board to tackle a string of GitHub issues.

Two things I’m thankful for as I begin my year:

1. Being part of an amazing team

2. You: being part of an amazing community

Why #2? Because a passionate community helps everyone grow and improve (our team included). Here’s how you help us become better:

1. Reporting issues on GitHub whenever you discover bugs or problems that don’t seem to have a solution. This helps us dig in further into our codebase to see where things can be improved.

2. Reporting issues on GitHub AND suggesting solutions. This saves a tonne of time for the team and benefits the entire community. Our resource stays focused on testing your solutions then quickly pushing it to our master branch repository.

Here is a list of GitHub issues I was looking at last week:

• #6996: Wrong math variables used in the crop component for trimmed frames. Thanks @CrispMind for reporting this and suggesting a solution that we could immediately publish to fix this issue.

• #6992: The calculation for widthInPixels and heightInPixels causes incorrect layout and rendering in hexagonal tile maps. Thanks @ptantiku for the heads up and providing a solution that can be published quickly after some testing.

• #6979: Interpolate.ColorWithColor always returns a ColorObject with an undefined color value. After some digging, it was discovered that not only the color value was undefined, but the alpha value was missing too. Thanks @XWILKINX for bringing this to our attention.

• #6972: Setting ignoreDestroy to true on game objects causes the game to freeze when leaving a scene. Thanks @samme for quickly pointing out the cause of this issue that happens in the DisplayList#shutdown() function. I made a minor code change in the while loop to ensure the Displaylist is cleared even if the game object is not destroyed. If you are thinking of moving a complex game object between scenes, this could be a possible solution. Thanks @Stever1388 for bringing this to our attention.

• #6967: The ArcadeColliderType is missing the StaticBody type. Strangely enough, all other occurrences where the Arcade Physics Body or StaticBody type is required, this is the only place where StaticBody is missing. Thanks @yongzheng7 for bringing this to our attention.

• #6893: NodeJS: scene ready before plugins loaded. There are cases where our community members run Phaser on NodeJS. Phaser typically runs on the browser and uses the HTML Canvas APIs. The challenge with NodeJS being server-side is it lacks native rendering context and this can cause some things to break. In this case, plugins aren’t booted up because it depends on completing a scene’s boot sequence in the browser. After discovering where the plugin boot happens, it was a simple fix to automatically boot the plugin whenever headless mode (server-side or non browser-based) is set in the game config file. Thanks @hubertgrzeskowiak for reporting this issue.

So what’s next?

• Tackling more GitHub issues (keep them coming so we can continue improving Phaser and making it a better)

That’s it for the week. Hope you have a good week ahead.

🧑‍💻 Can - Discord Activities

Happy New Year/Mutlu Yıllar, everyone!🌟

After having a blast year with the team & community, 2025 is here - refreshed the body and soul with bigger plans! I'm very excited to see where the journey goes.

Discord Monetization Guide

Last week, I kicked off the year by diving into the Discord monetization guide. If you haven't yet explored how to create Discord Games with Phaser, check out our tutorial.

This guide is one of the few resources out there focused on monetization within Discord games. We aim to show how to use the SDK effectively and implement monetization strategies(technical one!) in your projects.

You’ll find:

• An overview of Discord monetization options and how they work.

• Practical code examples for different scenarios.

• A step-by-step guide to implementing a one-time purchase feature that grants a badge reward on your Discord server.

We believe this guide will be handy for developers looking to make the most of their games on Discord.

As usual, keep your pixels sharp everyone!

🧑‍💻 Arian - Phaser Editor

Hello friends!

This past week I've been working mainly on Box2D. To be precise, most of the time looking at examples, reading the documentation, and doing little experiments.

One of these experiments is a "Box2D editor" inside Phaser Editor. Take a look at how it looks:

Well... the truth is that this is not a new tool of the editor, but regular shapes which I then convert into Box2D bodies in the game code itself. Although this is a "trick", it has allowed us to get an idea of ​​how we can implement our final tool. For example, so far we know that we will have to make a project template for Box2D and a new option to create a scene with Box2D support.

In this past year, we have seen many advances in the editor. Without a doubt it has been one of the most prolific years of the editor, which has been in development for 9 years now. This was to be expected, since we are now a team that has valuable experience in the field of video game development. Starting with the creator of Phaser himself... who better to contribute ideas and lead the development of the editor?

These are some of the features we added to the editor in 2024:

• A massive improvement of the script nodes presentation and installation workflow.

• Improved numerical input fields, that you can change with the arrow keys and the mouse wheel.

• A welcome page.

• Game object shader effects support.

• An in-scene particle emitter tool, with in-line preview.

• A new -amazing- logo.

• An improved "new project" workflow, that includes installing dependencies and starting the development HTTP server.

• Integration with the Phaser website authentication.

• A certified installer of the editor for macOS and Windows.

• A new Video game object.

• A Chat window integrated into the editor to contact the Phaser Studio support team.

• Improve assets workflow: from dropping files and folders to importing the assets.

• Adopt Monaco editor as the built-in code editor.

• Migrate to JavaScript ES modules in all project templates.

• In-scene preview of sprite animations.

• New Settings UI: including Keyboard shortcuts, external editor and external browser configuration.

• A complete built-in tilemap editor.

• Compressed textures.

If 2024 was a wonderful year for the editor, wait until 2025! For this year we plan to incorporate such important tools as:

• Tween-based animation editor.

• Layout manager for responsive games.

• Assets and template marketplace.

• Box2D physics editor.

• Publishing outputs.

• Support for many other game objects: Mesh, Plane, Geom, Shapes, Masks, Path.

• Game UI.

Will we be able to implement all this this year? I think so, to a large extent!

Happy new 2025!

Tales from the Pixel Mines

13th January 2024, Ben Richards

Happy New Year! We've got plenty of awesome things in the works for 2025. Here's just a sampling.

Phaser 4

We're polishing up Phaser 4 for release as we speak. The public beta has found a few bugs in the advanced filter padding logic, which I'm in the process of fixing. This is honestly great news; everything else seems to be working, and working better than ever. The new Beam renderer is a big improvement for speed, reliability, and flexibility of WebGL rendering.

Don't Stop Shading

Shaders are a vital part of game development. We understand that, and we're coming up with multiple ways to get awesome shaders into the hands of developers.

Rendering Guide

I've been discussing the internals of the renderer on Discord for much of the past week. It's clear we need a guide, not just to writing shaders for Phaser, but for the whole Phaser Beam rendering pipeline. So my next task is to write that guide, covering all the key parts of Beam:

• RenderNodes

• DrawingContext

• Batch Rendering

• WebGL State Management

• Basic Sprites

• Nested Rendering

• Filters

• Shaders

Shader Library

There are infinitely many possible shaders. We can't fit them all into Phaser. So we're planning the next best thing: a shader library for sharing shader and filter plugins.

We removed a lot of filters from Phaser 4, as they were too specialized to be useful to most developers. I've always planned to bring them back as plugins. This keeps the Phaser library small, but preserves the ability for developers to use shaders and filters freely.

New Frontiers

Right now, we're focused on making Phaser 4 the best 2D compositing system we can. But development doesn't stop there.

Rich has said that 3D is on the cards. We don't know what shape this is going to take yet, but we want to do it seriously. This is why we removed the Mesh and Plane objects that were in Phaser 3. They're useful, but they would be more useful as part of a true 3D system. Games in the 21st century rely on a lot of technologies, from lighting to animation, and I'd like to take the time to get it right.

Before that happens, though, we've been discussing smaller projects to push us in the right direction. See how I called Phaser 4 a "2D compositing system"? That's a very specific approach to rendering. Phaser's core strength is putting sprites on the screen, building up a scene layer by layer. That's very flexible, but it has tradeoffs in CPU time computing transforms, and bandwidth sending buffers to the GPU.

What if you didn't have to do that? Well, then you'd be able to render 100 times faster, handling literally millions of sprites. The cost is, you're no longer able to control the sprites you're rendering. Can you keep a secret? Listen: You don't need to control backgrounds. They stay in one place. Can you keep another secret? That's not true - backgrounds can move.

But hush - it's a secret. We think you'll be happy when you see what we've been cooking.

Into the Future

We've got big plans, and it all starts with Phaser 4. The beta is ongoing, so check it out if you haven't already. It's both a huge change, and a tiny change. Unless you work with masks, FX, shaders, or other parts of the render system directly, it should just work. We worked hard to make it as compatible as possible - and where we couldn't, we made it better instead.

From there, the wild ride continues. We hope you'll be there with us in 2025.

Share your content with 18,000+ readers

Created a game, tutorial, code snippet, video, or anything you feel Phaser World readers would like? Then please send it to us!

Until the next issue, happy coding!

In this issue, we have the free version of Phaser Box2D and new versions of Phaser v4 and Phaser Editor.

⭐ Phaser Box2D Released as open-source

A free, high-performance, industry-standard 2D physics engine built on Box2D v3.

We’re happy to announce that Phaser Box2D is now available completely for free and has been released as open-source.

The Phaser Studio team is thrilled to announce the release of Phaser Box2D, the ultimate 2D physics engine for creating realistic, physics-driven games for your browser. Whether you’re building fast-paced shooters, intricate puzzle games, or sprawling RPGs, Phaser Box2D is here to take your creations to the next level.

Phaser Box2D is powered by the latest version of Box2D, a cutting-edge physics engine designed for accuracy and performance. We’ve painstakingly converted the Box2D v3.0 API, written in C, to modern JavaScript, making Phaser Box2D the only v3 port available for the web. We’ve optimized it specifically for browsers, so it’s fast, powerful, and ridiculously easy to integrate with all modern web stacks.

It's also open source and released under the MIT license, so you're free to use Phaser Box2D in your games and applications. Phaser Pro and Enterprise customers can also benefit from priority technical support from the team that created it.

No one likes laggy physics or buggy collisions, and with Phaser Box2D, you won’t have to deal with either. Thanks to a fancy new Soft Step Rigid Body Solver, your physics will stay stable and smooth—even with fast-moving objects or crazy stacks of bodies. Plus, its island-based sleep management keeps things efficient by letting inactive objects and your processor take a break.

Have you ever had a bullet magically phase through a wall? Not with Continuous Collision Detection (CCD). Whether it’s high-speed objects, tricky AI behaviors, or complex aiming mechanics, Phaser Box2D makes sure everything behaves exactly how you expect.

We’ve kept it simple. Phaser Box2D works right out of the box as an ES Module. It’s also tiny — just 65KB when zipped — so it’s perfect for web games and playable ads. And for those of you who’ve used Box2D before, good news: we kept the original C API function names, so you’ll feel right at home. The added benefit of this approach is that if Box2D is new to you, you can rely on its rich 18-year history to learn it faster because tools like ChatGPT and Cursor understand its C API well.

It’s also packed with features you’ll love:

• Shapes, Shapes, and More Shapes: From circles to chains to rounded polygons, create the environments and characters of your dreams.

• Composite Bodies: Combine shapes for vehicles, ragdolls, or even funky robots with multiple collision parts.

• Versatile Joints: Build swinging doors, working pistons, or even car suspensions—if you can dream it, you can make it.

• Smooth Physics: Speculative collisions and continuous motion handling keep everything looking and feeling real.

We’ve also included over 50 examples to get you up and running in no time. From mini-games to single-feature demos, you’ll have everything you need to get inspired and start building.

Phaser Box2D is here to help you create incredible, physics-driven games that wow your players. Whether you’re an indie creator or a pro studio, this is the tool to bring your ideas to life.

Ready to get started? Let’s make some magic together!

Download Phaser Box2D

🚀 Project X: Light Years

Classic Shooter Gameplay Reimagined with Cutting-Edge Visuals and Design

Project X: Light Years is an exciting reimagining of the classic Amiga shooter, brought to life by MK Games and Team17. Fans of the original Project X will find themselves immersed in a modernized experience that pays homage to the roots of the genre while introducing new twists for today's gamers.

Scheduled for release on Steam, this game offers a fresh perspective on the beloved side-scrolling space shooter format. In partnership with Team17 this is an official entry in the Project X series. Engage in space combat as you navigate through visually stunning environments and swarms of enemies, and upgrade your arsenal to become the ultimate space fighter.

A demo version and gameplay videos are available on Steam.

Play Project X

⭐ Phaser Editor 4.8.1 Released

Enhancing Your Workflow with Compressed Textures, Asset Management, and more

Phaser Editor 4.8.1 launches with powerful compressed texture support, enabling seamless integration into scene and animation editors. The streamlined workflow pairs compressed textures with standard image files as fallbacks, while introducing robust blend mode controls for game objects and enhanced Glow FX capabilities with fine-tuned quality and distance parameters.

The update increases workflow efficiency through further improvements: a dynamic asset pack visibility system for superior asset management, quick OS terminal access via the Files view, and an improved file deletion system that utilizes the recycle bin in the Desktop edition. This polished release also squashes key bugs, addressing sprite animation preview glitches, Outline view navigation issues, and scene editor grid rendering at high zoom levels.

Subscribers can download this version immediately.

Read more about this release

🔦 Phaser Raycaster Plugin

The latest update of this raycasting plugin is now available

Phaser Raycaster is a Phaser 3 plugin, released by Wiserim, which provides raycasting for geometric Game Objects, Sprites, Arcade Physics, and Matter Physics bodies.

It has been in development for a while, but the new v0.10.11 release has just been made available, with updated documentation and examples to be found on CodePen.

Read more about Phaser Raycaster

⭐ Phaser v4 Beta 3 Released

The final release of the year introduces the new Filters Component and more fixes.

We're very happy to announce that Phaser v4 Beta 3 is now available on GitHub and npm. This represents all development work over the past month and takes us another step closer to the final release in Q1 2025.

The biggest change in this version came about thanks to the community feedback in the Phaser Discord. In short, we decided to rework the way RenderFilters work:

Previously, the RenderFilters object wrapped game objects to apply Filters. This worked well in several ways, but because it replaced the existing game object, it made object references less reliable.

The decision was made to change Filters to a component on game objects. This is similar to the old FX system, but it is now built into the base GameObject, so it can be used everywhere. Filters are not FX (they're better).

For those who have been using Phaser 4 beta 1 or 2, this will change the way you use filters. The core principles are the same, however: filters are still divided into internal and external lists.

Read more about Phaser v4 Beta 3 and be sure to read the Dev Log this issue too

📺 Build a Retro Style 2D Game

Learn Game Development with Phaser 3!

Jeremy Morgan has released a new tutorial on his site, How to Make Games, and also published it on YouTube: "Have you ever wanted to create your own video game but didn’t know where to start? In this video, we’re diving into game development with Phaser 3, a powerful and beginner-friendly JavaScript framework. Whether you're a total newbie or just curious about coding games, this is the perfect place to start!

Watch the video on YouTube

Phaser Studio Developer Logs

The Phaser Studio team is all off enjoying their holidays at the moment, but both Arian and Ben left developer logs before they went - so here’s a slightly reduced Dev Log for you all.

🧑‍💻 Rich - CTO & Founder

This is the final issue of Phaser World for 2024, and I’m taking a week off from writing, returning in early January 2025. Approaching the end of a year always makes me think back to what has been accomplished in the previous 12 months. I find that a little retrospection helps to focus the lens on what should be achieved in the coming year.

Suffice it to say that 2024 has been an epic year.

When you consider that Phaser Studio was only formed in December 2023 and consists of just 8 full-time staff (and a selection of lovely contractors), the fact we’ve managed to output so much is a testament to the determination and hard work of all those involved. I was planning on making a list of everything we released as a team this year, but the length of it was getting silly, so instead, here are some highlights:

• Constant Phaser Editor updates. From v3.66 to v4.8.1 with almost a release a month.

• Constant Phaser updates. From v3.80 up to Beta 3 of v4.0.0.

• The creation of a brand new state-of-the-art renderer for Phaser 4 from scratch.

• Over 50 Phaser Templates for React, Vue, Rollup and many, many more.

• The release of the Create Phaser Game CLI app.

• Complete documentation overhaul with hundreds of pages of new content written.

• A huge free book published! And lots of new tutorials covering Discord, Ionic, and Box2D.

• Phaser Compressor, Phaser Explorer, Phaser Playable Ads, and Phaser Sandbox released.

• A stunning new website 😀 and a growing new YouTube channel.

• 50 issues of this newsletter and 200 articles posted to the Phaser website (most of which I wrote!)

And this isn’t even everything. It is, however, a good representation of the diverse types of tasks any modern software company needs to undertake. Yes, of course, you need to write code, but if you don’t pay attention to the whole ecosystem around it, all of that hard work can often be in vain.

And if you do pay attention, the rewards are worth it.

The Phaser Templates we published? Our analytics show they’ve been used over 76,000 times in the past couple of months. Right now, someone is building a Phaser game every minute of every day.

Or the website? After the relaunch at the start of October, we’ve seen a dramatic uptick in registrations and time spent on the site. This week, we passed 27,000 registered users, which is an incredible amount of people if you stop to think about it for a moment. As for page views, we’ll close the year with over 7 million of those. You guys are reading a lot!

Interest in building games for the web is truly stronger than it has been in a long while.

I would attribute this to a couple of factors. The first is that you can now play web games pretty much anywhere. Everything is a games platform. From Discord Activities, Telegram, WeChat, YouTube Playables, Reddit, and even LinkedIn. Big tech is waking up to the appeal of games to keep people on their sites or apps. And game devs are waking up to the notion of taking their games, or little slices of them, to the places where gamers dwell. Of course, where there is a captive audience, there is a need to build for them, and Phaser is optimally positioned right in the center of this perfect storm.

The other factor that shouldn’t be ignored is the rise of AI.

How we write code has changed forever. Our first port of call is now a Copilot, Cursor, or LLM, which we’re using to supplement our skills and knowledge at a faster pace than ever previously possible. For skilled developers, AI is an enhancement tool like no other. Yet, we’re also seeing the opposite end of the spectrum. Developers are coming to the Phaser Discord and showing us games they’ve made entirely with the help of ChatGPT. Because OpenAI, Anthropic, and the rest have ingested and trained upon all of the Phaser documentation and API, it’s tightly embedded into their vector stores, making it relatively easy for them to guide beginners through the process of game creation in a way that was previously unthinkable.

Of course, this also extends into game assets, too. The creation of sprites, characters, title screens, logos and other game elements is now commonly handled by AI tools. We had originally planned to create an Asset Marketplace for Phaser developers so they could easily buy graphics and sounds to use in their games. In all honesty, this now seems like a pointless endeavor. Based on progress in this space alone in the past year, it’s only a matter of time before the type of developer who would have previously purchased assets from a store will generate them instead. This tidal shift is inevitable. It’s not going to replace game artists of course, there will always be a place for those skills, but in projects where it’s a solo dev, or small non-art team, they’re the perfect candidates for these tools.

Quite how this fits with Phaser we’re not entirely yet sure. But as I mentioned at the start, you have to keep an eye on the whole ecosystem to understand what direction to take. And like it or not, AI is now a key part of game development.

At the most basic level, it means we ought to consider how to provide Phaser documentation in a way that makes it easy for LLMs to digest and parse rather than writing it for humans first. And I can’t help but wonder how long it will be before we need to start designing our APIs in a similar manner. Classes, function names, and parameters tailored specifically for AI so that it can generate the most optimal and error-free code possible. It’s all food for thought as we round out the year.

Of course, the immediate technical priority of Phaser Studio in 2025 will be to get Phaser v4 released and used. And this is being built for humans 😅 I just wonder if I’ll be saying the same in a year’s time.

All that leaves me to say is thank you for joining us on this exciting journey, whether this is your first issue or you’ve been on this crazy ride since the very start. 2025 will be another epic year for Phaser Studio, and I hope it is for you, too.

🧑‍💻 Arian - Phaser Editor

Hello friends,

In the last few days we have been working on a new release of the editor. It is ready and will soon be announced on our channels. The key thing about this new version is that it incorporates support for compressed textures. This is a feature that many of you will not use, but for some cases the possibility of using these textures is of great importance. In addition, for the release we have reviewed the list of issues on GitHub and have implemented some of the community requests.

Some of these issues are: Send to the recycle bin instead of deleting a file. Add a parameter to the JavaScript compiler so that it does not generate the field declarations. Add the quality and distance properties to the FX Glow object, and the blendMode property to all Game Objects.

We also implemented a new command to open the operating system terminal in the folder selected in the Files view. This complements the "Locate File" command, which opens the system file explorer.

Something interesting we did, and which was also a community request, is adding the visible parameter to the Asset Pack editor. As you know, all the editor tools that work with assets use asset packs as a manifest for the assets available in the project. With the new parameter you can "hide" an asset pack from the view of the other editor tools, which allows you to filter them out and focus only on the ones you are working on in cases where you have a large amount of assets. It can also help you simulate a kind of skin system, where you can activate one skin or another and get better feedback when designing your levels.

During this week we have been working on the editor documentation. It is mainly an update task: features that are no longer there or have evolved, old screenshots, links to Phaser documentation, and also style. Thanks to the VS Code Copilot extension, I can now write in slightly improved English. Perhaps this is all we'll be doing regarding the editor for the rest of the year, as many of us on the team will soon be going on vacation, and el 2025 viene echando candela.

Tales from the Pixel Mines

20th December 2024, Ben Richards

In the past couple of weeks, I've changed the way Filters work. This affects more than just Filters, though; it adds a whole new way to manage rendering. I've also fixed some issues with Filter padding.

Render Steps

The RenderSteps system allows us to add steps to rendering, in addition to the renderWebGL method.

RenderSteps is available on all GameObjects. The basic idea is simple: we want to run a series of functions, so we can override or defer rendering. For example, if an object has filters, we want to render the object to another framebuffer, so we want to run extra code around the normal render.

This isn't as simple as running each function in sequence. In the filters example, we want to set up framebuffers, run the normal render, then run the filters. While we could break up the filter logic into two sequential functions, this is difficult to manage. It's easier to use one function, which can start the next step when it reaches the correct point.

So we add a parameter to these step functions: the current step. In most cases, we're running renderWebGL and it doesn't need to start another step so it doesn't care about this parameter. But when we do care, such as when rendering filters, we can use the current step to find the next step in the list of steps, and run that at the appropriate time.

This lets us "wrap" the render function in another function. By wrapping the function, we can override behavior without wrapping the entire game object, which can cause issues.

RenderSteps are currently only used to add Filters, but they can be used for any system that needs to run during the rendering process. Debug graphics are one possibility.

Goodbye RenderFilters, Hello Filters Component

Previously, the RenderFilters object wrapped game objects to apply Filters. This worked well in several ways, but because it replaced the existing game object, it made object references less reliable.

The decision was made to change Filters to a component on game objects. This is similar to the old FX system, but it is now built into the base GameObject, so it can be used everywhere. Filters are not FX (they're better).

For those who have been using Phaser 4 beta 1 or 2, this will change the way you use filters. The core principles are the same, however: filters are still divided into internal and external lists.

The new way to use filters is thus:

// Set up filter systems.
gameObject.enableFilters();

// Create filter controllers.
const blur = gameObject.filters.internal.addBlur();

When you run enableFilters(), Phaser creates an internal camera to handle the object's filters, and adds a RenderStep function.

By default, when there are no active filters to render, the RenderStep skips straight to renderWebGL. If you want the object to render to a framebuffer without rendering a filter, you can set gameObject.filtersForceComposite = true. This can be useful when you want to composite alpha, e.g. when you have several objects in a Container or Layer and you don't want to see them through each other, you can leave their alpha at 1, set filtersForceComposite, and reduce the alpha of gameObject.filterCamera.

Filters run focusFilters every time they render by default. This differs from RenderFilters.focus, which didn't run every time. This method ensures that the filterCamera is always locked onto the object. Some objects don't have enough properties to accurately lock on to, so the system will guess, and fall back to the screen resolution. You can run gameObject.focusFiltersOverride to manually set the camera target.

In general, this runs much like FX did - but with more control and better compatibility.

Filter Padding Fixes

I fixed some issues with filter padding. This padding is used to give filters extra space to work in, e.g. when an object is blurred it should extend outside the usual boundaries of the object and not be abruptly cut off.

I hadn't fully tested this system when I first implemented it, and it turns out there were some issues. When objects were rotated or scaled, the padding was applied in the wrong direction. This was not immediately obvious. Only when the padding changed, growing or shrinking, was it clear that it was pointing the wrong way.

What was happening: I had combined the internal and external padding to describe the position of the internal quad within the external context. But this meant that the external padding was transformed with the object, when it should have remained with the external context. I removed it to a step after the transform was calculated, and the issue was resolved.

This sounds like an obvious problem and an obvious fix. And I'm sure it was, to some minds! Alas, mine was recovering from illness, and there were more than a few moving parts involved, so it took me a moment to figure it out.

That's what it's supposed to look like, by the way. This might be helpful in visualizing what exactly filter padding does. (The diagram was made in Phaser itself, by the way. It's not just a game engine; it's a data visualization system!)

A Question About Texture Coordinates

As you may know, WebGL measures the Y axis starting from 0 at the bottom of a texture. Most software measures from the top. So Phaser does everything on the assumption that Y = 0 is at the top to keep things simple.

But it occurs to me that this might not actually keep things simple. These coordinates only really surface inside shaders, and most shaders are written with a bottom start. This means shaders written elsewhere have to be adapted for Phaser.

What do you think? Should we swap to use the conventional, bottom-first Y axis?

Next Week, er, Year

Next week I'm celebrating the holidays with family, and recuperating from a busy year. I've had a great time with Phaser Studio so far - I just have to remember to take time off every so often!

In the new year, we'll be putting the finishing touches on Phaser 4. The main area for public testing is the new shader system; I want to write a guide for using it, to make sure it makes sense to everybody else.

In the meantime, have a happy holiday, whichever is best for you. Meri Kirihimete from me to you!

Share your content with 18,000+ readers

Created a game, tutorial, code snippet, video, or anything you feel Phaser World readers would like? Then please send it to us!

Until the next issue, happy coding!

After months of hard work and Dev Log entries, we’re delighted to announce that Phaser Box2D is now available. This issue of Phaser World will be specially dedicated to exploring what it offers. However, we also have two tutorials and two great new games at the end! Regular newsletter service will commence in the next issue. For now, let’s fling some dynamic bodies around.

🚀 Phaser Box2D is now available

Create immersive, physics-rich 2D worlds

The Phaser Studio team is thrilled to announce the release of Phaser Box2D, the ultimate 2D physics engine for creating realistic, physics-driven games for your browser. Whether you’re building fast-paced shooters, intricate puzzle games, or sprawling RPGs, Phaser Box2D is here to take your creations to the next level.

What Makes Phaser Box2D So Awesome?

Phaser Box2D is powered by the latest version of Box2D, a cutting-edge physics engine designed for accuracy and performance. We’ve painstakingly converted the Box2D v3.0 API, written in C, to modern JavaScript, making Phaser Box2D the only v3 port available for the web. We’ve optimized it specifically for browsers, so it’s fast, powerful, and ridiculously easy to integrate with all modern web stacks.

Performance That Speaks for Itself

No one likes laggy physics or buggy collisions, and with Phaser Box2D, you won’t have to deal with either. Thanks to a fancy new Soft Step Rigid Body Solver, your physics will stay stable and smooth—even with fast-moving objects or crazy stacks of bodies. Plus, its island-based sleep management keeps things efficient by letting inactive objects and your processor take a break.

Pinpoint Accuracy

Have you ever had a bullet magically phase through a wall? Not with Continuous Collision Detection (CCD). Whether it’s high-speed objects, tricky AI behaviors, or complex aiming mechanics, Phaser Box2D makes sure everything behaves exactly how you expect.

Easy Integration

We’ve kept it simple. Phaser Box2D works right out of the box as an ES Module. It’s also tiny — just 65KB when zipped — so it’s perfect for web games and playable ads. And for those of you who’ve used Box2D before, good news: we kept the original C API function names, so you’ll feel right at home. The added benefit of this approach is that if Box2D is new to you, you can rely on its rich 18-year history to learn it faster because tools like ChatGPT and Cursor understand its C API well.

Packed with Features You’ll Love

• Shapes, Shapes, and More Shapes: From circles to chains to capsules (a new Box2D v3 feature), create the environments and characters your game needs.

• Composite Bodies: Combine shapes for vehicles, ragdolls, or funky robots with multiple collision parts.

• Versatile Joints: Build swinging doors, working pistons, or even car suspensions — you can access Revolute, Distance, Prismatic, Wheel, and Weld joint types.

• With Versatile Interactions: Combine the joints in interesting ways, with limits, motors, springs, and friction available.

• Smooth Physics: Speculative collisions and continuous motion handling keep everything looking and feeling real.

Hands-On Fun with 50+ Examples

We’ve included over 50 examples to get you up and running in no time. From mini-games to single-feature demos, you’ll have everything you need to get inspired and start building.

Made for Phaser, Open to Everyone

Of course, Phaser Box2D works beautifully with the Phaser game framework (thanks to our handy plugin), but you don’t have to use Phaser. It plays nicely with any web game framework or application, making it a great choice no matter what you’re building with.

Even the Phaser integration is entirely optional. We have been careful not to deeply tie the two together, instead opting to provide a thin layer of helper functions between the two. This makes it easy for you to roll your own fully custom integration without needing to unpick lots of legacy code. Or you can use the handy functions we created! Either is OK with us.

Let’s Build Something Amazing

Phaser Box2D is here to help you create incredible, physics-driven games that wow your players. Whether you’re an indie creator or a pro studio, this is the tool to bring your ideas to life.

Ready to get started? Let’s make some magic together!

We offer three licenses: one for those looking to integrate Phaser Box2D into their tools and systems, one for commercial use, and one for indie solo developers.

Find all the pricing details on the Phaser Box2D website.

What’s Included?

When you purchase Phaser Box2D, you will receive the following:

• A Comprehensive Getting Started Guide. This covers two sample projects, one using Phaser and one without, and guides you through some Box2D terminology and how to approach it.

• Over 50 Box2D Examples. The complete source code and assets to many examples, including stress tests, mini-games, joint and shape demos, and more. We will keep adding to the examples in the coming months. They are provided with a web-based interface and launcher script so you can quickly run them locally.

• API Documentation. We have written our own API documentation, which is included in the download. The docs cover all of the core functions you may need to use and the correct data types required for our JavaScript version.

• Vite Project template. To help you get started fast, we’ve also compiled a Vite project template that shows how to use Phaser and Box2D together. It supports development hot-reload and production build commands.

• 30 Advanced Tutorials. We’ve also published 30 detailed tutorials covering all aspects of Box2D, from querying the World to efficiently destroying bodies to advanced topics such as buoyancy and sticky projectiles. Feel free to browse the tutorials on our website.

FAQs

Q. Box2D is open source. Why does this cost money?

A. Phaser Studio invested months of full-time work into carefully porting, optimizing and testing this library specifically for web games. We believe it represents one of the most stable and feature-packed physics libraries available for the web and, as such, has commercial value to those earning from publishing web games and playables.

The Phaser Studio team also offers continuous updates and support, custom documentation, tutorials, and examples, ensuring Phaser Box2D remains reliable and up-to-date. We understand that the pricing isn’t suitable for everyone. Some developers' web games are purely a hobby. In those cases, we’d suggest a free alternative like the Rapier Physics integration we put together.

Q. Does it only work with Phaser, or can I use Pixi, etc?

A. Despite its title, Phaser Box2D is compatible with any web-based tech stack or framework, including Pixi, React, Vue, and more. It is provided as an ESM compatible Module and is not deeply integrated with Phaser itself. There is no Phaser code or Game Objects within the plugin at all.

Of course, as Phaser Studio, we include many helpful functions that ease the use of Box2D with Phaser itself. These are included with the purchase. However, using Phaser isn't a requirement.

Q. How complicated is it to use?

A. Complexity is, of course, subjective. However, we feel it would be remiss to say that this is perfect for complete beginners. You are expected to have a solid grasp of JavaScript and, ideally, previous experience with physics systems.

We provide tutorials, API Documentation, and examples from which to learn. Plus, you can ask us questions in our Discord. Even so, Box2D does have a certain level of complexity, and if you are unsure if it's right for you, we would recommend you read some of our public tutorials first to get an understanding of how it works.

You can find more FAQs on the Phaser Box2D page.

A Quick Phaser Example

In this example, we will create a simple physics Scene with a static ground platform on which we drop two dynamic bodies. The full code is as follows (minus the import statements, to save space in this newsletter)

class Example extends Phaser.Scene {

    constructor () {
        super();
    }

    create () {

        SetWorldScale(40);

        const debug = this.add.graphics();
        const world = CreateWorld({ worldDef: b2DefaultWorldDef() });
        const worldId = world.worldId;

        CreateBoxPolygon({
            worldId,
            type: DYNAMIC,
            position: pxmVec2(630, 64),
            size: 1,
            density: 1.0,
            friction: 0.2,
            color: b2HexColor.b2_colorGold
        });

        CreateCircle({
            worldId,
            type: DYNAMIC,
            position: pxmVec2(690, 0),
            radius: 1,
            density: 1.0,
            friction: 0.5,
            color: b2HexColor.b2_colorRed
        });

        const groundBodyDef = b2DefaultBodyDef();

        groundBodyDef.rotation = RotFromRad(-0.06);

        CreateBoxPolygon({
            worldId,
            type: STATIC,
            bodyDef: groundBodyDef,
            position: pxmVec2(640, -600),
            size: new b2Vec2(20, 1),
            density: 1.0,
            friction: 0.5,
            color: b2HexColor.b2_colorLawnGreen
        });

        this.world = world;
        this.debug = debug;

        this.worldDraw = new PhaserDebugDraw(debug, 1280, 720, GetWorldScale());
    }

    update (time, delta) {

        const worldId = this.world.worldId;

        WorldStep({ worldId, deltaTime: delta });

        this.debug.clear();

        b2World_Draw(worldId, this.worldDraw);
    }
}

const config = {
    type: Phaser.AUTO,
    width: 1280,
    height: 720,
    scene: Example
};

const game = new Phaser.Game(config);

This code should be very familiar to you if you've experience with Phaser. We’re using a Phaser Graphics Game Object to render our world. This is perfect for quick tests and debugging. You can, of course, hook bodies to sprites too!

We’ll show some more examples in the next issue.

We’re extremely happy with how this product has turned out. It was a lot of hard work, a lot of debugging and tweaking, but ultimately, we felt it was about time there was an industry-standard physics library available for web games, and we’re thrilled to have created exactly that. It’s fast, stable and powerful.

That’s enough Box2D talk; let’s conclude this issue with some tutorials and games from the Phaser community.

⚽ Full Breakout Tutorial

Breaking Down Breakout: Learn Essential Game Physics While Building a Timeless Classic.

Learn how to create a classic Brick Breaker (Breakout) game using Phaser JS! This tutorial covers everything from setting up the game configuration to implementing paddle and ball physics, creating colorful brick rows, and adding sound effects for an engaging experience. Watch how to handle game states like losing lives, game over, and victory, all explained with clear, easy-to-follow code. Perfect for beginners and those looking to expand their Phaser.js skills.

Watch the video

⚔️ Daily Dungeon

Your Daily Dose of Puzzle-Packed Adventure: A New Labyrinth of Challenges Every 24 Hours.

As the name suggests, Daily Dungeon is a quick-fire dungeon romp. The controls are simple. Move with the arrows, collect keys to open doors, and solve the puzzles. The difference is in the title: Every day, you get a different dungeon to explore!

Play Daily Dungeon

🧠 Steps

Game 3 of the 101 Game Challenge is out.

Emanuele Feronato is back with game 3 in his 101 game series. Each game is available both to play, and also download the source code, or buy an extended version of it. So you can simply enjoy it, or learn from it, too.

Read about Steps

⭐ Dangle Drop

Orchestrating the Perfect Chain Reaction: A Symphony of Falling Dots.

Dangle Drop is an engaging gravity-based puzzle game set against a calming night sky, challenging players to clear puzzles by eliminating all the white dots on the screen. The gameplay revolves around clicking strategically on various types of dots to create chain reactions, causing the white dots to fall away. Each puzzle offers a unique setup, and players must carefully consider their moves to succeed.

Play Dangle Drop

🖊️ State of Web Game Dev 2024 Survey

The survey should take no more than 20 minutes. The result will be used to evaluate the state of Web Game Development in 2024. The survey takes place between December 4th and 20th 2024, and we plan on sharing the results publicly in January 2025. Make sure to visit gamedevjs.com/survey/2024 for more details.

Please take part in this survey!

Share your content with 18,000+ readers

Created a game, tutorial, code snippet, video, or anything you feel Phaser World readers would like? Then please send it to us!

Until the next issue, happy coding!

A nice big chunky issue again! This time we’ve our brand-new Discord Activity Launcher available, two great new tutorials, two great new games and a Dev Logs section to enjoy!

🚀 Discord Activity Launcher Released

From Project Setup to Live Testing in Minutes with our free new tool!

Creating games for Discord just got significantly easier. Our new Discord Activity Launcher eliminates the traditional setup hurdles, offering a streamlined workflow for both newcomers and experienced developers working with Phaser.

The launcher automatically handles everything from initial project creation to proxy URL generation. Choose between single-player and multiplayer templates, and let the tool configure your development environment, install dependencies, and set up cloud tunneling - all through an intuitive interface.

For existing projects, the launcher serves as a quick way to generate proxy URLs, making testing on Discord seamless. It even integrates directly with the Discord Developer Portal, copying your proxy URL to clipboard and directing you to the right page when your APP_ID is configured.

Available for both Windows and macOS (including Apple Silicon support), the Discord Activity Launcher represents our commitment to making Discord game development more accessible.

Ready to start? Check out our comprehensive tutorial to learn how to use the Discord Activity Launcher and begin creating your own Discord games with Phaser.

Download the Discord Activity Launcher

🎨 Game Title Screen Generator Beta

Test out our new AI art tool that helps create game title screens

We’ve released a beta version of our new AI art tool, which has been built specifically to help you create title screens for your games or projects. It leans heavily into the retro 16-bit aesthetic, having been trained with a special dataset, and we’re really pleased with the results. Read about the development of this in this week’s Dev Log.

This is a time-limited beta release. If you’re reading this in the distant future, we may have already removed the service. Otherwise, feel free to have a play and share your favorite creations!

Phaser Title Screen Generator

🖊️ State of Web Game Dev 2024 Survey

The survey should take no more than 20 minutes. The result will be used to evaluate the state of Web Game Development in 2024. The survey takes place between December 4th and 20th 2024, and we plan on sharing the results publicly in January 2025. Make sure to visit gamedevjs.com/survey/2024 for more details.

Please take part in this survey!

🧠 Create a Whack-a-mole Style Game

Learn how to use Phaser Editor to create this fun monster-bashing game!

Scott Westover brings us this great new tutorial on YouTube: "Hey everyone! Today, we’re diving into Phaser Editor v4 to create a fun, monster-themed Whack-a-Mole game!

Phaser Editor makes it super easy to build HTML5 games thanks to its powerful, visual editor that helps us create engaging Phaser games with just a bit of code. In this tutorial, I’ll walk you through each step of creating a simple Whack-a-Mole-style game where you’ll learn a ton.

Watch on YouTube

🎮 Egg Hunt Mania

Scrambling for success in this fast-paced egg-catching challenge

Egg Hunt Mania turns the simple act of catching eggs into a surprisingly intense arcade experience. Players must deftly maneuver their basket to catch eggs rolling down from overhead chickens, all while managing their basket capacity and making crucial timing decisions about when to sell their collected eggs.

The game's core mechanic shines in its deceptive complexity. What starts as a straightforward egg-catching exercise quickly evolves into a challenging balancing act. The tension builds naturally as your basket fills up, forcing you to make split-second decisions: continue catching more eggs to maximize your selling price, or make a dash to the store before your precious cargo ends up as a mess on the floor?

Play Egg Hunt Mania

🧠 Create a game like Vampire Survivors

Build a quick prototype of Vampire Survivors with Phaser

Emanuele Feronato is back with the start of a new tutorial series sure to interest a lot of you: "I bet you’re all familiar with Vampire Survivors, the bullet hell roguelike that spawned a new genre of video games and hundreds of imitators.

Did you also know that it was originally built with Phaser? Probably, if you follow the fortunes of this fabulous framework.

So why not write a script of a handful of lines capable of running a prototype of Vampire Survivors?

Read the Tutorial

🎮 Lottie Arcade

Where Retro Meets Modern Web Technology

The team at Lottie, known for their web animation technology, has turned their talents to classic gaming with Lottie Arcade. Built during an internal hackathon, this collection of games brings beloved arcade classics to the modern web.

The arcade features three carefully crafted titles that capture the essence of retro gaming. Command Earth's last defenses in Space Invaders, where waves of alien forces descend with increasing intensity. Test your reflexes in Flappy Bird, perfectly timing each tap to navigate through an endless maze of pipes. For speed demons, Highway Rush offers an intense arcade racing experience as you weave through traffic at breakneck speeds.

Play Lottie Arcade

Phaser Studio Developer Logs

Here is what the Phaser Studio team has been up to this week:

🧑‍💻 Rich - CTO & Founder

Here in the UK, and I assume elsewhere in the world, there is a TV show called “I’m a Celebrity, Get Me Out of Here”. My wife and daughter love it. I can’t stand it. So I figured: What fun little evening project could I work on while this is on TV and they are otherwise engaged? Plus, I don’t have to endure watching people swim in beetles (poor beetles 🪳)

The answer came in the form of learning all about AI art generation. This has been a hot-topic for a while. We’re all no doubt familiar with Stable Diffusion’s ‘sausage-finger’ images combined with its inability to even render simple text. But I figured that things don’t really sit still for long. What was next to useless just a year ago, may be a lot more advanced now. And I wasn’t wrong. Some cursory reading on the subject led me to a new alternative model called Flux, created by Black Forest Labs. The results from this were quite staggering. It could do text! It could do fingers! It could do “display a solid red square on a white background” - such power! 🙂

But could it do pixel art? The short answer: No. Not really. It clearly has no actual concept of what pixel art even is. I was about to give up when I started reading about fine-tuning and creating your own LoRA (Low-Rank Adaptation). A LoRA works by modifying the fine-tuning process. It freezes the original model weights and then applies a separate set of weights, which are blended with the original parameters. In short, you don’t retrain the entire model - because only a handful of tech giants in the world can actually afford to do that - instead, you fine-tune it by training on a specific set of data and using those weights to influence what gets output at the end.

Now, this was fascinating. I found a bunch of online sites that offered LoRA training services for very reasonable prices. All you had to do was prepare your dataset, click a button, wait several hours, and out came a safe tensor file on the other end. So I did what I suspect a lot of noobs do. I threw in a whole batch of images, hit “train” and expected it to understand what I wanted 😅 of course, that’s not how AI works at all.

My initial test images were just a grab bag of retro game screenshots. When I asked the tuned model for an image, expecting to get some pixel-art beauty back again, it didn’t have a clue what to do and gave back rubbish. My weights were having no impact, or worse, ruining the base model. But on TV, contestants were still trying to drink blended cockroach smoothies, so I figured there had to be a reason for my training failure and dug deeper.

When you build your dataset, you have two components: the source image and a textual description of what is in that image. The quality of the description is fundamental. For example, have a look at the following image:

If you had to type in a description of this, you may write something like “a hand above a planet's surface.” I mean, sure, that is what you can see here. But the training needs much, much more detail. For example, it actually needs something more along the lines of this:

The image is a digital artwork, likely from a video game or old-school computer game, featuring a stylized, sci-fi scene. The central focus is a human hand reaching out from the bottom of the image, with fingers extended. The hand is rendered in a detailed, realistic manner with a slightly exaggerated texture, giving it a slightly cartoonish appearance. The hand is a light tan color with visible veins and creases, indicating a detailed shading and lighting effect.

Notice how precise we’re being about the placement of the hand. The shading, the color, the style. All of these things matter. This is how the LLM ‘learns’ what it is seeing. You cannot expect it to invoke any real ‘human sense’. There’s no actual ‘intelligence’ going on here. Just a huge vector cloud of related terms and weights.

Prompt an AI to create an image, and it isn’t like asking it to scan a database. If you ask for an “apple,” it doesn’t go and see what apple images it has stored and return one. Instead, AI image generation works more like the model has learned the "essence" of what makes an apple look like an apple. During training, it analyzed millions of images and their descriptions, learning patterns like "apples are typically round, have a stem, can be red or green, and often have a distinctive shape."

When you ask it to create an apple, the AI starts with random noise - imagine TV static or random dots. Then, through diffusion, it gradually refines this noise, using what it learned about apple-like patterns to transform the chaos into something that matches its understanding of "apple-ness." The LoRA is liking giving this understanding additional specialized training in a particular style or subject. When you apply a LoRA to an AI model, you're essentially tweaking its understanding of certain visual concepts.

Once I understood that, I understood the challenge a little deeper. The descriptions had to be excellent, and the source imagery had to be clean. Anything extra in the source imagery would be incorrectly perceived as being part of the image. Plus, for pixel art, you had to ensure all of the source images were properly scaled-up and all the same dimensions to avoid them falling into different training buckets.

Thankfully, Celebrity is quite a long show, so over several nights, I cleaned the source files, carefully resized them, and meticulously detailed them. I set the new training running and went to bed. The next day I got to see the fruits of my labor.

This hard work, combined with a massively powerful base model, resulted in some incredible images. They truly captured what a retro game title screen should look like to me. All bold faux-3D lettering, vibrant colors, and hard outline pixel art. That, when down-sampled and palette quantized, retained that sharp, crisp look.

I felt I was onto something enough to build a basic web interface to it all. This was some simple Bootstrap styles and a bunch of Node JavaScript. I threw it on a cheap VPS, and now it’s available for testing and playing with at:

https://gorf.io/titlescreen/

I posted about it to BlueSky and the Phaser Discord, and it was fun to see what was generated. In the past couple of days, over 1000 title screens have been made! A few of my favorites are below:

Feel free to play with the service. I won’t keep it online for that long, so if you make something you like, please save it!

This work has been interesting, taught me a lot, and is a feature that will manifest in Phaser Launcher upon release. You’ll be able to enter your game name, ask it to create a title screen, and have it add it directly to your project for you.

Who knows what else we could train it to do in the future? 🙂

🧑‍💻 Zeke - Phaser Box2D

I started the week adding 3 more Box2D examples:

1. Static vs. dynamic vs. kinematic bodies

   

2. Multiple physics body shapes

   

3. Different types of linear movement

   

The remainder of the week was spent working on publishing the first draft of our Box2D documentation on Phaser’s Hashnode Documentation site. I’m happy to announce that it’s up although there is still room for tidying up and tweaking to make everything cohesive and readable.

Until next week, happy game dev-ing!

🧑‍💻 Francisco - Phaser Launcher

Hi everyone,

This week, I’ve been working on user authentication for our new tool. The idea is to implement something similar to what Arian does in Phaser Editor, with a functional OAuth flow tailored to our application.

To achieve this, I needed to spin up a temporary server directly from the app, which I implemented using Rust. This server handles the authentication flow, including receiving the callback from the OAuth provider. Once authentication is complete, the server shuts down automatically to avoid staying in a listening state.

Ensuring the server closed properly was the most time-consuming part. Adjusting timings, handling errors, and making sure no orphan processes were left behind required several iterations, but I got it working in the end. Now we have a fully functional authentication flow, although it’s currently running as a separate project.

Next steps

Full integration: The next step is to merge this functionality with the main tool. This includes building a component to continuously validate with the server whether the user is logged in. Refinements: While the flow is functional, I want to make sure it’s robust against potential network errors or unexpected configurations. It’s been an intense week, but the result is worth it. We now have a solid foundation for authentication and are one step closer to a fully functional tool.

🧑‍💻 Can - Discord Activity Launcher

After enduring intense power cuts in my country, I'm thrilled to announce that the first version of our Discord Activity Tool & tutorial is finally complete—hooray!🎉

What I've Accomplished This Week

• UI Restructuring & Polishing: Completely revamped the user interface for better usability and aesthetics.

• Fixed Typos: Cleaned up all those pesky text errors.

• Updated App Info & Mac Icons: Ensured all metadata and visuals are up-to-date and looks good.

• Disabled Window Resizing: Locked down the app's dimensions for a better, controlled experience.

• Improved Cloudflared Check: The app now skips the installation if Cloudflared is already installed and avoids redundancy.

• Better Background Design: Thank you, Richard!

Tauri in Production

I discovered something unexpected about Tauri: even if you hardcode CSS colors in your app, Tauri will adjust the app's colors based on your system's theme mode (e.g., light/dark mode). While this can be neat in some scenarios, it wasn't what we wanted. Thankfully, it's an easy fix with a simple Tauri config tweak.

First Impressions of Tauri

• Effortless Builds: Minimal hassle, excellent performance, and the lightweight build size is a dream for a web app.

• Rust Experience: Although I'm not well-versed in Rust, implementing bug fixes and plugins wasn't as challenging as I feared.

• Upgrading from v1 to v2: The upgrade process was straightforward, though the documentation still needs refinement. Some details are missing, and following v1 docs can sometimes mislead—but also guide!

Got feedback or ideas? Drop by our Discord's #discord-activities channel and share your thoughts or showcase your own projects!

May the pixels be ever in your favor! (Or, if you're feeling nostalgic: "May the force be with you!")

Arian - Phaser Editor

Hello friends

Last week I have dedicated almost entirely to a new feature of the editor: compressed textures.

Phaser has supported compressed textures for a while now, and now you can use it via Phaser Editor as well, you just have to define the textures in an asset pack.

The process is similar to other assets or images, you must first define them in an asset pack to then be able to use it in the scene editor.

Compressed textures have a peculiarity, and that is that the editor needs an image (PNG, JPG, etc...) as a reference, and you must also define its counterpart with the different compressed texture formats, since browsers can vary in the support of these formats. So, first you select the reference image, and import it as a "texture":

Then, in the asset pack editor, you can define versions of that image in the different compressed texture formats supported by Phaser:

The process for importing a compressed texture atlas is very similar. The editor needs an atlas of reference images, and then you define all the versions in the different formats.

This feature is now ready. We are working on various issues and features requested by the community. We should have a new release before the end of the year.

Cheers!

Tales from the Pixel Mines

9th December, 2024 by Ben Richards

I'm back in action. The last couple of weeks were a writeoff, thanks to a second bout of COVID-19. Very unpleasant; do not recommend. The main symptoms took me out for a couple of days, and left me barely able to code for another week.

This is why I mask up in public places. I don't want to infect anybody else, because I don't like being sick and I assume other people feel the same way.

So there's not much to report, sadly. I'm still working on Phaser 4 beta 3. The main objective is still to get Filters working as a component, much like FX in Phaser 3. This entails some rewrites of the transform logic, because filters previously had a separate RenderFilters object to hold all their transforms, but a component just has the single GameObject to work with. Overall, however, this approach is simpler and requires fewer moving parts. I'm confident that this is a better approach.

I reckon there will be plenty to share next week.

Welcome to Issue 208 and two new product releases, Studio Developer logs and of course a Cyber Monday special offer. Read on …

🔥 Cyber Monday - 30% Off!

Get 30% off our annual subscriptions for a limited time.

Use the code CYBER30 during checkout to get 30% off.

This code expires on December 6th, 2024.

🚀 Phaser Editor v4.7.1 Released

Settings panels, keyboard shortcuts, support for JetBrains IDEs, font files, and more!

We are pleased to announce the release of Phaser Editor 4.7.0. This version introduces the long-awaited built-in web font loader. This new feature allows you to load web fonts directly from the editor asset pack editor, making it easier to use custom fonts in your scenes. This new feature was possible thanks to the latest Phaser version (3.87), which introduced the new FontFile API.

In addition to the font loader, we built a brand-new UI system that allows you to configure most Phaser Editor settings.

Today (Monday 2nd) we also published the 4.7.1 point release, which has a small fix for adding Tilemaps into Layers.

Read more about Phaser Editor 4.7.0

🎮 Arena Survivors

Visit interesting places and destroy everything in this bullet hell game.

Arena Survivors, developed by 2kblater, builds upon the addictive auto-shooter mechanics popularized by Vampire Survivors while carving out its own unique identity. This rogue-like RPG drops players into dynamic arenas where survival depends on quick thinking and strategic character building.

Like its inspiration, Arena Survivors excels in creating that "just one more run" feeling. The game sets itself apart through its diverse enemy roster – from mythological beasts to surprisingly deadly farm animals. Boss encounters and special events keep players on their toes, requiring quick adaptation of tactics and loadouts. The procedurally generated levels ensure no two runs feel identical.

Play Arena Survivors

🌮 Creat Game CLI Update

This new version adds multiplayer, Discord Activities and physics templates.

Today we released version 1.2.7 of our Create Game CLI app. This release introduces a new 'Middleware' section that offers you the ability to download and install the following new templates:

Rune Multiplayer Tic-Tac-Toe Example Discord Activities (Single Player) Discord Activities (Multiplayer) Rapier Physics Connector To use the tool, simply issue the command:

npm create @phaserjs/game@latest

Read more about the CLI Tool Update

💾 Game File Hosting

Free, easy drag-and-drop game file hosting for all Phaser users!

We're super excited to announce that our Game File Hosting Service is now available for everyone. Register an account on the Phaser site, and you'll have immediate access to our new file hosting service.

Because of the way browser security works, it's often quite complex to simply put a file somewhere and get a URL that you can use in your games. Direct linking to files, such as those stored in Imgur or GitHub, is nearly always blocked via restrictive CORs policies. And if you want to test something quickly, using our Phaser Sandbox is perfect for that — but again, how do you access your files from within it?

Previously, you'd need to run your own server and manage your security settings manually to achieve this. Now, you can use our free drag-and-drop file hosting service!

Read More about Game File Hosting

Phaser Studio Developer Logs

Here is what the Phaser Studio team has been up to this week:

🧑‍💻 Rich - CTO & Founder

This week was strange. Obviously, with Thanksgiving, several of the team members were away for two days. Plus, Ben contracted Covid, which knocked him out for the entire week. As a result, sadly, there are no Tales from the Pixel Mines in this issue! So we were much lighter-staffed than usual for most of the week. Even so, we published a new CLI create game tool version and a lovely Quality of Life release for Phaser Editor.

Internally, the design and build for the Box2D pages are now entirely done! This is super exciting. :) The library is solid, the documentation is done, the examples are coming together, and we’ve got lots of tutorials, too. All in all, it’s a compelling bundle of a package, and, touch wood, it should be on sale this week.

Once Box2D is out, my focus will shift to Phaser v4. Now that Ben is well again, the pace will ramp up this week, and we’ll push towards a new beta release. We’ve also got the Game Publishing service to go live, hundreds of new examples to upload, and new Discord Activities tutorials! It’s going to be a busy final month of the year 🙂

🧑‍💻 Francisco - Phaser Launcher

¡Hola a todos!

Phaser Template Installer

This week, we updated our Phaser Template Installer with the release of version 1.2.7, which brings three new templates and some important adjustments. One of the existing templates, Rapier, has been moved to a new section called Middleware, where you’ll find templates related to tools and extensions for Phaser. Some of these templates are contributions from third parties that we’ve carefully reviewed to ensure their quality and usefulness.

Phaser Launcher

Regarding Phaser Launcher, I’ve been working on the component responsible for displaying the game. This component has a rather unique behavior: it needs to open with the DevTools window enabled right from the start and allow users to toggle it open or closed at will.

At first, this turned out to be quite challenging, especially on Windows and macOS. The main issue was the iframe used to load the game—it captured all events, making it impossible to open the DevTools window. This limitation caused a lot of frustration as I experimented with different approaches to find a solution that wouldn’t break other functionality.

After what felt like hundreds of tests, I finally found the right approach: taking complete control of the component by injecting code directly into the game’s index.html. This allowed me to capture all generated events, making it possible to open and close the DevTools window smoothly, even with the iframe in place.

The exciting part about this solution is that it opens the door to injecting additional scripts dynamically into the game. This gives us a lot of flexibility to introduce new tools or features in the future.

That’s all for now — stay tuned for more updates!

🧑‍💻 Zeke - Box2D

This week, I focused on completing the Tiny Wings demo and started working on our Box2D Javascript documentation. Pete has done an amazing job porting the entire C library to Javascript and the demo’s the team has made are just beautiful to watch.

Here’s a gif showing the final step in the Tiny Wing’s demo featuring endless terrain generation.

As for Box2D documentation, I worked on reviewing existing code examples to ensure it works as intended. This also involves creating fully working examples of each tutorial so you can see how all the code is put together to make it work.

Here’s an example of a one-way platform:

This documentation will continue for the near future so expect to see more examples posted.

Have a good week ahead!

🧑‍💻 Pete - Box2D

It's a wrap! ... nearly! For my last week on Phaser Box2D I helped convert the entire contents of the iForce2D website from talking about Box2D v2.X in C++ to relevance for Phaser Box2D v3 in JavaScript.

Together Zeke and I went through the material several times, and hopefully I didn't miss too many of the old-style references for Zeke to clean up before it all goes live. Looking back at what this Phaser team has achieved is incredibly rewarding: a complete, fast, JS conversion of the newest version of the leading 2D physics engine.

With a fully documented API, tons of examples, and an entire website worth of tutorials. We truly "stand on the shoulders of giants" because none of this would have been possible without the amazing work done by Erin in creating Box2D v3 and Chris in writing such a wonderful tutorial resource.

In this issue, we introduce a free file hosting service, showcase two great games, dive into Phaser Editor tutorials, and have a massive dev log from the team. Let’s go …

🔥 Black Friday - 30% Off!

Get 30% off our monthly or annual subscriptions for a limited time.

Use the code BF30 during checkout to get 30% off.

Click here to see the Pricing page.

This code expires on December 1st 2024.

The discount applies to first-time customers and is for the first payment only. For the largest discount, use it on an annual payment.

💾 Game File Hosting

Free, easy drag-and-drop game file hosting for all Phaser users!

We're super excited to announce that our Game File Hosting Service is now available for everyone. Register an account on the Phaser site, and you'll have immediate access to our new file hosting service.

Because of the way browser security works, it's often quite complex to simply put a file somewhere and get a URL that you can use in your games. Direct linking to files, such as those stored in Imgur or GitHub, is nearly always blocked via restrictive CORs policies. And if you want to test something quickly, using our Phaser Sandbox is perfect for that — but again, how do you access your files from within it?

Previously, you'd need to run your own server and manage your security settings manually to achieve this. Now, you can use our free drag-and-drop file hosting service!

Read More about Game File Hosting

🧩 Reddit Games and Puzzles Hackathon

Create a new word or puzzle game and win a share of $116,000 prize money.

The Reddit Games and Puzzles Challenge kicked off today and gives Phaser developers a great chance at winning a slice of the $116,000 prize money on offer. The challenge? To create a word or puzzle game using Reddit's Developer Platform.

They are looking for apps that "leverage interactive posts", making this an exciting opportunity for developers to showcase their creativity and skills.

Read more about the Reddit Hackathon

🎮 The Crazy Hyper-Dungeon Chronicles

A fresh take on roguelite crawlers where procedural dungeons meet witty chaos.

In an era saturated with dungeon crawlers, The Crazy Hyper-Dungeon Chronicles stands out by refusing to take itself too seriously. This upcoming pixel-art RPG, slated for 2025, brings a refreshing blend of classic dungeon-crawling mechanics and modern roguelite elements, all wrapped in a layer of eccentric humor.

With 50 planned levels, multiple heroes, and three combat styles, The Crazy Hyper-Dungeon Chronicles promises substantial content. But its true appeal lies in how it balances accessibility with depth – easy to pick up, yet offering enough complexity to keep veterans engaged.

Whether you're following in the footsteps of the legendary Lando Lore or simply trying to keep King Dandelion entertained enough to avoid war, this quirky dungeon crawler looks set to carve out its own unique niche in the genre.

Everyone at Phaser Studio wishes the developers all the best for their full release. In the meantime, download the entertaining demo version from Steam and be sure to add it to your wishlist!

Read more about the Steam demo

🧠 Phaser Editor Script Nodes Tutorial

Learn how to manage custom code and modular development in Phaser Editor.

Scott Westover has published a new YouTube tutorial that goes in dept into one of the most powerful features of Phaser Editor v4 - Script Nodes. This tool opens up a whole new way to manage custom code, making game development faster and more flexible.

Watch the Tutorial

🎮 Murder

Creep up behind the king and take him out quietly in this 100M+ played game.

One of the things about Phaser being open-source is that anyone can come along, freely take the library and release a game without ever telling us. We absolutely love it when they do tell us! Yet there is, of course, no obligation to do so. Which means that we'll often come across a game that may have been released years ago, that we have never played before. And that is the case here, with Murder!

Play Murder

Phaser Studio Developer Logs

Here is what the Phaser Studio team has been up to this week:

👨‍💻 Rich - CTO & Founder

As usual, my week was a mixed bag of delights! On the Box2D front, I configured JSDoc and have it generating all of the documentation we’ve created for the v3 functions. We had to write it all ourselves, and there are hundreds of functions! But now this is done, it’s easy to scan through in HTML form.

However, we also realized that you need tutorials as well as function documentation. So we’ve attacked this on two fronts. The first is to create our own, and the second is that we agreed with Chris Campbell of iForce2D to license and repurpose his excellent Box2D tutorials. His are all for v2, and all code is in C, so we have a bunch of work to update them - but once complete, this will be a solid bundle: A modern, compact library, a whole bunch of examples to learn from (including both Phaser and ‘pure’ examples), a large set of tutorials and finally generated documentation. It’s been a lot of work to get the product to this point, involving weeks of hard graft from the team - and ultimately, this is why it can’t be a free release. I’m well aware we’re going to get criticized for this. I’m also well aware of how much it cost us to produce.

In other news, Ilija has completed the Phaser Beam logo! There are light and dark versions, and I absolutely love it. It’s everything I wanted it to be and more. Here is an exclusive peek at it:

Totally awesome 🤩

👨‍💻 Pete - Box2D

The week has been busy on several different fronts...

Code Optimization

We've achieved package size reductions by identifying and removing unused SIMD-related functions. Additionally, we've improved performance by optimizing even more heavily-used functions that were creating temporary b2Vec2 objects – inline mathematics operations now reduce garbage collection overhead and provide minor performance gains.

While maintaining close alignment with the official Box2D implementation, we made a decision to improve user experience: mouse joints now automatically wake sleeping objects upon attachment. We're tracking recent official patches regarding sleep/wake states and will evaluate their integration soon.

Code Quality

An ESLint pass has helped us clean up both the library and examples. During this process, I addressed nearly all of my outstanding TODO items, leaving only one complex design question for further discussion.

We've resolved display issues on high DPI screens, benefiting Mac users who were experiencing scaling problems with the debug drawing in the examples. The core library doesn’t include any drawing functions at all, but it’s always helpful to see what is going on in the examples, so there is both a canvas debugger and a Phaser one.

New Examples and Features

This week's new demonstrations include:

• A dynamic jar simulation featuring capsule-shaped pills stirred by a rotating paddle

• A side-scrolling car driving demo with an extensive chain-based terrain

• Physics-driven explosion effects triggered by mouse input

We've also refined existing examples and extracted the Earcut Constrained Delauney Triangulation code into a standalone helper file, temporarily housed in the Examples folder pending a permanent location decision.

Documentation and Tutorials

Additional help is available following the creation of first-draft tutorials covering 13 example projects. Pending initial feedback, we might extend this effort to most remaining examples.

Performance Testing

Our new stress test example dynamically maintains 58fps (±1) by adding or removing physics objects as needed. This benchmark helps us understand performance across different hardware configurations:

• Powerful but aging Windows desktop: ~2,300 objects

• Mid-range systems: ~1,900 objects

• High-end hardware (iMac M3): 6,000+ objects

This test dumps thousands of objects into one giant heap, so isn’t representative of an actual game, as it’s dealing with literally thousands of contact resolutions per frame. If you were to island the objects, so groups of them could achieve going to sleep, you can expect dramatically larger numbers. Even so, ‘stress’ is the important part of this test here: Huge piles of objects that never start overlapping or ‘squishing’.

Ongoing Development

We're actively following Erin's improvements to the official Box2D v3, carefully evaluating and incorporating the most critical updates into our JavaScript implementation. We've secured an agreement with Chris from iForce2D to adapt his excellent Box2D v2 educational content for Phaser Box2D. This adaptation work has just begun and promises to provide comprehensive, practical guidance for our implementation.

👨‍💻 Francisco - Phaser Launcher

Hi everyone,

This week, I’ve been exploring how to add drag-and-drop functionality to our small editor.

Initially, I ran into several challenges. My first approach was to use Tauri’s events to handle file drops. However, this method didn’t emit any events to the client, which caused issues when trying to display what was happening on the front end of the application.

The solution turned out to be simpler than expected. In the end, I disabled Tauri’s drag-and-drop events and leveraged HTML5’s DataTransfer API instead. This allowed me to copy files to the user’s selected path seamlessly.

Step by step, our application is growing and gaining potential. I’m excited to see where this journey takes us!

👨‍💻 Arian - Phaser Editor

Hello friends.

This week we finally completed the UI for the editor settings. Basically, we finished the tab for redefining command key bindings. This is something that many of you have been asking for for a while, and it's finally done. Here's a picture:

During the week, a few of us on the team were tasked with implementing small examples for the new Box2D JavaScript library they're cooking up in Phaser. This was quite stressful for me, as I had very little knowledge of how these kinds of physics libraries work. The first day I spent most of my time reading the Box2D documentation and even learning some physics concepts. Physics was never my strong suit in school. But finally on the second day I was able to complete two examples. Here are some pictures.

Spiderman movement example:

Retro volleyball gameplay:

Next week we're adding support for web fonts to Phaser Editor, and we'll start working on publishing a release. See you!

👨‍💻 Zeke - Box2D

Another week, another Box2D game demo completed and another in progress. Inspiration can come from anywhere, and this week’s demo is inspired by BenJames171’s Escape Pod game. Although it’s no longer available to play, here’s a screenshot:

The aim of the game is to reach your homeworld in an escape pod fired from a base on the other side of various planetary systems. The escape pod works as a projectile so you only control angle and power when firing off; you need to find the right trajectory that makes use of the other planets gravity along the way.

Demo 1

And here are the steps taken to create a basic implementation of planetary gravity in Phaser’s Box2D plugin.

1. Create a Box2D circular sensor zone and have objects touching the area drawn towards the centre. The planet itself is a solid circle body so the objects are able to land on it.

   

2. Add an aiming mechanism that controls the angle and power

   

3. Add collision detection for the planets

   

4. Add ending animation for the final planet

   

Just place the start and end positions, adjust the size, positions and gravity strength of each planet and you can easily create multiple levels.

Demo 2

This next demo is inspired by Andreas Illiger’s Tiny Wings.

The goal of the game is to control a bird while using hills in order to gain speed and fly as far as possible.

Although the demo is incomplete at this point, the basic mechanics are already in place.

1. The first step is to draw procedurally generated hills using a cosine function and enable physics bodies on the curve.

   

2. Next to add input controls to enable the ability to dive.

   

3. Camera pan and zoom effects are added to follow the player.

   

The last step in this demo that will be worked on next week is to add continuous terrain generation to make this demo an endless journey for the player. Of course, more features could be added but this is a good enough starting point if you’re interested in creating games with a similar mechanic.

Although we’ve already got a tonne of ideas for 2D physics demos on our plate, feel free to get in touch with the dev team on Discord if you have ideas or suggestions you’d like to see implemented.

Have a good week ahead!

Tales from the Pixel Mines

November 23rd 2024, Ben Richards

This week: Beta feedback!

Last week, we released Phaser 4.0.0 beta 1. As a beta test, we're trying to find problems, both in the code and in the way it gets used. With the help of the community, we're succeeding at both!

Bug Fixes

Beta 2 was quickly released with several fixes.

• roundPixels quality enhancement

• Fixes to DynamicTexture and Mask

• Fixes to shader compilation on diverse systems

• Fix Extern

• Separate TileSprite dimension defaults

• BaseFilterShader now accesses loaded shader cache keys correctly.

RoundPixels Quality Enhancement

The roundPixels setting, available in the game config and on individual cameras, causes the vertices of sprites to snap to integer values. This helps keeping pixel art crisp by avoiding antialiasing.

For the best pixel art results, use the new smoothPixelArt config option for antialiased, unfiltered texels, or the existing pixelArt option for aliased texels.

We've taken a few approaches to this setting in the past. They all have trade-offs and weak points. Phaser v3 has used a couple of techniques, including vertex shader rounding and CPU-side vertex rounding. CPU-side rounding got good results, but because the CPU runs one linear computation thread, it's slower. It also touches lots of regions of code, and such complexity is usually fragile.

So vertex shader rounding is probably the best choice. Unfortunately, there are a few problems which aren't immediately obvious.

The first problem: there's no round function in the OpenGL ES Shading Language 1.0 specification. All we have is floor, which will change 1.999 to 1.0. This is easy to hack: floor(value + 0.5) is pretty much the same.

The second problem: no it's not. Under almost all circumstances, floor(value + 0.5) returns the expected value. However, what happens when value == 0.5? You might think that 0.5 + 0.5 == 1.0, i.e. value is rounded up. Unfortunately, that's not always true. The GPU handles floating-point numbers with limited precision. In fact, the precision can be quite low, especially if the shader is set to mediump precision. Given different values, e.g. 1.5 versus 1000.5, we might round either up or down, without any way to predict it.

This might seem like a very unlikely problem. How often is a sprite placed at precisely 0.5 pixels? And what's the worst that could happen?

Unfortunately, it's very common, and quite visible. A sprite's position is, by default, midway between its corners. If its dimensions are odd, e.g. 27x53, "midway" means its corners are 13.5x26.5 pixels away. Their fractional component is precisely 0.5 - the problem value. And because we can't predict which way this value rounds, the corners may be up to 1 pixel off.

This means that the sprite may be slightly distorted, skipping or duplicating some pixels. Which is bad!

After some experimentation, we settled on a simple fix: adding bias. By adding a tiny quantity to the value, we can tip it into the precision range where 0.5 always rounds up - the desirable outcome. The former hack becomes floor(value + 0.5001). This is just as fast, but it produces perfect results in this very common use case.

Could this cause distortions in other scenarios? Probably, but they're far less likely. Consider that it's very easy to get 0.5, just by loading a texture with an odd dimension and positioning it at an integer. But it's very unlikely to get within the precision range of 0.5001 unless you're moving objects incredibly slowly.

Further, the position is calculated in "window space": it's always rounded to the nearest pixel on the screen. This limits any distortion to a single pixel. Even if you zoom in 1,000,000,000 times, you'll never see more than a pixel of distortion.

The value actually being rounded is computed on the CPU. JavaScript uses 64-bit floating point numbers, which have a great deal of precision, but some calculations use 32-bit buffers so the precision is not that high. Just avoid values in the quadrillions and everything will be fine.

Fixes to DynamicTexture and Mask

When we merged development of the Beam renderer with the latest Phaser code base, we inadvertently invalidated the way we create DynamicTextures. The base Texture naming rules were tightened, invalidating our original strategy. The Mask filter uses a DynamicTexture, so it stopped working too.

The fix was to standardize DynamicTexture naming to use UUIDv4 strings.

Fixes to Shader Compilation on Diverse Systems

Here's the truth about shaders: they work differently on different devices. In fact, sometimes something that works fine on one machine is an error on another: not due to different capabilities, but simply due to the way the shader compiler works. This can even differ between browsers on the same machine.

You can see where this is going. Shaders that worked fine on my machine failed to work on other devices. This is why community testing is good.

The most egregious example was a case where one vertex attribute was not used by a shader. On most systems, the attribute was still exposed; it just did nothing. On one Linux system, however, the attribute was removed by the shader, because it did nothing. So our code crashed when it tried to access it.

I've made changes to prevent these issues. Things seem to be working better.

Fix Extern

The Extern game object allows you to use other renderers within the Phaser render process. For example, you can use ThreeJS to render 3D graphics.

Our Extern handling retained a reference to removed code, which prevented it from working. This is fixed in beta 2.

Incidentally, with a bit of knowledge of the render system, you can now integrate external renders with Phaser systems like filters. The Extern.render method receives the current DrawingContext, which you can use.

const view = this.add.extern();
view.render = (renderer, drawingContext, calcMatrix) => {
    // ... Set up extern renderer.

    // Force update the current framebuffer.
    renderer.glWrapper.updateBindingsFramebuffer({
        bindings: {
            framebuffer: drawingContext.framebuffer
        }
    }, true);

    // ... Other rendering.
};

This might break things in external renderers, but that's no longer my department!

Separate TileSprite Dimension Defaults

If TileSprite received width or height 0, it would default both dimensions to those of the sprite texture. We changed it so that only the dimension that is 0 will default; if the other is valid, it won't be changed.

BaseFilterShader Shader Cache Keys

Fixed an internal bug with cache access.

Upcoming Changes

The main change is the RenderFilters object. After much discussion, we've decided this is going to become a component on GameObjects instead. It will retain all existing functionality; it's just where it sits in a game that will change.

RenderFilters is a wrapper around a GameObject. This made sense when thinking about rendering processes. The child GameObject is not rendered to the game; it's passed through filters, and those are what eventually renders out.

Unfortunately, this means that the wrapper has to duplicate a lot of information from the child. And after discussing use cases with expert user rex, we concluded that the duplication was too complex. If the child wants to manage its own properties, as is often the case, it would have to check if it was inside a wrapper, and do more complex work that isn't its own fault.

Phaser Beam works on the principle of "context agnostic rendering": objects should render the same in different contexts. This makes it flexible and fixes many bugs and incompatibilities from previous versions. So we don't want to bring in more context awareness.

The best solution is to turn RenderFilters into a component on a GameObject. This means that the GameObject remains in the same context, and doesn't need to care about filters at all. There's no data duplication. It's much neater.

However, the Filters component is still a wrapper! It just wraps the render method of the object, rather than the entire object. This preserves the intent of the render process. It does make invoking the render method a bit more complex, but I'm working on keeping that invisible right now. In fact, this work should make it possible to fully control the render process of any object from the outside, which is cool.

Big thanks to rex for talking through the use cases with me.

Next Week

I'll be finishing up the new Filters component, and we should see a beta 3 release very soon. Then it's more testing and fixing.

Thanks for checking this out. We couldn't get Phaser this solid without your help.

Another week, another packed newsletter. Plus, Phaser is now on Bluesky. If you’re also on there, please give us a follow!

🌟 Phaser v3.87 and v4.0.0 Beta 1 Released

Set renderer to warpspeed. Two brand-new releases of Phaser just landed.

Phaser Studio is very happy to announce the immediate availability of both Phaser v3.87 and v4.0.0 Beta 1. The v3.87 release closes off a couple of high-ticket issues and drops in a compelling new feature: the ability to load web fonts via the Phaser Loader. No more messing around with CSS hacks or cumbersome third-party web font loaders.

Download v3.87 here (available on both GitHub and npm)

However, we didn't stop there! Today also saw the release of Phaser v4.0.0 Beta 1. We have been working on our brand-new WebGL renderer all year, with 5 Technical Preview releases throughout that time frame. Eager readers will have been following the development progress, week by week, in our Phaser World newsletter. Finally, after months of hard work, we have merged the renderer into the core of Phaser and published the first beta release.

You can download v4.0.0 Beta 1 from GitHub and npm under the beta tag.

https://github.com/phaserjs/phaser/releases/tag/v4.0.0-beta.1

It's also already available in our Phaser Sandbox. Here's an example of how to use the new Bloom parallel filter!

We have also created a phaser4 channel in our Discord. So please join in there to get the latest details and answers to questions.

We aim to release new betas at a high frequency. There’s no limit to how high the number could go. We’ll keep pumping them out until it feels stable and ready to hit main.

Read more about the releases here

🎮 Curvelicious

A Fast-Paced Multiplayer Twist on Classic Snake Games.

If you're craving high-octane local multiplayer action with a touch of nostalgia, Curvelicious is here to deliver. Taking cues from classic snake and curve games, this new title from developer Filip Strelec reinvents the formula, infusing it with intense multiplayer excitement and strategic gameplay that’s perfect for game nights with friends.

Read about Curvelicious on Steam

Creating Pacman with Phaser 3

This six-part YouTube series covers the recreation of the dot-munching classic.

Simple Coding Tutorials on YouTube has been publishing a series of tutorials over the past few months, all about re-creating the classic game Pacman in Phaser 3. They are currently up to part 6, and you can follow-along at each stage of the development.

Read more about this tutorial

😊 MobileFuse hiring Phaser Developer

Experience with Phaser and HTML/CSS? Join a powerful creative team.

MobileFuse (www.mobilefuse.com) is a leading mobile advertising network. We are currently looking to hire an outstanding Freelance Creative Developer to support our growth. We are looking for candidates who have a desire to learn new skills and improve existing ones. The perfect candidates will pay attention to details and take great pride in their work.

You will be joining a team of designers who are the leaders in our industry. Take advantage of this opportunity to use your talents and creativity to design and develop captivating ads for mobile devices. Our world revolves around cutting-edge technology and finding the best talent possible. If you believe you match these qualifications, then we can’t wait to speak with you!

Read the full job posting

Phaser Studio Developer Logs

🧑‍💻 Rich - CTO & Founder

This week I’ve been working across all projects, as per usual. Although I did find time to create the Phaser v3.87 release and put a couple of nice enhancements in there. But the most exciting release was v4.0.0 Beta 1. You can read all about that elsewhere this issue, but we’re going to be really pushing the releases out at a fast pace.

We’re also very nearly finished with Box2D. This week, the whole team will sit down and play with it in depth, after which we will open it up to a handful of key community members. Beyond that, it’s release time! Our aim was always by the end of November, and I don’t think we’ll be too far off that.

I’m mostly just going to let the guys talk about what they’ve been up to this week. You’ll find my name in nearly all of their sections, because that is what being a CTO is really about: driving everything forward.

🧑‍💻 Arian - Phaser Editor

Hi friends

This week we started a new iteration on the editor. We will be working on a UI for the editor settings (including keyboard shortcuts and compressed texture support). This week we have made progress on the settings UI. This is a task that seems simple, but the editor has different configuration files with different scopes and this requires a bit of work to formalize a UI.

So far, there are several ways to configure the editor:

1) Using the flags of the server executable, as in PhaserEditor -opt1 -opt2.

2) Writing a flags.txt file, which can be present in the editor installation folder, the user configuration folder (~/.phasereditor2d), or the project folder.

3) Writing to the phasereditor2d.config.json file that is located in the project folder.

4) Some of the settings, like Phaser renderer, is written in the localStorage of the web browser.

5) And finally, writing to the settings.json file that is located in the user configuration folder (which is currently used to configure the editor proxy).

That is, there is a whole amalgam of configuration files in different places.

The problem is that we need two types of configurations: global, and project-wide. Global settings affect each project, such as the proxy, browser, code editor, and project-wide settings only affect a particular project, such as the type of Phaser renderer to use in the editor.

So, for this new UI, all global settings will be written to the ~/phasereditor2d/settings.json file, and all project-wide settings will be written to the phasereditor2d.config.json file that appears in the root of each project. However, the other configuration files will still be supported, but will have a lower priority when determining the value of a configuration parameter.

All configuration writing is done on the editor server, so it takes a bit of work to set up new communication APIs between the client and the server.

Another complexity regarding configurations is that the editor uses an architecture based on plugins and extensions, which can be installed even by the same user. Therefore, the configuration UI must be extensible.

Almost all of this is ready. Here are some screenshots.

UI to configure external apps (the browser and the code editor):

UI to configure Phaser scenes:

By the way, in the UI to configure external applications, we included some shortcuts to auto-configure options that are quite common for Phaser users, such as Google Chrome, Firefox, VS Code, JetBrains Webstorm, and JetBrains Rider:

Next week we will complete this UI and start implementing the UI to change the key combinations of the commands available in the editor.

Keep in touch!

🧑‍💻 Francisco - Phaser Launcher

¡Hola a todos!

This week, I worked on integrating an internal server for the editor, aiming to serve projects in real time. Initially, I started with tiny-http, a lightweight server for Rust. While I managed to implement it and get it running (starting and stopping worked just fine), I realized that adding MIME support required manual setup, which was a bit tedious.

That's when Richard recommended trying Actix and shared a link with me. After giving it a shot, everything fell into place. With Actix, the server became much easier to manage and could automatically switch ports if the one we wanted was already in use. I also added an autoreload feature, which refreshes the served content whenever files are updated, making it incredibly practical for real-time development.

While the functionality to open the browser directly from the editor with a right-click is implemented, what really excites me is how robust the server is now and how it enables a much more efficient workflow. I'm very satisfied with the outcome.

🧑‍💻 Pete - Box2D

We're moving towards release with a number of QoL improvements across the board.

Rich managed to get eslint working, so the beginning of the week was cleaning up the many (MANY) warnings and errors that were raised. Most of them were basic tidying-up, but a couple of potentially nasty bugs were averted, too.

The type definitions have been added for every JS class (99% of them simply replace C 'structs' but there are one or two new ones which were needed for the translated library to work).

Several assertions have been enhanced to generate very specific messages. These will show up when a few particularly 'likely' mistakes are made. They're a form of last resort assistance when we've been unable to design things differently to avoid the mistakes in the first place!

All of the original uses of b2Assert (in C it's a macro which vanishes in release builds) have been replaced with console.assert and we have a 'release build' equivalent when you use npm run build. This is separate from the b2Validation flag which enables all of the asserts and adds in some heavy-duty internal box2d verification.

I found the bug that made the top-down car driving example drive poorly, it now drives excellently! It's very interesting to see the difference between a car simulation with four wheels exerting forces compared with the usual single box with faked physics rules. It feels so much more dynamic and on edge...

Some new examples have been added or completed:

Top Drive has been finished

Spatial Grid Partitioning shows a large number of bodies with gravitational attraction, two seconds after a 'big bang' I enable gravity and watch everything fly together in larger and larger clumps. It uses a grid to divide the space into smaller squares, and uses those to optimise the gravitational calculations. The motivation for this one is to show the speed that we gain by using b2World_GetBodyEvents instead of calling b2Body_GetTransform on every body in the system.

Constrained Delauney Triangulation shows some convex or otherwise complex shapes being triangularised so that box2d can handle them (the usual limit is 8 points per polygon). I used the letters 'P','H','A','S','E','R' as the shapes to test with.

Trajectory Bombs is a small game example. Aim your catapult to launch a bomb at a building to knock it down. You might recognise the inspiration for this one 🙂

🧑‍💻 Zeke - Box2D

Thanks to Richard’s work on Phaser’s Box2D integration, we’re now able to create examples with proper graphic assets. I spent the week testing the integration and came up with this box stacking game example:

A game with simple mechanics, just tap / click on the screen to drop a moving box. The goal is to stack as many boxes as possible to achieve a high score.

With Phaser finally back in the centre, it only took a few lines of code to add random box graphics. Also, with integration working, Box2D physics bodies were easily resized to match the sprite.

Besides the Box2D elements, another camera was added to the scene with zooming features that enables you to see the entire box stack.

Do check out the example. So far my highest score is 22. Pretty sure you’ll be able to top that easily.

Until next week, enjoy the demo!

🧑‍💻 Can - Discord Activity Launcher

Another week, another adventure in Phaser Studio land. Let's dive into what's been happening behind the scenes (pun intended!).

After some brainstorming about our new design flow, it became clear: we needed something easier to manage the sections. That's when I thought, "Hey, we Phaser devs love our Scene Managers, don't we?" So why not create one for Tauri? I know web devs throwing tomatoes at me, why not use router or any other modern frontend framework to go with? Well, I like to experiment things, and find a decent workarounds of it. It fits for the app's needs, so why not! Also, I do love vanilla solutions.

You can see the example code to grasp an idea how it works!

Besides that, I've added traditional app's menu on the top, more space for tutorials, about and any other section is not necessary for the page.

Next up, I'm fine-tuning transitions between "scenes" in the tool and polishing up some UI elements. Its mainly working with div elements. Managing the scenes through them.

Until next week, keep coding, keep creating everyone.

Tales from the Pixel Mines

November 15th 2024, Ben Richards

This week: Phaser 4 beta 1!

Rich and I have done a lot of work finalizing the build, and it's ready for beta. We expect to find plenty of issues and release plenty of beta builds. But this is a huge milestone, and I can hardly believe we got here.

Let's recap. Phaser 4 introduces the Beam renderer. I've spent most of the last year working on Beam. Originally, I was trying to fix an issue where masks didn't work with certain FX. Things accelerated from there, and I rewrote the entire renderer. We don't even have masks or FX any more! (They're both Filters now, and more powerful than ever.)

DrawingContext

Beam uses a system of DrawingContext objects to ensure that different parts of the rendering system can't interfere with each other. A DrawingContext is basically a collection of WebGL settings. We apply these settings just before the actual draw command, ensuring that settings are always exactly what we need. We don't leave anything to chance.

This approach gives us the confidence to treat more game objects in exactly the same way. Phaser 3 had several restrictions, such as "no blend modes on Shader game objects" or "no FX on objects drawn to a DynamicTexture". Phaser 4 lifts most of these restrictions - objects don't care where they are in the render process, they just draw using the same rules every time.

Exception: lighting within framebuffers. Because normal map lighting is computed in "window space", relative to the pixels of the framebuffer where drawing is occurring, framebuffers which don't precisely match the game canvas and camera angle may compute lighting improperly. For now, framebuffer lighting is technically unsupported even if it works, although I'd like to develop a solution one day.

Performance Enhancements

By standardizing the render process, Beam has also become more efficient. We've switched from using 6 vertices per quad, to 4 vertices. Why did we use 6 in the first place? Well, the whole point of a 2D game engine is to render textures: rectangular images we call "quads". But WebGL doesn't know what quads are; it has to work with triangles. Two triangles together make a quad, but they also have 6 corners ("vertices"). Beam uses a couple of tricks (indexed rendering) to re-use 2 vertices, so while there are technically still 6, we only have to deal with 4. If a game is bottlenecked by vertices, this optimization can give you 50% more performance.

Note that performance depends on lots of things working together. You're rarely going to see full 50% improvements, because other bottlenecks come into play. The three bottlenecks to consider are:

1. GPU sync

2. Vertex load

3. Fill rate

GPU sync is the primary bottleneck. We upload vertex data to the GPU, which takes time. Lots of time. About a hundred times longer than it takes the GPU to actually draw that data! That's why going from 6 to 4 vertices is a huge boost.

Vertex load is the computation of vertices on the GPU. This is rarely an issue. Any modern GPU can push so many vertices that you just don't need them all. You don't have enough pixels on screen to resolve all of them at once.

Fill rate is the computation of each pixel, also on the GPU. This is also rarely an issue, but complex shaders or intense overdraw can eventually drag the frame rate down. Overdraw is what it sounds like: you draw things "over" each other, wasting the effort spent on the lower layers. Try to avoid too much layering if at all possible.

Filters

The existing Mask and FX systems were combined into Filters. I've written a lot about these recently, so in summary: Filters are post-processing effects. You can apply them to a camera, or via a RenderFilters wrapper to an individual game object (such as a Container or Layer, if you need to combine several objects).

I've fallen in love with Filters. How else can you get cool effects like this?

Tidy-Up

This week, we've been working on finalizing the build. Rich and I have both deleted old code that was no longer necessary. In my case, I cleared out 18,000 lines of code. I was keeping it around for reference, but now that Beam is ready for beta, we don't need it any more.

And we ran TypeScript over the code. While Phaser isn't a TypeScript project yet (watch the skies), we do have tools for generating type definitions (phaser.d.ts).

This is a good thing, because apparently I'd made quite a mess during development. The code worked, but the documentation attached to it was sometimes a tiny bit... bad. Copy-paste errors left the wrong names on properties. Iterative design left old names in forgotten corners of the code. Thankfully, the project picked them all up, and I spent a couple of days tightening things up. I changed a few call signatures on internal systems, defined a few complex types for config parameters, and eventually it all worked.

What is TypeScript? It's a compiled superset of JavaScript. You write files with type annotation, and the compiler turns them into ordinary JS. Or it tells you that you messed up and you need to fix something - which is the kind of thing a good coder loves to hear.

TypeScript is a boon to any large JavaScript project. Its ability to identify mistakes and loopholes in complex code saves a lot of time. I'd encourage anyone starting a new project to use TypeScript from the start. These days, it's more supported than ever: VSCode has plenty of integration, Deno runs TS files without even asking you to compile anything, and I'm sure there are plenty more cases.

Anyway, I'm pretty happy that this tidy-up went so fast. That's what let us get the beta out the door so quickly.

Next Week

The future is uncertain, but I see two things awaiting me: testing, and bug fixes. They're really the same thing. It's not a challenging divination.

We've got a huge pile of examples, covering hundreds of applications of Phaser. If I can get them all working, that gives us enormous confidence in the beta. There will definitely be examples which don't work due to changes in the render system; fixing these helps me build a sense for the practicalities of migration from v3 to v4.

Once this is all done, we'll be able to massively improve our release cadence. The foundation of Beam has been a long time coming, but it's a solid foundation from which we can do amazing things.

Share your content with 18,000+ readers

Created a game, tutorial, code snippet, video, or anything you feel Phaser World readers would like? Then please send it to us!

Until the next issue, happy coding!

Welcome to another packed issue of Phaser World. There’s a new release of Phaser Editor available, lots of progress being made on Box2D and the Phaser Beam renderer enters the final stages before integration. Busy, busy, busy! Enjoy …

🌟 Phaser Editor v4.6.0 Released

This brand-new version includes a powerful built-in Tilemap Editor.

Available for immediate download is Phaser Editor v4.6.0. This introduces a long-awaited and powerful feature: A built-in Tilemap Editor. The new Tilemap tools are directly integrated into the Scene Editor, allowing you to combine Tilemap Layers together with Game Object layers simply and effectively.

Watch a video and read more here

🎮 President 47

Regardless of who you vote(d) for, you can't beat a good bullet-hell action game!

President 47 from 2kblater Games is a wry take on recent Whitehouse events. But most of all, it's an action-packed bullet-hell in the Vampire Survivors school of blasting and is available on Steam.

Watch the game trailer (if you can stomach any more politics right now)

😰 101 Games Challenge

The challenge continues with game two, Bolaz, available to play and download.

Emanuele Feronato has set himself an ambitious task: To create 101 games as a solo developer. There are some rules around the games. Such as: all games must be actual playable games, not just prototypes. AI is not allowed to be used to create short-cuts and, most importantly for Phaser developers: the source code and project files for each game must be made available.

Check out Game 2: Bolaz

😊 MobileFuse hiring Phaser Developer

Experience with Phaser and HTML/CSS? Join a powerful creative team.

MobileFuse (www.mobilefuse.com) is a leading mobile advertising network. We are currently looking to hire an outstanding Freelance Creative Developer to support our growth. We are looking for candidates who have a desire to learn new skills and improve existing ones. The perfect candidates will pay attention to details and take great pride in their work.

You will be joining a team of designers who are the leaders in our industry. Take advantage of this opportunity to use your talents and creativity to design and develop captivating ads for mobile devices. Our world revolves around cutting-edge technology and finding the best talent possible. If you believe you match these qualifications, then we can’t wait to speak with you!

Read the full job posting

Phaser Studio Developer Logs

🧑‍💻 Rich - CTO & Founder

Hi everyone. Last week was quite intense, to say the least! From a company point of view, one of the most exciting things that happened was that we hired our permanent CEO. This also means that our interim CEO, Brian, departed for pastures new (and non-techy) - he has been invaluable to me over the past 6 months, and I’ve loved working with him. Yet, in order to move forward, we knew we needed a permanent CEO. After lots of interviews and talks, this process is now complete, and I look forward to him introducing himself next week.

On the coding front, I worked on the Box2D project. While Pete and Zeke kicked the tires from all angles to make sure nothing fell off, my task was to code a Phaser interface to the API. Unlike with Arcade or Matter, this interface is a much more ‘light touch’ approach. It wraps common things you’ll need to do, such as create a physics body from a Sprite, or pair a body with a Sprite and have them remain in sync as the physics world steps. These are available as functions you import:

const block = this.add.sprite(640, 90, 'block');

const world = CreateWorld({ worldDef: b2DefaultWorldDef() });

const worldId = world.worldId;

const box = SpriteToBox(worldId, block, {
    restitution: 0.7,
    friction: 0.1
});

AddSpriteToWorld(worldId, block, box);

Above, we create a basic Phaser Sprite, a Box2D world, and a body from this Sprite. The two are linked, so the sprite renders as the body updates. Repeat that for hundreds of bodies, and voila:

However, it’s all open and optional. If you don’t want to use the wrapper, you don’t need to. You can just look at the code for it and implement your own approach. Perhaps you may want to create your own extended Sprite class that has a Box2D body as part of it? It’s entirely up to you. We’re not going to force you down a ‘plugin only’ route.

Another task I completed was porting the debug renderer to Phaser Graphics, so you can now render all the examples via a single Graphics instance, such as these tic-tac-like capsules:

You’d rarely want to use this ‘in game’, but for debugging it’s invaluable.

With the documentation in place and the examples pool growing by the week, we’re very close to release now. The aim was always by the end of November, and currently, it feels like we can achieve that.

🧑‍💻 Pete - Box2D

Now that the implementation has (nearly) stabilised, we've rolled out a Phaser Box2D API. Following our earlier approach, we used the C original as our guide, and I'm pleased to say that the full original API is available. We've kept all the original function names and stuck as close as possible to the original parameters. For the few features that don't quite fit our JS version, we've added wrapper functions that give friendly console warnings.

The great thing about keeping so close to the original is that you can use the official Box2D documentation to learn about the engine and its physics simulation.

On the documentation front, we've added JSDoc comment headers to all 358 functions, complete with a quick summary, detailed description, and annotated parameters and returns. I'll be documenting the types today, and then we'll do several review passes to ensure everything's spot-on.

In the examples section, we've added a tiny Platform Character demo featuring a single (fixed rotation) capsule that responds to keyboard inputs for movement and jumping.

Building on that, we've created "Run and Gun" – a basic scrolling platformer where you can shoot at the mouse position. Right now, it uses a static box for each tile, which gives us that familiar 'tile corner hop' when crossing boundaries. I'd like to work on a helper class for creating edge chains or possibly a grouping algorithm to smooth this out by combining adjacent platforms. Since the mouse aiming was a bit tricky to get right, I've wrapped up some handy coordinate conversions as ConvertWorldToScreen and ConvertScreenToWorld.

We've also added an interesting new example called Joint Smasher. It demonstrates breakable joints with 400 boxes arranged in a square grid using Weld Joints, which get repeatedly dropped onto a heavy vertical pole. The joints get progressively weaker with each drop, leading to some pretty cool fragmentation effects, though it is quite bouncy. For a more rigid version, we'd want to group all shapes into a single body.

To make life easier, I've added a CreateChain helper function that lets you quickly create a series of linked objects in a line – perfect for chains, ropes, or bridges. What used to be a bit fiddly is now nicely straightforward.

And, of course, the week included our usual round of bug fixes, code polishing, and general preparation work to get everything launch-ready!

🧑‍💻 Arian - Phaser Editor

Hello friends

What a week! We have finally released Phaser Editor v4.6.0, a version that brings a built-in tilemap editor. We have been talking about it for the last four weeks. In the last few days we finished writing the documentation and we have made a new project template with an example of the new tilemap editor. I recommend you to take a look at it, it appears right in the examples section in the project page of the editor:

Now comes one of the most exciting parts, what will be our next project?

🧑‍💻 Zeke - Box 2D

Worked on two Box2D examples and one game demos this week. After creating the asteroids demo last week, I thought it would be good to break down the full game into smaller, easier to understand components. Here are the demos:

Ship movement

Creating ship movement with Box2D would be the first step in creating a similar top down shooter.

Collision filtering

Filtering collisions is necessary to ensure the right physics bodies are allowed to collide and respond. For example, you wouldn’t want to be able to shoot and hit your ship with your own bullets. Or maybe you do? In the asteroids example last week, asteroids can only collide with bullets and the player ship, while the ship could not collide with the bullets fired.

Suika Watermelon game demo

Do a quick Google search for "Suika" and you’ll be able to play the original full game on the web. In the game demo, you’ll see how to create a basic playable version of the game with Box2D.

🧑‍💻 Francisco - Phaser Launcher

¡Hola a todos!

This week, I've been focused on enhancing the Phaser Launcher, particularly in the landing section, which serves as the user's entry point to the app. Additionally, I worked on the functionality for importing and creating new projects.

While handling these tasks, I realized that a complete workflow was starting to come together, closing an exciting loop in the development of this tool. So, I decided to take the next step by setting up a simple server and launching a single project through it. The tool is shaping up really well, and we are excited about its potential!

🧑‍💻 Can - Discord Activities Tool

This week, I continued refining the Discord Activity tool, focusing heavily on enhancing user experience. One major task that consumed much of my time was dealing with Apple’s code signing and notarization process. Thankfully, working with Tauri made it significantly smoother compared to other development tools. Tauri’s streamlined workflow provided a much-needed boost in navigating Apple’s often complex requirements.

After thorough testing and analysis with Rich, we decided that the current UI needed a change for improved user experience. This led to exploring and implementing a new interface design that better meets user expectations.

On top of these significant updates, I added a few small but impactful features, such as the ability to open the project folder automatically after successful creation. These enhancements aim to make the tool more intuitive and user-friendly.

That’s all for this week’s progress. Keep your pixels sharp, everyone!

Tales from the Pixel Mines

November 8th 2024, Ben Richards

This week, I've hit a big milestone: full implementation. That means I've implemented everything on our roadmap for the new Beam renderer. It doesn't mean it's finished, as there's a lot to test and tidy up. We'll probably find things we've overlooked, or awkward features that need a little streamlining. But it's another big step forward!

The last pieces of the puzzle involved the last work on Filters, and a new implementation of the Shader game object. It also involves changes to the GLSL file loader.

Full Implementation

Beam is a complete rewrite of Phaser's WebGL render system. This makes it more robust and efficient, but it also means that everything that renders has to be rewritten. That in turn gives us opportunities to rethink everything. And that all took a while.

We took care to ensure that things work the same wherever possible. We view the Phaser API as an asset, and stability is important. The Technical Preview program helped users test compatibility, and we're pleased that very sophisticated games can still work with zero changes.

However, anything that touches the render system will need updates. The Filter, and Shader systems in particular are quite different. Filters take the place of FX and Masks. DynamicTexture and RenderTexture objects have simplified their command sets, and require you to call render() before they draw anything.

Further, we've chosen to omit some items from Beam. Several filters have been removed, as we believe they are easy to implement as a flexible combination of other filters. The Mesh game object and its subclass Plane have been removed, as we intend to rethink our approach to 3D rendering. BitmapMask is removed, and GeometryMask no longer has any function in WebGL, but does still work in the Canvas renderer. FX and Masks are gone from game objects, and are now surfaced in the Filter system, available through cameras or the RenderFilters game object container.

The Pipeline concept has been retired. Beam uses a collection of types including DrawingContext to track drawing requirements, ProgramManager to provide shader programs, and RenderNode as a superclass for various discrete rendering tasks.

This should all give you a picture of where you should expect changes, and where you should expect things to just work as normal.

Filters

Bloom Filter and ParallelFilters

Last week, I talked about the Bloom filter, and what choices we faced when creating it.

Well, this week I decided that you should make the choices. So I removed the Bloom filter. It's replaced by a special filter called ParallelFilters. This surfaces the branching logic I discussed last week, splitting the render path into two lists of filters, then blending them together again at the end.

Here's how I made the above full-screen bloom effect:

const parallelFilters = this.cameras.main.filters.internal.addParallelFilters();
parallelFilters.top.addThreshold(0.5, 1);
parallelFilters.top.addBlur();
parallelFilters.blend.blendMode = Phaser.BlendModes.ADD;

That's it! As you can see, it's a really simple effect, but you can tune it yourself. Tweak the threshold to control highlights, lower or raise the blend amount, use a different blend mode, control the blur using the same parameters as the Blur filter, or even add other filters to further take control of the effect.

Blend Filters to Blend Filter

I made an internal change to the Blend filter. My first pass used a dedicated shader for each blend mode. But I quickly realized that this was just inflating package size with a lot of boilerplate.

So I switched to a single shader. This has all the blend modes defined as separate functions. How do we tell which one to use? Simple: we use the shader additions system. When we run the shader, we update its additions to include '#define BLEND ' + blendModeName. The system is smart enough to know if this changes, and compiles a new shader program only when necessary.

Shader additions are super useful, once you get familiar with their use. You don't have to write an entire shader for every new function - you just add code into an existing framework.

GLSL File Loading

In Phaser 3, GLSL code is loaded as a single program, with vertex and fragment shader code. But because our handling of GLSL shader code is so much more flexible in Beam, we needed to rethink our file loading strategy.

I've changed the GLSL loader to a simpler text system. It no longer treats files as vertex or fragment shaders. And it no longer parses "bundle" files consisting of several shaders. Instead, it loads a single file, which can be a complete vertex or fragment shader, or a snippet of code for use in a shader addition.

This makes it easier to develop GLSL code for flexible use. Bundle files weren't in any recognized syntax, so you wouldn't get warnings about mistakes in your code. I've been careful to make systems which use valid GLSL for Beam, so your editor doesn't have to cope with any special syntax. (The #pragma phaserTemplate() syntax is valid GLSL, even if it doesn't do anything.)

Shader Game Object

What's a Shader? It's a slightly confusing name, but here's what it does: it applies a shader program to a quad. That's all.

Well, we have to define a few more rules before we can make everything simple. Here's what we settled on.

• A Shader has default vertex and fragment shaders. You can override or apply additions to either. We expect that you'll only need fragment code.

• A Shader game object is a quad. Its transforms behave just like a Sprite, and it uses the same code behind the scenes.

• You can use a Shader anywhere you'd use a Sprite. You can apply filters to it, or set blend modes (previously impossible). The only thing you can't do is set alpha or tint, because those are actually shader inputs and your shader needs to control them itself.

• Shader's vertex shader receives two attributes: position and texture coordinates. Texture coordinates are made available in the fragment shader as outTexCoord. We expect this to be the primary driver of generative shader textures.

• Texture coordinates default to describing a rectangle from [0, 0] to [1, 1], but each vertex can be set manually.

These rules mean that you can use a Shader just like a texture. The freedom to change texture coordinates means you can use frames from a texture atlas, or scroll around a generative texture space.

The API of Shader has changed, but remains as compatible as possible.

• scene.add.shader(key, x, y, width, height, textures, textureData) (Phaser 3)

• scene.add.shader(config, x, y, width, height, textures) (Phaser Beam)

I've removed TextureData, as it only changed some texture settings you can edit yourself.

The main change is going from key to config. The key string fetched a GLSLFile from the Shader Cache, which as you'll recall, was a fully compiled shader. The config object lets you define which parts to combine into your own shader. You can reuse additions and entire shaders in different configs.

But if you don't need that power, I've left a backwards compatible option. If config is a string, instead of a configuration object, it assumes it's the key for a fragment shader, and creates a config automatically. This is usually what you want: just load your own fragment shader and use that.

We encourage you to switch to the config object when Beam is released, as this provides a convenient place to define shader uniform handling. This is necessary for any form of animation or interaction in the shader.

Phaser 3 handled several uniforms automatically. These correspond to uniforms once used by Shadertoy. However, Shadertoy has changed its interface, so these are no longer valid, and I've removed them in Beam. This also means Shader is no longer calculating mouse input for all your shaders that don't use it. We will create examples to demonstrate how to achieve common tasks, such as using time to animate shaders, or use a pointer in a shader. It's usually just a boilerplate line or two in your uniform handling.

But enough technical stuff. How about some examples?

Random Noise

Random noise has many uses, so here are a few different kinds. These varieties use a single Shader config, modified with different additions to create different shader effects.

Gradient Noise

Random noise is cool, but it has no structure or continuity, so it's not useful for many applications. Enter Perlin noise, a way to use random noise to construct smoother textures. There are several improvements on this technique, such as Gradient and Simplex noise. This example has a Shader rendering such structured noise, using renderToTexture to make it available to other objects, and plugging that texture into a Displacement filter on a background sprite. You could actually combine the Sprite, Shader, and Filter together into a single shader to be more efficient, but this is a quick way to experiment with effects.

Clouds and Holograms

This is a quick hologram effect, and a not-so-quick cloud effect. It uses the same gradient noise as the last example, but I adjust the perspective, take multiple samples, and combine them to make something that looks volumetric. (It's not really, but it looks pretty close, no?)

Oh, the Phaser logo here is taken straight from a texture atlas. That was previously impossible. But with texture coordinate control, we have greater powers.

Next Week

Well, looks like it's time to test and trim! We don't have any more additions planned for the initial Beam release. That means I need to go back and pull out all the old systems that were left in Phaser while I developed Beam (the lessons of the past are always valuable).

We also need to update all the Phaser examples, and make sure they still work, or that the fixes are well-documented. That's going to take a while.

But soon we'll be done, and Beam will be ready for alpha. When? I can't say! But as soon as possible.

Until next week, be excellent to one another.

Share your content with 18,000+ readers

Created a game, tutorial, code snippet, video, or anything you feel Phaser World readers would like? Then please send it to us!

Until the next issue, happy coding!

Welcome to the first issue of November 2024. It has been a release-packed year and shows no signs of slowing down. This issue features a new update to the classic Phaser Debug Tool, new games, new tutorials, and not one but two job adverts! If you feel like coding in Phaser as a full-time role, check those out.

🔥 Phaser Debug Tool

A browser extension for real-time inspection and modification of Phaser games.

The Phaser Debug Tool is a Chrome and Firefox browser extension that, when invoked, checks for the existence of 'Phaser' within the page. If found, it hooks into it and provides all kinds of tools to inspect and modify the running game.

Read more about the Phaser Debug Tool

🎮 Legion

Assemble a team of warriors and compete to be the strongest in this stunning multiplayer PvP game.

Legion is a browser-based multiplayer PvP game where players assemble and level up a team of up to 10 heroes, including Warriors, White Mages, and Black Mages, each with unique abilities. Engage in real-time battles across Practice, Casual, and Ranked modes, climbing through five seasonal leagues. Enhance your team's strength by upgrading equipment and mastering powerful spells that can heal, inflict damage, or alter terrain. The game utilizes Phaser for its engine, PreactJS for the client app, NodeJS for the server and matchmaking, and Firebase for authentication and serverless API.

Play Legion

🌟 Halloween Memory Match Tutorial

Learn how to create a spooky memory game using Phaser Editor.

It's that creepy time of the year again - and what better way to celebrate than with this stunning new Phaser Editor video tutorial by Scott Westover?

"Spooky season is upon us! Ready to make your very own Halloween-themed memory match game? 🎃 With Phaser Editor v4, we’ll turn your ideas into an exciting game! By using the editor to create our game visually, and with a little bit of code we can create awesome games like this."

Watch on YouTube

🚀 Shapecraft Game Hackathon

Join the Shapecraft Hackathon with $250k in prizes available.

What if we all work together to build an interconnected game universe? A universe that is interoperable, where a player can carry their items, characters, friends list and accomplishments wherever they go. A universe that is fun, containing many independent game worlds that aren’t tied to any particular platform or genre. A universe that is neutral, where the rules are laid out transparently and no single entity has root level control. A universe that is massive, where the collective lore and depth of gameplay can rival or even surpass the largest massive multiplayer online games.

This is the dream of Shapecraft, a four week game jam/hackathon starting November 18th. We’re calling all of you, professional and aspiring game developers, to help bring this vision to life. There will be $250k in prizes awarded to the most inspiring projects submitted during this time period that capture this vision.

Read more about the Shapecraft Game Hackathon

😊 MobileFuse hiring Phaser Developer

Experience with Phaser and HTML/CSS? Join a powerful creative team.

MobileFuse (www.mobilefuse.com) is a leading mobile advertising network. We are currently looking to hire an outstanding Freelance Creative Developer to support our growth. We are looking for candidates who have a desire to learn new skills and improve existing ones. The perfect candidates will pay attention to details and take great pride in their work.

You will be joining a team of designers who are the leaders in our industry. Take advantage of this opportunity to use your talents and creativity to design and develop captivating ads for mobile devices. Our world revolves around cutting-edge technology and finding the best talent possible. If you believe you match these qualifications, then we can’t wait to speak with you!

Read the full job posting

😊 ProgGenius hiring Phaser Developer

Location: Remote
Employment Type: Full-Time
Budget: 2200-2400$/mo. (PayPal)

We are looking for a talented Phaser Developer to join our dynamic team at ProgGenius. In this role, you will be responsible for creating engaging and interactive 2D games using the Phaser framework. You will collaborate with designers and other developers to bring exciting concepts to life while ensuring high performance and user experience.

Project Overview Sea Battle Online is a multiplayer game within Telegram, offering a remake of Sea Battle 2 adapted for the Telegram Mini App environment. The main features include turn-based naval battles with enhanced capabilities, city development and visual customization, participation in tournaments, and completion of daily quests and achievements. Monetization is through in-game purchases, while the basic functionality remains free to play.

Fill out the Application Form

Phaser Studio Developer Logs

🧑‍💻 Rich - CTO & Founder

The fact we’ve now hit November both terrifies and excites me! The amount of things we have accomplished this year is nothing short of staggering. The team has really been pulling out all the stops these past few months. Yet it’s also exciting because we’re now in the final stretch towards releasing our Game Publishing Service, Discord Activities Tool, Phaser Box2D, and the first alpha release of Phaser 4.

The Game Publishing Service is our lite version of itch.io. From your user account, you can set your choice of phaser.games sub-domain, create a new game, and then drag and drop folders/files onto it from your local system. We’ll host the game for free, and you’ll get analytics and, over time, more options to customize the layout and build up your game portfolio. Of course, we’ll also build this into our templates, Phaser Launcher, the Discord Activities Tool, and Phaser Editor. Easy 1-click game hosting to share with your friends or clients.

As for Box2D, this creeps ever closer to completion. Pete was on holiday this week, but Zeke carried on putting the API through its paces by creating example after example. You can read his entry in this issue to see how it has been going! We have been very careful in retaining the Box2D API as it exists in the native C version. We have not renamed all of the functions or classes, for example. They still retain their b2 prefix and are name-spaced via the function name rather than an actual class structure. Box2D v2 was very OOP, but v3 changed all of that and it’s now almost entirely functional, but with OOP ‘emulated’ via the function naming. We kept that fully intact. The main reason is that it makes debugging easier, but another is that if you find a really nice Box2D tutorial or example written in C, you can easily use that with our port without having to worry about what ‘friendly class mapping’ we may have used because the function names are identical.

Someone asked on Discord if our Box2D library will be free or commercial. The answer (as I gave on Discord and previously in these Dev Logs) is that it will be commercial. This was the plan from Day 1 and we’ve never indicated otherwise. We’ll ensure there are suitable levels of pricing to make it affordable to both hobbyists and those wanting to use it for client projects. Personally, I would love for it to be free, but those who have been following along know that we’ve spent months of hard, full-time work on this, and as a result, we need to recoup some of that cost.

As for Phaser 4 - more on that soon! The goal is to complete Phaser Beam development and then release an alpha of effectively v3.86 with Beam replacing every single internal thing to do with rendering. It’s going to be a huge shift and I can’t wait!

🧑‍💻 Francisco - Phaser Launcher

This week, I focused on improving the Media Browser component within the text editor for Phaser.js, aiming to make file navigation and management more intuitive and functional. The Media Browser now allows smooth folder navigation using breadcrumbs, making it easier for users to locate themselves within the file structure. Additionally, I optimized file selection to allow both single and multiple selections.

The Media Browser is designed to open the assets folder, so having this module available to copy file paths directly into the editor will be valuable, streamlining the workflow by integrating resources directly from the Media Browser.

Another update is the addition of a contextual menu, which provides quick access to relevant actions for files and folders. This functionality makes the Media Browser not only more versatile but also more accessible to users, facilitating faster and more efficient file organization.

Next Steps

With the Media Browser shaping up, it’s time to start defining the application’s startup flow. I’m considering how best to structure folder opening and project loading for a smooth experience, including features that allow users to open a folder, load the current project, or even quickly access previous projects. The goal is to make startup intuitive and agile, catering to the needs of regular editor users.

🧑‍💻 Zeke - Box2D

Finally kicked off making a Box2D game demo on Monday. It’s called… Asteroids. Yes, it’s a classic and simple enough to build over a week while figuring out what functions, shapes and UI elements are needed to make this work.

First step, making a basic triangle shape and making it move around. Sounds easy enough, except it’s purely Box2D in JavaScript with no helper functions. The ship itself requires 3 components: a dynamic physics body, a collision shape and a triangle shape definition in vector format. To make it move requires getting the ship’s rotation and applying a force to the ship’s centre. Here’s what it looks like:

Step 2: Shooting. See what my first attempt at spawning bullets from the ship looks like:

Unexpectedly, smoke trails were created instead that look nice if implemented properly but that’s not my intention here. So after some tweaking and applying force to each bullet, I’m happy to see shooting working.

Tweaking shooting a little further to add a firing rate so bullets are not spraying out like a hose:

Step 3: Asteroids. What’s an asteroids game without it? Using a basic circle shape, this was a fairly straightforward step. I thought it looked good until…

At least collisions are working. Maybe I should change this to bumper cars in space instead. Before splitting the asteroid, I decided to add in a world wrap feature so bullets and asteroids will reappear after exiting the edges of the world.

Now to crack some asteroids.

After getting some feedback from the team, prettier asteroids are needed. So from a circle, it’s now a randomly generated 5 to 8 sided polygon.

Finally to add a simple UI to complete this demo.

It’s been a fun week learning more about Box2D and figuring out how to implement it in a game. The experiment has given me more ideas about what to build next. Until then, I’ll be working on creating specific physics examples to show you how to add specific physics elements like adding thrust, rotation and collision detection.

🧑‍💻 Can - Discord Activities Tool

This week was about refining and testing our Discord Activity launcher. Main tasks involved bug fixes and polishing to ensure a smooth user experience. I also implemented a cloudflared check to confirm if the package is installed, which adds a helpful UX layer before it launches the project. Another improvement we've made is moving from GitHub to our CDN. Downloading a ZIP of project struggles sometimes, responses slowly - with Phaser CDN, its much much faster now!

On the visual side, the app logo is shaped up beautifully (Ilija kills it, yet again), and I’m excited to reveal all together soon! So far, everything is progressing as planned, and I can’t wait to share more updates as we approach launch!

🧑‍💻 Arian - Phaser Editor

Hello friends

Our tilemap editor is almost ready. We have implemented all the features we planned for the next version of the editor, which should be released this week! Right now we are working on a new project template that includes a tilemap, which you can use to get an example of how to use it. In general, nothing changes from how you have used tilemaps before. Only now you can edit it from the Scene Editor itself. One thing we worked on all week was code generation. For this new version, all map data, including tile indexes, is included as part of the scene code. For future versions, we may give the option to save the data to an external file. Here is a screenshot of the example we are working on, which is an adaptation of the Sunny Land Forest demo created by Ansimuz:

Tales from the Pixel Mines

November 1st 2024, Ben Richards

This week has been a mix of squashing bugs and implementing filters.

Bugs

RenderFilters Focusing

There were a few issues around RenderFilters focus. This is an important aspect to get right, because the old FX system was supposed to just work. RenderFilters requires a bit more precision due to its greater capabilities, but we want it to just work too.

My solution is to detect imprecise child size, and toggle a flag to put the RenderFilters into "context focus" mode. This means that it derives its size when it renders, using the current DrawingContext. The DrawingContext includes a camera which the RenderFilters can copy. This is exactly the same as the old FX system. When the RenderFilters is rendered through multiple cameras, it will resize to each in turn.

DrawingContext Release

Several issues came up with DrawingContext release. It's vital to get these correct.

See, when we're working with filters, we need a constant stream of framebuffers to use and discard. We get these with DrawingContext objects, provided by a pool where they're recycled. Most of the time, the whole game only ever uses a couple of extra framebuffers under this system, which is very efficient.

The first problem is early release. When we release a DrawingContext, it goes back to the pool, and can be re-issued to another use. But if we want to use the DrawingContext in its original form, we have a problem. Very often, it's immediately taken and drawn to for another purpose, so the original is lost by the time we come to use it. Instead, we see something unexpected drawn where we don't want it.

The second problem is failure to release. If we don't release a DrawingContext, we never have a chance to reuse its framebuffer. But that framebuffer still exists. And we need a framebuffer, so we make a new one. Framebuffers quickly pile up, and the WebGL context quickly runs out of memory. WebGL crashes. This is a bad time.

The solution is, simply, to track all the complicated uses through, and make sure we're releasing everything correctly.

I also added the ability to "lock" a DrawingContext, preventing it from returning to the pool until unlocked. This is useful for "diamond-shaped" logic, where a given filter result needs to be used in two separate places before being combined. It's complicated stuff, and can crash WebGL entirely if you get it wrong, but it's there if you need it. (Mostly, it's there because I need it.)

Parallel Shader Compilation

The parallel shader compilation extension for WebGL is not available in some browsers, mainly Firefox. A logic bug prevented some shaders from ever compiling when the extension was not available. I fixed the logic and it works fine now.

You can enable parallel shader compilation in Beam by adding the following code to your game config: skipUnreadyShaders: true. This feature will skip rendering a shader until it's fully compiled, allowing your game to keep running in the meantime. It prevents stutter as shaders take several milliseconds to compile. This will result in blank renders, so it's best to pre-touch shaders and rendering options before you need them.

Quicktime Support

I added the ability to load Quicktime .mov video files, which was missing.

This is a horror story.

Quicktime videos load just like any other videos. There's nothing wrong with them. But Chrome on Windows (on my machine) says it can't play them. It can play them. I checked. It's lying.

Because media files are so complicated, browsers have a special interface to tell you whether you can play a given file. The HTMLVideoElement.canPlayType function has three possible results: "no", "maybe", and "probably".

There is no "yes".

And, as we've seen, sometimes browsers lie.

Suddenly, a monster joins our story: HEVC, the High Efficiency Video Coding standard. This is a monster of human creation, spawned by greed and carelessness. Taken by itself, it's a beautiful thing, supporting cool features like transparency, better file sizes, and improved color handling. But the megacorporations which created it wanted to get a return on their investment, so they put licensing fees on it.

As a result, many organizations were unable to use HEVC. For example, the Firefox browser can't implement it, or they'd have to charge you money to pay the fees. And, as we've seen, media file support is extremely vague on the Web. So when Chrome tries to play a file with HEVC, it comes out wrong. (In this case, the alpha channel is missing, replaced with a black background.)

And HEVC isn't a file type. It's a codec. That means it can be inside a MOV or MP4 file, with no way to tell until you try to play it. My Firefox says it can "maybe" play MOV files, so it gives it a try and throws an error because it finds HEVC.

HEVC could be lurking in any video, waiting, biding its time. Sometimes it behaves nicely. But every so often it reveals its hidden face, and does something wrong, or just crashes your game.

If you can help it, don't use HEVC. Not even for the cool transparency features. The VP9 codec does transparency without these issues, as part of the WEBM container. You might still be ambushed by a video that doesn't work as expected, but as I said, this is a horror story. The story of video in the browser has no happy endings. If you're lucky, you'll survive.

Filters

Color Matrix

Color Matrix is pretty much the same. However, the FX version concealed the fact that the color handling wasn't done by an FX Controller. It was a separate object, skinned to look like a controller. Because Filter Controllers are a bit heavier, this was no longer practical. The main difference is that you'll now call colorMatrixController.colorMatrix.negative() to set colors, instead of colorMatrixController.negative().

Because Filters run on cameras, we can take the previous scene, and put it through a camera with the Negative color matrix. This reverses the negative to positive, and changes the unfiltered items to negative. This is the kind of cool stacking effect you can make when there are no limits on stacking filters!

But there's more. Notice how the background didn't turn negative. That's because it's not part of the camera! That's the game background, which is set outside any scene or camera, and thus is outside the realm of filters. You can also add a background to a camera, which is affected by filters. This is a useful distinction to know about.

Barrel

Barrel is still the same. I had an interesting time replicating the example above, though, because the order of operations is slightly different. Padding won't get the same effect. Ultimately, I used box.focus(undefined, undefined, box.width + 64, box.height + 64) to enlarge the scope of the camera while keeping the sprite centered. You can do a lot of different things with the controls available to filters!

Blend

WebGL is infamously short on blend modes. While it has plenty of blend options, few correspond to the blend modes familiar in Photoshop or the Canvas renderer. You're left with ADD, MULTIPLY, SCREEN, and ERASE, where Canvas has dozens of familiar and useful modes.

While we still can't set those blend modes straight on objects, the new Blend filter will help. It gives you every blend mode from the Canvas renderer, from ADD to XOR.

But it's better than that. Because these are applied by shaders, you can tune and overdrive the blend. The Blend filter has a color property, which multiplies the blend texture, allowing you to tweak the behavior. And the blend amount property can go beyond the range 0-1, a setting I call "overdrive". This lets you do things that are otherwise impossible with a single blend, like apply intense colors or reverse a blend.

In the example below, I've used Blend in ADD mode to modify three gems, adding them to themselves. One is super bright. One is brightened just in the red channel. And one is brighter in red and darker in blue, turning it from cyan to orange. As you can see, overdriving a blend gives you new kinds of control you never had before!

Bloom

Bloom was the last filter on my agenda, and it turned out to be the hardest. It's a composite filter, using several passes to blur the input, then blending the blur with the original input. If that sounds like everything else in this log entry, you're right! I had to develop everything to support this filter.

And I'm not done, because I want to make Bloom look as good as possible. See, the original Bloom FX was composited in a way that made it darker in some places. Now that we have Blend shaders, we can composite it properly, making the image as bright as it was originally.

The question is, which Blend mode to use? ADD? SCREEN? COLOR_DODGE? I think the correct answer is to give the choice to you, and expose blend mode as a setting on the filter controller. But I still want the default to look great. I think SCREEN is probably best - it's way less garish than the alternatives in my tests.

If you're reading all this and getting flashbacks to the Bad Old Days of bloom 20 years ago, don't worry. You have the power to control every aspect of the filter. You can right the wrongs of the past.

Next Week

I'm going to polish off this batch of filters. (That implies more batches to come. I have ideas. They won't be in this release of Beam, but there are plenty more things to empower your games.)

Then I'm going to work on the Shader game object. This fills a vital role in game rendering. I think of it as the counterpart to textures: a way to cover a quad with something that's not an image file. It's also how you get new shaders into the game.

Fingers crossed, we're going to hit the last few features soon, and start the laborious process of tidying everything up and making sure it works. I'm pretty confident, but I also know that complicated things attract bugs.

Time to fire up the bug zapper...

Share your content with 18,000+ readers

Created a game, tutorial, code snippet, video, or anything you feel Phaser World readers would like? Then please send it to us!

Until the next issue, happy coding!

Welcome to another massive issue of Phaser World! We’ve got new videos, new tutorials, new games, and more animated gifs in the Developer Logs section than we’ve ever had before 😅

🌟 Phaser Beam Technical Preview 5

Play with new demos, download, and help test the latest release of our renderer.

Welcome to Phaser Beam Technical Preview 5. This preview is an insight into upcoming advances in Phaser and its WebGL renderer.

This version is all about framebuffers. We've revised DynamicTexture to be easier to use and more performant. We've also removed FX and BitmapMask, combining them into the new Filters system.

In this article you’ll find details about everything that is new, along with 4 demos in the Phaser Sandbox and a link to download and use TP5 in your own local builds. We’re getting very close to finishing all previews of Phaser Beam. The next stage is full integration with Phaser v3.86 and then an alpha release.

Read the full article

🧠 Build a game like Teeter Up

A tutorial series on building a game like Teeter Up using Phaser.

Emanuele Feronato published a tutorial series on creating a game like Teeter Up in Phaser. He writes: "During the past few days I’ve been watching a few Netflix video games on my iPhone, and I particularly liked Teeter (Up).

It’s a simple physics game with a ball, a platform, and a hole. What could possibly go wrong?”

Read the tutorial series

🎮 Mahjong at Home: Aloha Edition

Explore the rich heritage of the Polynesian people in this beautiful casual Mahjong game.

RavalMatic has released a new installment in their popular Mahjong at home series. This installment takes players to a Polynesian-themed environment by the sea, where they can explore the rich cultural heritage of the Polynesian peoples. Discover intriguing aspects of this vibrant culture through the immersive cabin setting, which is perfect for those interested in Polynesian history and art.

Play Mahjong at Home: Aloha Edition

🎥 Create YouTube Playable Games with Phaser

Enjoy our new YouTube video all about making games for YouTube!

We’ve another new video up on YouTube. Check it out above 👆

Phaser Studio Developer Logs

There has been so much going on; this is another pretty big Dev Log! with lots of pretty pictures and animated gifs 😀 So, let’s get going …

👨‍💻 Pete - Box2D Physics

This week has involved quite a lot of bug hunting, finding, and squashing (splat).

I started the week with the 'popcorn' bug which had been evading me on Friday last, it resolved as a combination of 5 separate 'silly' bugs (primarily typos, and two reference copies that should have been object clones).

On the way through I took a very close look at the new capsule implementation and found an (unrelated) issue that was allowing them to overlap. We now have fast and firm capsules which I plopped into a jar with a stirrer:

After a late night bug hunt I finally found the last silly bug that was causing the 'popcorn' explosions and fixed it. Unfortunately with that fixed I was free to notice that triangles landing on other triangles didn't react properly! A problem for Tuesday...

Another day, another catchy bug name: the 'polygon penetration' bug. It seems that the AABB used for broadphase collision pair finding is in the wrong place when polygons switch to 'fast' moving bodies. This one was lovely and specific which made it an easy capture: an inappropriate optimisation to reduce the garbage generation... in other words I tried to make things faster and broke them instead.

The fix was trivial at least. I then took some time to modify various tests to push a little harder, and to use a selection of shapes rather than just one or two. This tests the engine more thoroughly and is (generally) a more realistic use-case for gaming.

Late on Tuesday I enabled the island 'sleeping' flag (I've been meaning to test this for a while)... and it failed. Let's save that one for Wednesday.

On Wednesday we started additional testing with another team member... the bugs aren't entirely gone yet, but most of the engine does its job, so it's time to get Zeke involved!

Either I'm getting better or the bugs are getting slower... I had an intuition about the sleeping island issue, stepped through some code deep in the solver and found a bug where a slightly unusual JS function attempted to recreate C functionality that zeroed a deep object (in C it is flat memory, but in JS it's deep). It was just the one issue this time, and a relatively simple fix means that islands sleep and wake properly. I had to check so I created this test to shower things into bins for a while, then let them sleep:

Examples Revamped

Time to make things a bit prettier!

Build System Preparation

Rich and Zeke did some obscure things and made a build system with bundler... we're definitely gearing up for the full internal testing phase.

Another Bug

Prismatic joints decided to act up next. They always seemed a bit dodgy to me but I couldn't put a finger on exactly what was wrong - until today when they started hopping around the screen instead of sliding up and down the lines as they're meant to. This one was tricky, and eventually, I built a C++ test bed using the original C library and mimicked it in JS. After stepping them side-by-side I found a point of divergence and was able to track that bug down to its hidey hole. Guess what... it was another reference error (reference copy instead of clone). These guys are very sneaky!

New Examples

I closed out the week with a couple of new examples:

• A piston driving a wheel via a push-rod, in much the same way as a steam engine works

• A chain bridge

👨‍💻 Zeke - Box2D Physics

On Monday, I did some final polishing for parts of the Phaser documentation site.

On Tuesday, I started learning Phaser’s Box2D physics engine. It’s an exciting development since Box2D gives us an industry standard physics engine to work with, and will form a really nice addition to Phaser itself.

The rest of the week was spent coming up with ideas and implementing some basic examples.

Here are a few completed examples:

After I’ve gotten a better grasp on Box2D, I’m planning to create more game related examples to implement in your own games.

👨‍💻 Francisco - Phaser Launcher

This week, I focused on advancing the Phaser Launcher landing page and integrating features into the editor.

The editor now supports opening and viewing various file formats, including MP3s, videos, images, and more, directly within the editor itself. Additionally, you can modify files directly from your operating system’s native file system, with real-time updates reflected in the editor—making it highly responsive to external changes.

I also implemented a tabbed interface, allowing multiple open tabs with a sliding feature, similar to Visual Studio Code. This makes it easier to switch between files and keep multiple resources accessible at once.

For the landing page, I experimented with opening multiple windows and worked on inter-window communication. Since future modules will require interaction across different windows, this is a crucial foundation for the project’s modular growth.

👨‍💻 Arian - Phaser Editor

Hi friends.

The tilemap editor is going full steam ahead! I've already finished the basic tools: Stamp, Fill, Rect-Fill, Eraser, and Rect-Select. I think that next week we'll complete the features that will be part of the first version. There's still code generation to implement and some operations like deleting a tileset, and well, there are always some ideas that can come up along the way. Something very important and time consuming for me is writing the documentation. Proper documentation is essential, so I think we're still a bit short of the first version. We also need to create a project template or modify some of the existing ones. Changing the subject a bit, Scott Westover recently posted the video Phaser Editor v4 Beginner's Guide: Make Games Fast with Phaser 3! on his YouTube channel. I recommend it!

Here are some images of the new tilemap editor.

👨‍💻 Can - Discord Activities Tool

This week, we focused on making the project setup even smoother, following some internal tests with the team. Before the official release, we’ve added a new feature that streamlines creating projects with our tool. Now, you can simply select your template and desired installation folder, and the tool will take care of the rest, making the whole process hassle-free!

Here's what it handles for you:

• Downloads and unzips the template project into the folder you selected.

• Installs the necessary npm packages automatically.

• Renames example.env file to .env for you.

• Additionally, we've added the option to enable DevTools with the production build. This is especially helpful if something unexpected occurs that the app isn't catching on its own.

We’re wrapping up our final tests with the team, and if everything goes smoothly, we’ll be ready to launch v1!

Until then, keep your pixels sharp, everyone!

Tales from the Pixel Mines

October 25th, Ben Richards

My big headline this week is, of course, Phaser Beam Technical Preview 5. Released earlier this week, this adds support for Filters (formerly FX and BitmapMask) and DynamicTextures (and RenderTextures). I've continued to add filters to the engine, and fix some bugs along the way.

More Filters

Threshold Filter

The Threshold filter is new in Phaser Beam. It pushes each color channel towards 0 or 1, either within a range (creating heightened contrast) or absolutely (creating black and white with no shades of gray). Here, we see it used to turn a simple particle emitter into a more cohesive and stylized effect.

Threshold is particularly useful when combined with a Mask. You can convert an alpha gradient into a sharp edge, and animate where on the gradient that edge appears. This leads to cool effects like burning paper and dripping liquid.

Shadow Filter

The Shadow filter returns. In Beam, it has a bug fix. In Phaser 3, shadow alpha interpolation was not clamped, which could lead shadows to change color within their edge. The interior of shadows are now a constant color, as you can see here.

Glow Filter

The Glow filter returns, with big improvements. The glow shader algorithm has been tweaked to get higher quality and better performance.

We've added a scale property, which controls the width of the glow effect. This is necessary because the distance property is hard-coded upon creation, built into an instance of the glow shader. The hard-coded quality property has also changed; default quality is now 10 instead of 0.1, which I feel makes more sense.

The glow shader now employs stochastic sampling. It still has even coverage, but it no longer samples in straight lines out from the target fragment. This eliminates the tendency for the shader to produce sharp lines around corners, as seen in this screenshot:

Because the stochastic sampling is generally smoother, a good-looking glow can be achieved with fewer samples, improving performance.

Plugin Filters

The architecture for creating filters is pretty straightforward. I've developed some examples to demonstrate how to add your own filters, which should be available when Beam launches.

Bump To Normal Filter

On the left, a stylized face in grayscale. On the right, the same face converted to a normal map.

This example treats the input luminance as a height map, and converts it to a normal map, perhaps useful for other textures. The example is under 70 lines, explanatory comments included, consisting of a Controller, GLSL shader source, and a RenderNode.

Selective Blur Filter

This example demonstrates more complex filter techniques. It uses an extra texture to control the intensity of a blur effect, which is rendered in several applications of the shader. This uses some extra features of the filter system. The example is under 170 lines, documented and intended for use as boilerplate.

Bug Fixes

As expected, we were quickly informed of some bugs in Phaser Beam Technical Preview 5. I'm very grateful for these reports, as they help us discover things I never thought to test, which all makes for a better end product.

Game Resizing

Somewhere during development, I had broken the code which resizes framebuffers when the game is resized. Fortunately, the fix was straightforward. If you want this fix in TP5, before we release the fixed Beam, add this code to a Scene (and make sure it only runs once):

const renderer = this.game.renderer;
renderer.on(Phaser.Renderer.Events.RESIZE, renderer.baseDrawingContext.resize, renderer.baseDrawingContext);

Filter Draw in Padding Area

The padding of filters is a very complicated area, and I overlooked something. The drawing technique I used meant that internal filters with padding would not draw in the padded area, which eliminated the point of padding in the first place.

This is because I was drawing the filter input as a quad within the padded area. Obviously, the shader couldn't run on regions outside that quad. I could always do the filter with two draws: one to draw the input to a larger quad, and another to run on the expanded quad. But that would be very inefficient.

Instead, I turned the problem inside-out. Rather than shrink the quad into the framebuffer, I drew the quad full-size and expanded the texture coordinates. Thus, the entire framebuffer was subject to the shader.

The only problem was, texture coordinates outside the texture are treated specially by WebGL. They "wrap". The texture can tile, mirror, or just repeat the edge pixels endlessly. There's no option for simply having empty texels. That meant I got effects like this:

So I implemented a fix. Filters support "shader additions", a system I developed for other parts of Phaser. I developed a GLSL function which returns texture samples, except when it detects out-of-bounds coordinates, then it returns transparent samples. Then I used shader additions to make it available in all the padded filters, without having to duplicate the code.

This is an example of work coming together to support cool new possibilities. I feel pretty happy about that.

Next Week

I'm finishing up the remaining filters. Some of them might not make it, as we have better ways of achieving those effects.

I'm also working on a new version of the Shader game object. This should be as straightforward as the Filter plugins described above. The Shader, in my mind, is a system for painting with shaders instead of textures. It's a very useful part of the game maker's arsenal, especially when combined with filters and DynamicTextures. There might even be some new GameObjects one day... but that's another story.

Beam is coming. It's faster, it's more flexible, it's shinier. We've still got a lot of work to do, but we're getting there!

Share your content with 18,000+ readers

Created a game, tutorial, code snippet, video, or anything you feel Phaser World readers would like? Then please send it to us!

Until the next issue, happy coding!

Welcome to Issue 202 of Phaser World. As we enter the final weeks of October, we bring you new releases, new games, and yet another vast Dev Log section. An incredible amount is going on at Phaser Studio right now and we do our best to sum it all up in this newsletter each week. So please read, and if you’ve any questions just ask us on Discord - we’re only too happy to chat.

🌟 Phaser Editor 4.5.1 Released

An important point release of Phaser Editor that solves several high-priority issues.

We are happy to announce the immediate availability of Phaser Editor 4.5.1. We felt it was important to release this update to address some priority issues.

• Fixes the 'white screen of death' issue, where the Editor would hang on a white screen after opening a project if the server was slow to start.

• Fixes tilemap pixel rounding issue in the Scene Editor.

• Fixes the npm install command when the proxy is configured but disabled.

• Fixes the variable name generation.

• We have also taken the opportunity to update the editor to the latest version of Phaser, version 3.86.

Download Phaser Editor 4.5.1

🎮 Honey Snap

Guide bees to victory in this sweet, honey-filled challenge that will keep you buzzing for more.

Honey Snap, besides sounding like a tasty breakfast cereal, is an addictive new game from Black Moon Design. You're presented with a grid of hexagons set into the bark of a tree. Below it are honey-filled shapes that you must drag into the grid. If you manage to complete a line in any direction, it vanishes in exchange for lots of points.

Play Honey Snap

🎙️ YouTube Playables Phaser Tutorial

Learn how to create YouTube Playables with our extensive new tutorial.

Who would have thought YouTube would become such a popular web gaming platform? That's precisely what it has done with its YouTube Playables service. After a successful beta period, users of the YouTube site or app worldwide can now engage in an extensive range of web gaming titles, and developers we've spoken to have seen great success with them.

Of course, being web-first, Phaser is an excellent choice for creating games for submission to the YouTube Playables content team. We have published a brand new YouTube Playables Template and a comprehensive tutorial to make that process as easy as possible. The template includes a complete game, our Playables SDK wrapper, and full documentation. It is now available directly from the Google web samples repository.

To help you get the most from our template, we've also written a detailed new tutorial that covers the SDK and the Test Suite and how to use them in depth. So now you have the perfect reason to enhance your Phaser games into compelling YouTube Playables and introduce them to millions of new gamers.

Read the YouTube Playables Tutorial

🎮 Gloomyvania

A nostalgic platformer filled with challenging enemies and classic arcade vibes.

Gloomyvania is a lovely homage to the classic NES Castlevania series. In this arcade platformer, you run and 'gun' to destroy a variety of creepy enemies as you explore the castle.

Play Gloomyvania

💰 Let us publish your Phaser Games

Got a Phaser game you’d like published? Get in touch!

At Phaser Studio, we’re all about empowering developers to create great games. By focusing on the framework and tools to allow this, we’ve seen thousands of games released over the years, many of which went on to critical and commercial success.

And we’ve noticed the publishing landscape is changing yet again. New platforms are opening up that introduce keen opportunities for the right games. And it’s something we’re deeply invested in.

So - if you’ve developed a Phaser game you feel would benefit from wider distribution to exciting new platforms, then we’d love to hear from you. Please email a link to your game or games portfolio to bizdev@phaser.io , and we’ll be in touch.

Phaser Studio Developer Logs

👨‍💻 Rich

When I sat down to write my Dev Log, I thought about all the really exciting things that had happened this week. Then, I realized I can’t talk about most of them yet! We sign NDAs with our partners for a reason - so I’ll just have to bottle it up until such time as we can shout about it. Back in the realm of things I can actually discuss, we are getting close to the release of several new products. Can talks about his Discord Activities tool in his Dev Log this issue and once we complete some more testing and documentation we will release version 1 of this. There are many cool things this tool will evolve to do in the future, but for now, it’ll be good to have the first release live.

I’ve also been working on the new documentation site with Zeke. This has been a huge amount of work, but it will be so worth it. We have a couple loose ends to tie up on Monday, and then we can make it live. The site is a combination of lots of things. It’s a replacement for our API Documentation that currently lives at newdocs.phaser.io - we have redone all of this, and it’s now easier to browse and search than before. We have also bought together lots of written content and authored pages and pages of new material. This includes guides that I’ve written, and we’re also using some of the fantastic work of Samme and RexRainbow, obviously with full permission and attribution. This revised content allows developers to read about concepts, internal systems, and ‘how things work’ in one single location without having to try and extract that all from the API docs, which isn’t even possible in many cases. The docs site even has an ‘AI Search’, so you can use normal language prompts to query the contents. Having this live will be massive and I cannot wait.

Remaining on the tutorial front, I also finished my comprehensive tutorial on creating YouTube Playables using Phaser. This was featured earlier in this newsletter, so I won’t go over it again here, suffice to say it was great to finally publish it. The tutorial comes with a feature-packed template and a full sample game. It was fun to actually work on a game again! and even more fun to then see it merged into the official Google repositories 😀 Working with the team at YouTube has been a great experience. We’re excited to see where that will evolve in the future.

This week I’ve also been working with the team at Werplay. They’ve years of experience creating amazing games, and as one of Phaser’s enterprise customers we are helping them build a playable ads template that will fit their specific requirements. Doing this has been a nice mental shift for me, and it has also led to some new features landing in the Phaser codebase that will benefit everyone, so a double-win! We create private Slack or Discord channels for our enterprise clients so they can get direct support from the team for their projects. If this is something that would interest you, please drop me an email.

In the coming days, we should have a new Technical Preview of Phaser Beam, the new docs site live, and the first release of the Discord Activities tool. Oh.. and just maybe something else pretty cool 😎

That’s it for now. This is yet another huge newsletter, so keep scrolling to read what the rest of the team has been doing — it’s pretty epic!

👨‍💻 Zeke - New Phaser Docs Site

This week was focused on adding the remaining documentation and cleaning up all previous documentation!

Documents added:

• Blend Mode, Blitter, Color, Container, Device, DOM Element, FX, Game, Group, Image, Layer, Light, Mask, Nine Slice, Particles, Plane, Render Texture, Rope, Scale Manager, Shader, Sprite, Text, Tile Sprite and Video.

The clean-up has been completed by:

• going through and seeing if everything makes sense and is readable

• spelling and grammatically correct

• check links ensuring all are working and pointed to the right destination

• checking examples ensuring the code actually works

• standardized formatting on all pages on the site

That's all for the updates this week. If everything goes according to plan, the new documentation site should be ready by the end of the week.

👨‍💻 Can - Discord Activities Tooling

This week, I've made significant strides in finalizing the Discord Activities integration.

Upgrade to Tauri v2

I upgraded the project from Tauri v1 to v2. The biggest challenge was the new permission system for plugins, especially on macOS. It took more time than expected due to limited documentation. But rest assured, everything is now running smoothly!

Streamlined Discord Developer Portal Access

I've added a direct link to your Discord Developer Portal within the app. It fetches your Discord APP_ID and takes you straight to the URL mapping page. The generated proxy URL is auto-copied, just paste and save to profit!

More Polishing

To improve user experience, I've implemented alert boxes that inform you of any errors or successful events without disrupting your workflow.

Almost There

We're wrapping up the installer systems. With a few more tweaks, it will be ready for its first release!

Until then, happy coding everyone!

👨‍💻 Pete - Box2D Physics

On Monday I tracked down some strange numbers in the dynamic tree, where it appeared to be faster if the tree balancing was always an even split. This was (of course) not the case, and eventually I found a nasty bug. The tumbler 1000 demo doubled in speed with this fix, so that was a lovely start to the week!

I continued to reduce the transient memory allocations, concentrating mostly on a structure called b2ManifoldPoint I managed to reduce it from over 5000 per world step to 0. The current design is using a handful of these objects which are allocated only once, when the world is first created. Running some long-term mobile tests following the tree fix and the reduced garbage accumulation, we now see a solid 60fps with 1000 boxes in the tumbler on iPhone 14 and 15. On iPhone 13 we regularly touch 60 fps but then it drops, I think there may still be work needed on the garbage for those older devices.

I've revisited the frame timing system and given it a capability to catch up a dropped frame or two if the previous frame was at or above the physics simulation fixed frame rate (typically 60 fps). This approach works to smooth out temporary glitches like we see on mobile, while it 'does something else', without getting into a death spiral where the catch-up frame is continually triggering another one.

More optimisations, more memory management changes... tumbler 1000 is no longer a useful test and I've stepped up to tumbler 1250 even on mobile devices.

A note about mobile devices: performance on iPhone is significantly better than on Android. Even the more powerful Android devices on BrowserStack are significantly slower than the older iPhones. I'm not sure how to rectify this. Everything is running well on both Android and iPhone, but on Android the timing values are almost double. My understanding (from a Tom's hardware phone comparison) is that the CPU should be entirely capable of keeping up, so maybe I'm hitting RAM too hard, or maybe there's another element at play. I'll continue to experiment and see if I can work out how to reach parity.

Later in the week I ran the full range of tests to make sure nothing had broken during my heavy handed optimisation passes. Three (out of 8) were broken, so I spent some time with github, reverting to older commits and retesting to isolate the commit that broke things. In this way I have located four 'silly' bugs (x instead of y, min instead max, that type of thing) and one extremely sneaky bug that was well hidden inside the manifold creation system. With these all fixed all my tests are running again, although I am facing an issue where things rarely and randomly explode upwards. I'm calling it the 'popcorn bug' and I'll dig into it next week (with plenty of salt).

I took two days to experiment with WASM via AssemblyScript. I'd love to squeeze a bit more speed out of this, and the code structure (being translated almost verbatim from the C original code) should be ideal. TLDR: it was not good. The long version: I had only a short period of time to perform the testing, so I chose a suitably quick goal: replace the AABB system with a drop-in 100% wasm system. The AABB (axis aligned bounding box) system is called a phenomenal amount, but it's only called from 30-40 unique places. It takes in tiny amounts of data, does some processing, then throws out tiny answers. It's almost a perfect test except that the work it does is minimal. Ideally we'd find a system with the other properties but which does some very grunty processing inside - e.g. pixel manipulation in-situ (the large amounts of data going in can be controlled by the wasm, and processing the data where it lies means we don't have to do slow conversions on the way out, plus pixel manipulations are often relatively expensive per-pixel).

After I'd built the entire system in AssemblyScript and compiled it to WASM, linked the modules, and modified the 30+ places that called AABB related functions, the time test came back 4x slower than JS alone. I put this down to a relatively high overhead switching from JS to WASM and back again... I'd read some internet discussions that downplayed this enormously, but I think I hadn't read deep enough or widely enough. On the basis of these results I'd say that you don't want to be calling out to WASM more than one or two times per frame, making the AABB possibly one of the worst test cases I could have chosen. I would like to revisit this issue, but before I do, I'll need to locate a more suitable function, with much heavier internal processing, only one or two calls per frame, and a suitable data format or data requirements. To do this properly substantial changes will need to be made to the data format used by the engine core functions. Changing the data format will require rewriting a lot of the code uses that data, and in a physics simulation almost all of the systems rely on the same fundamental world representation. Throwing the original C at emscriptem might be a quicker solution, although I expect there could be a host of other problems going in that direction.

Plans for next week:

• fix the 'popcorn' bug

• make some new tests and demos stretching the engine and hunting for anything that's broken in there

• add new helper functions to the growing collection and make sure there's a meaningful example for each one

• polygon decomposition into triangle connected hulls would be lovely to have

• think about the engine in gaming terms: what features will be needed, and which ones are particularly awkward in Phaser Box2D right now

👨‍💻 Francisco - Phaser Launcher

Hello, everyone!

I’ve been working on adding more features to Phaser Launcher and running internal tests to explore how we can create our own packages, allowing for greater flexibility such as the option to use TypeScript if desired (though this doesn’t mean we’ll be using it).

The packaging tests with Rust have been successful; we managed to build packages for small test projects. However, there’s still a lot of work to do in this area, so we’ll continue these experiments and revisit them in the future.

As for our initial code editor, we’ve already implemented several commands like copy, paste, and delete. The key to these commands is the structure I’ve developed to handle everything smoothly.

Thanks to the use of states, we’ve separated the state management of the file system, tabs, the contextual menu, and options like reserving files for copy-paste operations. Slowly but surely, our editor is taking shape.

We also have an internal roadmap for this tool, crafted by the great Richard, filled with interesting ideas that make this application a compelling option for those just starting with our powerful framework.

👨‍💻 Arian - Phaser Editor

Hello friends.

It's been a while since I last wrote here. In Florida, many of us had to prepare for the impact of Hurricane Milton and then deal with the damage it caused. However, this forced break has allowed me to take a break from the computer and recharge my batteries to do the next job: the map editor.

Having a tilemap editor built into Phaser Editor is a feature I've wanted for years, and we're finally working on it. Many of the games you make with Phaser are based on tilemaps, and I think this new tool will eventually replace the need to use third-party map editors, such as Tiled.

There is definitely a huge advantage to having a map editor built into the Scene Editor, since in many cases, levels not only use maps but also parallax backgrounds, images of the environment elements, character sprites, and now you can do all of this in a single tool and with immediate visual feedback.

A map editor is a tool with many features and use cases, so it will take time to develop. However, I believe that we will have a first version very soon. Here are some images of what we have done this week.

Tales from the Pixel Mines

October 20th 2024, Ben Richards

This week, filters get up to speed. I've implemented several filters to check the system, and it's looking good. Let's talk about the changes you'll see in Phaser Beam when it comes to filters.

Foundations

This has been a long time coming. Phaser Beam is built around a whole set of upgrades and changes that were always intended to make it easier to use filters. But it took a while to get everything ready for the new system, so I'm ecstatic that the design is finally working.

The DrawingContext forms the backbone of rendering in Beam, but it was actually designed to keep things consistent with filters. It holds a reference to a framebuffer, and all the settings such as blend modes, camera, scissor mode, etc. When we render, the DrawingContext applies all these settings to make sure everything is properly lined up.

The WebGLGlobalWrapper is a vital companion. It performs state management, ensuring that we always know what all the bindings in WebGL are set to. It also eliminates redundant calls: if we try to set a value that wouldn't change the state, we don't do anything. Thus the DrawingContext can track everything, but doesn't need to update everything.

As discussed in previous installments, I've also developed the RenderFilters object to substitute for the old FX component. This acts as a wrapper for a game object, via an internal Camera. It's the Camera that does most of the work when it comes to filters. The wrapper mainly just provides an extra transform matrix, necessary for separating the internal and external worlds of the Camera.

RenderFilters Child Transforms

The short of it: the child wrapped by RenderFilters keeps its transform. The RenderFilters' internal camera snaps to the child when it's added. This has a number of consequences.

Why do we need to focus the internal camera on the child? Well, we want the child to appear just like a texture, not as an object oriented in the game world. There are actually two ways to ensure this. The first way is to remove all transforms from the object, returning it to the origin. The second is to transform the camera to focus on the object.

Of course, I tried the worst way first. I removed transforms from the object. In hindsight, this was fighting against the natural shape of rendering. It's just so much more confusing to try to map everything back to an un-transformed object.

Focusing the camera is much better. There are problems, though.

Framebuffer Resizing

Depending on the size of the child object, a filter requests a specific size of framebuffer. But that could mean a whole lot of different sizes, across different objects and filters. Too many framebuffers could cause a crash.

We reduce framebuffer count by using a pool. Unused framebuffers can be resized to meet demand.

It turns out it's important to manually delete framebuffer and renderbuffer objects when rebuilding them. WebGL's own garbage collection, if it exists, is inadequate to frequent resizing.

But we don't want to resize if we don't have to. The resize operation can take half a millisecond or more, because it's creating a new framebuffer behind the scenes. In a 16 millisecond frame, that's a huge cost - just a dozen resizes are already eating half the frame.

So by default, we resize just once, when a child is added to a RenderFilters wrapper.

However, some objects change their size every frame. For example, a ParticleEmitter has bounds defined by its particles as they fly about. How can we deal with this?

I've added a flag to automatically resize every frame. However, because of the above reasons, this flag is disabled by default. It's not the best solution.

I've also added a flag for running preUpdate on the child every frame. This flag is on by default, though, because preUpdate is necessary for all sorts of things, from particle movement to sprite animation.

Camera Focusing

Rather than relying on automatic resizing, we can instead give the user the ability to set the size of the RenderFilters. I've added a focus(x, y, width, height) method. This focuses the internal camera such that the child is at x, y within a view sized to width, height.

For example, the troublesome ParticleEmitter can be set to draw to a screen-sized framebuffer, and positioned within that screen-sized view. If you know what you need the RenderFilters for, you can really customize the way it works.

It's also possible to manipulate both the camera and the child after the camera is focused. The system is flexible. Just be aware that the automatic focusing will affect the transforms and origin of the RenderFilters, and the camera perspective. The focus method is actually a wrapper around setSize, setScroll and setOrigin calls. But in most circumstances, I hope focus is the simpler choice!

This gives you more control over internal filter coverage than ever before.

Camera Alpha and Compositing Changes

What should happen when you set RenderFilters.alpha? I think it should treat the RenderFilters as a texture, and change the alpha of that texture. If the alpha is 0.5, we should see the background behind the texture at 0.5.

That's not how Phaser 3 Pipelines handle alpha on cameras. There, camera alpha multiplies the alpha of every child being rendered by the camera. This means that objects blend together. If the alpha is 0.5, two objects overlapping will add to 0.75, and we would see the background behind them at just 0.25.

Here's an example of alpha on child objects. Observe how the text is bright in some places and dark in others, depending on the game objects behind it.

And here's an example of alpha on the final composited texture. See how everything is the same level of brightness, because it's blended before alpha.

In Beam, I've changed cameras to composite their children before applying alpha. This produces the more consistent results. Because filters run through a Camera, it also makes filters more consistent. Anything in a RenderFilters wrapper is composited to a framebuffer texture before alpha is applied.

This means you can use RenderFilters to not render filters at all! You can use it as a compositing tool, rendering several objects in a Container or Layer, then adjusting the alpha of the composite so you can't see one object through another. I think that's pretty useful.

Auto Padding

Some filters (and FX before them) have effects that spread out beyond a single texel. For example, a blur wants to blur the left and the right together. But what happens when a texel is on the very edge of a texture?

Well, by default the blur cuts off, and you see a sharp edge. That's OK if the edge is on the edge of the screen, or is otherwise obscured. But if the edge is in clear view, it's pretty obvious.

So FX had padding added. This was a manual override to add room for extra spread. It was applied by the FX controller and affected every FX on the object.

Filters are more sophisticated. Instead of a manual padding value, each filter controller has its own padding override, which is a Rectangle describing the left, top, right, and bottom sides of the filter. By default they are all 0, so no padding is added. You can change these to any values necessary.

But if you set the override to null, the filter controller uses auto padding. This is coded into filters which have spread. It computes the necessary padding from the controller's settings. (And on objects without spread, it's still 0.)

This should take the guesswork out of padding filters!

You can also override padding to inset, removing the edges of the texture. This could be useful for trimming down a filtered object during the rendering sequence.

More Filters

A lot of this work was precipitated by discoveries made while converting FX into filters. We've got a small collection now!

Pixelate

This is a mech walking through a forest. It looks very creepy in motion. I swear it's just a robot, though.

Bokeh

The classic Bokeh effect applied to a ParticleEmitter. This example used RenderFilters.focus to ensure that the particles were all rendered, and the emitter was at a particular place on screen, without running expensive resize operations.

Tilt Shift

A variant Bokeh which blurs out the top and bottom of the screen.

Blur

Blur, applied to the Phaser logo. This is the filter that really needs padding. Getting padding working correctly, for both internal and external filters, was a real mission, but it paid off.

Displacement

Displacement uses one image as a source to warp another image. We've got an exciting enhancement for this one: it now supports normal maps! Previously, it used the red channel from the displacement map to drive the length of the vector. I've changed it to use red for X and green for Y. This allows you to warp the image in two directions at once. Put a filter on the input, and you could animate the warp!

Next Up

My main objective is a Minimum Viable Product for filters. We're very close! All the filters listed above proved something different and vital. Pixelation tested axis-aligned filters, showing the difference between internal and external states. Bokeh tested filter padding. Blur tested composite filter operations, running several shader passes inside the filter. Displacement tested texture inputs to filter controllers.

I have just two more MVP tasks: Masks and Samplers. But you'll see more about those next week!

Share your content with 18,000+ readers

Created a game, tutorial, code snippet, video, or anything you feel Phaser World readers would like? Then please send it to us!

Until the next issue, happy coding!

Welcome to another packed issue of Phaser World! This week, we have a new release of Phaser and Phaser CE, two awesome games (one completely made with AI), and the teams' developer Logs to digest. Lots of fun stuff! Let’s dig in …

🌟 Phaser v3.86 Released

The latest version of Phaser is now available including important GPU memory fixes.

Phaser v3.86.0 is now available for download. This release is a seamless upgrade for any project using v3.85.x and is one we strongly recommend you all take. The full change log is available on GitHub, but the headline item is a fix in the way Render Textures are resized, which was causing Phaser 3.85 games to use significantly more texture memory than they should have been, leading to out-of-memory errors on some mobile devices. This fix reduces memory usage back down to 3.80 levels.

v3.85 also had an issue where black lines could appear between tightly packed sprites or tiles when you zoomed the Camera to a float (non-integer) zoom value. Upon investigation, we also uncovered a much longer-standing issue with the canvas renderer under similar circumstances. Both of these have been fixed in v3.86. Finally, we also fixed a severe run-time crash issue with the new EXPAND scale mode should you launch the game into a container or iframe with a horizontal or vertical width of zero. Please read the full Change Log on GitHub or npm.

All of the Phaser Templates for React, Vue, Discord Activities, etc., have been updated for v3.86, along with all the Phaser Editor templates, the Phaser Sandbox, and the create-game Phaser CLI app. Although there were only minimal documentation changes, the docs site is also fully current.

Download Phaser v3.86

🎮 Spellstrife

Plants vs. Zombies meets Scrabble in this word spelling tactics rogue-like

Spell words to summon monsters in a tactically deep turn-based battle system. Roguelike runs last about an hour each--choose your upgrades carefully as you climb the Spelltower with a variety of classes.

The starting letter of your word determines which of 26 unique monsters you will summon. Uncommon letters tend to be stronger, but each monster is useful in different scenarios. The length of the word determines the monster's HP and attack power.

You can also cast spells to manipulate your letter tiles or change the battlefield in your favor. Spellstrife is available to buy now on Steam and also has a demo version available. Developer Ben Coffman has done an excellent job of using Phaser to create a really novel blend of game genres and we wish him all the best for his release.

View Spellstrife Trailer

🍉 Suika Watermelon game

Create your own chart-topping suika clone with the full Phaser source code.

Long-time Phaser developer Emanuele Feronato has released the full source code to his Suika / Watermelon Phaser game. If you haven't seen it before, Suika is a Japanese puzzle game which combines elements of falling and merging puzzlers. It rose to glory recently with a series of games and apps using the same gameplay mechanic.

For $5 you get the full source code of the complete HTML5 "Watermelon Game" created using the Phaser 3.80.1 framework and Box2D physics engine powered by Planck.js, all written in TypeScript.

From the experience of more than 500 tutorials about Phaser framework, here is a complete Watermelon game which will make you learn game development using Phaser and TypeScript.

Read more about the source bundle

🌟 Phaser CE v2.20.1 Released

The Community Edition of Phaser gets a new point release.

Today, we released Phaser CE v2.20.1. Phaser CE is the 'Community Edition' of Phaser 2. It is no longer fully maintained by Phaser Studio but instead is looked after by the community.

This version includes the following changes:

• The canvases used for device capability checks and input hit testing are now created with willReadFrequently: true.

• Fixed an error when a video loaded after the game was destroyed (#742).

• Set forceSingleUpdate to false for better consistency in physics calculations.

If you still use Phaser CE for legacy reasons, then be sure to upgrade to this new point release.

Download v2.20.1

🎮 Setris

This AI created game mixes the classic Tetris and crumbles it all into sand.

Setris, or Sand Tetris, is a new twist on the classic original. As the Tetris blocks fall from the top, you can move and rotate them, but when they land, they turn into sand and crumble to pieces.

The sand falls convincingly down, and as more and more blocks crumble onto the playfield, it creates a glorious mess of sandy colors. If you can get a solid stretch of color touch from side to side, it will vanish - just like getting a whole row in Tetris does, causing the sand above it to slip into place and netting you some valuable points.

This is a fun and clever game. Even more remarkable is that it was created entirely using Rosebud AI. That's right. It was "prompted" together using their smart conversational game-making system, with Phaser powering it under the hood. Rosebud AI has recently left private beta, so anyone can register and try making games of their own. If you create something extraordinary, please let us know!

Play Setris

💰 Let us publish your Phaser Games

Got a Phaser game you’d like published? Get in touch!

At Phaser Studio, we’re all about empowering developers to create great games. By focusing on the framework and tools to allow this, we’ve seen thousands of games released over the years, many of which went on to critical and commercial success.

And we’ve noticed the publishing landscape is changing yet again. New platforms are opening up that introduce keen opportunities for the right games. And it’s something we’re deeply invested in.

So - if you’ve developed a Phaser game you feel would benefit from wider distribution to exciting new platforms, then we’d love to hear from you. Please email a link to your game or games portfolio to bizdev@phaser.io , and we’ll be in touch.

Phaser Studio Developer Logs

👨‍💻 Rich

Welcome to another update! This week has been a nice mixture of tasks for me, but the main thing I focused on is getting Phaser v3.86 released. This version contains some important fixes, making it essential for anyone using 3.85.

It was an interesting task tracking down the causes of the issues and brought home just how poor the debugging tools we have available as web game developers really are. Dev Tools does its best, but it really isn’t geared towards long-running or frequently updating processes. Given it was built for web devs making web sites, this isn’t really surprising, but it does highlight a truly massive hole in the market.

Team progress across all fronts continues at speed. Box2D is nearing completion, our Discord Activities tools are nearing a first release, Phaser Beam is very close to the end of its dev cycle, Phaser Editor is about to start venturing into tilemap territory, Phaser Launcher has nearly completed its R&D stage, the docs site is very close to release, and of course the new website continues to be updated every day, with new features and fixes here and there. We’re also well into the development of our publishing system, which will allow you to easily host your games on our site via a simple drag-and-drop.

Also, thank you to those of you who responded last week to my call-out about having your Phaser games published by Phaser Studio. We’ve already started working with a small group of developers and are keen to see where this partnership takes us. If this is something you’re interested in, then drop me a line (rich at phaser.io), and we can talk more about it.

Finally, I took a little time one evening to play with Deno 2. If you haven’t seen the announcement video for it, then I strongly recommend it! The first 3 minutes are just golden 😀

The product itself is outstanding and great fun to use. What with this, VoidZero and Bun on the market, things are starting to get really interesting.

👨‍💻 Pete - Box2D

Optimization and Performance Improvements in the Box2D Plugin

• Continued the "Great GC Clean-up" (GGCC) to reduce object allocations and improve performance.

• Reduced b2Vec2 allocations from 240,000 to less than 500 per world step for a 1000-object tumbler demo.

• Eliminated b2Sweep object allocations by converting to a single constant at program start.

• Modified b2Manifold and b2ManifoldPoint usage to avoid allocation.

• Replaced b2StackAllocator with faster JS arrays.

• Optimized time-critical code chunks using Claude AI and manual refinement.

• Improved performance of the 750-object tumbler demo to run stably at 139-144 FPS in Chrome and 70 FPS in Firefox.

• Achieved 1000-object simulation running at 139-144 FPS in Chrome desktop (the monitor refresh rate).

Memory Management

• Investigated potential memory leaks and explored tracking methods like WeakSet, though with limited success.

Documentation and Helper Functions

• Created documentation for Box2D 3.0 JS and helper functions.

• Developed an example project demonstrating the library's capabilities.

• Moved demo code from main.js into separate, more accessible files like fun_stuff.js.

• Wrapped and documented toy features such as Guns, Spinners, and a Ragdoll class.

Simulation Behavior Improvements

• Modified the world step mechanism to prevent FPS cascading failures during overload situations.

• Implemented a new approach allowing FPS to drop when overworked, avoiding permanent catch-up scenarios.

Ongoing Optimization Efforts

• Identified and optimized frequently called one-line functions like b2ContainsKey and b2AABB_Overlaps.

• Reordered conditionals to reduce function call frequency in critical paths.

• Optimized callback usage in inner loops, particularly for b2PairQueryCallback.

• Restructured a central function to avoid an inefficient callback and optimised it for the most common case.

• Created a reproducible test case: 1000 steps of a tumbler with 1000 objects.

Next Steps

• Continue documentation efforts.

• Prepare for team exploration and contribution in the coming week.

• Consider further performance profiling and optimization techniques.

Wins for the Week

• Dynamic memory allocation is sufficiently low that the GC time is almost irrelevant.

• Tumbler 1000 execution time decreased from 12500 to 8500ms.

• Improved understanding of systems in Box2D will help with further optimisations in the JS version.

👨‍💻 Francisco - Phaser Launcher

Hello everyone,

This week I’ve been working on the Phaser Launcher tool and managed to add several new features. Now, you can open files, switch between tabs, focus on the editor, and even save the files you’re editing.

The editor now has full context of the selected file. Additionally, in the file view, files are automatically selected when the editor gains focus.

Creating files, creating folders, and minimizing everything works as expected. It’s incredible how many small tasks come with building an editor like this. Tasks such as selecting a file, checking its type, creating the corresponding tab, getting the language, fetching its content, displaying it in the editor with its own context—it all adds up. And if a tab is closed, the editor needs to check if it was in focus, select the next tab in line, and repeat the process all over again.

Step by step, our Phaser Launcher editor is growing into a tool that will become extremely useful for anyone who wants a fast and easy way to work with Phaser.

👨‍💻 Can - Discord Activities

This week, I made solid progress on our Phaser Discord Activity Launcher! The core features are now complete, allowing us to jump into the development server with just one click.

I started by running npm commands (make sure npm is installed on your system) and dynamically adjusting them based on the user's operating system. Thankfully, Tauri made this part a breeze, utilizing the "os" package and executing shell commands under the hood.

Next, I tackled command output handling essential for real-time feedback. Now, we can read every output buffer from npm, making it easy to filter relevant data on the fly. Regex came in clutch here (gotta love that dark magic), and it's working like a charm!

For the UI, I added a CSS loader to keep users entertained while all the heavy lifting happens behind the scenes. A bit more polishing is needed, without a doubt.

I’m hyped to finish this up and get it into your hands soon - can’t wait to see what you’ll build with it!

Takes from the Pixel Mines

October 14th 2024, Ben Richards

This week, I got a thing working! But what is that thing? Well, I don't know what to call it. Let me explain, and maybe you'll see where I'm coming from.

How It Started

Originally, we called these things FX. They handle post-processing effects like blurs, pixelation, displacement, etc.

In previous weeks, I explained that I want to put these into a single wrapper around game objects, to improve clarity. It's good to know where the framebuffers are in your scene, because they can affect performance. I originally called this wrapper Box, but that was too generic. So I switched to calling it RenderFX.

How many framebuffers is too many? In one way, I can't tell you, because of another way in which I can tell you.

I tested nesting RenderFX objects, one inside the other. Somewhere above 1024 nested levels, Chrome gave up and gave me RangeError: Maximum call stack size exceeded. This means there are just too many things inside each other for the JavaScript engine to handle. While it's possible to set browsers to have a larger call stack size, that's no good for games that are supposed to run on any device. So 1024 nested levels seems like a good "soft limit" for nesting.

This was not a WebGL error. Every object requires a new framebuffer, and an extra draw call. Performance did not drop under 60 frames per second during testing. Thus, we don't really know how this nesting affected GPU performance, because on my machine it is actually impossible to stress the GPU in this way. The CPU gives up before the GPU reaches its full potential.

I did do some performance profiling, though, and both CPU and GPU utilization were around 60% when the stack size was exceeded. Most of the GPU cost is probably spent on waiting for draw calls to be sent, rather than actually executing them. Overall, even though we can't reach full GPU utilization, it looks like drawing 1024 framebuffers is close to the limits of performance.

How It's Going

This week, I made several discoveries and decisions. Nothing changes my objectives, but it does change the way I think about them.

First, I decided that the things called FX should instead be called Filters. Post-processing effects are analogous to filters that you'd use in Photoshop, right? And "effects" extends to more than just filters - things like particles aren't filters, but would be called effects. So Filters seems best to me.

Then I took a long, hard look at the Camera. I realized two things: the Camera doesn't have enough transform power, and the Camera is where all filters live.

What kind of transform power does the Camera need? Ideally, it should have full transforms for internal and external sides. The internal transform dictates where in the world the camera is looking; more precisely, it is applied to anything rendering through that camera. The external transform dictates where the camera is placed in its parent context; this usually means "where it is drawn on the game canvas". Right now, Camera doesn't have a complete transform for either. Its position is external; its rotation is internal, and it has scroll and zoom properties for internal position and scale.

I'm not going to redefine the whole camera paradigm right now. But I do have some ideas for incremental upgrades. In addition, putting a Camera inside a RenderFX object provides it with a full external transform. This means that a camera can be drawn rotated at last.

Why should filters live only on the Camera? Because a camera is always involved in rendering. There's a camera inside a RenderTexture, and there's a camera inside my RenderFX implementation. Additionally, cameras in Phaser 3 can use FX. It's just a natural place for filters to reside.

After all this, I concluded that the RenderFX object was mostly just a wrapper around a Camera and a child (the game object you want to put filters over). It's necessary... but is it still a RenderFX if it doesn't even handle FX?

So after a week with RenderFX, I think I want to rename it to RenderFilters. I considered naming it after the camera, but that buries its main role: handling filters. However, it can be used to render cameras in new ways, such as rotating them.

Do the new names, Filter and RenderFilters, make sense?

A New Quandary

So with all that sorted out, I implemented a system for rendering filters. And it works! I have a minimal implementation which can apply the Pixelate filter.

There's just one problem: I overestimated the old FX system, and now my system does something different.

Here's how Phaser 3 renders a certain test, with a rotating image, using PreFX:

And here's how Phaser Beam renders the same rotating image test:

You can see that Beam has aligned the pixelation filter to the rotation of the image. But Phaser 3 has not.

Now, both of these are set to apply the FX/filter "internally", supposedly in the context of the texture/object rather than that of the world. To me, that means the axis of the filter should follow the camera view used to render the filter. If we instead applied the filter "externally", it should follow the main camera, as Phaser 3 has done.

Further, this is how I'm going to apply masks in Phaser Beam. A mask is just a filter which removes material. When it's "external", the mask will be applied in screen space; this is how masks currently work. When it's "internal", the mask will match the object's transformations; this is a much-requested feature, and in the Beam paradigm, it just works.

So I'm going to continue in this way. Does that make sense?

Coming Up

We're planning one final Technical Preview to test filters, or whatever they're called. Now that I'm actually implementing the filters, we're extremely close to completion. After that, it's time to integrate Beam with updates made to Phaser over the last year, and move forward with a full release. Very exciting! I'm looking forward to finally getting Beam, and all its enhancements to performance and quality and flexibility, into your hands.

Send us your stuff!

Created a game, tutorial, sandbox entry, video, or anything you feel Phaser World readers would like? Then please send it to us!

Until the next issue, happy coding!

When Phaser World first started in 2015, we had no idea it would still be going nearly ten years later. Yet here we are with issue 200. Yes, there was a bit of a break around 2021, but aside from that, it has been a pretty epic journey so far. In Issue One, I talked about the release of Phaser 2.4.4, and there was a tutorial telling you how to use Phaser with the Atom Text Editor (remember that?!) - oh, how times have changed. Let’s not dwell on the past. Instead, here is what has been happening recently.

🕸️ The new Phaser website is live!

Out with the old and in with the shiny, glowy new!

It took a lot of effort from the whole team, but the new Phaser website is finally live! We had been stuck with the previous design for too long, so it was time to reboot it. Designer Simon Floter took our requirements and nailed the creation of something nice and modern, which kept the characters and charm we had built into the Phaser brand over the years. Then our site developer, John Pope, turned that into the site you see today, complete with all of the backend goodness that powers it all.

We also released our brand new Phaser Examples site, which offers a much quicker way to search through our thousands of examples. It also has new features, such as downloading the entire example as a zip file, including all the source files if it’s a multi-file example.

As with all undertakings of this magnitude, plenty of work remains to be done. We need to make tweaks (especially for ultra-wide monitor users) and add new content, but overall, we’re thrilled with the changes. It would appear our visitors are, too, because our user registration rate has skyrocketed since the redesign's launch.

The new Phaser Documentation site is next up for release. Hopefully, we can announce it shortly.

🎮 Kitchen Sorting

Sort your zucchinis in this food themed puzzle game!

Kitchen Sorting is a lovely new puzzle game that challenges you to sort ingredients into correct jars before you add them to your delicious dish. Tap a jar to pick ingredients from the top, tap another jar to drop them in. Once a jar is filled, it's added to the pot and the meal gets closer to completion.

Play Kitchen Sorting

💰 Let us publish your Phaser Games

Got a Phaser game you’d like published? Get in touch!

At Phaser Studio, we’re all about empowering developers to create great games. By focusing on the framework and tools to allow this, we’ve seen thousands of games released over the years, many of which went on to critical and commercial success.

And we’ve noticed the publishing landscape is changing yet again. New platforms are opening up that introduce keen opportunities for the right games. And it’s something we’re deeply invested in.

So - if you’ve developed a Phaser game you feel would benefit from wider distribution to exciting new platforms, then we’d love to hear from you. Please email a link to your game or games portfolio to bizdev@phaser.io , and we’ll be in touch.

🌟 Solitaire Tutorial Series

Scott Westover takes on Solitaire

Scott Westover is back with another tutorial for a classic game. This time, he is building Solitaire. While Solitaire may not be the next summer blockbuster that you were planning to create, the foundational knowledge that you’ll gain while making it will allow you to create any kind of card game or deck builder in the future!

Watch the Solitaire Tutorial Video Series

Phaser Studio Developer Logs

👨‍💻 Rich

This week has been quite the rush. We kicked it off by finally releasing the new Phaser website. This was a monumental amount of work. You’d think building a new website would be pretty easy, yes? Perhaps for some projects, it is. But the Phaser site has so many moving parts and such a legacy to uphold it became a lot more challenging than we could ever have conceived. However, Simon, John, and Jean finally smashed it out of the park, and the new site went live early in the week.

Because it was so fresh, I didn’t announce it or mention it on the Phaser Discord. I just wanted to keep an eye on our regular organic traffic and try to catch issues as they popped up. Thankfully, they’ve been pretty minor. We still need to do some more layout tweaks for those psychos people who run their browsers full-screen on ultra-wide monitors 😀 (I mean, I love ultra wides, I have 3 of them side-by-side! But I never fullscreen my browser on one), but aside from this and a few other little CSS text sizing and footer tweaks it’s all pretty solid.

The result of the redesign on user conversions is pretty remarkable, too. The Phaser site has always enjoyed a good quantity of organic traffic. We average around 100k users a month and use Sentry to monitor and alert us to site issues, so if something does break, we get notified within minutes. Thankfully, nothing too gregarious happened! However, we saw a significant uptick in users registering and subscribing. We can attribute this purely to the redesign, as we did no marketing or announced the site on socials. So, that’s a massive win for everyone involved.

Aside from working on the site, I’ve also been busy with the new docs site and our partnership with Hashnode. We found a few critical issues in their service, which they promptly addressed, and we’re very hopeful that when they close off one large stopper for us in the coming days, that will be it! We can then do a final pass on the content, links, and layout and release the new Phaser docs site. It’s already much better than the current one and will have such a huge impact on developers’ lives that I cannot wait for it to be available. If all goes well, that should be this week. Fingers crossed!

👨‍💻 Francisco - Phaser Launcher

This week, I've been working on organizing the code of the Phaser Launcher tool we had from our previous draft. While it was functional, it had several issues, such as difficulties opening large folders with many subfolders. Additionally, the lack of proper state management made it harder to know which folder was selected or which tab should be displayed.

In response, I reorganized the code and researched how to optimize the loading of large folders, which led me to implement lazy loading. This improvement significantly enhances the tool’s ability to handle large datasets efficiently. I also added internal state management, allowing the tool to track which elements have been added or selected.

Moreover, I started working on implementing a tab section, which is a key feature needed for the system, similar to how Visual Studio Code handles multiple files and views. This will be essential as the tool evolves to manage multiple file operations simultaneously.

👨‍💻 Pete - Box2D

Over the past week, we've been on a whirlwind tour of optimization and refinement for our physics engine. We wrapped up the 'easy access' interfaces for the remaining joint types, giving developers useful tools to work with distance, wheel, prismatic, motor, and mouse joints. We then dove into a performance and stability comparison.

While our version showed excellent stability, we uncovered some performance issues, especially when dealing with numerous contacts. We discovered we were creating and destroying a staggering number of b2Vec2 objects per world step, triggering frequent garbage collection.

We noticed that we were still using Object.seal(). Removing this legacy safeguard doubled our performance - a pleasant surprise! We took a look at debug drawing performance, which proved to be a constant and minor factor. Comparing our JavaScript version to its C counterpart highlighted the challenges of garbage collection in JS.

This prompted us to roll up our sleeves and dive deep into optimizing object creation. We added instrumentation to track the biggest consumers of b2Vec2 objects and began refactoring to reduce run-time object creation. b2Vec2 allocation has dropped significantly from 140k-240k per world step, to < 25k. However, mobile performance is not good in longer runs, with frame rates declining substantially after an initial smooth performance of 60fps with 400 objects in a tumbling box test, which you can see below:

Looking ahead to next week, we'll continue optimization, targeting other memory-hungry elements like b2ManifoldPoint and b2ContactSim. We're also gearing up for wider testing, which means we need to polish our 'easy access' interface and create some JS-specific documentation.

👨‍💻 Can - Discord Activities Tools

After updating our Discord templates and tutorials, I dived into our new tool, to get boring tasks from the devs as much as we can. The biggest struggle we identified is dealing with tunneling the project from the local, not having assets loaded properly, connecting client and server on the Discord itself.

It's my first time going with Tauri, so lot's of tinkering, research and of course failures going on behind of the scenes. I've came up with minimal working solution as you select your project folder, once its selected, the app will read your package.json to catch npm script commands in order to execute with just one click and it will filter the tunneling url you will need.

Idea is great, yet execution is not that great yet! Once the quirks are solved, we will be going much faster for a possible build! You can get the grisp of the idea from the app's screenshot, though it might change all over too, so don't look too close!

Till next week, keep your pixels quality everyone!

👨‍💻 Zeke - Phaser Docs

Hello and welcome to another weekly update on Phaser Documentation:

1. Sound. I discovered Web Audio API actually has an analyzer node feature that enables creation of audio visualisations. With some work, it’s entirely possible to make procedural rhythm-based games like Osu!, Beat Hazard or Piano Tiles in Phaser. Besides the usual audio playback and volume control, you can also play around with spatial audio to give a sense that some sounds are coming from a specific direction.

2. Mesh. This Game Object allows you to add simple 3D objects into Phaser games. Import your 3D .obj files, apply some textures to it and voilà! Well, checkout the examples mesh folder here for more details. If you really want to try making a full fledged 3D game in Phaser, check out Enable3D.

3. Animations. One feature you may want to consider using is chained animation where you specify the animation that plays after an animation sequence ends. Think of using chain animations to create smooth transitions between different Game Object states such as from walking to running to jumping.

4. Timer and timeline. Timers help you keep track of time, trigger time-based events and create complex timed sequences. One interesting feature is called time scale where you can manipulate a given time by scaling up or scaling down to increase or decrease the rate of change in time. Check out this example in the Phaser labs.

5. Display List. Used to control the order that Game Objects are rendered in a Scene. A common way to use the Display List is to add Game Objects into Containers so it is rendered as a layer. Use this to sort the rendering order of different game elements such as the background, in-game objects, user interface and overlay menu.

6. Phaser.Utils.Array. While JavaScript already comes with its own set of methods, Phaser adds on additional functionality commonly used in games. Some features I’ve found most useful are Shuffle, GetRandom, RemoveBetween, Swap and CountAllMatching. No more writing lines of code to create such features, Phaser does it in just a single line. Example: Phaser.Utils.Array.Shuffle(array) automatically shuffles all items in the given array. Check out our existing docs here and examples here.

Tales from the Pixel Mines

October 7th, 2024 by Ben Richards

This week, I finished the DynamicTexture revamp, and finally got started on the new FX/masks system. We'll look at each of these in a bit more detail.

DynamicTexture

The finalized DynamicTexture (and RenderTexture) have a diminished instruction set. I've removed any need to manage render state; it all happens automatically now. Just call render() and it executes all the commands you've queued up.

The drawing commands are now reduced to the following:

• stamp draws a configurable texture frame.

• repeat draws a texture frame using a spare TileSprite.

• draw draws a texture frame, game object, Group, DisplayList, or array.

• erase is like draw but it uses the ERASE blend mode to erase holes in the texture.

• clear clears the texture.

• fill fills a rectangle with color.

• render executes all commands in the queue.

Several of these commands just draw texture frames directly, without creating a dedicated game object. I've changed the origin of texture drawing to make defaults more consistent. The origin defaults to (0.5, 0.5), the middle of the texture, instead of the top-left. This may change the way existing DynamicTexture uses render. It is now consistent with other game object positioning.

Several other commands have been removed. Now you don't have to worry about batching. Everything performs at maximum efficiency. This will also affect existing uses of DynamicTexture.

If you want to use DynamicTexture, either in a future release or if you routinely look at working branches of the Phaser repo, you'll need to make a few changes. Most of the removed commands can just be replaced with draw. If you're drawing a texture frame, and its coordinates have changed, you should be able to get the same results with stamp(texture, frame, x, y, { originX: 0, originY: 0 }). This will set the origin back to the top-left and get the previous behavior.

These revisions have made DynamicTexture more efficient. For example, Phaser 3 renders a DynamicTexture with two draw calls: one to render it to a temporary framebuffer, and another to flip it upside-down in the destination framebuffer. The new Phaser Beam renderer will use just one draw call, and one framebuffer, making it nominally twice as efficient! This doesn't necessarily mean twice as fast, because the repeated operations are in WebGL and typically run much faster than CPU code. And it doesn't mean memory usage is halved, because temporary framebuffers can be recycled, so there are typically only a few being passed around. But it does mean things are better.

RenderFX

I'm now working on the RenderFX object. This was previously referred to as "Box" until Rich reminded me that a box could be anything. I'm calling it RenderFX now, because that puts it next to RenderTexture, and that might help users associate the two types.

A RenderFX is a wrapper around another game object. It puts it into a framebuffer, and applies FX to it. This replaces the existing FX component on game objects. This does make it slightly more awkward to set up an object with FX; you need to make a RenderFX and put the object into it (which I'm making simple with automation functions), and you need to consider input and physics for the RenderFX instead of the original object.

However, this makes the number of RenderFX more clear. Because each RenderFX consumes resources (a few temporary framebuffers, and a few draw calls), it's a good idea to know how many you have in your scene. You can probably have hundreds without losing performance, but you do want to be careful. FX do lots of different render operations, so they are performance intensive.

Removing FX from other game objects also eliminates some inconsistencies. For example, a Container or Layer renders a list of child objects. But how do these children blend with other objects in the scene? Well, that depends on which framebuffer they're drawn to. And that framebuffer depends on whether FX is active on the collection.

Here's a diagram showing how things can differ. I've used a DynamicTexture to keep things simple, but it uses a framebuffer just like the FX system.

In the first example, two sprites are drawn with additive blending. They combine with the background and with each other.

In the second example, two sprites are drawn on a DynamicTexture. They do not have additive blending, so one overlaps the other.

In the third example, two sprites are drawn with additive blending, but this time they're drawn on a DynamicTexture. They combine with each other, but do not combine with the background, because the DynamicTexture itself does not have additive blending enabled. When they are drawn to the DynamicTexture (which has a transparent black background, thus additive blending has no effect), they turn into texels and have no memory of what blending mode was used to draw them.

In the fourth example, two sprites are drawn on a DynamicTexture. They do not have additive blending, but the DynamicTexture does. Again, one sprite overlaps the other, but now they combine with the background. This is because the finished DynamicTexture adds to the background.

In Phaser 3, a Container draws directly to the background (as in the first example). Unless it has FX enabled, in which case it draws to a framebuffer (as in the third example). As you can see, this will produce different results! We don't want that to happen. In Phaser Beam, a Container or Layer will always draw to the background of the current DrawingContext. You can put it in a RenderFX to use a new DrawingContext with a new framebuffer.

RenderFX provides certainty around compositing. If something is inside a RenderFX, it will be drawn to another framebuffer. If not, it's drawn to the current drawing context. (There may be exceptions, such as disabling the framebuffer for a RenderFX if you want an object that only displays FX sometimes. This will be under your control, and remain predictable.)

This is why you want to understand where the framebuffers are in your game! They make a big difference.

Next Week

More work on RenderFX! I've worked through a whole lot of logic to figure out the best approach, and I'm in the middle of putting things together. Once this gets going, it'll be amazing.

Let us know what you think of all this! I'm trying to keep things familiar, but we had to change a few pieces. I think it will all work much better when we're done.

Submit your content

Created a game, tutorial, sandbox entry, video, or anything you feel Phaser World readers would like? Then please send it to us!

Until the next issue, happy coding!

It’s been another busy week in the Phaser Studio offices. We’ve got a new release of Phaser Editor, great new tutorials and case studies to read, and, of course, new games to play. Plus, the team has been hard at work on lots of great projects - which you can catch up on in this week’s extensive Developer Logs.

🎮 Astrogon

Play solo or against the world in this hardcore precision platformer.

We sadly missed this awesome game upon release, so we’re covering it now! Created by Kosmoon Studios, Astrogon is a dynamic arcade game in an intergalactic synthwave universe. Jump and dash your way between walls and obstacles. Avoid touching what will kill you, and reach the teleport portal. Get precise and strategic, or die. Then, create an evil challenging level for the rest of the world on Steam, Google Play, or the App Store.

Play Astrogon

🌟 Phaser Editor 4.5 Released

The latest version of Phaser Editor includes Monaco built-in, an updated JavaScript ESM template, refactored Script Nodes and new drag-drop project support.

Today we published our weekly release of Phaser Editor. In 4.5 we continue to polish the details, to make the editor a simpler and more powerful tool for all users. This time we've got a new integrated editor, vastly improved handling of JavaScript ES Modules, new updates for Script Nodes and you can now even drag a whole project folder onto the Editor icon/window.

Read the full release notes for details about all of the improvements.

Subscribers can update to this version immediately. Just grab it from your account's Downloads page or pick ‘Check for Updates’ within Phaser Editor. If you don't have a subscription, we offer a 30-day trial.

🚀 How Phaser is used at OpenForge

Solving accessibility challenges with Phaser.

Phaser is a natural choice for games, but you can also use it for apps. OpenForge, a top-rated mobile app development company specializing in mobile and web solutions since 2016, uses Phaser to build its product, StartupWars. OpenForge kindly agreed to talk about their experience using Phaser.

Read the full OpenForge story

💎 Creating Phaser games for Rune

Learn how to easily make a multiplayer Phaser game that can be enjoyed by millions of players on Rune.

Phaser is perfect for single-player games since physics and collision happen on the client side. But what if you want to create a multiplayer game? Enter Rune, a social gaming app with millions of people playing HTML5-based games together across iOS and Android.

Their mission is to make mobile gaming more social and enable indie game developers to get their games into the hands of millions of players. By leveraging the Rune SDK, developers can add multiplayer capabilities to their Phaser games and get access to tons of new players by adding their app to the Rune platform. Now that's a win-win!

Read the Phaser + Rune Tutorial

🎥 Twitch Stream Hackathon

Use your Phaser skills to build an app for streamers.

Twitch has announced a new hackathon, this time centered on building an app for streamers to collaborate with each other, their community, and enhance their streams. The goal is to build an application or Twitch Extension that uses Twitch authentication for application users, and the Twitch API or EventSub. For Phaser developers, two of the three submission categories stand out.

Read the Twitch Streamer Hackathon article.

👻 Ghosts in the Machine

A thrilling, puzzle-based adventure that blurs the line between the steampunk world and the supernatural.

The FocusFire team has released a great new Phaser game for GBJAM 12, a jam about making gameboy inspired games. In "Ghosts in the Machine," you find yourself as a restless ghost haunting a lonely mansion. Your mission is to scare away visitors as you outwit them on every stage with unique machines, traps, and, is that phonograph?

Play Ghosts in the Machine

Phaser Studio Developer Logs

🧑‍💻 Rich

Last week, someone emailed Phaser support, asking what the status of Phaser v4 was. That's a valid question. Even though I have covered this quite a few times now, there is still a lot of material out there talking about v4 development from several years ago. So I figured I'd use my reply as my entry this week so everyone can be crystal clear on what is and isn't going to happen in Q4 2024:

As you know, the current version of Phaser is v3.85.2. We have spent all year working on our brand-new renderer, Phaser Beam. This was a complete rewrite from scratch, built in a modern way, with outstanding performance and a reduced memory footprint. We expect to finish development of this within the next month. You can track the development of Phaser Beam through all of our weekly Phaser World issues. We've been writing about its features and evolution all year, so there's plenty of juicy meat to pick from the Dev Log bones if you're interested.

Once the initial version of Phaser Beam is finished, we plan to merge it with Phaser v3.85. We will make other improvements at the same time, but the core API will remain largely the same. The improvements will nearly all be rendering-related, and this merge will form the Phaser v4.0.0 release.

After Phaser v4 is out we will focus on what can be done to modernize the API, i.e. move fully to using ESM Modules, ES6 classes, etc. But our priority is getting our powerful new renderer in place, and to us, that is Phaser 4.

Anything you may have read in old Dev Logs from 2021/22 re: Phaser 4 is no longer applicable. While we could have carried on down that path, it made no sense. It would have forced every single Phaser developer to start again from ground-zero and would have been entirely incompatible with Phaser 3. Instead, we are favoring an incremental upgrade roadmap rather than a 'nuke it all from orbit and start afresh' approach, which would have benefited no one.

I hope everyone reading this can clearly see how busy we've been this year. From constant updates to Phaser and Phaser Editor, to stacks of new templates, tutorials, a brand new renderer and a new physics system. And we're not done yet. The new docs site is imminent, as is a brand new web-site - and of course the release of Phaser v4. It's been quite the journey so far, but stick around because things are about to get really interesting 😊

🧑‍💻 Pete - Box2D

A short one this week: After finally fixing the bug that has been plaguing the box2d conversion (turned out to be 8 separate bugs spread through-out the code... or maybe it was just the last one, I wasn't going to put the other 7 back in to verify!) the project is moving forwards again at pace.

I've been expanding the testWorld with new features and more and more objects to stress test the code and get an idea of where the strengths and weaknesses lie. It's very good at joints and objects including compound objects. It slows down significantly when you get a large heap of things all touching but not asleep.

I believe this is because the color graph code was part of the threaded system and it's been disabled where it hasn't been outright removed. I think the concept of colour groups is a brilliant optimisation, and there's no reason why it wouldn't work to a worthwhile degree on a single thread and without SIMD instructions. We should definitely look at implementing something similar. I don't recommend wasting any more time trying to modify the original though, the SIMD instructions and support code is incredibly tricky to remove and it is also tangled in with the multi-threading support.

I've been converting all the bespoke code for each effect into a set of tidy wrapper functions. That is going smoothly, and there are many more we could add which will add value for users... we'll probably have to triage them eventually, although it could be made into a longer-term support effort based on request frequency.

At the end of the week I restored a bunch of the older demos so they will work with the new helper functions. There's a handy 'switch' at the bottom of main.js now which lets us switch between them. I also added an 'image circle' and an 'image capsule' draw function to the debug draw code. This lets us load images and fit them to those shapes, for more attractive looking demos. See the image below for an example.

🧑‍💻 Francisco - Phaser Launcher

This week, I’ve been focusing on a new project that we believe will simplify the onboarding process for anyone interested in Phaser. The goal is to create something that lowers the barrier to entry, making it accessible for developers of all skill levels.

As part of this initiative, I’ve been testing Tauri’s potential to develop a lightweight editor. The idea is to allow users to load a folder directly into the editor and easily modify any JavaScript files they find. It’s a small but powerful tool that could greatly improve the workflow for developers working with Phaser.

The next step we’re aiming to test is generating a server with hot reload functionality, if possible. This would allow the tool to launch a small template with Phaser already installed, ready to work right out of the box. Thanks to everyone, and stay tuned to learn more about this exciting new tool!

🧑‍💻 Zeke - Phaser Docs

Hello and welcome to another weekly update on progress on the new Phaser Documentation site. This week I finished the following new sections:

1. Maths functions

The documentation includes different aspects of mathematical operations and utilities available. Here’s a brief summary:

• Basic Functions : Functions built on top of native JavaScript Math functions with its own Phaser.Math namespace to prevent conflicts. Used to calculate Average, Difference, Factorial, whether a number is even (IsEven) or is a power of 2 (`Pow2).

• Minimum, Maximum : Functions to calculate a range of values between the minimum and maximum range.

• Round To : Various rounding methods like CeilTo, FloorTo, RoundAwayFromZero, and RoundTo.

• Distance : Calculate distance between points, including specialised methods like Chebyshev and Manhattan.

• Angle : Calculate various angles and perform conversions between radians and degrees.

• Random : Generate random values and vectors.

• Color : Convert between different color formats, adjust color properties, and generate random colors.

• Vector: Create and modify 2D, 3D and 4D vectors.

• Curve : Creating and modifying curves and paths including lines, circles, ellipses, arcs, splines, and beziers.

2. Geometry

Phaser comes with an extensive set of Geometry classes which are used internally by the physics and input systems. This document includes:

• Geometry Classes : Listed the geometry classes on offer, including Circle, Ellipse, Line, Point, Polygon, Rectangle, Triangle, and the Mesh class.

• Geometric Operations*: This includes:

• Containment Checks : Check if a point is contained within various shapes.

• Nearest Point : Find the nearest point on a shape to a given point.

• Area and Perimeter : Calculate the area and perimeter of shapes.

• Transformation** : Transform shapes by scaling, rotating, and translating.

• Intersection Functions : Test whether one shape intersects another.

3. Graphics

How to draw primitive shapes in your game. Primitives include rectangles, circles, polygons, lines, arcs, curves and others. Graphics can be drawn using a specific line style, fill style or both. Here is a full list of shapes that can be drawn:

• Arc : Draws an arc shape with a specified start and end angle.

• Circle : Draws a circle shape.

• Curve : Draws a curved shape.

• Ellipse : Draws an ellipse shape.

• Grid : Draws a grid based on the width, height, cellWidth and cellHeight.

• IsoBox : An 'isometric' rectangle where each face has a different fill color.

• IsoTriangle : An 'isometric' triangle like a pyramid where each face has a different fill color.

• Line : Draws a line between two points.

• Polygon : Draws a polygon from a list of points.

• Rectangle : Draws a rectangle shape.

• Star : Draws a star shape with 5 points by default. You can control the number of points, the inner and outer radius.

• Triangle : Draws an triangle shape.

4. Tweens

Tweens create smooth, time-based changes to object properties over a given duration of time. The documentation shows the following:

• Creating a Tween : How to create tweens, set target properties, easing functions, duration, repeat, yoyo, and other configurations. Tween Property Expressions : Shows different ways to set tween target properties, including direct value assignment, relative value changes, random value generation, using an array of values or setting object properties.

• Tween Callbacks : Lists events where callback functions can be triggered.

• Tween Configurations : Details properties that can be used in tweens such as delay, yoyo, ease, duration and more.

• Easing Equations : A list of available easing functions that affect how a tween progresses.

• Tween Controls : Methods to control tweens include: pause(), resume(), complete(), stop(), play(), restart(), seek(amount), remove() and destroy().

• Tween States : Use isPlaying() and isPaused() to check current tween states.

• Tween Chains : Create and manage tween chains by adding, removing, pausing, resuming, and restarting the chain.

• Tween Events: A full list of events dispatched throughout the lifecycle of a tween.

🧑‍💻 Arian - Phaser Editor

Hello!

A new week, a new Phaser Editor release! Check out Phaser News because a new version of the editor may be available. For this latest release, we've focused on improving the experience for those who don't have much experience with web development yet. What does this mean? We've updated the project templates to be based only on plain JavaScript. These templates now use modules, which follow how JavaScript is programmed today.

Something else we've done to make JavaScript newbies more comfortable is to incorporate a more advanced JavaScript editor, based on Monaco, the main component that Visual Studio Code uses in its editors. With this update, you'll have a decent set of features to code your game directly in Phaser Editor. However, if you want to go a bit further and use a more advanced toolchain, such as web bundlers, TypeScript, etc... it would be best to use Visual Studio Code. But if you're looking to get started with plain JavaScript, you're covered with Phaser Editor!

Something else we've added this week is a new way to open a project in Phaser Editor. This involves dragging your project folder onto the editor icon to open the project. This works on macOS only.

Another alternative is to drag the folder onto the editor's start page. This works for all platforms.

Keep in touch!

🧑‍💻 Can - Discord Activities

Kia ora!

Exciting times — Discord has made Activities public for all! This opens up a fantastic opportunity to bring your Phaser games directly into the Discord ecosystem, for the millions of players. In response, we've updated our templates and working on an app to simplify publishing your games as Discord Activities. The biggest update was a breaking change for the previous versions, which is about setting our url paths as "./proxy" for all HTTP requests we make. All our templates are updated and works in local too.

We can't wait to see you all coming up with cool games that reaches out to millions, a new era for the HTML5 games!

We have #discord-activities channel on our Discord. Come and join us, share your inspirations, issues or how can we help you to make your workflow easier!

Tales from the Pixel Mines

September 30th, 2024 by Ben Richards

This week, I've been trimming DynamicTexture down to size. Its implementation under Beam will have a few changes, which I'm hoping will be convenient, but it's still worth explaining them.

• Command Buffer

• Projection Matrix

• Everything is GameObjects

• Repeat is TileSprite

• Camera Enabled

• Canvas Too

• Texture Trimming

• 50% Off

DynamicTexture is an ordinary Texture, with built-in drawing tools so you can edit it at runtime. This is a great way to render accumulating visuals in a scene, such as damage on a battlefield, breaking holes in windows, or painting in the game world.

This post is mostly about WebGL rendering, because that's the focus of the new Beam renderer.

Command Buffer

The DynamicTexture now uses a "command buffer" similar to Graphics. Instead of rendering whenever a drawing command is run, it puts the command in a buffer, along with all its parameters.

To execute the command buffer, call DynamicTexture.render(). This will immediately run all buffered commands. This is more efficient than piecemeal rendering, because it is almost exactly the same as a regular render pass. This allows us to use the same rendering systems, with all the optimizations and capabilities that entails.

The main difference is that there are no camera effects (background color, flash, fade, shake) in a DynamicTexture. These generally make no sense, because a DynamicTexture isn't animated.

Performance of the command buffer render is excellent. It works just like regular rendering, so you can estimate a rendering budget based on what you're rendering.

Projection Matrix

The projection matrix is a piece of linear algebra used to map from game world coordinates to WebGL texture coordinates. This is necessary because WebGL is upside-down compared to how we normally think about screen coordinates!

2D game world coordinates are [0, 0] at the top-left, and might extend to [1280, 720] at the bottom-right.

WebGL texture coordinates are [0, 1] at the top-left, and [1, 0] at the bottom-right. So [0, 0] is at the bottom-left. It's flipped upside-down compared to the game world! Also, it's always square, even if it's drawing an area with a high aspect ratio.

(WebGL clip coordinates are another thing again. These are how WebGL draws to the screen. Here, the top-left is [-1, 1], and the bottom-right is [1, -1]. Confusing? Yes! Phaser does this all in the background for you.)

The projection matrix lets us draw in WebGL without worrying about stretching things into a space 1 unit across. We can keep coordinates in a sensible world system, and convert them to WebGL space in the vertex shader.

Sound complicated? It is! We had to make some decisions about which space to prioritize. Here's what we've settled on for Beam:

• All textures and framebuffers have the top-left at [0, 0] in WebGL coordinates.

• The main game canvas has the top-left at [0, 1] in WebGL coordinates.

This means that texture coordinates are in an intuitive top-left system.

It also means that everything is upside-down from WebGL's perspective, so when rendering to the main game canvas, we flip the projection matrix upside-down to put it right-side up. As a side effect, all textures appear upside-down in debug tools. This doesn't matter because the projection matrix corrects everything.

This is a new assertion for Phaser in Beam. Previously, this was mostly true: textures were upside-down, and the projection matrix is upside-down for the game canvas. But some systems didn't work that way. We're trying to make things simpler, so we're unifying coordinates. This could come back to bite us when I start work on FX shaders, so things could change; but I hope it works out.

Everything is GameObjects

Unification allows us to use standard rendering technology in more places. This brings us back to DynamicTexture, where we want to draw various items into a texture via a framebuffer.

Previously, we used various Pipelines to render textures to the framebuffer. These followed their own logic, separate to standard rendering.

With the command buffer, we take textures, apply them to a spare Stamp object, and render them with the regular rendering systems. This sounds simple, but it has some far-reaching consequences. Now, anything that can be rendered can also be rendered to a DynamicTexture, and will render exactly the same way.

This is part of a general drive towards consistency. Things should work the same wherever they are in the game.

Repeat is TileSprite

A DynamicTexture has the repeat method, used to repeat a texture across a region. Because everything is GameObjects, we now render this by setting up a spare TileSprite object and rendering it.

This means the repeat method can take some extra parameters, allowing it to do everything TileSprite can do. The texture can be scrolled, scaled, and rotated. (Rotating TileSprites are new in Beam. Everything synergizes.)

DynamicTexture Camera Enabled

DynamicTexture has always had a Camera. This was originally just for rendering, and didn't actually do anything. Now, the camera can transform, which gives you more freedom to draw as you want. Note that camera effects are not rendered, and Stamp objects (including all drawing operations with raw textures and frames) are unaffected by camera transforms.

Canvas Too

All the changes to DynamicTexture work in the Canvas renderer too. This took a while to get working, mostly because I forgot that I was clearing my test texture, and spent too long trying to figure out why nothing was rendering. But the code was all running perfectly.

Texture Trimming

Here's another reason why consistency is good: it means we can keep complicated things to just one place, reducing the risk of mistakes.

Case in point: texture trimming was handled differently between Textures and GameObjects in DynamicTexture. But now that everything is GameObjects, the differences have disappeared.

What is texture trimming? It's a space-saving measure taken by texture packers. When packing several sprites into a single atlas, empty space around the edge of a sprite can be removed, and stored in the atlas data. When we come to use the sprite, we can make the GameObject the size of the original sprite; and then render just the smaller frame. The empty space around the edges is implicit.

Unfortunately, this means that a trimmed sprite doesn't have a single size. Here's a screenshot of me analyzing one particular example:

You can see how the trimmed region (yellow) is offset from the original region (red). Other sprites overlap the original region, but because of trim, we don't render these overlaps.

But if we use the wrong size to render the image, it will appear somewhere we don't expect. For example, DynamicTexture.draw(texture) and DynamicTexture.draw(gameObject) had different results, even though they were using exactly the same texture:

However, because everything is GameObjects, in Beam they both render with the original frame margin:

This is a change from the way things originally worked, but it provides more consistency. I hope that makes things easier to work with!

50% Off (Functions)

We've added the new render method to DynamicTexture. However, because everything is GameObjects, we've also removed a whole lot of functionality from the class. (And by extension, those functions have also been removed from RenderTexture which wraps DynamicTexture.) Right now, it looks like about half the functions have been removed.

These functions were mostly batch-oriented. They allowed you to manually start batching, add objects to a batch, and render a batch. However, why should you need to do that? Batching is pretty technical, and as the engine designers, we should take care of that for you. So we did!

And that's why I went to all that effort over the course of this week. Now, all you have to do is order a DynamicTexture to draw some things, and we'll take care of the rest. As it should be.

Coming Soon

I've still got some tidying up to do on DynamicTexture. After that, I'm finally moving on to the Box, my new design for handling FX, masks, and other framebuffer tasks. This should bring more of that delicious consistency to Phaser Beam. It's taken a while, but we're finally getting there, and I'm excited to put everything together!

Submit your Content

Created a game, tutorial, sandbox entry, video, or anything you feel Phaser World readers would like? Then please send it to us!

Until the next issue, happy coding!

Welcome to another issue of Phaser World! It’s quite incredible to think that we’re closing in on 200 issues. That’s an awful lot of content over the years. And this issue is no exception! We’ve got videos, exclusive new tutorials, games, and, of course, the Developer Logs.

🎥 Phaser 2024 Games Showreel

We’ve released another new video onto our fledgling YouTube channel. This time, a showreel of Phaser games to give you an idea of what it’s capable of when placed into talented hands!

🎮 Hawaii Match 5

Enjoy over 4,000 levels of this addictive tropical puzzle adventure.

SoftGames has released their latest game, Hawaii Match 5! Set in the stunning landscapes of a tropical paradise, this puzzle game will take you on a journey through dreamlike island scenes, packed with vibrant fruits and flowers. With over 4,000 levels, players are challenged to match five or more symbols to achieve goals and earn stars, all while managing limited moves.

Play Hawaii Match 5

🌟 Phaser Editor 4.4 Released

The latest release includes enhanced Go To support, tighter integration with VS Code, built-in Live Chat and has been updated for Phaser v3.85.2

It was only last week that we announced the 4.3 release, but we’ve added so many cool new features that we pushed out 4.4.

Included are new UI improvements, the ability to see animated sprites in real-time in the Scene Editor, buil-in Live Chat support (with a human, not a bot!), better Visual Studio Code integration, and updates for Phaser v3.85.2, which was also released last week.

Read the full release notes for details about all of the improvements.

Subscribers can update to this version immediately. Just grab it from your account's Downloads page or pick ‘Check for Updates’ within Phaser Editor. If you don’t have a subscription, we offer a 30-day trial.

🚀 Phaser Enterprise Plans

Does your company use Phaser as part of its development process? Then, you may want to consider a Phaser Enterprise plan. Benefits include:

• Access to your own private Slack / Discord channel with Phaser staff for direct technical support

• 30 minutes worth of 1:1 video calls per month for support or pair programming

• Help porting your game/s from other platforms or systems to Phaser

• Help with upgrading older Phaser 2 games to Phaser 3

• Access to Phaser Editor, with SSO and on-premises versions available

Interested? Please email Richard Davey (rich @ phaser.io) with further details about your company and we can take it from there.

💻 Making Phaser games for iOS and Android

Read this great exclusive new tutorial on using Phaser with Capacitor

We have just published a new tutorial where you'll learn how to deploy your Phaser game to iOS and Android by wrapping it with Capacitor. We use an existing game, Starshake, as an example.

The tutorial features:

• Integrating Capacitor into your project, a cross-platform native runtime for web apps, to easily transform your Phaser game into a mobile app.

• Changes to be more mobile-friendly, including touch controls, resizing the game for mobile devices, and adding safe area support.

• Setting up live debugging on Android or iOS devices to display game changes immediately.

• You can bring your Phaser game to mobile in just a few steps.

Read the tutorial here

💻 3 New Tutorials!

Here are three new tutorials from the community.

Making a game in 1 month with Phaser and AI: Oleg Shabrov made a new take Vampire Survivors in a very unique manner, without a single line of JavaScript code!

Device rotation prompt in JavaScript: A small library that solves a big problem!

Connect Four Tutorial: Phaser YouTuber Scott Westover returns with a classic puzzle game!

Phaser Studio Developer Logs

👨‍💻 Rich

Work on the new Phaser documentation site continues to take priority. This involves collating together a huge amount of resources, ensuring they are properly formatted and then generating the correct front-matter for every single file. It’s a huge task but the 3 of us are making good headway.

As I mentioned last issue, we’re using the Hashnode Docs service. Their system works by having TypeScript configuration files in each folder. These files are similar to JSON files, in that they map out the contents of the folder, the slugs, the sidebar content, nav links and so on. Working with them is quite tedious though. Not as tedious as working with JSON! But still lots of manual copy/paste work. It’s also quite easy to accidentally make a typo that leads to broken links or conflicting slugs.

As developers so often do when faced with a daunting task, I coded something to help. This took the form of a library that allows us to generate these config files programmatically. It also checks to ensure the files exist, have the correct extensions, have properly aligned slugs and so on. In short, we get to code the structure of our docs like this:

import { Export, Guide, Link, Page, Section, SideBar } from './HashnodeDocs';

Guide('Phaser', 'phaser');

SideBar('Phaser v3.85.2', 'v3.85.2', true);

Section('Getting Started', [
  Page('what-is-phaser'),
  Page('installation'),
  Page('set-up-dev-environment'),
  Page('project-templates'),
  Page('make-a-game'),
]);

Section('Concepts', [
  Page('scenes'),
  Page('game-objects'),
  Page('cameras'),
  Page('events'),
  Page('factories'),
  Page('plugins'),
]);

Link('Phaser Discord', 'https://discord.gg/phaser');
Export();

Which, honestly, is a lot easier for us 😊

I also finished and published Phaser v3.85.2 last week. There wasn’t much in it, mostly just fixing a few high priority issues, but it was important to get it out fast.

We will stay on top of issues reported in GitHub but our focus, once the docs site is live, is building Phaser v4 with the new renderer inside of it. As I’ve said before, we want to keep the API as close to v3 as we can to ensure a seamless transition. After all, we’ve spent a year working on our incredible new renderer, so we want as many devs to use it as quickly as possible without having to abandon v3 projects to do so. Yes, we still want to transition to ES6/ESM internally, but it’s not essential for us to do this before getting v4 out.

👨‍💻 Francisco - Phaser Docs

This week has been very productive in the development of scripts that automatically generate the Phaser API. One of the biggest improvements has been the restructuring of the code, moving from a rough draft (hardcode) to a much more organized and modular structure. This has not only made future modifications easier but also made the code more maintainable.

A key achievement was enabling the script to generate its own phaser.json file. This step is crucial as it allows me to keep the documentation automatically updated without having to manually regenerate this file using an external tool.

Additionally, I grouped functions, constants, and events, which significantly reduced the size of the documentation. In fact, the documentation size was reduced from about 50 MB to just 18 MB, making it lighter.

I also worked on the overall organization of the code, separating functions and migrating the rough draft JavaScript code (hardcode) to TypeScript, improving both readability and scalability of the project.

👨‍💻 Arian - Phaser Editor

Hello friends! Last week we released a new version of Phaser Editor. It was a lightning release, which we worked on for about two weeks. The main feature of this new release is a new communication channel between editor customers and the Phaser Studio team. You will find an icon to open a chat window on the top right. In this window, you can contact us and we will respond as quickly as possible.

In addition, we implemented some other features such as a button to launch Visual Studio Code. If you press this button, Phaser Editor will open the project folder in Visual Studio Code, and if you are editing a scene or user component, the code for it will open in the popular Microsoft editor.

We also improved the dialog to open a scene. This improvement consists of, first, showing a button to launch the dialog, and second, we added a lot more content to the dialog, so that now you can quickly access not only scenes, but also user components, animations, and asset packs.

This week we will be working on another lightning release of the editor, mainly dedicated to simplifying project templates and the use of script nodes.

See you soon!

👨‍💻 Zeke - Phaser Docs

Hi there. Here’s the documentation I’ve been working on the past week.

Camera: Did you know that Phaser has some amazing camera features available for use in your games? Check out our code lab for examples here

• Multiple cameras. Having multiple cameras opens up the possibilities to create in-game minimaps and split screen games. From Defender (1981), Diablo, Age of Empire, these games include a minimap to help players keep track of their current position within the game world. Other games like Sonic the Hedgehog 2, Rock n’ Roll Racing and Mario Kart show how multiple cameras can make local co-op games fun.

• Camera follows the player. Movement and zoom effects. Cameras can move (pan), zoom and even trigger shaking effects.

• Camera fade in / out for scene transitions. Round pixels for crisp and clean pixel art games.

• Shader effects. Check out the link above for all our current examples.

Loader: The Phaser Loader is responsible for loading all external game assets. Here’s a complete list of file types that you can use in-game: audio, binary, glsl, html, htmlTexture, image, json, script, spritesheet, svg, text, tilemapCSV, tilemapJSON and xml.

Events: Events send signals to other systems that are listening to act on. For example, if the player clicks their mouse on your game, that will internally emit a sequence of events within Phaser. Or if the Loader finishes downloading a file, that will emit related events. The documentation provides examples for adding/removing event listeners, triggering events and creating custom event emitter classes.

Renderer: The Renderer draws everything you see on the screen. Phaser comes with 2 built-in renderers: Canvas and WebGL. Phaser automatically queries the browser to see if it supports running WebGL to create a WebGL renderer, otherwise it uses Canvas.WebGL advantages:* Lights, shaders, sprite effects, tints Mesh, Nine Slice, and Rope game objects Better performance, usually Canvas 2d advantages:* Extra blend modes Better performance for Canvas Texture and Text Smaller build * Slightly faster startup and canvas resizing

Caching: The Phaser internal Cache stores downloaded files for quick access. Files are stored using unique string-based keys. If the file uses the Loader, it will use the same key to store it in the Cache. The Phaser Cache is separate from the browser cache and only persists during the game session.

Textures: Create and store textures with the Texture Manager. A Texture is made up of one or more Frames. Frames allow you to split a single Texture into different sections. Sprites can be assigned to show a texture with different frames at any time. Phaser supports Sprite Sheets with multiple frames of the same size or Texture Atlases that use a single large image that combines multiple images and data to create the frames for use. Phaser also allows Dynamic and Canvas Texture generation that can create Textures at runtime.

Arcade physics: Used to create 'arcade' or 'retro' style games, Arcade Physics is a lightweight physics system that can only handle rectangle and circle collisions. It is ideal for platformers, top-down games and puzzle games as it’s very fast and easy to use, with lots of helper functions. If performance is your primary concern, consider using Arcade Physics.

Matter physics: Based on an open-source third party physics library, Phaser comes bundled with a customised version of MatterJS. Matter Physics provides a more advanced 'full body' physics system and can be used to create complex physics shapes, polygons and compound bodies. It is also able to simulate behaviours that include constraints, joints, springs, soft body dynamics and more.

Tales from the Pixel Mines

September 20th, 2024 by Ben Richards

Last week, I talked a lot about implementing new framebuffer rendering techniques. Long story short, FX and masks become the domain of something called a Box, and framebuffers are only seen in a Box and DynamicTexture.

This week, I set about implementing those framebuffer systems. Much of this is still in progress, but I do have one thing to show off: the Stamp GameObject.

The Stamp GameObject is similar to an Image, except it ignores camera transforms. It doesn't just set them to zero - it doesn't even calculate camera transforms. This is different to the scrollFactor properties of other GameObjects, which reduces the amount by which camera scroll transforms the object. The Stamp also ignores camera zoom and rotation.

This is visible in the following image. Here, the background doesn't scroll as the camera moves, to create the impression of parallax; but it still rotates and zooms. But the bar at the bottom of the screen is a Stamp, so it doesn't rotate or zoom.

Stamp also works properly with lighting. Lights are calculated in screen space, so the Stamp's position on the screen lines up perfectly. In the following example, we've moved the camera many screens away from the origin, but the car (a Stamp with a normal map) is still lit properly.

A Stamp has some limitations, however. It is just an Image. It can't play animations like a Sprite, or display repeating textures like a TileSprite or Tilemap.

To create complex camera-independent elements, such as an involved HUD or a background moving independently from the level, your best option is to create a whole new Scene and render it before or behind the game world. Cameras are not linked between Scenes, so you can build a HUD and leave it in place.

Light does not pass between Scenes, though, so a more complicated option is to use a Container which follows the camera in the same scene, and put your HUD in there. Like most things in game development, there are many ways to get results.

Of course, the main purpose of the Stamp is to simplify drawing a DynamicTexture. I'm in the middle of reorganizing the logic for this system now. Next week, we'll hopefully have a lot more to report!

Submit your Content

Created a game, tutorial, sandbox entry, video, or anything you feel Phaser World readers would like? Then please send it to us! Email support@phaser.io

Until the next issue, happy coding!

Welcome to issue 197 and a whole lot of fresh content this week. We will keep tweaking the layout as we get used to our new home on Hashnode, but overall, we’re really enjoying the expanded features this format offers.

This week, the team’s Dev Logs are back, so you can catch up with what we’ve been working on. We’ve also got new tutorials and a great game. Let’s dive in …

😍 30-day Trial Subscription Available

A lot of you asked for this, so we made it happen.

We now have a 30-day trial subscription option available.

You can test out Phaser Editor v4 Desktop edition entirely unrestricted for 30 days. If you've never used Editor before, we strongly recommend reading our starter tutorials so you can appreciate what it is and what it isn't, all while learning how to use it.

You can use every feature and even build complete games. If you get stuck, please reach out to us in the ‘phaser-editor’ channel on our Discord server or email support@phaser.io. We want you to appreciate how powerful Phaser Editor is, and we will help you get there as best we can.

View the trial subscription page.

🎮 Deep Space Survivor

Survive massive amount of enemies in space in this top-down action auto-shooter.

Gnome Castle Games has taken the fan favorite Vampire Survivors and thrown it into deep space. Can you survive the onslaught of enemy ships in this top-down space auto-shooter?

In Deep Space Survivor, you try to survive the numerous enemy space ships that are trying to get you, blowing them up with unique weapons and powerups. Influenced by Vampire Survivors and Magic Survival, this game provides tons of action and roguelike elements.

Read more about Deep Space Survivor

🌟 Phaser Editor 4.3 Released

Enjoy new quality-of-life improvements, such as drag and drop asset management and UI updates in this latest release of Phaser Editor.

A brand-new version of Phaser Editor has been released. You’ll find a much quicker and easier way to add assets to your projects, UI improvements, updates to support Phaser v3.85, a super-handy new “Go To Scene” icon, and plenty more.

Read the full release notes for details about all of the improvements.

Subscribers can update to this version immediately. Just grab it from your account's Downloads page or pick ‘Check for Updates’ within Phaser Editor. If you don’t have a subscription, we offer a 30-day trial.

🎙️ Interview with a Phaser creator: Ar0se

Learn more about the game Txtaria and how it came to be.

Ar0se caught our attention with her game Txtaria. The game is a platformer with an ASCII art style that gives it a mysterious look and feel. Ar0se agreed to tell us more about her story and the development behind Txtaria.

Read the full interview here.

🎥 3 New Tutorials

Here are three great new Phaser tutorials.

The Phaser 3 Pac-Man Tutorial Continues. This time, it’s all about pathfinding.

Learn how to code a conveyor belt effect in this new video from Scott Westover.

Emanuele Feronato has challenged himself to create 101 games. Pushori is the first one, and it is complete with code.

Phaser Studio Developer Logs

👨‍💻 Rich

It’s been a busy week in the Phaser Studio offices. I mean, we all work remotely, but things have been cooking up a storm in our respective offices. As usual, since we formed Phaser Studio, I’ve been spread across multiple projects every day of the week. Mostly, I’ve been focusing on our new documentation site with Zeke and Francisco. I wrote a huge amount of technical content, which is being turned into actual guides and maps of the internal systems. Plus, we’re updating the API documentation too. So, the new site will be a combination of getting started, core concepts, deep dives, flow diagrams, and the full API docs.

I’m happy to announce that we partnered with Hashnode to host the docs sites. This is a brand new service they’ve been working on, and we’re loving it so far. We get to create our docs as markdown and code in our own git repo, and they sync them to a beautifully presented site on every commit. We no longer need to worry about keeping our doc site tied to the current version of Phaser, as we’ve traditionally done. Instead, we can update and publish new site content whenever we like. I’ve wanted to do it for years, and we’re finally doing it!

We’ve also been planning out the product roadmap for the next three months. Our priorities are getting Phaser Beam complete and then merging it all into Phaser v4, getting the new physics system released (see Pete’s section below!), getting the docs site live, getting the new web site live, and, of course, constantly updating the Phaser Editor throughout all of this. Plus, there are a few other neat ideas in the works.

Amazingly, this will bring us to the end of 2024, which is quite a shocking realization in some regards. Of course, I’m incredibly pleased with what the team has achieved this year, and we’ve still got our most important quarter ever to go, but time does seem to be flying by. Anyway, read on to find out what the rest of the team has been doing. Spoiler: it’s pretty damn cool 😎

👨‍💻 Pete - Box2D

I'm currently developing a Physics library for Phaser.

The project? To convert the new and wonderful Box2D v3.0 from C to JS.

Large Language Models

Work has progressed very quickly, largely thanks to Large Language Models (LLMs) like GPT 4o and Claude Sonnet performing the grunt work.

After a lengthy process of chopping the source code up into pieces small enough for the LLM to digest, then rearranging them so that each piece has enough context from the rest of the project to make sense, I was able to use the following system and user prompts to get a first draft for each piece of code:

System: you are an expert C and JS programmer, you will answer questions and fulfill requests accurately and concisely

User: please convert this code into JS (from C). Use the exact same labels. Comment out all macros like B2_ASSERT. Skip any code which is disabled by conditional compilation (permanently false, or using a debug flag). Where a data structure is used but not defined, assume that a similar JS structure will be used as an import. Export all functions that start with the characters b2. Where a type is used but not defined, assume that it will be available as a similar JS structure elsewhere in the project (e.g. b2_circleShape). Convert any typedef struct into a class.

Problems

Whilst far from perfect, the generated rough cut hugely reduced the amount of search and replace and routine editing for me. I don't think any file worked perfectly, but the errors tended to fall into categories which made them easier to address rapidly:

• missing imports. These show up during run-time testing - thorough testing is essential

• missing conversion, more on this later

• inconsistent type use. There were a lot of cases where instead of using classes like b2Vec2, the JS used generic objects instead. I used search to find these and manually replaced them. Search strings "= {" and "({ " gathered 90% of them

• inconsistent code conversion. This was usually my fault in that I'd failed to provide enough context and the LLM 'made it up' resulting in pieces of code that didn't fit together via types or overall approach. Manual fixing was required, although in extreme cases I tailored the prompts specifically, changed the context, and pushed the file through again

• pass-by-reference vs pass-by-value

In attempting to fix the missing imports I ran into to module errors with repeated or looping dependency issues. I resolved them the lazy way by sticking to the C language design where 'header' files contain definitions, and 'source' files contain everything else. All files import only 'header' files, which avoids circular dependencies. It looks weird having 'include/constraint_graph_h.js' and 'constraint_graph_c.js' but it works. As it is close to the original C file structure, it also minimises the conversion required for this early stage development.

After fixing these widely prevalent import issues, other errors included typical LLM type nonsense where it seemed to forget what it was told to do:

LLM: class b2World { /* include JS conversion of the b2World structure here */ }

Me: Hang on, that's literally all I asked YOU to do!

There were a lot of problems with pass-by-value conversion to pass-by-reference. Some of them were exceptionally hard to find, and I resorted to building identical demos in C and JS. I could step through both of them in parallel and compare the numbers at every step.

An early output comparison, C on the left, JS on the right. This was the first test where a falling box detected collision with a ground platform:

Testing the Conversion

My testing structure was created in the file main.js, which started as a list of 'unit test' type code snippets. I'd show the LLM a class definition then ask it to devise some unit tests to check the operation is correct. Creating and debugging these for all the major Box2D systems was a boring, slow, iterative process that took approximately 8 days. The LLM was helpful for creating ideas here, but it was very poor at creating the unit tests themselves. A large number of the early attempts were testing invalid calls or expecting unreasonable results. Eventually I used an LLM (Claude Sonnet) to suggest possible tests, then manually coded the ones which seemed to have merit. Getting close to the code at this point was very helpful for later understanding when deeper issues started to show up in the conversion running full demos.

At the end of this stage, I had working tests for all the major classes in the physics engine and was able to start building some demos - safe in the knowledge that the unit tests would catch most errors if I broke one thing while adjusting another.

Shapes!

Now the fun part starts. I began with a single box landing on a static box 'ground'. In Box2D a box is a polygon type which is a fundamental element of nearly everything. We use them for ground platforms, stacks, and of course stress-test demos:

Additional shape types include circles, capsules, segments, and chain-segments. The chains are mostly used for platforms, and address issues with adjacent segments which will otherwise cause unwanted collisions for a shape sliding along on top of them.

Every shape type has bespoke collision and rectification functions for interaction with the other shapes, so this job was bigger than I had anticipated (5 more days) but did not require any modification to my process.

Joints!

With all the basic shape types working, I moved on to the Joints. Starting with a Revolute Joint, I debugged my way through to a working ragdoll. I was relieved to find that the conversion was now largely stable and the remaining bugs were generally easy to fix when I'd located them. I continued to use the parallel build and compare approach, with a matching C demo for every JS demo.

After getting one joint type working, I moved on to distance, motor, mouse, prismatic, weld and wheel joints. My approach remained constant: take a C++ sample from the comprehensive range available in the Box2D repository, convert it into a JS test in main.js, run it and fix the obvious bugs, then compare the results both visually and numerically and dig deeper if necessary. Now that all of the joint types are working, I believe the only remaining systems are the Sensors and their related Events.

Future Work

Going forward, the JS library is working but it is a very literal translation of the C. This makes for some strange looking and inefficient JS, which we must clean up and optimise. The API design is heavily orientated towards the C programming language and its quirks. It has a strong emphasis on avoiding memory allocation and release after initialisation. Given the conversion of typedef struct to classes for JavaScript, many of those design choices can be changed to make the library more familiar to JS developers. It will need to be integrated with Phaser eventually but initially we'd just like to have it available for Phaser projects to use. The original C makes very effective use of multitasking and SIMD instructions. It would be interesting to see if JS worker threads can be used effectively to regain some more of the speed of the original code.

You can see the results of the work so far in the YouTube video below:

👨‍💻 Can - Phaser Nexus

Physics Particles! This week’s work on the Nexus particle system focused heavily on optimization and restructuring. I’ve been refining the code for particle presets, ensuring flexibility without sacrificing performance. The primary focus was on improving physics particles, both in terms of object creation and overall system efficiency. After several iterations, we were able to push the system to handle 5,000 DOM physics particles, maintaining 15-20fps on the M3 Max as the maximum limit at the moment, which is not too bad for the DOM! The biggest challenge was the initial load, as firing up all the particles at once created noticeable bottlenecks.

The key breakthrough came from utilizing DocumentFragment to batch the particle initiation process. By grouping the creation and manipulation of particles before injecting them into the DOM, it significantly reduced the strain on performance during the initial setup phase. This approach proved essential in keeping frame rates more stable under heavy particle loads. These improvements are setting the stage for even more scalable particle systems in the future, with a solid balance between performance and complexity.

Until the next one, hope you all have high frame rates without drops!

👨‍💻 Francisco - Phaser Documentation

These past weeks I've been working on updating the Phaser documentation. On the current API Phaser docs site, a new path has been added that allows users to access the latest published version of Phaser by simply adding latest instead of the current version number. Try it out at the following link:

https://newdocs.phaser.io/docs/latest/Phaser.Game

I have also fixed several issues that our dear users reported to us, such as problems with certain links in the sidebar.

Documentation: A New Awakening

We’re also working on a brand-new documentation site too!

Continuing with the documentation, but now something a little more exciting. I've been working on a new exporter for the Phaser documentation that will help us convert what we have in JSDocs to Markdown, making the documentation cleaner and easier to read. At this time, I can't reveal more about this project, but I'm sure Richard will announce something exciting in the future.

👨‍💻 Zeke - Phaser Documentation

Hi there 🙂

This week has been an exciting week as we begin migration and updating our current documentation to the Hashnode Docs platform. With the help of rexrainbow and samme, we're looking to create some solid documentation that is readable, simple to understand and loaded with example code.

My week was spent diving deep into Phaser documentation while examining documentation written by Rex and Sam. To kick things off, Richard led our team in discussing the new documentation structure and format with the goal of making it easy to maintain, scale and migrate (if the needs arises in the future).

My role involves reading through all 3 sets of documentation above, deciding what would be most helpful and merging each piece of writing into a single coherent document.

My thought process when putting together this documentation is as follows:

1. What is the natural flow of thought a user might have when learning about this component?

2. How can some light narrative be weaved into the documentation to make it more readable?

3. Where can code examples be added to further clarify how each method, function or feature works?

From reading through pages of documentation, Sam's writing style flows more naturally and is readable while Rex is more technical and goes deep into every property and method available. While different, both complement each other really well.

Here's what I've worked on this week:

1. Phaser Scene. Richard has kindly written a proper introduction to all of Phaser's core components including the Scene that I have added to this piece of documentation. Following the structure of what Sam has written, more code examples and technical details were added from Rex's document.

2. Phaser Events. Sam provided a good fundamental explanation of how events work in Phaser and Rex provided comprehensive technical details to implement this is code. Rex also provided a more advanced implementation showing how to extend Phaser's EventEmitter to create your own custom event emitter class.

3. Phaser GameObject. The most detailed documentation worked on for the week with over 1200 lines of text and code. It covers the full usage of creating game objects, methods to change its properties, interactivity, rendering, data management, events, dealing with common problems and even creating custom game object classes. Sam provides the structure, flow and narrative while Rex injects solid code examples with detailed explanations.

4. Phaser Game. The heart of a Phaser game, all games start by creating an instance of the Phaser Game class. Sam shows you the fundamentals of creating a Phaser game instance and explains basic configuration properties. He also explains the differences between WebGL and Canvas rendering and how it could affect your game. I have also added Rex's global members in the Game class that includes the Scene Manager, Data Manager, Time, Game Config and Window size. Also included are details on how to pause/resume your game and handling browser events that affect gameplay.

5. Phaser Input. Only Rex's documentation was added here as Sam did not have documentation that deals solely with Input. Rex goes deep into explaning how interactivity works in Phaser. It includes touch / mouse input, keyboard input and how to create keyboard combo input, gamepad input and using the mouse wheel.

Overall, it's been a productive week reading into various documentation, compiling and editing writings from 2 accomplished Phaser users, and thinking how to best present it to our fans and developers.

👨‍💻 Arian - Phaser Editor

Hello!

This week we finally released the new version of Phaser Editor. The team has also been working on a new Trial service for the editor, with which you can use the editor for 30 days. After the storm of a release comes the calm? Not in Phaser Studio! So we immediately got to work on the new release. Although we may have an interim release with some changes we've made as we're busy refreshing our studio image, and we're making promotional videos. For these videos I added some sugar to the editor. Here's what we've done:

A button to launch Visual Studio Code. If you're working on a scene, the code for that scene will also be displayed in Code.

We've added commands to sort objects in the Tools Pane of the scene.

And what's even more exciting, you can now play sprite animations right in the scene, in real time!

For this mid-release we are evaluating a better way for you to contact us, directly from the editor. Stay tuned!

Tales from the Pixel Mines

September 16th 2024 by Ben Richards

I have spent this week arguing with myself. It's been very productive.

Last week saw the release of Phaser Beam Technical Preview 4. We've already gotten some good feedback just by letting people experiment with it. When the possibilities are endless, we can't find every edge case by ourselves!

This week, I've got two stories about arguing with myself. The first is about parallel shader compilation. The second is about framebuffers. These are technical, but cool.

Parallel Shader Compilation

I said I wouldn't work on this. Then I worked on it anyway. Let's not ask why; let's just look at what it does for you.

Shaders do all the rendering in WebGL. With the new shader factory system, we can deliver a wide range of shaders, optimized to the demands of the moment. However, every time we compile a new shader, we have to... compile it. That takes time.

That time will vary depending on device, but on my desktop, I find it takes 10-15ms. A full frame is 16.7ms, so a single new shader will eat most of a frame. Two new shaders will eat multiple frames, causing stutter as there's now no way for the frame to finish in time. And this gets worse with more complex scenarios, as we add more effects or rendering optimizations, or as you add detail to your games.

If only there were a way to keep on rendering while a shader compiles in the background.

There is! It's the KHR_parallel_shader_compile extension. With this, we can start a shader compiling, and efficiently poll WebGL to ask, 'Is it ready yet?'. If it's not ready, we can simply skip drawing with that shader.

So I've created the render config option skipUnreadyShaders. This is off by default. When activated, it enables the extension and stops doing stuttering, blocking checks of shader completion. This results in silky smooth frame rates even when multiple new shaders are compiled at once.

But there is a cost: an object that needs a shader won't render while the shader is compiling. This is typically almost unnoticeable, but that's not ideal.

Also, KHR_parallel_shader_compile is not presently available in all browsers. While Firefox may add the extension at some point, right now only Chromium and Webkit renderers appear to have it.

The best practice, whether we are using the extension or not, is to pre-touch shaders. That is, use the shader in an unobtrusive way before it's actually needed. Once it's been used, it will remain available in the render system, and there will be no further interruptions. You might do this on a loading screen, or as your main menu or titles load in.

But how do you know which shaders are going to be used? Unfortunately, that's a technical question that can only really be answered with comprehensive analysis of the shader factory system. The practical answer is, just be thorough. Pre-touch each type of game object, in the conditions that you expect it to be used. Include lighting and special effects. If you still observe pop-in, check exactly what you're doing and try to replicate it more thoroughly.

Pre-touching will ensure that everything is ready before you need it. It may only save a few frames, but that helps keep your games running smoothly. And it works now, even before the render config option is released.

Framebuffers

The last big development for the Beam renderer is around framebuffers. We've been working towards this objective for months. It's not just a performance upgrade, or a few extra features; it's a whole rework of the system, making it more reliable, powerful, and flexible than ever before.

This is very important to get right, so of course, I've been arguing with myself all week. What is the best approach? How much do we keep the same, versus change or improve? Are the benefits clear? Etc etc.

We think we've come up with a pretty cool approach. None of this has been coded up yet, so consider it a work-in-progress subject to change without notice. But it's enough of a change that I want people to start thinking about it - if I'm doing something really unhelpful, I want to know!

The New Approach

Rather than explain how things work right now, which is complicated, I'll just propose what I want to do.

• DynamicTexture uses a command queue and a manual render command.

• A new Stamp object renders without reference to a Camera.

• A new Box object wraps GameObjects in FX.

DynamicTexture Command Queue

The DynamicTexture is a Texture containing a framebuffer where you can make persistent drawing operations. This is used in the RenderTexture GameObject, and can also be used directly. It's convenient for composite graphics which don't need to update frequently.

We will use a command queue to render a DynamicTexture. This records all the draw operations you want to perform, then renders them all at once when you call DynamicTexture.render(). This is more efficient than drawing each operation as you make it, and can take advantage of the full render system, making drawing even more efficient and predictable.

In practice, you may never notice the command queue. You'll still just call commands like stamp() and draw() and erase(). You just need to call render() once you're done.

Commands like beginDraw() or batchDraw() will be removed, because you no longer need to consider how the renderer works. This removes the possibility of bugs, such as a missing endDraw() command or running batch commands without beginDraw().

This makes DynamicTexture more reliable and straightforward to use, which we think is a good trade-off for one new render() command.

Stamp GameObject

The new Stamp object will be like an Image, but it ignores cameras. This is similar to how a DynamicTexture handles stamps already, but by becoming its own object, the Stamp can be more efficient. As well as being used in DynamicTexture operations, the Stamp can be added directly to your game scene. It could be useful for HUD elements or other purposes.

This is more efficient because cameras apply a transformation matrix to everything they see. Most of the game's performance budget goes on those matrices! By eliminating them, we improve performance. The Stamp isn't suited to many things in a game world, but if your camera never moves, it could be amazing.

Box GameObject

The new Box object is a wrapper around another GameObject. Its main purpose is to handle all the FX in the game.

A Box has two sides: 'inside' and 'outside'.

The 'inside' is the world inside the Box. The Box might be moving in the outside world, but the inside doesn't change. This is similar to the 'preFX' available on some GameObjects right now, but expanded from the concept of just affecting a texture. For example, we want lighting to still work inside the Box, as one of the more obvious rendering technologies that we're using. It doesn't work with preFX, because that technique takes control of rendering, rather than allowing objects to render as they wish.

The 'outside' is the Box in the world. Once the Box is positioned on the screen, 'outside' effects run in screen space. This is similar to the 'postFX' available on most GameObjects right now.

Why are we making this change? Why not let objects manage their own FX?

Well, this method makes it easier to compose a scene render graph. It's far quicker for us to develop new rendering technologies if everything is modular like this. And at your end, when you're developing a game, it's easier for you to see precisely where your game is using framebuffers. Just count the Boxes.

This modular approach to rendering should overcome some longstanding issues with flexibility. Where objects were once restricted in their use of blend modes or FX within Containers, we can now nest Boxes inside other collections, and be confident that they'll do the same thing at all levels of the scene hierarchy.

Speaking of Containers (and Layers), they now gain some predictability. Previously, if you added FX to these collections, it would change some aspects of the way they were blended with the scene. With Boxes, we can remove this multi-function rendering, and give you confidence that collections will always render exactly the same. You can still put a Collection in a Box to add FX to it.

This is a big change to FX, but we think it's going to make it easier to see how a game is put together. Each Box represents a framebuffer and a new set of WebGL calls, which can help you reason about game performance more easily. You can also see where your game is rendered to a framebuffer. And, of course, it makes complex hierarchies more reliable and flexible.

I argued with myself about every part of this design. (You should see the Discord logs. I really did argue with myself.) There are lots of ways to approach this problem, and I've looked at most of them! This seems to be the best.

Masks

In theory, I've spent most of 2024 working towards improving masks. Boxes with FX make it possible to do masks in a really powerful way, so that's great!

We intend to treat masks as FX, going forward. With the 'inside'/'outside' concept of a Box, we can make masks much more flexible. This is probably as simple as a shader which erases the masked region of the image.

Current mask behaviour is in screen-space. A mask FX in the 'outside' does exactly this. But how do we make a mask which follows an object? Just put the mask in the 'inside' of the Box instead.

And with masks as FX, we can do really cool things, like apply a mask in between other FX. Imagine: recolor an object, trim it with a mask, and apply bokeh blur to the trimmed result. This is how we want masks to work, and we're so close now!

Next Week

Next week, I'll start getting this stuff working. The DynamicTexture is first on my agenda. And then I'll get to grips with the shiniest, shader-iest part of the whole render system, and work on FX and Boxes. Looking forward to it!

Submit your Content

Created a game, tutorial, sandbox entry, video, or anything you feel Phaser World readers would like? Then please send it to us! Email support@phaser.io

Until the next issue, happy coding!