Jump to content

Most Liked Content

#29053 Phaser 2.0.0 Released!

Posted by rich on 14 March 2014 - 07:47 AM

After a LOT of hard work I finally pushed Phaser 2.0.0 out today! It literally only just snuck into the March 13th release date :) But I'm super happy with this build. The headlines:


1) Pixi 1.5 under the hood = much faster in nearly all cases

2) Multi-physics engine support: Arcade, p2.js full Body and Ninja.

3) Better Group handling - more sensible parenting, less code, better child support, faster.

4) Better Text handling - Bitmap Fonts with spaces in the name! Text shadows, text events, web fonts, etc.

5) More consistent input events across more game objects than before.

6) Literally hundreds of bug fixes. I cleared out github entirely :)

7) Much better tilemap collision than ever before - tile delta options, tile padding on bodies, faster getTiles, faster rendering

8) Tilemaps supported across Arcade, p2 and Ninja!

9) Lots of bizarre physics bugs nuked.

10) Retro Fonts :)

11) Tilemap ray casting :)

12) Load Lime/Corona polygon files direct into p2 bodies.


and loads I forget because I've not slept for 26 hours :)


In short ...




It's all on the repo: https://github.com/photonstorm/phaser


Site to be updated when I'm back in the land of the living.


Thanks to everyone who helped test and reported bugs :)

  • Mike, abiyasa, nem0ff and 16 others like this

#23179 Phaser 1.1.4 Released!

Posted by rich on 05 February 2014 - 07:17 PM

I'm really pleased to announce that the long-awaited 1.1.4 is finally out. There is a full write-up about it on my blog here:




Thank you to everyone who contributed feedback and testing during development. This is a significant upgrade, so be careful before blindly upgrading from 1.1.3 if your game is well established under that codebase.


If you find issues (and I'm sure you will!) please check the Examples first to see if there is a new way of handling things, then post about it on the forum (don't clog up this thread, it will be impossible for us to keep track, create a new one). Or use github issues too.


Thanks everyone :)


  • Mike, Hsaka, Bodman and 10 others like this

#1647 Learning to write (good) JavaScript - resources for beginners

Posted by Chris on 16 April 2013 - 09:57 PM

Hey guys,

since we have a few beginners here on board, trying to make their first steps in the world of HTML5 games, I thought it might be good to point you to a few resources about how to learn to write good javascript code.


JavaScript is a language where you have to be a bit careful about your syntax and code style if you want to write maintainable and readable code in the long run.


The advice I give to most newcomers is: DONT dive right into developing a complex game! First learn how to handle the language properly.

Spending a week or two with reading through a good JavaScript book and a couple of tutorials will give you enough knowledge that will increase your development speed a thousand times and helps you avoid common pitfalls for beginners.


I would suggest every beginner to first decide for a good IDE that supports code completion and syntax checking. If they even support jshintyou can't wish for much more!

A few IDEs are: Netbeans, WebStorm, Microsoft Visual Studio, heck even Dreamweaver. Just pick one you like.



Okay, lets throw a bit content at your brains! First out, a few books I can personally recomment reading:



JavaScript - The Good Parts by Douglas Crockford

O'Reilly, ISBN: 0596517742

Good for beginners


JavaScript Patterns by Stoyan Stefanov

O'Reilly, ISBN: 978-0-596-80675-0

Very good for beginners


JavaScript - The Definitive Guide by David Flanagan

O'Reilly, ISBN: 0596805527


JavaScript Cookbook by Shelley Powers

O'Reilly, ISBN: 978-0-596-80613-2


JavaScript Web Applications by Alex MacCaw

O'Reilly, ISBN: 978-1-449-30351-8

For advanced users


High Performance JavaScript by Nicholas C. Zakas

O'Reilly, ISBN: 978-0-596-80279-0

For users with basic to advanced knowledge


You may find some of this books in digital PDF format, if you google for it.


A list of more books in digital format: http://jsbooks.revolunet.com/

I also recommend a look at the digital books from Addy Osmani.




We don't stop there. When you read even only the top two books of this list, you are armed with a set of JavaScript knowledge to develop 99%

of the games you want to.


Lets continue with a list of online resources, for the more digitally aligned people out there :)



Basic introduction into Javascript

For beginners and advanced users. Explains what JavaScript is and how it works.




JavaScript learning portal by Mozilla

Take this as your starting point for learning JS online. Mozilla gathers many notable sources and links of good tutorials and documentation on this page. This is one of the best sources for beginners, as well as for advanced users to learn something new.



Google Code University: Videos for fundamental JavaScript understandment

If you are looking for a quick introduction, watch this videos. The two JS videos are both about 17 minutes long and will give you a good basic understandment if you are a beginner.

There are also videos about CSS and HTML on this page.



Learning advanced JavaScript by John Resig

This information collection by John Resig covers basic mechanics of JavaScript but they are meant to be used as supportive content to his upcoming JS book, so lack descriptions and comments.

We recommend to use this only if you already have a fundamental understandment of JS.



Mozilla JavaScript Guide

This advanced JS guide shows you how to work with JavaScript in the browser, what pitfalls and differences you have to watch out for in the different JS versions and good tips and best practices about debugging your JS code.



Best practices guide by the Opera guys

This very long article covers many many good tips about what you should avoid when coding with JS. Many beginners mistakes are covered and explained why they should be avoided.



Usage cases for JavaScript by the Opera guys

This article covers the topic what you can achieve with using JS on your websites in the first place. You have many resources for learning JavaScript now - so this one covers what it enables you to do.



JavaScript Garden

A growing collection of documentation about the most quirky parts of the JavaScript programming language. It gives advice to avoid common mistakes and subtle bugs, as well as performance issues and bad practices, that non-expert JavaScript programmers may encounter on their endeavours into the depths of the language.



Code Academy

An interactive way to learn coding, with live examples, you solve directly in the browser.





Thats my 50 cent to help the beginners starting with JavaScript.

If you want to add something here I forgot to cover, just post me suggestions. :)




  • benny!, Mike, EmployeeNumber8 and 10 others like this

#26655 Kiwi.js vs Phaser

Posted by rich on 27 February 2014 - 04:24 PM

The important thing to look at with those posts is the date on them, to appreciate what happened and when. But this is a perfectly fair question, so here goes a little history lesson :)


When I left my previous company and started Photon Storm full time, my first project was to help build Kiwi.js for a company in New Zealand called Instinct Entertainment. It was just myself and one other part-time developer (the massively talented Ross Kettle). We had nothing to work from, no template as such, so we were literally creating it on the fly - and what's more, the html5 landscape was constantly shifting beneath us as well (back then even iOS hadn't accelerated canvas fully yet).


After a few months we made the jump from plain JavaScript to TypeScript. This actually helped the project significantly at the time, as we had structure and clarity that was a bit lacking before. But I also needed to start doing client games as well (to pay the bills basically, as fun as frameworks are, they don't make you much money :)) so my time was now split between Kiwi and client games. And I used Kiwi for most of those early games, which helped it grow and develop. But still I was essentially coding on my own most the time, and after a while that gets really tiring. Ross was doing loads as well, but like me he had his own projects too, so we'd get strange boughts of him not being able to do anything for a few weeks, and then doing loads, and the same from my end, and it all kind of gets mixed and muddled up (it's not a great way to run a project in hindsight). Even so I coded for months: days, nights, nights into mornings, literally thousands of lines of code.


Kiwi was still closed-source at this point and was a quite monstrously sized project. Too much so really. At the time I really wanted it to support DOM as well as Canvas, and spent a good while refactoring to support this. In hindsight it probably didn't need it, but back then DOM was still significantly faster than Canvas in most browsers (you could argue, for certain games, it still is) but of course adding this dependency didn't help with the scale of the project. So I'm literally burning the candle at both ends, trying to manage a hugely growing small business and trying to keep Kiwi moving forwards with effectively zero project management.


Remember no-one else was allowed to see what we were doing, we couldn't release it onto github (due to funding applications going on at the time) and it was all just getting too much. There weren't enough hours in the day to manage it all and I basically burnt out.


To try and rekindle my love for it I literally spent a weekend while the family was away hacking together a crude conversion of Flixel. I literally copied it wholesale, having to rebuild classes that existed in AS3 and porting the others. A couple of days later I was done - it was small, clean and just worked, because it only tried to do a few things so it did them pretty well. It was called Kiwi Lite (a name that I feel is a strong indication of my mindset at the time) and I wanted to release it on github. I was told I couldn't use the name as Kiwi had to remain closed at that time. So I asked Adam (creator of flixel) if I could call it Flixel5, but he said he'd rather I didn't as it would confuse things with the Flash build. So I spent an hour brainstorming some names with my good friend Ilija and we settled on Phaser. He drew a cool little space dude sprite and logo and the first build was pushed to github on April 12th 2013.


I had always intended it to be a 'younger brother' to the much more sophisticated and feature-complete Kiwi.js, and for a good while that is how it remained. But an interesting thing happened: other people started using it. It started to take on a life of its own, and a small but constant trickle of devs started submitting pull requests and bug fixes. And then people actually started making games with it. And this does a curious thing when you've been working effectively in isolation for so long: it motivates you, like nothing else possibly can.


And although I carried on working on both for a while, I slowly drifted away to Phaser because I was getting real tangible feedback and support, and it was infectious. The team at Instinct hired other devs to work on Kiwi and they've done an excellent job of cleaning it up, adding in WebGL support and making it a really attractive framework, and they released the first beta late last year (and didn't even tell me :P). It's still TypeScript to the core, something I moved away from with Phaser - a move that's well documented on the forum if you want to read about my troubles with it!, but it's well worth looking at and using, especially if you like TypeScript or come from AS3.


And while they were finishing Kiwi, Phaser evolved. When I swapped to plain JavaScript that was the same time I swapped to using Pixi.js under the hood, mostly because Mat is such a great guy :) but also because it was tiny and clean and it made sense to me. Version 1.0 was released just under six months ago, and for some reason it's hit a real chord with developers.


Just so we're clear there is (or was) no 'breach of contract' here. There was a simple agreement in place, and I literally poured my heart and soul in Kiwi development for months, way more time than agreed (or ever invoiced for!) because I believed in what I was building. I'm not involved in development of it any more though, because it's no longer my "baby". A lot of work has been done on it, lots of internals changed (for the better) and the new devs own it now. It's their creation and they don't need me sticking my oar in.

I've really held back from promoting Phaser, I think in part because I felt guilty and somewhat humbled that people even liked it and used it! And I wanted to give Kiwi time to release and establish itself. You can count the number of posts about it on my blog on one hand for example, and even though it has been ready for months the web site is still just a single pager. But that didn't stop it growing in popularity. I'm genuinely amazed at how well it's going. I'm not really doing anything other than trying to constantly improve it and help people use it, but I guess those are 2 quite fundamental things :)
Phaser 2.0 is finally the version I'm truly, genuinely 100% happy with. I've spent weeks fixing bugs, making it simpler under the hood, using Pixi.js more intelligently and improving it as much as I can. It's taken a long time and a lot of work to get to this point and as corny as it sounds, absolutely none of this would have  happened if it hadn't been for the community around it. The more people that use it, the more I want to make it better. And for those that submit pull requests and help fix bugs, you're the best :) When 2.0 ships in March I'm no longer going to hold back from promoting it, so you'll see it appearing in a lot more places and things will step-up a gear around the site and tutorials.
tl:dr - I spent a long time working on Kiwi, but am no longer part of that team. It's a great framework and well worth using. Phaser was a weekend creation born from a pit of frustration/depression that went mental and grew into what you see today, utterly unplanned, but utterly wonderful because of it.

  • Mike, nem0ff, Jorasso and 9 others like this

#9878 The Decline Of Common Sponsors

Posted by rich on 22 September 2013 - 03:27 PM

I've got nothing personal with him, all I'm saying is that if the average html5 quality is far from the average Flash one. There is a lot of potential to up the quality of HTML5 games, whereas the prices are already declining as I hear.


There's two sides to this - yes we can up the quality, but only to a certain point. We just can't do on mobile browser what Flash can do on desktop. The performance simply isn't there, so comments like "the quality will just keep getting higher" are only true to a point. I think production values will improve massively, but the platform is what it is, and having years of experience under your belt won't give you a magical extra 50% CPU power or something.


I've not seen any decline in prices either. They have always been pretty low!


For me the area where HTML5 is most interesting has always been commercial / client work. The demand for this is quite frankly insane at the moment and it is not letting up. I get far more enquiries for new projects than I could ever cope with. If you're a good developer (with time available to spare) then seriously drop me a line, I could easily put several thousand $ of work your way every month. What is interesting is that this isn't going to change either. Flash is dying out commercially. Clients who a few years ago wouldn't question using it now need HTML5 games built, and the experience just isn't out there to meet the demand. This doesn't suite an 'indie' lifestyle though, and it's a very different sort of work to making the types of games you enjoy yourself. But it pays extremely well if you're good at it.

  • PixelPicoSean, True Valhalla, haden and 8 others like this

#24039 Phaser 1.1.5 Released and where we're going next

Posted by rich on 12 February 2014 - 03:54 PM

Hi all,


I've just pushed Phaser 1.1.5 to the master branch on github. This fixes a range of bugs, including a few physics ones, missing documentation and fixed TypeScript defs.


It also includes a "Call to arms" to help test Phaser 1.2, which I'd urge you to help with if you can.


Please note that I will still accept pull requests against the dev branch for a potential 1.1.6 release, but that I won't be fixing any of the outstanding current physics issues because progress with 1.2 has been so fast, and basically so awesome that I don't want to waste any time patching ArcadePhysics as it has been removed entirely from 1.2.


Believe me I carefully considered this. As I see it there are two options: Get 1.2 out FAST and forget 1.1.4 ever existed, or struggle to work on both and slow down the development of each of them. While I could potentially do a roll-back to 1.1.3 and include the tilemap features of 1.1.4, that is still quite a chunk of work to undertake. I was considering it though right up until this week, but to be honest 1.2 is more than just replacing physics, it's a deep change across most of it.


I probably should have left 1.1.4 in dev only, but there were so many fixes in there (well outside of physics, not that you can call that 'fixed') that it seemed a shame to just not release it at all. Trust me, I didn't want it to be quite as broken as it is in some cases. Lots of 1.1.4 works better than previously, but given the biggest overhaul was the tilemaps it's ironic that it's those sort of games that have the issues the most (because of the physics changes).


Right now though I can't state enough how fast 1.2 has moved. The new version of Pixi has made life considerably better for me, p2.js is bloody wonderful and I'm using 1.2 exclusively for client work now. If anything I think it's fair to say that the issues I know about with 1.1.4 are a dramatic form of motivation to ship 1.2 faster!


I fully expect to have 1.2 released this month. It's a serious "tidy up" release. So many things removed, made neater, made smaller and basically all a bit more smarter. The new Pixi is doing wonders under the hood, and having a proper real physics system in there is making all the difference for our client projects, so I'm sure you'll enjoy it too!

  • haden, Hsaka, tackle and 8 others like this

#33662 Phaser 2.0.3 Released

Posted by rich on 11 April 2014 - 01:11 PM

Hi all,


I'm pleased to announce that we've just released Phaser 2.0.3 onto Github




In this release we have upgraded both pixi.js to v1.5.2 and p2.js to v0.5.0. This improves features and stability across the whole framework, and as always you'll find the complete list of improvements in the change log.




We've taken some time to enhance the Particle Emitter adding a few substantial features such as the ability for Particles to now change scale or alpha over time using any of the easing functions, or apply a blend mode. These small additions now allow you to create visually more impressive effects than before, and while we still have a complete overhaul of the particle system on our roadmap it's a welcome boost in the meantime.


Along with the p2.js update we have also refined the Phaser P2 classes, making tweaks that help overall performance, such as splitting the world bounds into separate bodies. The World now has a default contact material, which allows for easier setting of responses when objects collide with no materials set. All in all it's a powerful update.


What's interesting is that loads of the new features and bug fixes in this release have come direct from the community. Of course we've been busy and working hard on Phaser as well, but the volume of contributors now is fantastic. We've have always listed their names next to the issues they helped resolve, but now we're doing so with their github usernames directly so they appear on the revisions change log.


As promised with the 2.0.0 release we have done all of this without changing existing API calls in the core Phaser classes. New features are introduced either via the creation of new optional parameters or by creating new methods. Where a feature has been deprecated we have flagged it as such in the docs, but left it in so as to not break existing code.


Some of you may not be aware, but the phaser.min.js file in the build folder contains all 3 physics systems bundled in. We've refined our build process so that it's easy for you to create custom builds now via grunt, but if you know you only need Arcade Physics (and not P2 or Ninja) then you can use phaser-arcade-physics.min.js which is found in the build/custom folder. This will save you 180KB from the minified file size, so please use it if you can.


Have fun everyone :)


  • Hsaka, gaelbeltran, turnA and 7 others like this

#27823 Explaining Phaser 2s multiple physics systems

Posted by rich on 06 March 2014 - 03:52 PM

So a few of you are rightly confused after my recent commits :) Let me explain what's going on with the physics systems inside Phaser ...


As you may know, I've been really happy with p2.js for all of Phasers proper full-body physics requirements. It's excellent and I'm really pleased with how well it integrated. However on mobile it doesn't take long before the frame rate starts to dive. This is no fault of p2, it's having to do a lot of heavy lifting math and mobiles just struggle. Even with just 50 bodies in the scene you can see it start to suffer. So I wanted to offer an option to devs.


In Phaser 2 no Sprites have physics bodies as standard, they all need to be physics enabled (much in the same way you enable them for input). This helps keep things fast. Where-as in 1.x Phaser is spending a LOAD of time processing a physics Body it may never even use.


Arcade Physics, back from the dead


So I decided to go back and resurrect Arcade Physics. Not the broken SAT one in 1.1.4, but the one previous to that. I merged lots of the fixes I had made in 1.1.4 (things like process callbacks actually working properly) with the previously working separation code from 1.1.3. This means that existing 'old' games won't have to be ported over to p2 to run, they can just use Arcade Physics like before - the only difference being they'll need to enable the Sprite bodies. All those annoying/broken things about 1.1.4, like the way gravity and velocity are messed-up, are all fixed.


Because physics is 'off' by default I created a Physics Manager via which you do things like 'enable p2' or 'add a physics body to this sprite'. While I was doing this it occurred to me that you could actually have p2 and arcade physics running together in the same game. p2 could be controlling whatever bodies you give it, and arcade the same. After a few basic tests this was working just fine.


Here is how you activate a physics system:


The important thing to remember is that a single Sprite can only belong to ONE physics system. So you can enable a Sprite for p2 or arcade - but never more than one. It cannot exist in multiple simulations at once.


Here is how you enable a Sprite for say Ninja physics. You can do it directly on the system like so (here creating a new Circle shape):

game.physics.ninja.enableCircle(sprite, radius);

Or you can use the physics manager interface (this will create an AABB shape for the sprite, the default):

game.physics.enable(sprite, Phaser.Physics.NINJA);

In 'enable' calls you can pass in either a single object or a whole array of them.



p2 and Arcade running together


Why on earth might you want to have both running? Well for a lot of games I would say there is what you could call 'simple' and 'advanced' requirements. For example you could have a nice complex polygon terrain all handled by p2, with a car body with  motors/constraints/springs driving happily across it.


But what if you wanted that car to be able to fire up to shoot some aliens overhead? Assuming you can fit those aliens into clean AABB shapes then it's now entirely possible to have the car itself controlled by p2, driving over a p2 managed landscape, but when you shoot it launches a stream of bullets managed entirely by Arcade Physics, and collision with the aliens who are all running under Arcade Physics too. In short you're leaving p2 to deal with just a handful of complex bodies and motion and not bogging it down with ultra simple requirements.


I'm not suggesting that all games will need this, but at least you have the option now.


Great, but what the hell is Ninja Physics?


As I was working through all the above I realised that even with p2 and arcade available, that still doesn't cover all bases that a game may need. What if you wanted to use Box2D? Or Chipmunk? It dawned on me that I should stop referring to the physics systems inside Phaser as just 'arcade' and 'advanced', but actually call them by name. Then I could provide a (mostly) standardised physics Body object, a single Manager to handle them, and then you could use whatever physics system your game actually needs. The Physics World object needs to implement a standard set of methods, but otherwise can work quite independently.


While renaming these classes I remembered that I had spent weeks about a year ago working through the physics system that Metanet Software used in their awesome N+ Flash ninja games and porting it to JavaScript. I had shelved it as it was only suitable for certain types of games and didn't play well with Arcade Physics settings (at the time I was trying to merge some of their collision responses with Arcade Physics). But I dug out the old source files and had a look, and sure enough it was pretty much complete. So to test out my theory of Phaser supporting a variety of physics systems I created Ninja Physics from it, and integrated it.


It's a really nice little physics system, supporting AABB and Circle vs. Tile collision, with lots of defs for sloping, convex and concave tile types. But that's all it does, it's not trying to be anything more really. As you'll see from my Labs demo it works well, and is really quite fast on mobile too.


Which one do I use?!


I've no idea, it depends on your game :) The choice is yours. If you need full-body physics, then p2 obviously. Arcade Physics has proven successful in lots of games so far, so you could carry on using that too. Or maybe if you like what you see re: Ninja's tiles, you could test that out. The important thing is that it's up to you now, and although it requires more careful planning with your game, you can even combine them too.


Phaser doesn't have all of these physics systems running together wasting CPU, they all start off as 'null' objects and do nothing until explicitly activated. I'm also tweaking the grunt scripts so that the build folder will provide versions of phaser with none, one or all physics systems embedded into the code, so they're not going to waste space either. The plan is to carry on adding support for popular physics systems in, most importantly Box2D and Chipmunk. Again these will be separate libs you can bundle in with phaser, with just a single variable stub in the physics manager. As long as the Body and World objects adhere to a few simple requirements, it will 'just work'.


Anyway, hopefully this clears things up a bit! :)

  • Mike, brejep, tackle and 7 others like this

#21461 phaser.js State transition plugin

Posted by xnamex on 24 January 2014 - 12:20 PM

Hi everybody,


Pretty new to Phaser.js but kind of old to AS3 :)


I just started to port a as3 game into html5 with phaser, but my client wanted transitions between states - just like my game had in flash. Therefore I created a plugin just for this.


You can find it here: https://github.com/c...tate-transition


Let me know, what you guys think, or what can be improved.



  • haden, plicatibu, shawnbless and 7 others like this

#12456 Phaser 1.1 is released :)

Posted by rich on 25 October 2013 - 06:00 PM



We're really pleased to announce that Phaser version 1.1 was just released and pushed to the master branch of our github repo. We've worked extremely hard on this release to make Phaser the most stable and powerful 2D HTML5 game framework we can.


Here are some of the headline new features:


API Docs are live!


We know these were a long time coming, but we've finally documented nearly every part of the framework with jsdoc3 and published the resulting docs as well. So you can at least now look at the docs first before having to dig through the source code to figure things out. We've still got more work to do in this area, but it's a great start.


150+ Examples!


We've got a brand new Example Test Suite, with a great design, two display modes (full stack or side-by-side) and over 150 different examples for you to work through. We've tried to cover all of the core features of Phaser, there are even little mini games included (some in more complete states than others) and lots of demos.


What's more, we're looking for new Examples to add to our collection and we've got prizes for the best submission each month :)


Enhanced Arcade Physics


The Arcade Physics system that ships with Phaser has been almost completely rewritten. It's now considerably more robust than before, the Sprite update loop has been heavily optimised and refined, and collision is now a lot more stable. Gone are the 'jitters' and potential wall-sticking of the previous release!

Infinite Worlds
The way in which the game world operates has changed significantly. The World is now an infinite plain extending in all directions as far as you need, with 0,0 being the centre of the world. The Camera now roams within this endless world, which you can resize dynamically. This gives you some powerful new features - for example you can now rotate the world around its axis, for truly different sorts of games. You can extend it vertically for a scrolling shoot-em-up or in all directions for an 8-way scroller. It's a whole lot more powerful and we made a new example game Tanks to show it off.
Bug Fixes galore!
We've tightened up, updated and fixed literally hundreds of bugs across all parts of the framework. Virtually every reported issue on github has been resolved and cleared down, as well as numerous things we found ourselves and had reported on the forum.
Thank you to everyone who helped out with this release. To Alvin for his tireless work sorting out the Examples and helping me every week, to all the great people in the forum who keep showing me amazing stuff they're making, and to those reporting issues, helping with fixes.
Please grab version 1.1 from the github repo and as always we look forward to your feedback!

  • benny!, Noid, Hsaka and 7 others like this

#25939 Phaser 1.1.6 Released ("Shienar") - the last of the 1.x family

Posted by rich on 24 February 2014 - 02:02 AM

Hi all,


As we start finishing-up the Phaser 2.0 release we noticed that there were still a number of great additions made in the dev branch or via feedback that we didn't want to ignore. So tonight I pushed the 1.1.6 release which contains some small but essential physics and tilemap fixes, lots of documentation updates and other bug fixes across the core which you can see on github: https://github.com/photonstorm/phaser


This signifies the final release in the 1.x family. A version which has done us extremely proud since the 1.0 release back on September 13th 2013. It may seem like quite a jump from a 1.0 to 2.0 in just six months, but that's how fast the library has evolved, mostly in part to the awesome feedback and support we see on these forums. We will focus on solidifying the API and freezing it as much as possible when 2.0 ships this March, as we're now seeing Phaser being used widely in the industry and starting to be picked up in education too, where a fixed API is a requirement. Before we were able to shift the API around at will, moving and changing things as we saw fit - but we now have a much wider responsibility and one we're taking very seriously from 2.0 onwards.


It's a shame that 1.x will end with some known physics issues still outstanding, and I do apologise for that. But it was a case of splitting resource in half and slowing down progression of both 2.0 and 1.x, or accepting that we needed to move to a proper full-body physics system, and fast. If anything the issues we know exist in 1.1.4+ helped motivate us like nothing on earth to get 2.0 shipped as soon as possible, and we're extremely happy with progress and performance so far.


At this point in time we're aiming for a March 13th release date. After which we'll take stock and focus purely on tutorials and sample games for a while.


To everyone who has used Phaser, in whatever incarnation, thank you.

  • Hsaka, tackle, aberrantmind and 6 others like this

#25414 Tutorial: How to make a Flappy Bird in HTML5 with Phaser

Posted by lessmilk on 20 February 2014 - 04:36 PM



I just wrote a Phaser tutorial on how to make a simple Flappy Bird clone in 65 lines of Javascript.


You can read the tutorial here: blog.lessmilk.com

Edit: And here's the part 2 of the tutorial.


FB 2.png


If you are new to Phaser, this can be a good way to discover how Phaser works.

And if you already know well Phaser, I'd love to hear your feedback!


Thanks :-)

  • Lonan, Arlefreak, plicatibu and 6 others like this

#25079 Common Phaser + CocoonJS issues

Posted by Videlais on 19 February 2014 - 02:16 AM

Last update of this information was 16 April 2014.


Note: As of this writing, CocoonJS comes in two versions (1.4.7 and 2.0) and a total of five modes.


"System WebView" in both CocoonJS 1.4.7 and 2.0 is the same. It creates an instance of the default browser for a platform, loads its own API, and then hands off the code execution. In most cases, it is the same as running the code in a mobile browser.


For Canvas+ mode (previously accelerated, "Canvas 2D/WEBGL") it strips out things like XML and most DOM and CSS support to make running the canvas as fast as possible. Because of this, most common things like getElementById and createElement in JavaScript have reduced functionality. It is designed purely for Canvas-based projects. (For the 1.4.7 list of available functionality, consult this list. For 2.0, see the changelog from 1.4.7.)


Since there is limited DOM support, make sure to use an empty string for the parent element during the creation of a game object when using the accelerated/Canvas+ mode. (This is to make sure the created canvas element is appended to the document.body object, and not some other element the getElementById function cannot find.)

var game = new Phaser.Game(window.innerWidth, window.innerHeight, Phaser.CANVAS, '', {preload: preload, create: create, update: update});

Issues with Phaser <= 2.0.3 and CocoonJS 2.0 (Canvas+ mode and Canvas+/Accelerated for CocoonJS 1.4.7)


Images not rendering


When using Phaser.CANVAS, there is a problem that sometimes happens where images are not rendered correctly. This affects all functionality that use images.


While still under investigation, the current solution is to introduce at least one other non or default image object to your project or game. Something as simple as including "game.add.sprite(0,0,'')" as part of the create() will bypass the problem.




CocoonJS does not have native support for XML. Its XHR does not return responseXML and it does not have a window.DOMParser object.




Generally, you can use window.innerWidth and window.innerHeight to compute the size of the screen in CocoonJS. However, if you know there might be a device pixel ratio issue, the following code works for that.

var width = window.innerWidth * window.devicePixelRatio;
var height = window.innerHeight * window.devicePixelRatio;

There is also an excellent thread called "How to scale entire game up" that covers some different techniques and has code for different ways to scale groups, the stage, or the canvas size itself.




Because of the lack of XML support, one solution for BitmapFonts is to convert the XML into JSON and use an alternative loader. This post covers the code needed and what to use to convert the XML into JSON.


Audio problems.


Most often, audio problems are related to the device itself, not CocoonJS or Phaser. If you are running on an Android device, make sure you have OGG or WAV files. Apple devices support MP4.


Remember too that MP3 decoding, depending on the device, can often be slow.




When using Phaser.WEBGL, buttons do not seem to receive tap or click events. However, they work fine with Phaser.CANVAS.


Issues with Phaser <= 2.0 and CocoonJS <= 1.4.7:


Basic Text Support


As detailed in the "Issues with Phaser <= 1.1.6" section, game.add.text will often not work correctly. Because the accelerated mode does not have a full CSS model, the line-height of the internal Phaser object will be incorrect and often draw the text misshapen or not at all.


Until a better solution or patch is accepted, it is recommended to use RetroFonts instead. (See this Phaser example.)




There are several known issues with CocoonJS 1.4.7 and the handling of clipping regions. Until a newer version comes out, it is highly recommended to avoid using WebGL mode with CocoonJS and Phaser. Most drawing of any sort will not display correctly.


Issues with Phaser <= 1.1.6:


The 'DOMContentLoaded' error message when using Phaser.Canvas. [Fixed in Phaser 2.0]


A blank screen when using Phaser.Canvas. [Fixed in Phaser 2.0]


Text problems.


"game.add.text()" does not work correctly. This is not an issue with Phaser, but with CocoonJS and Pixi.js.


There are two solutions to this:

  1. Directly write to the 'screencanvas' itself using calls to fillText() as shown in the following example:

    (Note: CocoonJS does support loading TrueType fonts directly. See the "TrueType Fonts" for the example on the demo page.)

    (function(window, Phaser) {
      var game = new Phaser.Game(window.innerWidth, window.innerHeight, Phaser.CANVAS, '',
              {preload: preload, create: create, update: update});
      function preload() {}
      function create() {}
      function update() {
        writeText("Updated text");
      function writeText(string) {
        var context = game.canvas.getContext('2d');
        context.font = "45px arial";
        context.textAlign = "left";
        context.fillStyle = "#ffffff";
        context.fillText(string, game.world.centerX, game.world.centerY);
    })(window, Phaser);
  2. As introduced in Phaser 2.0, use RetroFonts. These are fixed-width, sprite-based text objects constructed out of the frames of an image.

    The following example code shows how to use them.

    var game = new Phaser.Game(window.innerWidth, window.innerHeight, Phaser.CANVAS, '', { preload: preload, create: create, update: update });
    function preload() {
        game.load.image('knightHawks', 'assets/fonts/retroFonts/KNIGHT3.png');
    var font;
    function create() {
        font = game.add.retroFont('knightHawks', 31, 25, Phaser.RetroFont.TEXT_SET6, 10, 1, 1);
        font.text = 'phaser was here';
        for (var c = 0; c < 19; c++)
            var i = game.add.image(game.world.centerX, c * 32, font);
            i.tint = Math.random() * 0xFFFFFF;
            i.anchor.set(0.5, 1);
    function update() {}


Gamepads. [Fixed in Phaser 2.0 and with this plugin for Android system like Ouya.]

  • haden, sfcal99, Starnut and 6 others like this

#15760 Phaser 1.1.3 "Arafel" Released - Hello WebGL shaders

Posted by rich on 29 November 2013 - 07:02 PM

I'm pleased to say that version 1.1.3 of Phaser is now released!


And we've also now got over 1000 stars on our github project, which is excellent :)


This release focused on updating Phaser to use the latest version of Pixi.js, which introduces the wonderful world of shaders to your WebGL games. We have been busy creating and modifying shaders for your use, and you'll find a bunch of them in the new filters folder in the repository plus examples in the Examples area. They include fire, plasma, light beams, blur effects and lots lots more coming.


There is also a brand new (but still experimental) BitmapData object which we'll work on making more solid over the coming weeks, but it essentially gives you a blank canvas onto which you can draw, plot lines, render text, copy chunks and perform effects and but it can also be used as a texture by any Phaser.Sprite - so dynamic sprite effects are now a whole lot easier. We'll carry on ironing out this class, but it's already pretty powerful.


I have spent a long time updating the documentation as well. Some classes which didn't have any, like all the Tilemap ones, are now fully done. And I've replaced lots of instances of "Description" (i.e. "todo") with actual meaningful descriptions. Many type definitions have also been fixed. Thanks to community help the TypeScript definitions file is now a lot more accurate too.


There is an extensive change log on the github repo, but I've included the 'new' section below.


We will aim to get 1.1.4 released before the end of the year and then start planning out the features that will make 1.2 (almost certainly a proper physics system, as our p2.js tests are going extremely well).


Enjoy everyone!




* Phaser.Filter. A new way to use the new WebGL shaders/filters that the new version of Pixi supports.

* Phaser.BitmapData object. A Canvas you can freely draw to with lots of functions. Can be used as a texture for Sprites. See the new examples and docs for details.

* The entire Phaser library has been updated to match the new JSHint configuration.

* Added a .jshintrc so contributions can be run through JSHint to help retain formatting across the library (thanks kevinthompson)

* Added a new in-built texture. Sprites now use __default if no texture was provided (a 32x32 transparent PNG) or __missing if one was given but not found (a 32x32 black box with a green cross through it)

* Loader can now load JavaScript files. Just use game.load.script('key', 'url') - the file will be turned into a script tag in the document head on successful load.

* RenderTexture.render now takes a Phaser.Group. Also added renderXY for when you don't want to make a new Point object.

* Physics.overlap now supports Sprites, Groups or Emitters and can perform group vs. group (etc) overlap checks with a custom callback and process handler.

* Added Sound.externalNode which allows you to connect a Sound to an external node input rather than the SoundManager gain node.

* Added SoundManager.connectToMaster boolean. Used in conjunction with Sound.externalNode you can easily configure audio nodes to connect together for special effects.

* PluginManager.remove, added PluginManager.removeAll (thanks crazysam)

* scrollFactorX/scrollFactorY have been added to TilemapLayers (thanks jcd-as)

* Phaser.Game parent can now be an HTMLElement or a string (thanks beeglebug)

* Now using the latest version of Pixi.js. Which means you can use all the sexy new WebGL filters :)

* Sprite.animations.getAnimation will return an animation instance which was added by name.

* Added Mouse.button which is set to the button that was pressed: Phaser.Mouse.LEFT_BUTTON, MIDDLE_BUTTON or RIGHT_BUTTON (thanks wKLV)

* Added Mouse.pointerLock signal which you can listen to whenever the browser enters or leaves pointer lock mode.

* StageScaleMode.forceOrientation allows you to lock your game to one orientation and display a Sprite (i.e. a "please rotate" screen) when incorrect.

* World.visible boolean added, toggles rendering of the world on/off entirely.

* Polygon class & drawPolygon method added to Graphics (thanks rjimenezda)

* Added Group.iterate, a powerful way to count or return children that match a certain criteria. Refactored Group to use iterate, lots of repeated code cut.

* Added Group.sort. You can now sort the Group based on any given numeric property (x, y, health), finally you can do depth-sorting :) Example created to show.

* Enhanced renderTexture so it can accept a Phaser.Group object and improved documentation and examples.

* Device.littleEndian boolean added. Only safe to use if the browser supports TypedArrays (which IE9 doesn't, but nearly all others do)

* You can now call game.sound.play() and simply pass it a key. The sound will play if the audio system is unlocked and optionally destroy itself on complete.

* Mouse.capture is a boolean. If set to true then DOM mouse events will have event.preventDefault() applied, if false they will propogate fully.

* The object returned by Math.sinCosGenerator now contains a length property.


  • Mike, Hsaka, Arlefreak and 6 others like this

#11140 1.0.7 progress update

Posted by rich on 09 October 2013 - 01:47 PM

Hi all,


The next version of Phaser (1.0.7) is taking a bit longer to complete than anticipated. We've finished off about 95% of the API docs, have totally overhauled the physics system, sprite bodies and loads of other things. There are some significant changes internally too:


1) Worlds no longer have a fixed size. They are now centered around the 0,0 coordinate and extend infinitely in every direction. You can of course set bounds on them (and the Camera), but equally you are no longer restricted in how those bounds should go - so if you want to make a game that is all about the world rotating around the player it's now really easy.


2) The Camera has been overhauled as well. Following a sprite no longer 'jitters', it has a new bounds system and more importantly it no longer modifies the local position of ANY game object. Before I was updating the objects local transforms based on the camera placement. But this was a bad idea and after a chat with Mat (Pixi.js) we decided it would be far better if the World was a single display object container and the camera just shifts the position of that. This has dramatically reduced the complexity of the Sprite update loop and physics collision, both of which I'm very happy are now solid and robust. Objects can still be "fixed" to the camera (i.e. for UI/HUD) if you need.


3) ArcadePhysics has had a complete overhaul too. The velocities are now properly integrated, all of the motion functions are revamped and working and we've created lots of examples showing them in action. Personally I really love just being able to do: game.physics.moveToPointer(bullet, 800) and have a bullet fly across the screen correctly :)


4) New static html examples! The examples page has been re-designed to match the web site and we're in the process of doing away with the requirement of php to run them. Also we've dropped the examples running inside anonymous functions. They now populate the global scope, which while bad practise for a full game is actually really useful when messing around and learning, as you can open the console and tweak things instantly.


I created a new Tanks game last night to test and show-case most of these new changes:




You can play it here: http://gametest.mobi/tanks/


There is more to do with this game of course, but it's now a good demo of what's possible I reckon.


I still need to finish the documentation (basically the gameobjects folder) but more importantly tilemaps are removed from the current dev branch until I redo the collision handling for them. That is the last final piece of the puzzle before we can launch really. The old (flixel inspired) collision method isn't going to work any more, so it needs to move to something more sophisticated and that will take a little time (if you've got a fully working / 100% robust tilemap collision system that supports slopes then drop me a line! it will help speed things up a lot).


So bear with us, this is a significant update but probably the best we've ever released. I would also really like some people to test it out before we push it live, but I'll post a new thread about that when we're ready as it's changing daily right now.


The full gory change log is here: https://github.com/p...phaser/tree/dev


  • deis, haden, Son of Bryce and 6 others like this

#10543 Documentation

Posted by Alvin on 30 September 2013 - 01:11 PM

Hi everyone,


I'm Alvin, the new member of the Photon Storm team.


The moment you have been waiting for is coming, today we have finished adding the JSDocs blocks to every file, so the full API documentation will be released along with the 1.0.7 update this week.


We are also really pleased to see your enthusiasm in building games with Phaser.


There are also a lot of new examples coming, just hang on a bit more :)

  • Mike, Fla5h, Sanatan and 6 others like this

#9863 Hide HTML5 Sponsers' list

Posted by rich on 22 September 2013 - 09:08 AM

There is no way I'm going to check games before allowing someone access to the forum. The only reason its 'hidden' is because it contains email addresses and I don't want Google indexing it.


It's up to the sponsors to decide if the game is good or bad, not us. If they pick someone elses game over yours then make a better game.

  • nem0ff, @99golems, MikeHart and 5 others like this

#31602 Phaser 2.0.2 Released

Posted by rich on 28 March 2014 - 02:04 AM

I've just pushed to master the 2.0.2 release. If you've been having any issues with ArcadePhysics doing weird things, like flying sprites off the screen, then upgrade!




Here's the change log:


Bug Fixes


* Sprite would glitch if it had an ArcadePhysics Body that was re-positioned out of loop.
* Sprite would "fly off" if it had an ArcadePhysics Body that was re-positioned during an input handler.
* Tween.generateData would enter an eternal loop if the total resulted in a float. Now wrapped in Math.floor.
* ArcadePhysics.Body preUpdate has been modified to stop Sprites with non-1 scaling from gaining delta and moving off the screen (fix #644).
* ArcadePhysics.Body deltaMaxY wasn't being correctly applied.
* P2.World - Removing tilemap layer retrieval for object layers in convertCollisionObjects() (thanks bmceldowney, fix #653)
* Calling Keyboard.stop() wouldn't let you call Keyboard.start() later on in the same game




* The "Build your First Phaser Game" Tutorial has been updated for Phaser 2
* Line.fromSprite now sets "fromCenter" to false by default as Sprite.center is deprecated in 2.x. Documentation and Examples updated to reflect this.
* All the documentation has been re-published for 2.0.2.
* Lots of ArcadePhysics.World methods have been marked as private where they shouldn't be called directly (separateX, etc)
* xtian jshint fixed nearly every single file in the repository!


New Features


* Sprite.overlap lets you quickly check to see if the bounds of two display objects are intersecting or not, without having to use a physics system.
* Keyboard.destroy will now clear all event listeners and any custom set callbacks or Keys.

  • Mike, Hsaka, Lonan and 5 others like this

#15265 Phaser + CocoonJS vs. WebGL scaling finally solved

Posted by GregP on 22 November 2013 - 10:26 PM

Hi Guys, 

Just wanted to share with you the result of my recent struggling with Phaser and CocoonJS - I finally managed to scale my game properly while running in WebGL mode!  :)

I spent some time digging in Phaser and Pixi.js source codes, also this thread was really helpful.


And here's the code:

(function () {
    'use strict';

    var width = navigator.isCocoonJS ? window.innerWidth : 320,
        height = navigator.isCocoonJS ? window.innerHeight : 480,
        game, nanoha;

    game = new Phaser.Game(width, height, Phaser.WEBGL, '', {
        preload: preload,
        create: create,
        update: update

    function preload() {
        game.load.image('bg', 'assets/bg.png');
        game.load.image('nanoha', 'assets/nanoha.png');

    function getRatio(type, w, h) {
        var scaleX = width / w,
            scaleY = height / h,
            result = {
                x: 1,
                y: 1

        switch (type) {
        case 'all':
            result.x = scaleX > scaleY ? scaleY : scaleX;
            result.y = scaleX > scaleY ? scaleY : scaleX;
        case 'fit':
            result.x = scaleX > scaleY ? scaleX : scaleY;
            result.y = scaleX > scaleY ? scaleX : scaleY;
        case 'fill':
            result.x = scaleX;
            result.y = scaleY;

        return result;

    function create() {
        var ratio = getRatio('all', 320, 480);

        if (navigator.isCocoonJS) {
            game.world._container.scale.x = ratio.x;
            game.world._container.scale.y = ratio.y;
        } else {
            game.stage.scaleMode = Phaser.StageScaleMode.SHOW_ALL;
            game.stage.scale.minWidth = 320;
            game.stage.scale.minHeight = 480;
            game.stage.scale.pageAlignHorizontally = true;

        game.add.sprite(0, 0, 'bg');

        nanoha = game.add.sprite(160, 240, 'nanoha');
        nanoha.anchor.x = 0.5;
        nanoha.anchor.y = 0.5;

    function update() {
        nanoha.angle -= 2;

All the magic happens at the top of the create function - scaling world._container does the trick - the scale factor is applied to all it's children.


As a result I came from this:



To this:



I also tested touch events and these work as expected  :)


Complete sample app can be downloaded here: https://dl.dropboxus.../scale_test.zip


Please let me know what you think about such approach, maybe there's a better way around?




By the way, it would be soooo great to have Phaser supporting CocoonJS by default with no additional hacks... just tellin'  :rolleyes:


  • haden, Hsaka, Arlefreak and 5 others like this

#13255 Phaser 1.1.2 Released

Posted by rich on 01 November 2013 - 06:31 PM

Here we go with the next update. Not a bad change-list really! 1.1.3 is likely to be around 3 weeks away and we'll focus on some of the larger changes internally for that (better State management for example).


Here's the full change list:

Version 1.1.2 - November 1st 2013

  • New: You'll now find a complete Basic project Template in the resources/Project Templates folder. Will add more complex ones soon.
  • New: Phaser.Button now has the ability to set over/out/up/down sound effects so they play automatically based on those events.
  • New: Added init method to plugins, to be called as they are added to the PluginManager (thanks beeglebug)
  • New: Physics.Body now has a center property (issue 142, thanks MikeMnD)
  • New: Lots of fixes across Full Screen Mode support. Input now works, scaling restores properly, world scale is correct and anti-alias support added.
  • New: Added Group.cursor. This points to the first item added to a Group. You can move the cursor with Group.next() and Group.previous().
  • New: Added Tween.isTweening(object) to check if an object is currently being tweened or not (thanks mikehamil10)
  • New: Added getMagnitude, setMagnitude, normalize and isZero methods to Point (thanks beeglebug)
  • New/Change: Group.callAll now supports nested functions and a context, making it really powerful!
  • Updated: Fixed a few final bugs in the Sprite body and bounds calculations, in turn this resolved the Tilemap collision issues in the 1.1 release.
  • Updated: Finished documentation for the Phaser.Button class.
  • Updated: Fixed the Invaders game sample and enhanced it.
  • Updated: Fixed the Star Struck game sample and enhanced it.
  • Updated: If you pause an Animation, when you next play it it'll resume (un-pause itself).
  • Updated: hexToRGB now accepts short hex codes (#EEE) (thanks beeglebug)
  • Updated: State functions (preload, update, render, etc) are now passed the current game as a parameter (thanks beeglebug)
  • Updated: If your game is running in Canvas (not WebGL) you can now set Stage.backgroundColor to rgba style CSS strings, allowing for semi-transparent game backgrounds.
  • Updated: event.preventDefault() has been added to all Mouse event handlers.
  • Updated: Sprite.deltaX/Y removed due to non-use. prevX/Y values moved to Sprite._cache.prevX/Y.
  • Updated: Due to missing extends parameter the Sprite prototype was picking up functions from classes it never meant to (Button, TilemapLayer), now fully isolated.
  • Fixed issue 135 - Added typeof checks into most ArcadePhysics functions to avoid errors with zero values.
  • Fixed issue 136 - distanceTo using worldX/Y instead of x/y.
  • Fixed lots of examples where the cursor keys / space bar were not locked from moving the browser page (if you find any more, please tell us!)
  • Fixed issue 149 - Starling XML files now load properly again, also created an Example to show use of them (thanks haden)
  • Fixed an issue where if the Starling XML file didn't contain a frameX/Y value it would crash on import.
  • Fixed the Multiple Animations Example - it's now a lovely underwater scene :)
  • Fixed issue 141 - If a Sprite is dragged and you release the Pointer while not over the Sprite, it will think it's still over it (thanks Paratron)
  • Fixed issue 88 - Incorrect game.input.x/y values on click with scaled stage (thanks DrHackenstein)
  • Fixed issue 143 - Entering full screen mode made the Input x/y coordinates go wrong.

  • Mike, Dabney, korpuskel and 5 others like this