Using Chipmunk for RPGs

[MostAwesomeDude]

I'm working on some code for an RPG with a couple artists. Chipmunk's been pretty useful to us, but there's a couple interesting "features" that they've been complaining about, so I've decided to see if I can get some help.

- Boxes of roughly 20x100 can push through each other at 60 FPS, both glancing and straight angles. I'm not sure if this is related to how I'm doing motion; right now I'm using Body.apply_impulse to the moving body, and then clamping the velocity during the velocity callback. Not sure if there's a better way to do this.

- Shapes are not solid to the pixel. This is a problem for e.g. dungeon walls, which shouldn't have any give to them.

- Shapes are easier to push through each other when they're glancing, almost as if the math is being done on ovals instead of boxes.

- Boxes shouldn't rotate. I think my solution of forcing the angle to zero inside a position callback is the best way, but I'm not sure.

- Collisions aren't swept. I think the best thing is to cut my dt into small chunks and step the space multiple times per frame, but again, I'm not sure.

While they might be complaining, I honestly feel that Chipmunk's a big step up from the hand-rolled code I was using before, and I'd like to keep using it, but they're kind of insisting that I find solutions to these. Any help would be appreciated.

~ C.

[slembcke]

Chipmunk doesn't work the greatest for top down stuff as you may have found out. I've been meaning to add a top down friction constraint for a while now to make top down games doable, but haven't gotten around to it yet. It would give you correct friction response when pushing objects around without "creeping" where the object moves very slowly when it shouldn't move at all.

1) Applying impulses every frame can be bad. Depending how big the impulses are, you may be overriding what the collision response is trying to do. That could likely explain objects passing through each other.

2) Again, applying impulses can be the culprit here. Positions are updated before running collision detection/response, so if you keep setting things to have an explicit velocity, it's going to let the objects embed themselves in the wall by v*dt. Moving all velocity changes and impulses into the velocity update function should mostly fix that if this is the problem.

3) Not sure why boxes are pushing through the way you say they are, though I suspect it has to do with the next item.

4) If you want to make objects non-rotatable, simply give them an infinite moment of inertia when you create the body. An infinite mass object cannot be moved (translated) by external forces, and an infinite moment of inertia means that it cannot be rotated by an external force. No need to play with forces or reset angles.

5) Collisions aren't swept, but how fast are you objects moving? I'm having a hard time seeing fast moving objects in an RPG I guess. If you aren't calling cpSpaceStep() with a constant time step, you really should be for many reasons. Read this: http://gafferongames.com/game-physics/f ... -timestep/ If you only need fast moving projectiles or something like that, I recently got raycasting working very well in the trunk code. (http://code.google.com/p/chipmunk-physics/wiki/Queries)

Chipmunk isn't perfect for top down games. You have to use a few hacks to get it to do what you want currently, but I know at least a few people have made it work pretty well for them probably using a combination of damping and/or calculating frictional forces manualy like you are.

[MostAwesomeDude]

I found a bug in the way we were doing timesteps. We're using cocos/pyglet, which does dt-based steps already, and there was an error in the maths for physics timesteps. After fixing it, it appears that nearly all of the behaviour issues have vanished! I'm fairly surprised but pleased.

I'll keep your other suggestions in mind, if/when I need them. Thanks again for making such a sturdy little piece of code!

EDIT: Currently, the controllable bodies are moving at roughly 100px/s, and our timestep is (now) 1/64s. So both boxes would (if I am doing this right) have to be 4px or smaller in the relevant dimension, in order to pass through each other. That's not too bad, and I can always halve the timestep if need be.

~ C.