Warning

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

Published in Phaser World Issue 50 on 7th October 2016 by Richard Davey   @photonstorm

Ironing out Pixi and Staying on Target

image

This week has been another intense one to say the least. The Phaser dev branch has been getting a real hammering, as I methodically work through the current set of tasks. It's probably not immediately obvious what is happening from the commits, so I'll try and summarise it here (see also the previous couple of newsletter issues for more details)

The overall aim is the complete removal of the Pixi namespace. Please don't think we're doing this out of vanity, as it's something Pixi themselves did for their own v3 release. The reasoning is two-fold: First we want to try and move away from using any globals at all, which will get us to the point where we can convert over to being a fully module based library with minimal impact. And when you've got literally hundreds of 'PIXI.This and PIXI.That' all throughout your code, that's a hard jump to make. So by carefully removing, replacing, and renaming, we're arriving at a much more consistent place.

The second reason is that I've been able to remove a huge amount of duplicate, or just redundant, code in the process. The inheritance chains have become a lot more simplified. There are no longer duplicate methods in classes causing confusion (i.e. Group doesn't have 'addChild' and 'add' any more). And I've been able to really tidy-up the Pixi classes as well. The coding style is has been bought in-line with our new ESLint configuration. The naming of methods and classes makes more sense, and things have been broken down into smaller, more logical, pieces. This will make our documentation better, and get rid of confusion about what the heck happens, and where. Plus it will make the core renderer a whole lot more hackable, which is something I've wanted for a while now, but had been locked out to all but the most ardent source explorer.

An axe through the renderers

One of my favourite new features though is that I've literally prized apart the Canvas and WebGL renderers. Game Objects no longer carry the baggage of both renderers inside them, so it's perfectly possible to build a 100% Canvas only version of Phaser, that doesn't include a single bit of WebGL anywhere. It's also possible to now remove say the Graphics entity, and it'll literally remove all associated rendering code as well. It's one of those 'quite dull on the surface' things, yet internally it makes life a whole lot better. And it puts us in a good position for the future too.

Stay on Target

I'll be honest with you; when I played Nearwood (see the Games this issue) I nearly cried, because of the fact that something so utterly beautiful had been created with Phaser. You see, whenever I dive into the Phaser source, which is pretty much every day, all I see are things that need improving. I have piles of notebooks filled with my thoughts about what Phaser could do, and I keep one next to my bed, and in my bag, at all times. My inbox constantly pings with new GitHub Issues opening, Disqus comments asking why X doesn't work, or Stackoverflow posts I've been tagged in. When faced with a small yet constant barrage, it's easy to be consumed by it, and to forget the bigger picture: which is that, in the right hands, people can, and are, making really incredible things with it. That has to give me hope that all these hours invested are worthwhile.

So please, stand by me as we go through this transition within the code. I'm genuinely excited about the shape that v3 is taking. I'll keep coding, and writing about it here, and as soon as we're ready I'd love for your input and help testing.