Posts Tagged ‘physics’
29th Mar 2014
Exactly 6 months after the release of Phaser 1.0 we released version 2. It was a huge update. Not so much in terms of new features, although it did bring its fair share of tasty new treats to the table. But more so it underwent a large internal change. We upgraded to the latest version of Pixi.js, our renderer and this in turn allowed us to literally shave thousands of lines of code out.
The core update loops of all the game objects like Sprite and Button, were dramatically reduced. Lots of the things that caused Phaser 1.x to not be quite as optimal as it could be were eliminated. Expensive routines and processes were either removed entirely or disabled where possible.
It was a big update, but it felt good. It felt clean and fresh. Like when you tidy-up your work space, or white wash a room ready for painting. You know you’re building on top of something sound.
There were a number of API breaking changes moving from v1 to v2, which is why we jumped version number so high (originally it was just going to be the 1.2 release). It was a lot of simple but important alterations. Things like the Group class now properly extending a DisplayObjectContainer, so they can easily be nested and shifted around the display list. Or Sprites no longer having physics bodies by default, or input handlers, which meant the amount of code they process during their basic update is now utterly minimal. Those features are still available of course, you just have to activate them explicitly. The changes were so extensive we produced a Migration Guide to help developers shift over.
Traditionally Phaser has had the ArcadePhysics system built in. This was a port of the one found in Flixel and our Flixel Power Tools. It was fundamentally basic, but still covered quite a lot of bases and most importantly was very easy to use. However the limitations really started to bug us, and we tried to address them in the 1.1.4 release of Phaser, with less than stellar results.
A strong reason for us developing Phaser 2 was so that we could use a proper full-body physics system, in our case the excellent p2.js by Stefan Hedman. And for a good while this was the only physics system we had built in. But as we worked through the weeks of development, it became apparent that there was a real need to keep ArcadePhysics around. Not the broken 1.1.4 version, but the earlier release that mostly just worked, because it didn’t try to be too clever.
5th Feb 2014
We planned to release Phaser 1.1.4 towards the end of 2013, but as with all the best laid plans that never quite happened. As we dug further into it we found some key areas that we desperately wanted to update and as we travelled deeper into the rabbit hole more and more things were changed. After weeks of intense work, refactoring, testing and example building we finally broke the surface and 1.1.4 has moved from dev to master on github.
There have been some significant internal API changes, so if you had a game in build under 1.1.3 please be aware of these before blindly upgrading! Here are some of the headlines:
New SAT Based Physics System
The previous physics system relied on AABB for all collision. It was fast, but very limited. You couldn’t use circles, rotated rectangles or create slopes of any kind. We do still plan to use a full proper physics system in Phaser 2.0, but in the meantime we felt that we really needed to give our current one a shot in the arm, and this is the result.Utilising SAT.js internally you can now create much more complex collision shapes and responses. We also made some large changes to the way the delta timer and integration works and added a bunch of new debugging features too.
New Tilemap System
The tilemap system in 1.1.3 was ok, but had some strange limitations. For example if you rotated a sprite it would often pop through a tile into the other side and there was no support for the more advanced features from the Tiled map editor. The new tilemap system resolves the vast majority of these issues. It uses a much more robust ‘edge chain’ for collision detection. It supports multiple tilesets per map. It supports tile specific callbacks and properties defined in Tiled are carried over into Phaser. You can now turn a whole group of tiles into a group of Sprites with one command and mix layer order around with ease. We’ve still more work to do with the tilemaps, but on the whole it’s a marked improvement over the previous version.
7th Dec 2013
This article was written by Alvin Ourrad and Richard Davey.
Freshly updated for Phaser 2.0!
Welcome to the our first tutorial on Making a Game with Phaser. Here we will learn how to create a small game involving a player running and jumping around platforms collecting stars. While going through this process we’ll explain some of the core features of the framework.
What is Phaser?
Phaser is an HTML5 game framework which aims to help developers make powerful, cross-browser HTML5 games really quickly and, unlike some others, has solely been built to work with the mobile browsers. The only browser requirement is the support of the canvas tag. It also borrows a lot from Flixel.
- Download the source files and assets that go with this tutorial.
- Also make sure you go through the Getting Started Guide, it will show you how to download the framework, set up a local development environment, and give you a glimpse of the structure of a Phaser project and its core functions.
If you’ve gone through the Getting Started Guide you will have downloaded Phaser and got everything set-up and ready to code. Download the resources for this tutorial from here and unzip it into your web root.
Line 1 is where you bring Phaser to life by creating an instance of a Phaser.Game object and assigning it to a local variable called ‘game’. Calling it ‘game’ is a common practice, but not a requirement, and this is what you will find in the Phaser examples.
The first two parameters are the width and the height of the canvas element that Phaser will create. In this case 800 x 600 pixels. Your game world can be any size you like, but this is the resolution the game will display in. The third parameter can be either Phaser.CANVAS, Phaser.WEBGL, or Phaser.AUTO. This is the rendering context that you want to use. The recommended parameter is Phaser.AUTO which automatically tries to use WebGL, but if the browser or device doesn’t support it it’ll fall back to Canvas.
The fourth parameter is an empty string, this is the id of the DOM element in which you would like to insert the canvas element that Phaser creates. As we’ve left it blank it will simply be appended to the body. The final parameter is an object containing four references to Phasers essential functions. Their use is thoroughly explained here. Note that this object isn’t required – Phaser supports a full State system allowing you to break your code into much cleaner single objects. But for a simple Getting Started guide such as this we’ll use this approach as it allows for faster prototyping.
Let’s load the assets we need for our game. You do this by putting calls to game.load inside of a function called preload. Phaser will automatically look for this function when it starts and load anything defined within it.
Create a Sprite
If you bring up the page in a browser you should now see a black game screen with a single star sprite in the top left corner:
The order in which items are rendered in the display matches the order in which you create them. So if you wish to place a background behind the star sprite you would need to ensure that it was added as a sprite first, before the star.
Under the hood game.add.sprite is creating a new Phaser.Sprite object and adding the sprite to the “game world”. This world is where all your objects live, it can be compared to the Stage in Actionscript3.
Note: The game world has no fixed size and extends infinitely in all directions, with 0,0 being the center of it. For convenience Phaser places 0,0 at the top left of your game for you, but by using the built-in Camera you can move around as needed.
The world class can be accessed via game.world and comes with a lot of handy methods and properties to help you distribute your objects inside the world. It includes some simple properties like game.world.height, but also some more advanced ones that we will use in another tutorial.
If you run this, which you’ll find as part4.html in the tutorial zip file, you should see a much more game-like scene:
The first part is the same as the star sprite we had before, only instead we changed the key to ‘sky’ and it has displayed our sky background instead. This is an 800×600 PNG that fills the game screen.
As with sprites game.add creates our Group object. We assign it to a new local variable called platforms. Now created we can add objects to it. First up is the ground. This is positioned at the bottom of the game and uses the ‘ground’ image loaded earlier. The ground is scaled to fill the width of the game. Finally we set its ‘immovable’ property to true. Had we not done this the ground would move when the player collides with it (more on this in the Physics section).
With the ground in place we create two smaller ledges to jump on to using the exact same technique as for the ground.
Ready Player One
This creates a new sprite called ‘player’, positioned at 32 pixels by 150 pixels from the bottom of the game. We’re telling it to use the ‘dude’ asset previously loaded. If you glance back to the preload function you’ll see that ‘dude’ was loaded as a sprite sheet, not an image. That is because it contains animation frames. This is what the full sprite sheet looks like:
You can see 9 frames in total, 4 for running left, 1 for facing the camera and 4 for running right. Note: Phaser supports flipping sprites to save on animation frames, but for the sake of this tutorial we’ll keep it old school. We define two animations called ‘left’ and ‘right’. The ‘left’ animation uses frames 0, 1, 2 and 3 and runs at 10 frames per second. The ‘true’ parameter tells the animation to loop. This is our standard run-cycle and we repeat it for running in the opposite direction. With the animations set we create a few physics properties.
The Body and Velocity: A world of physics
Phaser has support for a variety of different physics systems. It ships with Arcade Physics, Ninja Physics and P2.JS Full-Body Physics. For the sake of this tutorial we will be using the Arcade Physics system, which is simple and light-weight, perfect for mobile browsers. You’ll notice in the code that we have to start the physics system running, and then for every sprite or Group that we wish to use physics on we enable them.
This is an arbitrary value, but logically, the higher the value, the heavier your object feels and the quicker it falls. If you add this to your code or run part5.html you will see that the player falls down without stopping, completely ignoring the ground we created earlier:
The reason for this is that we’re not yet testing for collision between the ground and the player. We already told Phaser that our ground and ledges would be immovable. Had we not done that when the player collided with them it would stop for a moment and then everything would have collapsed. This is because unless told otherwise, the ground sprite is a moving physical object (also known as a dynamic body) and when the player hits it, the resulting force of the collision is applied to the ground, therefore, the two bodies exchange their velocities and ground starts falling as well.
The update function is called by the core game loop every frame. The Physics.collide function is the one that performs the magic. It takes two objects and tests for collision and performs separation against them. In this case we’re giving it the player sprite and the platforms Group. It’s clever enough to run collision against all Group members, so this one call will collide against the ground and both ledges. The result is a firm platform:
Controlling the player with the keyboard
Although we’ve added a lot of code it should all be pretty readable. The first thing we do is reset the horizontal velocity on the sprite. Then we check to see if the left cursor key is held down. If it is we apply a negative horizontal velocity and start the ‘left’ running animation. If they are holding down ‘right’ instead we literally do the opposite. By clearing the velocity and setting it in this manner, every frame, it creates a ‘stop-start’ style of movement.
The player sprite will move only when a key is held down and stop immediately they are not. Phaser also allows you to create more complex motions, with momentum and acceleration, but this gives us the effect we need for this game. The final part of the key check sets the frame to 4 if no keyis held down. Frame 4 in the sprite sheet is the one of the player looking at you, idle.
Jump to it
The final part of the code adds the ability to jump. The up cursor is our jump key and we test if that is down. However we also test if the player is touching the floor, otherwise they could jump while in mid-air. If both of these conditions are met we apply a vertical velocity of 350 px/sec sq. The player will fall to the ground automatically because of the gravity value we applied to it. With the controls in place we now have a game world we can explore. Load up part7.html and have a play. Try tweaking values like the 350 for the jump to lower and higher values to see the effect it will have.
Quite simply the star is killed, which removes it from display. Running the game now gives us a player that can dash about, jumping, bouncing off the platforms and collecting the stars that fall from above. Not bad for a few lines of hopefully mostly quite readable code
So 10 points are added for every star and the scoreText is updated to show this new total. If you run part9.html you will see the final game.
You have now learnt how to create a sprite with physics properties, to control its motion and to make it interact with other objects in a small game world. There are lots more things you can do to enhance this, for example there is no sense of completion or jeopardy yet. Why not add some spikes you must avoid? You could create a new ‘spikes’ group and check for collision vs. the player, only instead of killing the spike sprite you kill the player instead. Or for a non-violent style game you could make it a speed-run and simply challenge them to collect the stars as quickly as possible. We’ve included a few
extra graphics in the zip file to help inspire you.
With the help of what you have learnt in this tutorial and the 250+ examples available to you, you should now have a solid foundation for a future project. But as always if you have questions, need advice or want to share what you’ve been working on then feel free to ask for help in the Phaser forum.
More tutorials will follow, stay tuned
25th Jun 2013
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.
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?
8th Jan 2011
Just a quick one, but some people asked me if I’d send them the source to the Pixel Smash demo I posted the other day. I figure it can’t hurt, so I’ve packaged it up, removed some useless bits, added comments and thrown it together in a zip.
Pixel Smash source code (includes Flash Develop project, set-up with Nape linked in ready to compile)
Should work “out of the box” on PCs running Flash Develop. Will need rebuilding in anything else. It isn’t optimised by a long shot, so make of it what you will.
All about Photon Storm and our
HTML5 game development services
Filter our Content
- Cool Links
- Flash Game Dev Tips
- Game Development
- Geek Shopping
- In the Media
- Phaser 3