If we have a floor (no gravity/forces), a player (gravity, forces) and a vertical stack of objects (gravity, forces), and the player collides with the stack of objects and then continues attempting to move through them, we get some very weird collision behavior (see the stack-up physics test). Mainly, the player and some of the objects clip through each other, or worse through the floor and begin to fall.
We do not know what the root cause is yet.
Details
The core issue seems to be with how we determine final position after a collision
The intent is "check if our move causes overlap/collision. If no, do the move as-is. If yes, move as close as we can to the object without colliding with it"
We do a test based on the collision axis, then determine the offset of the source's center from the target's center. We may change the x or y value of the final position to avoid a collision.
This seems to result in object's "teleporting" to a wrong final position
We also assume that the correctly computed final position doesn't result in us overlapping with any other objects; if A's move collides with B, we assume that calculating the correct final position with A won't result in it overlapping with C.
This assumption has been proven false in code.
This probably has nothing to do with the physics system directly; I expect the same features would emerge if we changed the velocity/forces code to something simpler
I don't want to land this broken collision-testing code, but it "mostly works" and the first game I want to design with Sprawl (Berserk clone) doesn't require this type of physics.
The problem here is that we move our final position into an overlap, not that the move distance is wrong or that forces get added by mistake.
I added some assumption / testing code to confirm we never are overlapping after any final positions / moves during the collision resolution process.
Ideas / Approaches
This isn't a major blocker until we start working on physics based games that have multiple objects colliding at once; not convinced this bug will break simpler games.
It's unlikely changing the physics system will fix this. But, would working with smaller changes in position per-frame help? This could at least give perspective on the problem / see how it results there.
The forces system does "big move, apply drag". Is this resulting in a choppy-but-smooth-looking movement style? How much do we actually move per frame?
It might help if we simplify / start over norvig style with the collision code; currently it's bit of a mess across a few different functions.
Some edge cases appear to be from a very small object colliding with a very large one; a tiny rectangle can collide with a massive one via an X/Y or X move. Should we compare sizes and test accordingly?
If a tiny rectangle is directly left of a large one, but not directly below it, it should be able to perform the Y portion of an X/Y move, but not all of the X portion. Moving straight up won't cause a collision. Does our code reflect this?
What working examples exist for checking these types of collisions? Can I look at Elliott's code, or other examples and compare? What about the SDL demos?
Summary
If we have a floor (no gravity/forces), a player (gravity, forces) and a vertical stack of objects (gravity, forces), and the player collides with the stack of objects and then continues attempting to move through them, we get some very weird collision behavior (see the stack-up physics test). Mainly, the player and some of the objects clip through each other, or worse through the floor and begin to fall. We do not know what the root cause is yet.
Details
Ideas / Approaches