next »

[Paolo Victor]

Oh hai,

I've noticed that, once on a while, some random thread about collision detection/general physics pops up. The general answer is "For zombie Jesus' sake, don't create your own physics engine!", which I completely understand - reinventing the wheel sometimes may just hinder your progress and take away the focus from the game itself.

However, sometimes it's just not that simple. At least for me. What I want to do is a simple, old school platform game, but it seems that, since those games obviously don't follow real physics very well, you have to resort to all kinds of hacks to make it work, including but not limited to:

• Manually setting velocity for player movement
• "Simulating" friction by manually decreasing X velocity on each step, because using Box2D's friction support leads to strange behavior, like characters sticking to walls
• Checking collisions with the world in order to tell if the player is allowed to jump
• Checking the player's world collision normals and manually setting velocity/applying forces to compensate slopes*

At least that's what I gathered after some googling and toying with pybox2d.

I really think that it shouldn't be that complicated, and that probably I just got everything wrong, but do you guys share the same feeling? Have you tried something similar?

*I want characters to ascend and descend slopes at the same velocity as if they were on plain tiles

[BorisTheBrave]

The problem is Box2D rewards consistency, and old school platforms are anything but. They are usually implemented as hacks (beyond the basics, I mean).

It's my belief you can recreate most of the feel in Box2D, by discarding large and large amounts of the physics. E.g. start doing your own velocity calculations instead of using ApplyForce. But the more you discard, the worst the physics becomes,.

If you want real fidelity, I'd recommend disabling collision between the player and the ground and doing that for yourself. Because the fact is, there's no shape that would described the collisions correctly, once sloped platforms come involved.

Another idea to consider is treating feet separately from the rest of the body. This simplifies determining when you can jump, and fixes that problem where friction and aircontrol mean you can hug walls. Best of all, it represents a more accurate simulation of the world, which I usually find is the long term solution to problems, though not old school fidelity.

[Impossible]

Hmmm... the problem is traditional platformer physics do not work like rigid body physics at all.  3D physics engine solve this by having character controllers that usually behave like FPS or 3D platformer characters.  Maybe someone should implement an official character controller for Box2D?

Anyway, it looks like you have the right idea.  Move your character manually and use Box2D to check for collisions against static objects. Looks like Box2D doesn't support kinematic bodies, but it should be ok to either use a very massive dynamic body or a maybe a static body.  Someone with more experience with Box2D could answer these questions better.  I'm curious because I'm thinking about making a 2D platformer that uses Box2D for some physics stuff as well.

[Ivan]

Yeah, there's a way to manually check for collisions. You have to set the isSensor flag on the shapes to make them not collide automatically and then use the regular collision listeners (there's stuff on that in the manual).

You can even mix it with its regular physics. Just reset your non-physics shapes' translation and rotation on every frame. (Unfortunately, it doesn't seem like you can use just static bodies, because Box2D doesn't check static to static collisions)

[Triplefox]

Echoing the sentiment that all collision is a hack. The only time it isn't is when everything in the world can be defined in some extremely regular and consistent way. Approximating characters as AABBs, circles, capsules, or spheres and adjusting their boundaries to fit sprites/models as they perform different animations breaks all the "expected behavior" that makes a physics engine go. Along the way, you pretty much always end up with game-specific stuff where you say something like "oh I want the player to be able to grab ledges, and crouch-walk through low areas" and then you have to add hacks that cross collision with animation and player state to get the effect down. Hence the motto of my old boss, "collision is gameplay."

So you can choose between the "hack a physics engine down to work with characters" route, or the "hack basic collision detection upwards to character physics" route. For most people the former seems to be an easier task, and it allows for physics elements to be included piecemeal, but I've been stubborn and put together my own systems - I've moved towards a really, really simplistic model where everything is a composition of same-size tiles, because with tiles of equal size, it's fast and easy to resolve the "best" movement vector - one which preserves the maximum amount of movement while avoiding the collision, giving you sliding behavior instead. Algorithms for finding a vector which simply stops movement and throws objects out to the point of contact are well-known and easy to implement, but going with that approach means throwing on another layer of hacks for movement-preserving behavior. This led me to look for "best vector" algorithms, which turn out to be really hard to create for non-square shapes - with squares the separating axis theorem will give you both the "stop" vector and the "slide" vector simultaneously, but for other shapes it only gives a "stop" vector. You end up with a huge boondoggle of complexity. So I use multi-tile composition to get around that. With multitiles I sort the tiles by vector distance and take the largest one that is valid for the entire shape.

The results I get from this are pretty fast and consistent. This demonstration shows an environment with 250 snowflakes of 9 tiles each. The only thing the app code does is add a randomized downward vector and reset their position on a timer - all the other behavior comes from the basic collision model. So I've devised myself a method for retaining that "regular & consistent" world model within the realm of squarish 2D shapes - and it remains true only as long as the only thing I expect moving objects to do is to slide, retaining all their momentum, when they collide with the world. Getting a bounce, surfaces with friction, or the same behavior with multiple moving objects or environments on non-regular grids would all involve hacks again.

[moi]

I have develloped a platform engine not so long ago and I can confirm that this is totally hack country

[nihilocrat]

For a platformer where any kind of collidable non-circular object doesn't rotate, I would go with rolling your own system based on bounding-box collisions. It will probably be a little easier to implement strange hacks, have better performance, be easier to use, and teach you a thing or two.

However, if you want to use Box2D for some reason or another, you will probably want to set almost all of the shapes as sensors because you don't want your character/enemies toppling over if they land incorrectly or any number of another 'noisy' collisions that do not belong in a platformer.

[OMGAlec]

Could you just set the player body mass to 0 and stop rotation and collision?  I mean, you'd basically be discarding all the physics information and only using the physics engine's collision callback and implementing your own movement system instead of using apply force.

[BorisTheBrave]

Could you just set the player body mass to 0 and stop rotation and collision?  I mean, you'd basically be discarding all the physics information and only using the physics engine's collision callback and implementing your own movement system instead of using apply force.

Two static (mass 0) bodies will not collide, as Box2D assumes you do not want this information. But with collisions resolution turned off, you don't really need static bodies. Other than that, this works fine. But you've thrown away so much of Box2D that it's getting hard to justify using it. Particularly as the information returned is oriented towards collision resolution, and it quite hard to use if you do not have this turned on. The upcoming version improves on that considerably.

[bateleur]

When people say "don't write your own physics system" they're talking about realistic physics. If you're writing a platformer I'd say do use your own system. Making Box2D do what you want will be way harder. (And I speak as someone currently using Box2D for a large project which does modify its default physics rules.)

[raigan]

When people say "don't write your own physics system" they're talking about realistic physics. If you're writing a platformer I'd say do use your own system. Making Box2D do what you want will be way harder. (And I speak as someone currently using Box2D for a large project which does modify its default physics rules.)

Yeah.. there is a _huge_ difference between physically valid movement and what you experience in a SMB-type game. Unless you need complex physics mechanisms/constraints, writing your own system for a platformer is not that bad.

[BorisTheBrave]

It's a pity that there is such a binary distinction between physics/non-physics. Pick either one, and certain elements of platform games are locked off to you.

I usually advise a physics engine, as it's easier to add hacks into it for platforming (they are just harder hacks than usual) than it is to add physics or physical constructs into a naive implementation. But for people who know exactly what sort of game they want, I guess it varies.

[leaf]

I've never played with box2D, but I have in the past created 'physics' from the hacks you've described. I think it depends on the type of game you're creating. If you want just simple, really quick physics, then creating your own may be the way to go instead of spending many minutes on reading the docs for box2D.

[Eclipse]

if you want to do a simple oldskool platformer doing your own collision system is the best way.
Also it's quite easy, around 2 hours of coding to have a robust stuff imo

[Slather]

Box2d is new-school. If you want to do old-skool gameplay, use old techniques. I'd recommend doing something interesting and new if you want to use a physics library. The game "N" (http://www.thewayoftheninja.org/n.html) would be an example of new-school platformer gameplay using physics.  Do something different!

[LemonScented]

In defense of Box2D...

I've done platform character physics in several games, and the only thing I can say with certainty is that they're always a pain. Currently I'm using Box2D in my project, so I've gone down the route of fudging Box2D to do what I want - dealing with all of the examples in the original post, and more (controlling velocity whilst in the air, increasing the upward jump velocity to unrealistically high numbers which artificially increasing gravity for the character to get that nice quick, high jump and a nice speedy descent without that "floaty" feeling, all sorts). I'd argue that fudging Box2D is awkward, but it's defensible in certain circumstances. In my case:

1 - I don't want all of my physics to be old-skool (quite the opposite, in fact, my game is heavily physics-based), even though I want the character physics to be that way. Old-skool physics is really easy in Box2D anyway, just turn off object rotation and set masses/gravity according to your tastes (I recommend starting with a relatively low mass but a very high gravity and tweaking it from there).

2 - Box2D's collision system (well, the engine in general) is tried & tested, solid, stable, and fast. I've rolled my own collision systems in the past, and they're a nightmare. Even if I didn't use any of Box2D's physics at all, I would still keep it for the collision detection routine alone.

I think if ALL the game physics is old-skool, and particularly if (as has been mentioned) your level design is tile-based (like old-skool platformers were), and/or if you've not rolled your own collision/physics system before and you're as interested in learning about that stuff as you are in making the game you want to make, then totally roll your own physics. However, if you're jaded and old like me, Box2D offers so much convenience that it might be worth turning off/hacking around features in the engine to get that retro vibe with more modern means. Remember that turning off object rotations and artificially tweaking mass and gravity are really easy in Box2D - the hard bits are (for example) collision testing to work out if the character is allowed to jump, and frankly you're going to run headfirst into that problem whatever physics system you use.

As a side note, I've tried a few collision shapes for characters under box2D, and my favourite so far is a capsule: 2 circles, one above the other, joined together by a box. It means falling stuff bounces/slides off the character's head well (assuming that falling stuff doesn't just kill the character), and seems to give something that behaves nicer than other shapes for feet on different terrain.

[Eclipse]

i really don't see the point of using Box2D for an oldskool gameplay if not the one that you're not able to code a good collision system yourself, and if you're not... you should learn how!

[John Nesky]

Shameless plug: I made Planet of the Forklift Kid in about a month for the Video Game Name Generator Competition using Box2D and few hacks.

Basically the Kid is a unicycle:
-a non-rotating rectangle with a width of 1, a height greater than 1, and a friction of 0.
-a rotatable wheel with a diameter slightly less than 1 and absurdly high friction (>1).
-a motorized RevoluteJoint attaching the above two bodies, which is spun to walk sideways and up or down hills.
-a tiny bit of forced acceleration when not touching a floor for air control.

This setup dodges the "sticking to walls" problem, and creates a pretty realistic walking behavior.

[weasello]

In defense of Box2D (again) and as another plug...

I'm no miracle programmer, but putting in an hour or two a day for the last month has resulted in (the early alpha version of) www.protonaut.net .

The game is entirely Box2D-physics based with only one "hack"; I couldn't get jumping to feel "quite right" with a single impulse, so I do ApplyForce several times after you have left the ground (similar to Mario and other games where holding down jump will make you go higher than just tapping it).

Everything else was just a matter of finding the right numbers to plug in, which I admit was annoying, but ultimately rewarding.

As far as character construction goes: The player is a sphere, there is a collision-detection box (Sensor) for feet and another detection box on the left/right side so I know when you can validly wall-jump. Other than that it's pure physics, through and through.

[Afinostux]

If it helps at this point, I found a way of getting around the 'sticking on walls' shenanigans by building each 'box' out of three tri shapes:


The red one on the top has friction, and the two blue ones are set up to have minimal friction. Friction on top, but not on the sides! mariotastic.
Hope that helps. It's a bit of a kluge, but you could use some clever rectangle-merging thing to make your level use as few of them as possible.