Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've finished programming my game engine, and now that I've been testing it, I've been noticing some graphics problems.

The big one is that when a player tries to push against a wall, their character will "jiggle" against it as it constantly tries to enter the wall's space and the collision detection constantly pushes it back outside.

What is the proper way to handle such a situation?

My first instinct was, if moving in a certain direction causes a collision, disable movement in that direction until the entity's position has changed. I.e., once an object falls onto a platform, disable gravity until the object is no longer above a platform.

Is there a better way to resolve repeated collision detections between the same two objects in the same overlapping space?

share|improve this question
up vote 5 down vote accepted

About character collisions with a wall, for instance (I'll use some arbitrary values as example): if you are 10 units (e.g. pixels) away from a wall, and a single step would normally move you 20 units in that direction, the correct behavior is for your character to move 10 units and stop there. If you cancelled the action instead, you'd remain 10 units away from the wall which is not what you'd want.

One way to do this is to move the character by the full amount, then detect the collision and its depth i.e. how much the bounding boxes of the character and the wall are overlapping, and move the character back by that same amount. If you do this correctly you shouldn't be getting any "jiggle" behavior from your character, he'll just press against the wall and stop there. If he's jiggle'ing then you're probably moving him back too much (you're probably moving him back to position he was before the collision, instead of clamping it against the wall boundary).

That being said, I usually see gravity being treated as a special case. In most implementations I've seen, the character stores an onFloor flag and gravity is only applied when that flag is false.

Edit: I guess you could expand this last concept and create additional flags such as touchingRightWall or touchingLeftWall, but only when the boundaries of the character and the wall match exactly. In that case you could perhaps bypass movement altogether. But if the boundaries are not matching precisely, you should let the movement take place and let the collision detection system resolve any intersections.

share|improve this answer
That is how I'm handling collisions, currently. The "jiggle" looks more like the sprite is vibrating than a detectable amount of forward/backwards. – Raven Dreamer Dec 27 '11 at 22:12
Are you calculating the intersection depth correctly? Try to debug the character's position values and the intersection depth against the ones you'd expect to have. I've done this before with no vibrations at all. Could also be some case of subpixel floating point problem? If that's the case, try rounding your values. And finally, check the XNA's platformer sample. – David Gouveia Dec 27 '11 at 22:16
Honestly, I think it's just because the IO (which moves the entity) happens at a different time than the Collision detection, which means the two entities overlap until the game engine gets to the collision subsystem's update loop. – Raven Dreamer Dec 27 '11 at 22:44
But aren't the IO and collision detection subsystems being updated in the same iteration of your update loop? The only way I could see this making a difference is if your rendering loop were completely separate and could somehow be called between your subsystems updates, or if you're stretching this processing between several frames. – David Gouveia Dec 27 '11 at 23:11
The entire process will usually be [IO -> Collision Detection -> Collision Resolution] -> [Rendering]. Even if the Update and Render portions are called at different rates, you should never be able to see your objects rendered in some intermediate state (i.e. after IO but before Collision Detection, or after Collision Detection but before Collision Resolution). You'll always see your character rendered after all the stages of Update have been applied, so it shouldn't matter that they're processed in different steps or not. – David Gouveia Dec 27 '11 at 23:21

This problem usually occurs when the code clamps positions before detecting a collision. I.e:


instead of


The reason it "jiggles" is because the check happens after the character has been clamped to a "safe" location, but because the character is in a non-colliding location at the time of the check the engine allows for the character to continue to move, then the character is drawn and then the next frame the check fails, Clamp is called, causing the character to "snap" back to the safe location.

share|improve this answer
I don't really see how this makes sense. How could the clamp ever happen before checking for collisions if you need the results from your collisions to know against which values to clamp in the first place? – David Gouveia Dec 27 '11 at 23:14
What's really happening is the character is being drawn before being moved to the correct location on the next frame instead of being moved to the correct location before the current frame is drawn. – Casey Dec 27 '11 at 23:33

I've had the same problem recently and fixed it like this:

move the object, checking for a collision, if collision is found, place object outside of colliding object. draw the object.

The player could keep running into the wall without any jiggling because before he is drawn, he will be placed at the side of the object.

share|improve this answer

Using vector / plane mathematics you can calculate exact point of collision with wall that will happen in next frame. This assumes that your character has velocity which you can use to calculate movement vector that will happen during next frame. After finding point of collision you can calculte sliding vector that will move your character along wall, this vector actually can collide with another wall.

So back to your question, you should calculate the exact position of collision where your character should be located and what actually should happend then. If this is a wall and its FPS game, then let character slide along it.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.