Due to the rapid pace of change some links or details may no longer be correct.

Published in Phaser World Issue 60 on 16th December 2016 by Richard Davey   @photonstorm

Loader XHR Updates, Maps and Explaining v3 Module Structure


First of all, how cool is that pixel art Christmas tree above?! It's from the Atari ST and felt suitable for this issue (click it to see more art by the same artist).

In Phaser CE I spent some time on Monday getting jshint running again. The config has been put back in, and I fixed all linting issues in the code. I also updated the readme with instructions on how to prepare a release of Phaser CE. It's good to have the jshint step back in again. It caught a few errors that shouldn't have been there, and you can of course use it to validate your own code before submitting. It also allowed me to close off a few more issues. Phaser 2.6 may have been the last official release, but I'm still spending time now and again helping out with CE.

Phaser 3 Weekly Updates

With Phaser 3 I started the week tweaking the Loader. You can now pass in your own XHR Settings object with any file. There is a global (loader-based) XHR Settings object, but you can now tweak it per file too. This means you can override things like the response type, or set a specific username and password for XHR requests. File loaders for all of the core types (excluding audio) are now in.

I also updated the Set and Map classes. These are ES5 implementations of what we've now got available natively in ES6. They're powerful, and extremely useful, and used throughout the new Loader and Cache classes. The API matches the ES6 implementation as closely as possible, meaning when support is broad enough we can deprecate them to polyfills.

As well as this I've been working on porting over more of the functions needed to support the first beta release, and have started building the main Phaser export package as well. Lots of the core math and utility functions have been converted, and I've updated the boot sequence as well. Loads more of the tests and examples are now running again, which is encouraging.

In Modules We Trust

I wanted to take a little time to explain about how Phaser 3 has evolved over this quarter, and why there won't be a release before Christmas:

Breaking Phaser down into modules has been a mammoth job. I knew it would be, because I had already gone part way through the process with Lazer. But that doesn't diminish the sheer amount of work involved. I've been slogging through it, often into the small hours of the morning, and I'm not done yet either. I'll be honest - it's not exactly fun or sexy work. But it is essential, and needs to be done right. When you dissect something so large, into something so small and singular, it forces you to be extra critical of each new function, and check them to make sure they are right.

While it would have been easy to just throw a bunch of 'module.exports' into our Phaser 2 class files, that would have defeated the whole point of moving to modules. Originally (i.e. pre December) v3 was meant to be a relatively low-key release. An evolved v2 codebase with some internal tuning, and bells and whistles added on the top. At that time I was bullish about having a release in time for Christmas, because honestly we were pretty close to it already.

But it was eating away at me that it just wasn't the right move. There was still a mammoth code base under the hood, it was still using God-classes, a gigantic grunt build process, and expected global scope (internally it created and used 'Phaser' level objects everywhere). Although I had tidied things up a lot, the tentacles from the internal plumbing were myriad and stretched deep.

It took a lot of soul searching and effort to decide to stop, and re-evaluate what was happening. Rather than keep adding ingredients into the mix, it was time to bake a new cake. Which is what Phaser 3 now is. On November 22nd I literally moved the entire codebase into a folder called 'merge' and started again from scratch. I had the same objectives, the same end goal in mind, just a different technology stack underneath it all. And quite frankly, one that everyone had been crying out for, for ages now.

In moving to webpack2, and CommonJS modules, I have to methodically go through the entire v3 code base, line by line, and break it into proper modules. This process is accelerated in places by revisiting the Lazer code, as I'd already gone through the motions for a lot of classes in that. I was literally pulling in code from Lazer (and 'downgrading' it from ES6 to ES5), merging it with Phaser, and injecting all the new things I'd added in v3 too. As you've seen from the hundreds of files committed over the past 4 weeks it's been a rapid, but intense, process, and it's not over yet.

My aim now is to marching towards a Beta 1. I'll focus on continuing to convert over the previous code into modules, and Felipe will focus on building the brand new renderer features (as you'll see in the next section on masking). The first version will absolutely be missing loads of features, because there is no need to wait until every last single thing is put back in before releasing it. As long as you can build something, to me that's a valid first Beta. And right now, Christmas aside, I'm doing everything I can to get there, as quickly as I can.