Explaining Phaser 2s multiple physics systems

[rich]

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:

game.physics.startSystem(Phaser.Physics.NINJA);

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!

[jflowers45]

Thanks Rich.  One of my favorite things about Phaser is the transparency you have with all other devs about your process and the roadmap, etc.  

[codevinsky]

Excellent post. Thanks, Rich.

[brejep]

Looks like I started experimenting with porting over my game to 1.2 a little too early.

 

This sounds like a great way of dealing with the physics in Phaser. Look forward to the new release.

[Mefteg]

Thank you, very instructive!

[Memphis]

Thanks for post and your work, Rich.

 

I'm currently working on top-down racing game based on Phaser and it's pleasure to work with, looking forward to 1.2's advanced physics system. 

[andrewho]

Congratulations on this new feature ! 

[codevinsky]

So, maybe to clear up a bit of confusion:

 

Which physics engine is "classic" phaser?

 

Which physics engine is the new hotness?

[Geaz]

"Classic" is the Arcade Physics.

New is P2 and Ninja.

[tackle]

If I understood this correctly the Ninja engine is a bit of a mid-point between Arcade and p2, performance wise and function wise?

 

If Ninja has all the functions you need - it would be a better fit for mobile games than p2 due to performance?

[rich]

Ninja is quite specialised, for example it doesn't *yet* support aabb to aabb, or circle to circle, although I will add that post launch (or maybe someone else can!) but it's nice and fast and does all kinds of cool slopes with ease, and you can actually move the Tiles around happily, meaning they can be cool shaped sprites as well as level tiles.

It's a bit limited, but what it does it does really well. And it's ripe for expansion.

[fase]

This helped clear a lot things up.  Thank you.

[ROODAY]

Complete newb here, sorry for newb question, but when will this build with p2 be released? I'm currently trying to use p2 with phaser and if phaser had it already it would save a  lot of time.

[rich]

Thursday.

[george]

Hi Rich,

this is outstanding. I've never ever seen an engine with an abstracted physics layer to use any available engine. After a week with no work I'm back in the office and now I've plenty to upgrade with all the changes from the last week. It's a pleasure to do so

If you plan to create a sample integration of Box2D please, please, please do not use a totally outdated port of Box2D like 2.0 or 2.1alpha. This is typical for all the ports which are based on the flash as3 port of box2d.

 

Instead I recommend to use this version:

https://code.google.com/p/box2d-html5/

 

It's compiled with google closure and targeting the 2.3 branch of box2d. I created a test project with this version last year. It's fast AND you have all the cool features from 2.3 included (Edge Shapes! Rope Joints, Wheel Joint). And because of the use of Google Closure Compiler it should be easy to be on the bleeding edge (although box2d seems not to bleed anymore)

 

Regards

[feiss]

Amazing, there's a lot of room for performance improvement here.. Great job! This will be an impressive version, but don't rush yourself! if it's not for thursday, it's for monday next week, take it easy man! 

[rich]

George - yeah I remember you saying about that version of Box2d a while ago, so I will make sure that is the one used (hopefully someone in the community will contribute it, but we'll see!)

 

feiss - don't worry, the vast majority is finished, it's just a few final fixes and tweaks in the physics classes. I could go on forever modifying those, so it's best to just get them stable and push them out really. They're already a lot more solid than any previous build. The list of things left is totally do-able imho.

[Vieo]

Hey Rich! Awesome to see the new physics stuff in place. I'm currently using Phaser 1.2. If there any examples of a Tile Map using Arcade phsyics?

[rich]

Nope you'll have to keep an eye on the commits before that's re-enabled fully.

[BunBunBun]

hey Rich, can you tell me please, Does "aabb vs circle collision" work now? 

[rich]

Not yet, and may not do pre-launch. Will see how things go.

[BunBunBun]

and what about "circle vs line"?

[rich]

There are no Lines in Ninja Physics. Ninja is for AABB or Circle vs. Tile only. See the big block of text in the JS file at the top

[FedeCuci]

This is a great post, thank you very much! One thing is not very clear to me, however... When you say 'If you need full-body physics, then p2 obviously.' what exactly do you mean by 'full-body physics'?