Closing in on the Phaser 1.0 release
Although the master branch of Phaser has been quiet for a couple of months we have been extremely busy working on what will be the 1.0 release. If you take a look at the 097 branch README you'll get an idea of the sheer scale of change that has happened to the framework. Although the initial release was heavily inspired by Flixel, indeed taking lots of the core classes and directly porting them over, this has been mostly reversed for 1.0. We hit limitations pretty quickly and were constantly stretching the framework in different directions until one day it finally snapped and we realised it needed a fresh approach. So while the majority of the core classes have changed entirely, we've been extremely careful to ensure that actually using Phaser is just as easy as Flixel is (if not more so in some places!). We've worked really hard to make sure you can rapidly build games with it. For example the following code will create a new game, load an image, create a sprite and display it on-screen:
var game = new Phaser.Game(this, 'game', 800, 600, init, create);
function init() {
game.load.image('bunny', 'assets/sprites/bunny.png');
game.load.start();
}
function create() {
game.add.sprite(0, 0, 'bunny');
}Needless to say the sprite is now under your full control. Alpha it, tween it, flip it, animate it, rotate it, move it around with touch/mouse/keyboard, collide it, emit it in the particle system, etc. We've been hard at work creating several large games for clients with Phaser, so we're able to battle test it and evolve it through actual use. The first of these games was released onto the BBC site last week, and although aimed primarily at small children it still allowed us to deploy a Phaser game to a heavily trafficked audience and gauge response. So what's new in 1.0?
Physics ahoy!
One of the biggest changes we've been working on for the past few weeks is the physics system. Flixel used a standard AABB system, meaning every object has a simple bounding rectangle that is used for all collision. You can resize it, but you can't rotate it (even though the sprites themselves could rotate). Hit detection, mouse events, motion and separation were all calculated against this box. There are pros and cons to this approach. On the plus side it's extremely fast. The math required is very basic, so ideal for low-powered devices like mobile browsers. Flixel employed a basic single pass separation system. It worked great but exhibited strange side effects when the quantity of objects or velocities started increasing. For a good percentage of games it's enough, but the biggest downside is that for anything a bit more interesting you were left to your own devices to implement it yourself. Also input collision using just AABB isn't very useful - irregular shaped or rotated objects were registering touch/pointer events even though you were far away from the graphic itself. We needed to find a solution for this. With Phaser 1.0 we evaluated a lot of JavaScript physics libraries. The most common in use is Box2D. However there are no really good ports of this to JavaScript, and performance on mobile is horrendous once you go beyond the most simple of scenes. ChipmunkJS is a popular alternative, certainly containing far better written JavaScript code, but again is best suited to desktop and is a sizeable library to integrate tightly into a game framework. It also meant we were at the whims of the Chipmunk authors, and if they decided not to fix something, or drastically change something, we'd have to re-integrate with Phaser. It was a dependency step too far. We didn't want something as extensive as Chipmunk, but it had to be much better than the simple bounding boxes offered in Phaser 0.95 and Flixel. We also wanted it converted to TypeScript so we had full control over it. In the end we opted for a custom physics system. Based heavily on the excellent work of Ju Hyung Lee we took his original code and with his permission adapted it to our needs. The result is a powerful physics system that's still easy to implement and use. Including native shapes (Box, Circle, Triangle, Polygon, Segments), full Joint support (welded joints, distance joints, revolute joints, wheels, prismatic, angle joints, rope and input based joints), a solid Contact Solver and Collision system and Contact responses. It's the perfect midpoint we needed: fast, pretty well optimised (although there is always room for improvement!) and most importantly it's featured enough that you can create really interesting and dynamic games using it. It added very little overhead to the file size as well, coming in at just 45KB (gzipped, non-minified).
To Merge or Not Merge?
The stage we're at right now is deciding how tightly this should be tied in to the core of Phaser. It's actually 100% stand-alone at the moment, so we've two approaches to consider: We can keep the current Flixel AABB style physics system and make the new advanced one optional. Or we could ditch the old and replace with the new. For some games simple AABB is more than enough, but for a lot it isn't - and you can't mix and match them, it's an "either or" situation. We're not opposed to bundling both systems in 1.0 and letting the developer decide, but it may be easier to just stick with the new one. I can think of pros and cons for both choices. Feel free to post your thoughts in the comments section below. Especially if you find the AABB physics of the current build too limiting for the sorts of games you want to make.
When will 1.0 ship?
The six million dollar question! We've a massive BBC game that ships on July 11th across mobile and tablet devices. This is an extensive game; a large central map system leads you through 19 unique puzzles, from action based mazes to lock breaking and matching. Think of as being like the Professor Layton games. It's a bold move for the BBC actually, as it's one of the more 'cerebral' games they've ever commissioned, relying on brainpower rather than dexterity. We need to ship this game before we can think about making 1.0 public. Right now the end of July is looking hopeful. Of course all the work we're doing is available right now on the 097 branch, but it's highly experimental in places so you venture in there at your own risk. It has been an exciting time building Phaser. Releasing it early and seeing people use it was a massive boost for us to carry on developing it. Playing games made in it is such a great feeling, and being able to use it for our own projects is just the icing on the cake. We've got a fantastic new site design to go with the launch and honestly we cannot wait until we get 1.0 into the stable master branch. For now please follow development on our forum or leave feedback in the comments.
Although the master branch of Phaser has been quiet for a couple of months we have been extremely busy working on what will be the 1.0 release. If you take a look at the 097 branch README you'll get an idea of the sheer scale of change that has happened to the framework. Although the initial release was heavily inspired by Flixel, indeed taking lots of the core classes and directly porting them over, this has been mostly reversed for 1.0. We hit limitations pretty quickly and were constantly stretching the framework in different directions until one day it finally snapped and we realised it needed a fresh approach. So while the majority of the core classes have changed entirely, we've been extremely careful to ensure that actually using Phaser is just as easy as Flixel is (if not more so in some places!). We've worked really hard to make sure you can rapidly build games with it. For example the following code will create a new game, load an image, create a sprite and display it on-screen:
var game = new Phaser.Game(this, 'game', 800, 600, init, create);
function init() {
game.load.image('bunny', 'assets/sprites/bunny.png');
game.load.start();
}
function create() {
game.add.sprite(0, 0, 'bunny');
}Needless to say the sprite is now under your full control. Alpha it, tween it, flip it, animate it, rotate it, move it around with touch/mouse/keyboard, collide it, emit it in the particle system, etc. We've been hard at work creating several large games for clients with Phaser, so we're able to battle test it and evolve it through actual use. The first of these games was released onto the BBC site last week, and although aimed primarily at small children it still allowed us to deploy a Phaser game to a heavily trafficked audience and gauge response. So what's new in 1.0?
Physics ahoy!
One of the biggest changes we've been working on for the past few weeks is the physics system. Flixel used a standard AABB system, meaning every object has a simple bounding rectangle that is used for all collision. You can resize it, but you can't rotate it (even though the sprites themselves could rotate). Hit detection, mouse events, motion and separation were all calculated against this box. There are pros and cons to this approach. On the plus side it's extremely fast. The math required is very basic, so ideal for low-powered devices like mobile browsers. Flixel employed a basic single pass separation system. It worked great but exhibited strange side effects when the quantity of objects or velocities started increasing. For a good percentage of games it's enough, but the biggest downside is that for anything a bit more interesting you were left to your own devices to implement it yourself. Also input collision using just AABB isn't very useful - irregular shaped or rotated objects were registering touch/pointer events even though you were far away from the graphic itself. We needed to find a solution for this. With Phaser 1.0 we evaluated a lot of JavaScript physics libraries. The most common in use is Box2D. However there are no really good ports of this to JavaScript, and performance on mobile is horrendous once you go beyond the most simple of scenes. ChipmunkJS is a popular alternative, certainly containing far better written JavaScript code, but again is best suited to desktop and is a sizeable library to integrate tightly into a game framework. It also meant we were at the whims of the Chipmunk authors, and if they decided not to fix something, or drastically change something, we'd have to re-integrate with Phaser. It was a dependency step too far. We didn't want something as extensive as Chipmunk, but it had to be much better than the simple bounding boxes offered in Phaser 0.95 and Flixel. We also wanted it converted to TypeScript so we had full control over it. In the end we opted for a custom physics system. Based heavily on the excellent work of Ju Hyung Lee we took his original code and with his permission adapted it to our needs. The result is a powerful physics system that's still easy to implement and use. Including native shapes (Box, Circle, Triangle, Polygon, Segments), full Joint support (welded joints, distance joints, revolute joints, wheels, prismatic, angle joints, rope and input based joints), a solid Contact Solver and Collision system and Contact responses. It's the perfect midpoint we needed: fast, pretty well optimised (although there is always room for improvement!) and most importantly it's featured enough that you can create really interesting and dynamic games using it. It added very little overhead to the file size as well, coming in at just 45KB (gzipped, non-minified).
To Merge or Not Merge?
The stage we're at right now is deciding how tightly this should be tied in to the core of Phaser. It's actually 100% stand-alone at the moment, so we've two approaches to consider: We can keep the current Flixel AABB style physics system and make the new advanced one optional. Or we could ditch the old and replace with the new. For some games simple AABB is more than enough, but for a lot it isn't - and you can't mix and match them, it's an "either or" situation. We're not opposed to bundling both systems in 1.0 and letting the developer decide, but it may be easier to just stick with the new one. I can think of pros and cons for both choices. Feel free to post your thoughts in the comments section below. Especially if you find the AABB physics of the current build too limiting for the sorts of games you want to make.
When will 1.0 ship?
The six million dollar question! We've a massive BBC game that ships on July 11th across mobile and tablet devices. This is an extensive game; a large central map system leads you through 19 unique puzzles, from action based mazes to lock breaking and matching. Think of as being like the Professor Layton games. It's a bold move for the BBC actually, as it's one of the more 'cerebral' games they've ever commissioned, relying on brainpower rather than dexterity. We need to ship this game before we can think about making 1.0 public. Right now the end of July is looking hopeful. Of course all the work we're doing is available right now on the 097 branch, but it's highly experimental in places so you venture in there at your own risk. It has been an exciting time building Phaser. Releasing it early and seeing people use it was a massive boost for us to carry on developing it. Playing games made in it is such a great feeling, and being able to use it for our own projects is just the icing on the cake. We've got a fantastic new site design to go with the launch and honestly we cannot wait until we get 1.0 into the stable master branch. For now please follow development on our forum or leave feedback in the comments.