I am trying to implement a two dimensional sidescroller of the Megaman/Abuse genre. My platform is python with Pygame and OpenGL. I am not using fixed-size tiles for my terrain. My latest problem is resolving collisions between the player (or other non-volatile object) and any static or moving terrain. For now, the terrain is non-moving and both player and terrain are represented by rectangles.

I use the pygame method pygame.rect.collidelistall() to seek collisions between the player and terrain. Once a collision is found, I subtract the player's velocity from his location to find his position last frame, which should be non-colliding. Using an intimidating cascade of ifs, I at one point managed to properly move the player to the correct location along the terrain according to where he had previously been.

When I tried to add sloped or free-form terrain to the mix, I nearly had an aneurysm and ended up deleting all related code.

Does anyone have any experience with solving this sort of problem? I came across one solution (here, and slopes here) which involved scanning the terrain map for collisions only along the X axis first and adjusting for only those, then doing the same for Y axis collisions, however, the examples assumed fixed-size tiles. I'm sure my variable-size terrain shouldn't pose a problem, as long as I ensure a tile's size is at least as large as the player's maximum velocities, but having spent days pounding my head (and axe) against cecropia trees over this, I thought I'd ask for advice.

I could give you a powerful(ly messy) circle to circle, circle to quad, quad to quad collision system Don't if it would solve your problem of terrain, but you could easily build the terrain out of quads.

It seems to me that bounding box collision response always gets messy because of the if's involved. If you want sloped surfaces and such, have you considered using BSP?

DevMaster Article

I'm not using the bounding box... I'm using bounding quads subtle but importance difference.

such as the ability to have an arbitrary shaped quad

skyhawk Wrote:I'm not using the bounding box... I'm using bounding quads subtle but importance difference.

such as the ability to have an arbitrary shaped quad

He's not though. A poly based approach can be a lot simpler because you don't base the collisions on special if cases as much. That's what my experience is anyway.

I'm finishing such a game as we speak. ;-) The way I've done it is to create the environment completely from polylines. This works surprisingly well. Tell me if you want some source.

Fenris Wrote:The way I've done it is to create the environment completely from polylines. This works surprisingly well. Tell me if you want some source.

I'd certainly be interested in seeing your code! I want to improve the scenery collision detection in Yoink shortly, so I'm keen to look at as much relevant code as possible.

Skyhawk, I'd like to see your code too, if that's OK.