A Question for Rich: Why is Phaser so tightly coupled with it's Physics Engines?

[codevinsky]

Why aren't the physics engines stand-alone/plugin projects?

 

Would it not be possible to have an adapter layer that must implement some interface for passing back collision data so that we could use which ever physics engine we wished and without having the bloat of trying to wrap other physics engines into Phaser?

 

I'm asking this both from an academic and practical point of view. Is it slower to do it that way? Is it something you considered/attempted and decided it wasn't gonna work? Was it completely unfeasible? 

 

 

Just curious.

[rich]

I would say that they are now pretty stand-alone. They compile into their own js files, and custom builds allow you to pick and choose only what gets put into the final package. So they're no longer wrapped into the full build (unless you specifically use a version that does that I guess!)

 

In terms of the APIs the reason there is no 'standard' interface is simply because they are all just SO different. There are a handful of shared properties, but far less than you'd think. For example P2 requires Springs, Constraints and Contact Materials, none of which have any use in ArcadePhysics. So do I create a generic Body interface that has all of these properties (like adding a spring or applying thrust) that don't actually work if you're not using P2? How do I communicate this to the developers? And what about when we add Box2D? The property and parameter orders for that are likely to be different from P2 again

 

There may have been an elegant way to abstract out which system you're using, but personally I think picking a physics system is something you should inherently know you're doing, and be prepared to work around that environment specifically, because they all act in their own unique ways. If I was to try and hide that from you I think it would raise more questions / false-negative bug reports than exposing it like I do.

[codevinsky]

First, thank you for the answer. It was much more thorough than I was expecting.

 

Secondly: You know how there's the things you know, and then things you know you don't know? There's also an entirely third area: The Things You Don't Know you Don't Know.

 

Almost all of game dev falls under the third category for me. So take that into account when you read one of my questions and you go: "Wow. That's a stupid question."

 

Your response to a blog post I made recently concerning polygon collisions (and fishrock's explanation there of) is a good example there of.

 

That being said, I've got a follow up question:

 

What use is the physics engine other than to tell us what has collided against what? 

 

My assumption is that the physics engine only exists to run the simulation on each step and provide the game with data. To the extent of my knowledge, (which, as I've just said, isn't much) the physics engine's sole purpose is to tell use what collided with what and where things are. If that's the case, wouldn't a simple adapter class be all we'd need?

function PhysicsAdapter() {  this.collisions = []}PhysicsAdapter.prototype.setCollisionData(collisions) {  this.collisions = collisions;}PhysicsAdapter.prototype.getCollisionsData() {  return this.collisions;}PhysicsAdapter.prototype.update() {}

function P2Interface() {}P2Interface.prototype = new PhysicsAdapter()P2Interface.prototype.update = function() {  PhysicsAdapter.prototype.update.apply(this, arguments);  world.step(1/60);}

That's obviously a severe oversimplification. Upon thinking through it, you'd need to move sprites based on physics data as well.  

 

 

I suppose I answered my own question and the answer is:

Smarter people than I have done this a lot longer than I have and have decided on the best roadmap for this library.

 

However, I'm still going to feel free to complain about things I don't understand until I understand them.

 

I hope we're all copacetic with that.

[rich]

What use is the physics engine other than to tell us what has collided against what?

 

 

I would say that is one potential outcome of a simulation, yes.

 

I'm not a physics expert (by a long way) and will readily admit it. But I've worked with enough different physics libraries (and spent long enough implementing them!) that I can assure you they all do things in their own unique ways. Fundamentally you want to know what has collided, yes - but if you take just that one element alone you need to start thinking about all the variations and questions that can throw up:

 

For example are we checking in the broad phase or narrow phase? During the collision exactly which shapes of the body collided with which shapes from the other body? Were they moving into or out of a collision? Was it a result of a locally applied force or something global like gravity? Should the collision be processed at all? Maybe the body is set to ignore collisions on that face? There are so many variations here just in this one section alone.

 

And that doesn't even cover all the various properties a Body or World may need. The ability to add a Spring to the world is essential for P2, but pointless for anything that doesn't use Springs So how do you create an interface for something that exists in one situation, but not in another, without confusing the end developer? (that's an open question btw, not a statement.. I'm curious how it could be approached).

[jerome]

really interesting question and answer !

kind of explanations I'd like to read in the future book too :-)