Jump to content
  • Advertisement
Sign in to follow this  
Bombshell93

Platformer Collisions - where to start?

This topic is 2561 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

title says it all!
I'm working on a 3rd person shooter with platforming elements, I know how to go about basic collisions but I think I'd be better off seeing a variation of ways to approach platforming collisions.
By platforming collisions I mean slopes, curves, moving and or rotating platforms etc. As a vague example the kind of stuff you see in a sonic game.

I've been giving it a go myself by every approach I think up I second guess myself, always thinking there has to be a simpler, faster way.
At the moment I'm trying to write a bounding box class where in its intersection it says how far in a direction you have penetrated another bounding box.
This is a start but it won't help me with slopes, curves, steps, etc. etc.
I tried google but all I seem to find is how to make simple collision classes as opposed to resolving the collisions, in most cases, methods just returning "yes you are inside of that wall"
Any Opinions, tips or links to valuable resources on the matter would be perfect

EDIT: Accidentally posted this in the wrong forum, sorry!

Any and all help is appreciated,
Thanks in advanced,
Bombshell

Share this post


Link to post
Share on other sites
Advertisement
I'm not entirely sure this belongs in Graphics Programming and Theory.

Anywho, are you developing a game to learn about physics? or are you developing a game to make a game?

I'd suggest looking at a physics engine to save a lot of time, and minimize headaches.

Bullet3D is a great physics system to use, and I strongly recommend that.

Even if you're developing the game to learn about implementing a physics/collision system, I'd recommend looking at Bullet3D anyway to see an example implementation of 3D collision detection.

Hope things go well. :)

Share this post


Link to post
Share on other sites
woops accidentally posted in the wrong forums >.< sorry about that!

But I'm making the game for the sake of making something to get my hands dirty with. Get to know all aspects of game development and understand the depth of each part of a team.
I've already got myself well into graphics programming and theory but recently I got smacked in the face with; its only one part of development. So I'm not as experienced as I'd prefer in other areas of game development.

Thanks for the replies even though I posted in the wrong place,
which if someone who can reads this, I think the topic needs moving XD

Share this post


Link to post
Share on other sites
You're treading into dangerous territory :) This was one of my great quests of programming for many years. Solid tile collision is a piece of cake. 45 degree slopes are tricky but not too bad. Slopes of other steepness are a whole different ballgame. Worse if you want to be able to place standalone slope tiles that don't lead up to solid ground or a wall. Also to be able to make jump-through platforms with slope tiles. This is the most I've done currently. Some more things to desire are:
1. Slopes of any grade, defined by height on each side of the tile. I've only done 1:1, 2:1, 4:1, and 1:2 (steep), along with their vertically flipped versions for sloped ceilings.
2. Non-linear slopes, like the circular type in that tutorial Unbeliever linked to, or the loops in Sonic.
3. Sloped moving platforms. My moving platforms are flat, and handled separately from the level collision.

Anyway, a couple years ago I finally solved the whole thing, totally 100% works with any arrangement of tiles, and all integer math so no jitters or rounding problems or falling through floors. Even returns terrain type info of what you're standing on, for ice and stuff. I think I did have to constrain the character collision box width to max 1 tile wide though, but no limit on height. It's been so long I don't remember exactly how it works, but I've been meaning to go back over it and write up a tutorial. This stuff needs to be out there in the world, clearly described to the point that you can actually code the darn thing and without limiting yourself to just a couple slope types.

But, I'm not sure if my implementation is at all similar to what the old SNES games really used. From the games I studied, nobody solved it completely. Always compromises and requirements on how you place slope tiles to simplify it and save processor time. Then again, that's probably pretty smart since the unsupported cases aren't very interesting anyway. Maybe I should go back and write a simpler version that doesn't bother with things like standing on the pointy tip of a standalone slope tile, or treating the back side of it like a wall. Perhaps then I could deal with that character width limit too...

Share this post


Link to post
Share on other sites
Hidden
I highly recommend you looking at this (rather old) thread where you'll find Kasper Fauerby's (Telemachos) famous 'Improved Collision Detection & Response' article:

http://mrgamemaker.yuku.com/topic/368/Telemachos-tutorial-Improved-collision-detection-amp-resp

The algorithm he describes can be imagined easily in an FPS type of game, but with some clever use of the given technology you should be able to figure out how to go about rotation/moving platforms and such (make clever use of friction).

It might take you a few reads before you fully understand the article, but it's more than worth it.

Share this post


Link to post
Well I've been stuck on resolving simple collision for a few hours now, because I keep thinking what I should do when the character is going too fast or how to treat moving platforms.
As far as slopes go, non-curving I assumed I'd do something like treat it like a regular block with the height of the linearly interpolated point.
so if the slope was from 0 to 2 and the player was 3/4 the way up it, I'd treat it like a flat 1.5 (of course with this being 3D space it'd be more like 0, 0, 2, 2 but its easier to explain in 2D)
With curves I could treat it like many slopes or I could treat it like a 3D bezier curve.

I've got at the moment an AABB which when given a direction (object velocity) and another AABB (the other object) will find how far in or past the other object the current AABB went.
The only real issue I have now is how can I resolve these collisions allowing for support with moving platforms and physics-like slopes (gravity making you slide down steeps, launching over slopes if you have enough speed, etc.)

Share this post


Link to post
Share on other sites
Well, since I probably will continue to not get around to writing that tutorial, here are some tips.

Resolve horizontal and vertical motion somewhat separately. When doing horizontal, check if you're going to run into a slope (either directly for an uphill, or getting pulled down a hill if you're on the ground and walk onto a down slope), and if so, handle that vertical motion immediately. It's a lot easier if you don't worry about jamming your head into a ceiling here, so you can just change the Y position and don't bother doing a collision check. After that, handle the actual Y velocity. For Mario World style, there is no sliding against slopes here, although you can still land on them, and steep slopes have logic in the player update to make you slide down. For Sonic style, I think you would slide against slopes here, plus any slope sliding alters the velocity that will be applied next frame.

When checking against slope tiles, always use the horizontal center point of the sprite, rather than the corners. That keeps your feet on the slope rather than floating in the air with at most your toe touching it. However, it's tricky when walking up a hill onto flat ground, because your corner runs into the side of the solid tile while your center is still down the hill a bit.

Limit speed to one tile per frame, so you only ever need to deal with the tile you're in, and the tile you're moving to. If you need faster speed, then call the collision function multiple times per frame so each call moves one tile or less.

For easy moving platforms, make them jump-through type so they can't push the player horizontally, or bump your head on them. After the world collision check (which returns a vector of how far you successfully moved), add just the X of the move vector to your position. Then if the Y movement is downward, do a trace against moving platforms and see if moving down that much would land you on one. If so, shorten the Y movement to that, and set your ground object to that platform.

Update all moving platforms first thing in the frame, and have them store their movement vector. Then in the player's update, check if he has a ground object pointer. If so, add the ground object's move vector to the player's velocity before passing to the world collision check. But add it in a temp variable... you want the player's velocity to stay separate from the platform, at least until you jump off the platform, in which case you may want to add the platform's velocity to the player's to maintain speed.

Share this post


Link to post
Share on other sites
I've got a theory.
Would it work if I get the weight and velocity (including direction) of the 2 objects.
change their positions to the point of the collisions (I already have how far they collided with each other so that should be simple)
I then make get remaining velocity and modify their velocities direction and power based on a ratio of their weights. if weight is 0 its treated as infinity and all of weight 0's velocity is inherited by weighted objects, E.G. player and moving platform.
This would also allow for wall sliding and slopes provided during slope / curve collisions I find where they would be if the slope was treated as a block of the height of the point the player was horizontally. The velocities could be modified in to that direction.
As for detection of faster speeds get the direction make a step vector and test collisions from current position to desired position after of course finding the desired height and direction modified velocity.

Share this post


Link to post
Share on other sites
Bullet3D is a great physics system to use, and I strongly recommend that.
I just want to point out there's no such thing as Bullet3D. It's just Bullet.

The only real issue I have now is how can I resolve these collisions allowing for support with moving platforms and physics-like slopes (gravity making you slide down steeps, launching over slopes if you have enough speed, etc.)
Dynamics are going to be a problem. I strongly suggest against even trying to roll your own solution. Use middleware. I cannot recall how much months I spent on physics with no benefit at all. Even using middleware, providing quality, coherent dynamics is a non-trivial task for kinematic objects. Be careful.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!