# Collision resolution with walls

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

## Recommended Posts

Hey, for a collision resolution with a wall would a good method be recording the last direction key pressed (e.g. w,a,s,d) then setting the camera/player's position relative to the direction back a tiny amount by using something like "playerPositionZ = playerPositionZ - 0.5"?

thanks :)

##### Share on other sites

There's a variety of ways to go about it, but generally I give the player a velocity variable, then move the player by the velocity (generally multiplied against time) per update. The advantages are you can then calculate a "bounce" from the collision by just altering the velocity. You can also predict where the player is going to be next update, and calculate your collision based on that, rather than where you are this update.

Depending on how your game is set up, you could run into a few bugs with your current suggestion, depending on say, the speed of the computer running your game, or perhaps get your character stuck in walls if they've moved into it further than your offset. I think you'll also find it's a little unsatisfying, as if you're pressing a direction into a wall, you just kind of glitch back and forth until you stop pressing the movement key.

So, essentially, when you hit a direction key, I generally increase their velocity in a certain direction, and when you collide with an object, calculate the reflection of that collision (if you're using a reflection of the velocity variable, you're guaranteed to get back out of the collision area then) and apply it to the velocity. I can post some examples or pseudo code if I'm not quite explaining things clearly (I'm never sure ).

Edited by Misantes

##### Share on other sites
Thanks for the reply :) if you dont mind I would really appreciate pseudo code :)

##### Share on other sites

Definitely decouple collision testing from keyboard input, and compute those two completely separate from each other.

That is, when processing keyboard input, use the pressed keys to define acceleration/impulse/velocity/position update to your object (whatever the type of motion you want to model is), and then in collision detection and response, don't read the keys at all that the user pressed. If necessary, you could store the previous position of the object, but just don't read the keys.

1. 1
2. 2
3. 3
Rutin
15
4. 4
5. 5

• 10
• 9
• 9
• 11
• 11
• ### Forum Statistics

• Total Topics
633687
• Total Posts
3013327
×