Gravity and collision detection interfering with player movement

Question

I am attempting to implement collision detection for a 2d sidescroller game and I'm having trouble keeping gravity from interfering with player movement.

Every frame I get and handle input, creating values for a point that represents the players movement vector. I then add gravity to the vector and check for collisions. This is the way AI will be handled as well.

The problem I'm having is when the player is on a floor tile, even if the input says to walk horizontally, after I add gravity to the move vector, collision detection returns a collision so the movement is completely negated.

I know i can test which a is is the problem, negate that and move the player but then if I change the players movement vector inside collision testing, wouldn't I have to cull for collisions again based off the new move vector?

I don't know if this has to do with input handling or collision testing. So how should I go about adding gravity to the players movement?

Answer 1

It sounds like the issue is your collision resolution mechanism. The correct resolution depends on the particular type of collision, but here's some points that could be your issue:

Collision-generated impulses should be directed along the normal of the collision surface. In the case of static, axis-aligned world geometry, you just need to zero-out that component of the velocity. For example, when a character lands on a surface, it's just the y-component of his velocity that should be set to 0, not necessarily all of his velocity. You can certainly damp his x-velocity, but for the reason you're experiencing it shouldn't just be zero'd out.

Now, it's possible that once you've done this you still have collision issues. Imagine a character standing on a solid, square block, and walking onto an adjacent touching solid, square block. When he first tries to step onto the second block, he will be colliding with the corner. For that moment, the face of largest penetration will in fact be the side, not the top. He could be 'colliding' with the corner of the block facing him. I can't speak with authority on the best resolution for this issue, but I think adding some penetration tolerance should do the trick.

An alternative, one I don't like and I don't know why you would choose to do it but I offer it anyway because I don't know anything about your game, is to try to manage gravity with some sort of state machine. You do gravity checks on your physics-enabled objects and toggle between gravity states. Again, I don't see any advantages to this, but if you're doing something strange with gravity or game mechanics, this could work for you.

In summary, it sounds like your gravity system is working and the issue is collision resolution, and not gravity, per se.

Answer 2

It sounds to me like your problem is that you are blindly applying gravity without considering the effects of whatever the character is standing on. If there is something below you there is no meaningful effect of gravity!

Furthermore, you don't want to simply not move if a collision results. Consider what happens if you jump off something--at the point the next movement frame intersects the ground you're frozen in space for all eternity.

Instead you want to stop the character (or perhaps only zero out the velocity in the direction that caused the collision) at the point of impact but allow them to move that far.

Simply stopping the movement only works if you don't care about exactly where you are. (And, yes, that can happen. I did a simple 3D first person journey through an environment once--more an experiment in 3D than a real game. I implemented collision handling by zeroing any velocity component that would take you within .1 of a wall. The result is how closely you can approach the wall depends on how fast you impact it, the guy heading straight for it will be stopped sooner than the guy approaching it at a very narrow angle. Without a debug display showing the actual numbers you would never know, though, as being first person you can't tell exactly how close you are anyway as the point of contact isn't in your field of view.)