I'm scripting my own collision logic for a 2D game that works like this:
Boxcastin the direction of movement against appropriate colliders in the scene
- If a contact is detected, move to the
- Move back in the opposite direction of movement while trying to maintain constant "padding" around level geometry
- Finish movement (using something similar to a collide and slide algorithm)
My issue is with #3. Once it's time to resolve collisions, instead of resolving in the direction of the surface's normal, I want my collider to be moved backwards in the opposite direction from which it just came (easy enough). But I also want it to be placed in a such a way that it is displaced from the contacted surface by the surface's normal multiplied by some padding amount.
Let me try to clarify with these pictures:
Here, my collider in green boxcasts (in red) against the square shape; the translucent, dark box around it represents my desired padding around the geometry. The collision is then resolved in the direction of the red vector. This is simple and works fine because the surface normal is identical to my desired resolution direction.
But then if the collision occurs on rotated geometry, or I contact, for example, a 90-degree surface while moving diagonally, I don't know how to find the appropriate resolution vector, as the opposite direction of my movement is different than the surface normal (in white).
My goal is to find a reliable way to calculate the red vectors regardless of the contacted surface's normal, or to find a different way to maintain a constant distance around my collision geometry. I have found this problematic in certain scenarios, especially in top-down games in which the player may move in several directions on the same surface.