Phaser in 2015 and beyond

2015 was the biggest year yet for Phaser. Both in terms of updates, volume of developers using it, and the sheer quantity of games released. The quality bar was raised massively too, with Phaser firmly establishing itself as one of the leading tools for web game development.

So let's have a quick recap of 2015, picking out a few highlights along the way, and mix with a good dollop of what 2016 will bring.

Phaser Site Traffic

At the start of 2015 the Phaser web site was split into three separate sub-sites: The 'news' and downloads on the main site, the Phaser Examples and the Phaser Docs. As a result the main site on its own received on average 5,500 page views a day. On March 10th this all changed and after several weeks of hard work the Examples and Docs were merged and the site became a 'whole'.

As a result of this change, and the growing popularity of Phaser, the site traffic exploded. An average day is now between 35,000 to 40,000 page views. In the month of December the site served 915,961 page views (and probably a few more after I've written this article)

We will close 2015 having delivered just over 9.02 million page views to 557k users. During the peak times of the day there are easily 150+ people active on the Phaser site at any one time. And we run all of this 100% ad free. I did experiment with Disqus ads for a while during 2015, but the ads were horrendous - often totally inappropriate, sometimes downright offensive. So I disabled them all.

The site runs from a dedicated server hosted in the UK. This costs £190 GBP a month (about $280), the cost of which is covered fully by myself. Sales of Phaser plugins and books help go towards the pot that covers this expense.

Little known fact: The Phaser site was built entirely by myself, and uses a 100% custom written Laravel back-end. Site content is created in plain text markdown files. A bunch of custom scripts import this into the site. All data is stored in SQLite databases with the exception of the Phaser Sandbox which uses a redundant MySQL set-up. There is no 'admin' area, no CMS tools or anything of the sort. I create content directly in Sublime Text, push it to git and it syncs to the site. I'd much rather this workflow over struggling with the likes of WordPress.

HTML5 Game Devs Forum

The HTML5 Game Devs Forum continues to grow at a nice and steady pace. We've now got 13,277 members who have made 109,814 posts in total. In an average month the forum serves 410,000 page views (from 175k sessions).

Over the whole of the year 875k users contributed to 4.8 million page views. That's 230k more users and 400k more page views compared to 2014.

I'm very happy with this, and have no plans to try and boost it or change things in any way. The forum has always served a niche section of developers, and the fact we're still growing year-on-year goes to prove that it's still needed.

I've run or helped moderate forums for decades now, including some of the largest game dev forums out there in the past, and I'm really pleased with how nice HTML5 Game Devs is. It's a testament to the quality of developers who frequent the forum that in the years it's been running we still only need a handful of moderators to cope with it all. Flame wars and arguments are extremely rare. To every forum member reading this: Thank you! You help make it the friendly place it is.

One thing we will do in early 2016 is upgrade the forum to the new version of Invision Power Board. IPB v4 has been out for a while and is now the main focus, getting all the new features and security updates first. So we'll upgrade to it, but otherwise it will be business as normal.

The small banner ads that appear on the forum cover the cost of the IPB license, which is a year-on-year expense. The hosting cost is merged with the Phaser site. Moderation time is given freely.

Phaser on GitHub

At the time of writing Phaser has 10,978 stars on GitHub. This makes it the highest rated JavaScript game framework on there. According to this list it makes it the highest rated game engine full stop.

By way of comparison with other super-popular open source projects: React has 33,845 stars. three.js has 22,643 stars. Babel has 12,646. Angular has 7,791. JSDoc has 4,055.

GitHub stars aren't really worth anything. They are about as much use as a Facebook 'Like' or a Twitter 'Heart'. Just a vague indication of the global appeal of something. But even so I personally find it great that so many developers voted for Phaser. I know it shouldn't encourage me, but I'd be lying if I said it didn't.

The Phaser git repository had 281 pull requests in 2015. Sadly the GitHub stats only check contributions towards the master branch. As all Phaser development is done against the dev branch the volume of commits, amount of code changed, etc is hard to quantify using GitHub stats alone.

However via the magic of git log I can tell that we all contributed 1,216 commits to the Phaser repo over the year. The first bit of code committed back in January 2015 was Device.webAudio check inversed to avoid throwing a warning in Chrome. (thanks Chrome!) - this fix was indicative of a trend that only got worse through-out the year. We're still dealing with browsers raising warnings, dropping the use of prefixes, moving features behind SSL and generally being a pain in the butt while going through essential evolution.

Looking forward to 2016 I'm not expecting as large a growth as this year. Splitting Phaser and Lazer apart means that both will grow at a slower rate, or indeed once Lazer is the mainstream version that Phaser use will start to drop-away. I guess we'll find out in next years round-up.

Phaser Releases

Phaser entered 2015 on version 2.2.1. This had been released on December 4th. 2.2.1 was a hot fix release for 2.2.0, which had landed a day earlier, and was a truly massive release. The biggest change in 2.2 however was the move to using Pixi 2.2 internally.

Pixi 2 bought some big changes with it, and some challenges too.

In hindsight we should have waited for Pixi to become more stable before diving in head first and adopting it, but that isn't how things played out. There were definitely lots of improvements and the Pixi team did some stellar work on it. But I know for a fact there are still several studios out there, even today over a year later, still using Phaser 2.1.2 with the old version of Pixi, because they find performance better in that build, especially on mobile.

The problem was two-fold: Adopting 'cutting edge' releases of Pixi, and bundling too many changes in to Phaser at once. The change log for the 2.2.0 release is massive and demonstrates the problem well.

And here-in lays the rub: When you've got so many changes in a single version, coming in from so many different contributors, it's impossible for them all to have been thoroughly tested. Combine that with a sweeping change to the underlying renderer being used and it's a recipe for things to slip through the net, no matter how good our intentions.

It also explains why Phaser 2.2.2 "Alkindar" was released on January 6th 2015, barely a month later than 2.2.1.

On March 26th we released Phaser 2.3.0 "Tarabon". With this release we undertook a lot of internal restructuring. Game Objects were paired down and moved to a mixin component system. This allowed us to drastically cut down on the amount of duplicated code through-out Phaser. There was a concerted effort to 'get our house into order', tidying up and optimizing the internals rather than bulking it out with new features.

We also introduced the first pass at allowing for 'Custom Builds'. This would finally let you skip whole chunks of Phaser if you didn't need them in the build step. By this point a lot of people had been asking if we could make Phaser more modular. This was (and remains) a massively non-trivial request of course, so Custom Builds was our intermediate approach until we could do this properly in Phaser 3. v2.3.0 also had some great new features by way of an overhauled Loader with proper parallel stream support, and spacial sorting added to arcade physics.

The final significant change in this version was moving away from using a mainstream release of Pixi. We had always used a customized Pixi build, even from day one, but it had generally followed the Pixi mainline closely. With Phaser 2.3.0 this all changed. The reason was that they were dropping support for Pixi 2 and concentrating on Pixi 3 instead. The structure of Pixi 3 was so incompatible with how Phaser had grown that we couldn't adopt it easily.

Equally, after the burn of the issues we'd faced in the previous upgrade (which I stress was our fault for not giving it time to bed down), we made the decision to carry on investing in developing our own renderer.

July 22nd saw the release of Phaser 2.4.0 "Katar". Again this was a large update, but we had been far more careful this time. Changes were a lot less dramatic and more feature focused. There were now thousands of developers relying on Phaser, and we knew we couldn't just change things 'on a whim'. So updates became more focused. Phaser 2.4.1 and 2.4.2 followed in quick succession, again focusing mostly on resolving issues rather than packing in features. August 24th saw Phaser 2.4.3 "Coramen" and on October 15th we released the last version of the year: 2.4.4 "Amador".

Suffice to say it was another busy year for Phaser.

In 2016 we will focus on Phaser 2.4.5. There are a lot of pull requests and open issues that we will attend to. Because we are now working on Phaser 3 full-time it's hard to switch back and forth between the two of them, so instead we're going to have 'Phaser fortnights' where we push all other things to one side and focus entirely on updating Phaser over a dedicated chunk of time. The first of those will take place in early January 2016.

Right now I can't say how many versions of Phaser there will be after 2.4.5. It's possible it will be the final release before we put it into maintenance mode.

Lazer (aka Phaser 3)

I knew that despite how popular Phaser had become it was time for an overhaul.

While I spent most of 2015 being careful about what new additions were pushed into Phaser, I always knew there was going to come a point where I would just need to start again from scratch. The reason was that even with all the work that I did trying to streamline things, Phaser was still a multi-tentacled monster, deeply coupled through-out almost every class within it.

It was a double-edged sword of a design. It suffered from the classic 'inheritance' scope problems, where the framework had evolved in directions unforeseen at the outset, and classes were spread wide and thin as a result. However it did also mean that it had probably one of the friendliest APIs of any game framework out there, which I am utterly convinced is the reason for its popularity.

Whatever Phaser 3 was going to do it had to retain it's friendly API, no matter what, but under the hood it needed to be completely different.

The browser landscape is changing. With the ratification of ES6 it's vitally important to look forward, and not be stuck with the habits of old. ES6 brings some important changes to the table, not least of which include its module support, native classes and new data types like Map and Set. It's as if JavaScript development has 'come of age', and it feels fantastic to work within.

After a long discussion on the forum about if Phaser 3 should be coded in TypeScript or not (which turned into a mini religious war) the decision to be 'pure ES6' was made.

I spent many months of 2015 just planning what Phaser 3 should contain. I collected literally hundreds of thoughts and requests from the community. From the quite frankly ridiculous, to the painfully obvious. Due to work on client projects, and continued updates of Phaser, development of the Phaser 3 core took a long time to get started. In hindsight this was good because it gave ES6 time to settle down, and the tools that go with it like Babel and SystemJS to catch up. It also gave me time to research and give more careful consideration to how this new framework would be built.

The reason for the name change

We also came up with a new name for it: Lazer.

There were several reasons for changing the name: First, and most important, is that the name 'Phaser' is trademarked by CBS, the company who own Star Trek. With the release of a new Star Trek TV series in 2016, as well as another film, and the rise in popularity of Phaser, it became more and more worrying to us that it was impossible for us to ever be able to legally secure the name of our own framework. Plus there was the shadow of potential legal issues hanging over us, should CBS ever want to act. In the end, after consulting with our company lawyer, and much internal head banging, we decided the best course of action was to choose a new name entirely.

After many, many thoughts the name Lazer was selected.

The new name was clear in all respects that mattered to us: npm package name, domain, trademark and didn't conflict with any other game frameworks or JS libs. It also still have a 'sci-fi' feel, is short and was similar sounding to Phaser, while being different enough.

The up-side of the new name is also that it will help distinguish itself from Phaser too. Lazer is fundamentally different in every possible way. The thought of having to deal with support issues where someone isn't totally sure if they're using Phaser 2 or 3 was too much. We've had a Phaser 3 sub-forum for a while now and have already had loads of posts made by mistake from people needing help with Phaser 2 code. This name change will also help when it comes to posting questions to Stack Overflow, npm package names, GitHub repos and so on. It was the clean break needed.

We started exploring building our own renderer in January 2015 and this carried on through-out the year. Development was handled by Pete Baron and we captured most of his work in the Phaser 3 Dev Logs.

Development of the core of the library is taking place in the Lazer GitHub repo and can be followed on the mailing list, where I post my daily updates.

Lazer Philosophy

It's important to understand how I'm approaching the development of Lazer. To do so let's first take a look at Phaser:

Phaser is based on classes (or an approximation of them via extending JavaScript prototypes). Most Phaser classes extend or were derived from Pixi classes. For example a Phaser Sprite is an extension of a Pixi Sprite, which extends a Pixi Display Object Container, which extends a Pixi Display Object. And this hierarchy flows everywhere. The entire framework is literally built around the way Pixi does things.

This rose to the existence of God classes. Single large classes with lots of methods that perform a large number of tasks. These in turn are linked to lots of other systems within Phaser. It was implied that most, if not all sub-systems were available all of the time to any class. I.e. the Loader expected the Cache to exist. The renderer expects a Texture to have a BaseTexture, which in turn has to have a frame property, and so on. The dependencies and associated assumptions run right to the core and back out again.

This isn't an unusual approach. Indeed it's very common in game frameworks, and you'll encounter it in some of the biggest frameworks out there; Unity and Cocos2D being prime examples. They work on the assumption that the framework owns the entire process flow from start to finish. Sure, it might consume some external input or data, but even that is typically massaged and absorbed into its own internal structure before you are allowed access to it. For example browser DOM events are ingested into the Mouse class, which feeds them to a Pointer instance, which relays important parts to Sprite Input Handlers before you even get to hear about the event.

But if there's one thing I realized during 2015 it's that this doesn't feel like the right approach for Phaser any more, and it doesn't fit with where I see the future of web game development either.

A Tale of Two Camps

Phaser developers tend to fall into one of two main camps: Game Developers and Web Developers. It doesn't matter if they're hobbyist or professionals, they usually tend to fit into one of those two.

The Game Developers are those using Phaser to purely create games. There may be a bit of overlap as they integrate the games into web sites, but on the whole that isn't how they identify their profession. They (and their studios) focus on making games, or game related tools. Perhaps they used to be Flash developers, maybe some still are. But you'd generally never find them messing with the likes of React or Angular. For a lot of them the JavaScript ecosystem is almost irrelevant, and browser updates are something Phaser should be concerned about, not them. Indeed for lots of them they may not even care about the browser at all, their destination instead being a native desktop or mobile app. They just want to make games with as minimal 'fluff' and tooling getting in their way as possible.

The Web Developers are on the opposite side of this fence. Mostly they're web developers by trade who have been asked to make a game, or have game dev as a side-interest or hobby. They do care about the web stack and JavaScript best practices. They worry about integrating their games into Ember apps or streaming in data from React Flux, and they care about modularity and file sizes. These devs are the ones bending Phaser into environments it was never intended to live: banner ads, interactive campaigns, digital tools and such like.

As you'd expect, within each camp there are varying levels of skills. Professional developers vs. hobbyists. Agencies vs. students. Each needing different levels of access to the underlying APIs.

The Future of Web Game Development

Having seen how many different places Phaser games have been used over 2015 (and indeed before) made me realize that the "One size fits all" approach taken with Phaser doesn't apply any more.

Lazer was going to have to change that, and it required both building it differently and thinking differently from the outset.

The best analogy I can come up with is to think of Lazer as being a massive box of Lego bricks. Hundreds of bricks. And each brick constitutes a single function. Some naturally fit with other bricks to create mini-sets, but on the whole they are designed to be as independent as possible.

Along with all of these bricks we will also be providing pre-built sets. I.e. collections of bricks, slotted together in a specific way, exposing a friendly API.

The pre-built versions of Lazer that we release will be our choices of which "Lego sets" work well together in a single collection. They will offer the most Phaser-like experience possible. These will be the 'lazer.js' files ready for instant consumption into your projects should you wish.

But as anyone who has played with Lego knows: Sometimes you just don't want to follow the instructions. Often to make what you really want, you need to pull in bricks from elsewhere, and tweak things until looks the way you wanted. This is where the flexibility of Lazers new structure will come in.

To drop the Lego analogy for a moment consider this scenario: You've been tasked with creating a particle effect to go behind a product logo on a web site you're building. Each particle is a single image. You don't need any masks, blend modes, native Graphics effects, tweens, sound, state management, user input, joypad support, etc. It's just a particle effect after all.

As it stands today you could easily fire-up Phaser to create this. Using a Custom Build you can exclude the more obvious things like the Sound Manager or Joypad support. But you're still getting loads of things you don't need. You could use Pixi on its own, skipping Phaser entirely. But even then you're carrying around a complex renderer with all of its shader support, Graphics handling, masks and more all there, even though you don't need any of that.

Indeed for a particle system like this you don't even need a display list. The particles won't need children of their own, so transform matrix calculations aren't even unnecessary. Pixi works on the basis of using interleaved vertex quad and color data with GL TRIANGLES. This is perfect in lots of cases, but for this it's a slight overkill and GL POINTs would make more sense, assuming you don't do the whole effect in a shader.

As it stands today you simply can't make these kinds of changes without a massive amount of refactoring. It's as if the Lego bricks have been put together with super-glue, and prizing them apart involves snapping a few, denting some others and generally getting in a mess.

And what if instead of using WebGL what you really wanted was for the particles to be SVG objects? Right now you don't even have a Lego set to deal with that, and you're left scouring npm or GitHub looking for alternatives.

This may sound like a convoluted scenario. But based on the discussions I've had with developers over the past year I don't believe it's too far from the truth. Phaser has been pushed and pulled into environments and onto platforms it was never intended for. And developers have struggled as a result, and I've been left feeling deflated because it should have been possible to use it in that way, had we approached things differently from the start.

So with Lazer the 'bricks' will be kept as absolutely separate as possible, allowing you to build whatever you want, from as few of them as you like. Because this is where web development has gone, and it's where game development that is built from web technologies should head as well. No more assumptions about "do it this way", instead just common and clear exchanges of data and plain JavaScript objects. If you need to get in there and replace one tiny part of Lazer that should be trivial for you, not an ordeal.

Yes, we will always provide a pre-built version of Lazer with no barrier to entry, just like we did with Phaser. But unlike with Phaser it won't be the only way of making something.

The Principle of Least Astonishment

Now you know the mentality and reasoning behind the change, I can explain the key tenants driving everything that is being done:

• Do One Thing and Do It Well. Also known as the Unix philosophy the concept is as obvious as its name. It will be applied to all of the functions and modules that make-up Lazer. It will also make it easier to write test-cases.

• The Principle of Least Astonishment. Although this originally comes from the UI world it applies very well here. It should be clear exactly what a function does through a combination of the module name and function name. There should be no 'magic' involved at this level. Magic will be permitted higher-up, in the 'friendly API' layer, but the core functions driving everything under the hood will do exactly what they say and nothing more.

• Monorepo. Lazer will use a monorepo approach, rather than a manyrepo. The main reason for this is ease of use from my perspective. The time involved in updating and maintaining what would otherwise be thousands of repos (one per function / module) would be truly insane. It would also create massive dependencies chains for your projects. So a single monorepo is the way forward for Lazer.

• Composition over Inheritance. There are hundreds of opinionated posts out there about how 'classes' are the worst thing to ever happen to JavaScript, and how the inheritance model is broken, yadda, yadda. It's a religious war, not a technical one, and frankly I don't fall into either camp. However because the whole structure of Lazer is to be composed of lots of single-use functions, it makes a great deal of sense that it favors composition over inheritance where possible. That doesn't mean there won't be any classes used in Lazer, there will. But they will be kept to an absolute minimum and only used where there are genuine performance concerns.

• Data Designed Approach. This fits neatly with the previous point. The underlying functions are created, and expected, to exchange data or plain JavaScript objects, not instances of classes. As long as you provide an object to a function that has the properties it needs, it can work with that data and return it back to you. Data will go through as few changes as possible before being used - after all data manipulation is the most expensive part of nearly all frameworks, so ensuring the data structures are clean enough at the outset will help with this. It also makes the functions useful outside of Lazer. I absolutely want developers to be able to import whatever Lazer functions they like and use them directly. As long as the functions expect and provide clean data this will be entirely possible.

• Three Dimensions. A lot of work is being done to ensure that Lazer can support 3D natively going forward. Although 3D is a huge area, and almost certainly won't be supported in the first Lazer release, it was important that all functions and data structures we created from the outset took 3D into consideration. It's something we will definitely have in the future, so being careful not to hedge ourselves into a 2D corner is an important decision.

• Have Fun. I appreciate this sounds strange, but it's important. You should be able to genuinely have fun while working with Lazer. I want it to do things that excite you. I want it to be flexible enough that when it doesn't do something quite the way you need, you can tweak it so that it does with minimal effort. I want to see you all creating your own Lego bricks, and putting things together in your own way, and I want you to have fun while doing it. I fully expect that given time we'll see game frameworks built from Lazer.

So far I've managed to adhere to most of the above. There's a long way to go yet, and I could certainly do with your support, both via the mailing list and the forum. This is genuinely exciting. I'm very pleased with development so far. I'm pleased with the approach. The way it's all slotting together and what this ultimately means for the future of Lazer.

2015 Highlights

2015 was an incredible year for Phaser. The diversity and range of games and tools created with it was outstanding. I will pick out a few highlights:

• The very first news post of 2015 was this Sokoban tutorial written by Emanuele Feronato. Emanuele went on to author a huge number of Phaser tutorials through-out 2015 and is easily the most prolific author to date.

• The Booster Media studio released a number of games, including the beautiful Jewel Academy. They would go on to release more high-quality titles such as Bubble Fever and Scrappy Dog.

• In February Zenva opened their game dev kickstarter. This was successfully funded and as a result they created piles of quality video content teaching you how to make all kinds of Phaser games. Zenva also become a Phaser patron.

• Also in February I did an interview with Matt and Geoff on the Lostcast podcast 110, which was great fun as always.

• At the end of February Phaser was built into the Intel XDK as an officially supported package. Pretty cool!

• How about some robots playing HTML5 games? Sure, why not. The Pepper Robot proved that Phaser could be used in areas that I would have never imagined, ever.

• Mega Death Space Stalin Super Fun Time YEA!!! wins the award for 'Strangest Game Title of the Year'.

• Ananias was a lovely turn-based rogue-like. Son of Blagger Remake showed that retro-remakes live-on strong!

• In September I released Interphase 1. I had a lot of fun writing this with Ilija, and both of us were extremely pleased with the end result. The book continues to sell well and helps fun further development of Phaser. It's a shame that Interphase 2 had to be delayed to 2016 though.

• A Phaser game was used to promote the new Iron Maiden album: Speed of Light, and also featured in the video of one of their songs! Seriously, seriously cool :)

• Phaser was also used to power the Dr. Who Game Maker and the East Enders: Soap Factor.

• The game studio Cangrejo Ideas released some incredibly high quality games in 2015. Including the beautiful (and utterly addictive) Sea Bubble Pirates, Bubble Penguins and Magic Stones.

• In October the first issue of Phaser World was published. This weekly newsletter rounds-up all of the cool things that have been going-on on the Phaser site that week. Thanks to some custom php scripts to help me automate it's creation I've managed to publish an issue every Friday since starting it. Phaser World currently has 4575 readers. It will be interesting to see what that number is next year.

• At the end of August the Phaser Slack channel was created. I love Slack, and although you're not really supposed to use it in the way we are, what the heck - it's still great :) We've currently 239 people on the channel, so feel free to join us!

There were some outstanding games released in 2015. You can browse through all of the Staff Picks for yourself. Like I said, the quality bar was raised significantly, and I think this really shows.

Phaser on Patreon

In July of 2015 I started a Patreon campaign for Phaser. After a few days of opening I wrote this:

"I always hoped that others would share the same passion as I do for the future of Phaser, but when you ask people to commit to that same vision with money it's always a scary moment. And yet here we are after just a few days, with our first goal genuinely in sight! I can't express how grateful I am to those who have become patrons so far."

Those words still hold true. Entering 2016 we've got 77 patrons and raise $1,248 per month. Thanks to this amount, and sales of Phaser plugins and books, it has allowed me to 'save up' for a solid 3 months worth of Phaser / Lazer development to kick-off 2016. That's a great way to start the New Year :) Please don't ever under-estimate how much I appreciate those who support me on Patreon. Your money is genuinely used to help me focus on development. I still need to supplement it with income from client work, but it goes a long way to my ultimate goal of working on Phaser full-time, so thank you.

Phaser Plugin Sales

If I want to be in a position to work on Phaser full-time then I need to have a steady income from it. Yet making income from an open source project is extremely difficult. When the core 'product' itself is free, all you can really sell are either things that enhance the product (i.e. plugins) or training materials (books and courses).

Still, I was determined to give it a go and experimented with quite a few things in 2015.

I started out selling via FastSpring, but their interface and checkout process was so archaic the conversion rates were terrible. During March I moved to Gumroad for a few weeks. Their interface was perfect, and the admin area wonderful. Sales dramatically went up as a result, but they didn't support PayPal and it was costing me a lot of lost sales. So I moved to Paddle, who had a similar checkout experience to Gumroad but did accept PayPal. Unfortunately the Paddle back-end isn't very comprehensive and has hardly any features. But it worked and sales went up as a result. I remained using them for a few months until Gumroad announced PayPal support in August. As soon as they did I moved back to Gumroad and haven't looked back since. They've gone from strength to strength, and recent innovations there have sealed my ecommerce future with them.

By the end of 2015 I had 5 plugins and 3 books on sale, with a 'bundle pack' that sold them all together at a reduced rate. I also have a handful of affiliates who sell on my behalf. They each get 50% of any sale they make. If you're reading this, have a decent level of traffic to your site, and would like to be an affiliate then email me.

Since August 2015 (which is when I started using Gumroad again) we sold 1,691 products which earned $43,822 in total. Not all of that is direct income of course. It doesn't factor in affiliate commissions (50%) or company tax (20%). The total also includes pre-sales of Interphase 2, and I also give a % of sales from Interphase 1 to the co-author Ilija. Even so, it's a good amount to be earning from an open source project.

By far and away the single biggest selling product was Interphase 1. Out of those 1,691 products sold, 1,140 of them were Interphase 1. This just goes to show that the demand for knowledge, by way of books, far outstrips the demand for plugins. It was really useful to learn this and it will influence everything we do in 2016. As you can see from the total we're not that far off being able to sustain Phaser development full-time. Factoring in Patreon contributions as well I'd say I'm about half-way to the amount I need per month to cover payroll and bills. But as already stated I definitely want to try and make this 100% by the year end.

Code.org use Phaser to build Minecraft game

Let's end on my personal favorite Phaser highlight of 2015. It came about late in the year when Code.org used Phaser to create the Minecraft "Hour of Code" game. Over 20 million students used the site to learn how to code during the week. Although of course the majority of them didn't even know Phaser was under the hood, that doesn't matter to me :)

Code.org developer Brian Jordan explains their decision to use Phaser:

"When kicking off development for the Minecraft tutorial, I did a good bit of research on options for HTML5 game engines out there. We were going to be under a tight schedule and collaborating with engineers and artists on Microsoft's Minecraft Education team, so I wanted to provide an environment familiar to experienced game developers and artists.

For previous tutorials, we'd custom-written straight SVG and Canvas visualizations, but this time I wanted to find something that'd give us semi-transparent spritesheets, z-index sorting, tweens with common easing functions and a camera class out of the box. We've been bitten by countless browser-specific bugs in the past, so going with something with a simple interface that has a track record of field testing was extremely appealing.

Phaser checked all of the boxes, so I made a minimal test playground to check performance across all of our supported browsers (IE9+, iOS, Android, Firefox, Safari, Chrome). Everything worked, and the frame rate was great up to a large number of animated sprites.

The example code and docs available for Phaser are fantastic. Between the Phaser Examples and Game Mechanic Explorer, it was quickly obvious what would be quick and easy.

Without using a nice framework like Phaser, I'm not sure we would have had time to throw in a larger-than-10x10 final free play level (game.camera.follow(playerSprite);), a fast-speed mode for tests, Texture Packer spritesheets or proper asset pre-loading.

Thanks for putting the work in to make Phaser cross-browser compatible and well-documented. Spending a bit of time vetting it early on ended up being a worthwhile investment, and paid off in sweet, nearly-free features toward the end of the project. Phaser worked out great, glad we went with it!"

:)

2016 here we come ...

I've already talked about what Phaser and Lazer will become in 2016. For me personally I would very much like to be in a position where I can work on them full-time. This is an ambitious goal, but one I hope to achieve by the year end.

Whatever happens it's going to be another exciting year for web game development. I'm sure it will be full of it's usual trials and tribulations as well! I predict Apple causing us more grief with further product and iOS updates. I predict ES7 throwing spanners into the transpiler worlds. But on the whole it's yet another exciting time to be a developer, and long may that last.

Happy New Year everyone!

Rich