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.

📺 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.

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!