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!