next »

[paste]

Hi,

I'm starting to work on this platformer game that I'm all hyped up and excited about, and having not done any yet, I started looking into collision detection methods, and stuff.  I started working on implementing the separating axis theorem, when someone mentioned Box2D to me.  Now, this project isn't intended to be very physics heavy; I'd say it will use about as much physics as Mega Man X.  So, I was wondering whether it would be better to use Box2D or to code my own collision detection, physics, etc.  Can anyone explain the pros and cons of each?  What do people usually do?  I know these are pretty broad questions, so please feel free to answer or ignore any part of it.

[increpare]

It will very likely be easier to roll your own collision engine than to try to recreate something of a similar feel in box2d.  You don't need to do separating axis stuff if your rectangles aren't going to be rotating - you can just check that the x and y intervals the rects occupy don't interact.

The only thing that might be a pain are moving platforms, really, and those can still be dealt with easily enough.

Box2D operates using forces/velocities/&c., these aren't really things that make much sense in the context of mega-man, where everything in quite binary - you're either moving or you're not, there's no accelleration/&c. .  You get a lot of potentially unwated physical phenomena creeping in when you try to do platformer stuff normally with physics engines.  I'm sure other poeple can outline these things far better than I can, and my experience isn't too great, so I'll leave it there.

[paste]

Cool, thanks.  I figured B2D would be a bit of overkill. 

Regarding separating axis, the main thing I was considering it for was angled platforms.  Unless you know an easier way...

[Cimpresovec]

Yes Box2D would be too much for so simple collisions.

I also wouldn't recommend you going through the trouble with separating axis theorem only for angled platforms. It took me 3 days of try and error to implement that theorem in my code from scratch using web sites and mathematical books.

For angled platforms, I am sure you can do some kind of a hack. Like make the collision boxes for those smaller and the player can step on them. I haven't done this yes so someone probably has a better solution.

[kiwi]

A very simple hack you could do is draw two scenes, the one you see and a color coded one with additive blending in the back. So you associate a color with each object and when you check for collisions, you first do a simple bounding box and then check in the overlapping rectangle to see if you can find a color that's not supposed to be there.

I've never implemented the separating axis theorem, so I can't say how much easier this method is compared to it, but I've found this one relatively easy to implement

[Draknek]

My rule of thumb is:

If game objects can rotate, use a physics engine.
Otherwise, it's probably easier to code it yourself.

[paste]

You guys rock.  And so quick with the responses.  Okay, so I just went ahead and coded the SAT check for collisions.  Now I just gotta adjust the positions.

[slembcke]

My advice would be to use bounding circles or ellipses for your collision shapes and line segments to define your levels. SAT based Line to ellipse collisions are pretty easy and are very smooth to control when you have bumps and sharp corners in your game. I'm pretty sure that N (that flash based ninja physics platformer) just used bounding circles to great effect.

I've had a few OK instances of trying to get a platformer game to work with physics both with my own engine and with Unit. Physics based platformers definitely have a different feel, and you will be fighting the physics system a bit. On the other hand, you usually get a very nice, complete collision detection system to go along with it. If you have a lot of experience with physics libraries, it's probably about the same amount of work to trick the physics library into doing platformer physics for you as writing it all from scratch.

[LemonScented]

As someone who is currently using Box2D to try to make a decent-feeling platformer, I can testify that whilst Box2D is a great library, it's not easy to fool it into doing platform physics with that "classic" feel. That said, there is a third option that's not been mentioned: it's entirely possible to set up Box2D to be a (fast, efficient, accurate) collision detection library whilst handling all of the collision response and physics yourself. It's not an all-or-nothing deal.

[Ushi-kun]

A very simple hack you could do is draw two scenes, the one you see and a color coded one with additive blending in the back. So you associate a color with each object and when you check for collisions, you first do a simple bounding box and then check in the overlapping rectangle to see if you can find a color that's not supposed to be there.

I also found this method to be simple and sufficient for basic collision games.
Most of the time, you don't even need to check all the pixels inside the bounding box. If your objects velocity isn't too high, you can just check the x pixels to the right/left and y pixels below/above, and then the little x by y area diagonally, before moving your object to see if there is a collision.

[dcarrigg]

My rule of thumb is:

If game objects can rotate, use a physics engine.
Otherwise, it's probably easier to code it yourself.

I agree with this.

Also, I don't see anything wrong with using box2d for only collision information. It's very easy to set up and from everything I've seen it doesn't add very much overhead.

[deemen]

I've been using Box2D for my platformer and it takes some tweaking for sure. Getting the right feel for player movement took a lot of time. We use the physics throughout the game though, so it was certainly worth it, but if your game isn't physics heavy or objects don't rotate, it's probably not worth the effort. Consider it an advanced solution. Implementing Box2D has to match with your design goals.