Thoughts on changing the way collision works

[rich]

Hi all,

 

Right now all collision in Phaser is bounds based, i.e. Rectangle to Rectangle (AABB). Mostly because (a) it's fast and was easy to add ( that is how flixel handled it.

 

Other html5 game frameworks seem to take one of 2 approaches:

 

1) They use AABB too

2) They implement something like Box2D

 

I really really don't want to add Box2D to Phaser. There isn't really a good JavaScript port of it, it makes things much more complicated internally, adds about 250KB to the library size, runs like a dog on mobile and quite frankly is utterly overkill for 90% of use cases.

 

However I'm not happy being stuck with AABB either. It's fine for lots of games and it's extremely fast too, but if you want to have lots of balls in your game, you really need circle to circle collision. If you want to have your sprites rotate, you really need the bounds to rotate with them, and in some cases it would be extremely handy to have a polygon too, for those really weird shapes that just don't fit well into a rectangle or circle.

 

So what I'm thinking at the moment is to do away with the GameObject.bounds property entirely and swap it for a CollisionShape. By default the shape will be a rectangle the size of the image. But it can be set to be any Geometry object (circle, line, polygon) and all collision will be performed against that. The shape could be sized larger than the GameObject and will be fixed to it based on a given point (which will default to the top left corner).

 

My concern is that I wonder if people will then expect the collision shapes to re-act, in a physics way as accurately as they do in Box2D, because they almost certainly won't.

 

I'm also considering adding an InputCollisionShape as well, used just for input detection. Very often I've needed to build a button where the input collision box was larger than the actual button image. But I wonder how important that really is.

 

Anyway happy to hear your thoughts on a good direction to take. I need it to remain fast and stable, but it feels like it ought to be a bit more flexible than it is right now.

[Chris]

I would just add more collision options to the engine. I don't think anyone assumes physics to be present when we are talking about simple collision.

 

My first thought about being able to use ANY shape for collisions was: wow, how would that impact on the performance of collision detection?

Afaik, AABB is the fastest way of detecting collisions, followed by circle-based collisions (when you leave out sqrt!).

 

It gets complicated when you try to collide circles with boxes or odd shapes... Maybe you can introduce three methods (aabb, circle, anyshape) so

you can get the best performance dependend on your needs.

 

But maybe I just developed my thoughts in the wrong direction - if so, my apologies, I am currently a bit weakminded due to illness

[rich]

 think there are 2 things here: Collision (or intersection) and Physics.

 

Detecting for collision between various shapes is fine (line, point, rect, circle, polygon) and even now Phaser has a lot of methods in there that handle this.

 

But in order to be properly useful they need to cleanly separate (hard) and exchange velocities/elasticity/etc realistically (very hard).

 

I'm in two minds about if I simply add in support for handling collision between rotating boxes and that's it, no more Or if I go down the CollisionShape route instead.

[PROGRAM_IX]

How unreasonable is radial (vector distance) detection? For cases where you're not too concerned about accuracy or things are simply too small, would it be a handy thing to have? Bullets for example, whether round or not, could easily be small enough that simply detecting if they were x pixels/other units from the centre of a given sprite would be enough. Not sure about performance impact, though. I used it a bit in my game framework thing, but I didn't test that thoroughly enough to say for sure.

[rich]

There's several "distance from" methods in there already, so that would be quite painless really. To be honest it feels like that would just be a Point collision shape. If anything it should be an ever so slightly quicker check than rect to rect actually.

[PROGRAM_IX]

Fair enough. I certainly don't mind implementing it myself on a game-by-game basis. Just wondering if it was a wildly stupid consideration as a library method.

 

Yes, I was going for something that would be faster than rect to rect, as that can get sloooow at times in my games. >.< Poor optimisation on my part, probably.

[HackManiac]

I agree that Phaser does not need it's own physics support as long as it can be easily combined with one of the third-party physics engines. I tried it with Box2D and it worked reasonably well for rectangles and circles (if you set your sprite's alignment to center), but did not test it with anything else yet. If you offered a Phaser Test example with such an integration I assume that would make clear that Phaser itself does not come with physics support out of the box. And in addition to that potential users would get another reference / template for their game

 

I really like the idea of having a "CollisionShape" mechanism. Chris' suggestion of having three different methodologies sounds like an interesting idea as well. But it only would be necessary if the "anyshape" method checking a bunch of AABBs take significantly longer than the specialized "aabb" method checking the same boxes. That way a game that needs complex "anyshape" collisions could opt into that without penalizing all other use cases as well.

 

But it feels a bit weird (at least without having used it in action) to sacrifice the "bounds" property for it... I imagined that the CollisionShape would form around an origin point (like a shape does in Box2D) and I would then have to tell the sprite were this origin is located in the world and in its texture. And removing "bounds" would also remove its "width" and "height" which were useful to scale the texture. I can currently not image how I would achieve that purely with a "CollisionShape". But I'm open for enlightenment

 

I'm unsure about the "InputCollisionShape" approach but that might well be my lack of game dev experience. What makes "InputCollisionShape" different compared to a regular "CollisionShape"? Isn't a "InputCollisionShape" just a regular one checked against a circle shape (mouse pointer or finger from touch event)?

 

 

All in all the basic idea of having a "CollisionShape" mechanism supporting rects, circles and complex polygons sounds like a great addition to Phaser. But I can't judge how much work hides behind that feature... If you have a plan and need help - just let me know.

 

[rich]

I will certainly keep all of the current physics stuff that is in there, because for lots of cases it's enough anyway, so no need to involve a heavy-weight physics system.

 

But of course adding in CollisionShape and then not having that used in the current physics system would be a bit strange

 

And yes I'll keep bounds now you mention it My thinking is that you can get the exact same values from the GameObject.x/y/width/height properties, but it will be much easier to keep as a Rect.