>>70426015All right. So generally speaking collision code has to handle two different types of run-ins with walls: running into the wall by moving, and having the walls run into you (being squished). The former is far easier than the latter when dealing with a collision box.
Also generally speaking, you know you’ll only ever encounter the former from a maximum of two adjacent directions (eg. up-left, down-right, etc.), and the latter from two opposite directions (up-down or left-right). This is important for later.
Platform fighters usually use an ecb shaped like a diamond for their collisions, with the distance from center for each of the points being a little malleable, at least in smash. This is something every smash game does, rivals 2 does it (rivals 1 used rectangles but rivals 1 is gross), nasb1 and 2 do it, etc. etc.
This is what my game does, initially programmed with a constant offset for each point with the exception of downward, which is smaller in the air to allow for aerials to be done lower to the ground.
The reason they do this is because the rhombus produces a very pleasant set of circumstances for dealing with collision. For starters, you know you slip off when your center line goes off the ground. You know you land and collide on the ceiling based on that center line. And when you’re grounded, you can use that center line to walk on slopes pretty easy, with the added benefit that the geometry of the shape itself handles horizontal barriers for you without any headaches (you will have to do a little screwing with it of course).
What about collisions other than the center line in the air? Easy, just eject out of the wall sideways. This might not be perfect since you get stopped on geometry sideways when if you did the same vertically you’d slide off it, but beggars can’t be choosers. And come to think, there’s probably a way to handle that too. I will have to look into it. It might be able to work even more cleanly than it currently does.
But that’s only addressing the first type of collision. What about the second, the pinching? In a game like this, the ground doesn’t move, so you don’t have to worry about getting crushed by moving terrain. However, you do have to worry about getting squeezed by falling into a gap that’s too thin or too short.
Landings are only triggered if your center like hits the ground, and ejection from the walls only accounts for your ecb running into them on one side. It would shove you into another if they were too thin. And if you’re in the wall, there’s no really good way to handle it. Games usually do a few different things. Older platformers would either crush you when it happens vertically or just eject you sideways in the opposite of the direction you’re facing. That would usually work and pop you out of the wall, unless you managed to clip in facing the wrong way, which could trigger the infamous genesis Sonic zips. Other games would just figure out the closest way to get you out of the wall and snap you there. However, that’s off-putting, especially when you can replicate this setup easily and consistently. If your game is going to have a thin space like this, you either need to prevent your player from getting into it, or you need to handle it in a smarter way. With the ecb shape making the former impossible, I had to do the latter.
My solution was to script out a way of determining whether you were being squished in either direction, and then go ahead and process that into a set of “effective ecb offsets” that shove you as much into the middle of the gap as they can and serve as your new effective ecb. These want to be the standard ecb offsets and try to reset to that every frame, but the squishing code keeps them compressed until they can pop back out, and it does so very efficiently.
Horizontally there are no limits, except smaller than 2 pixels on either side. Considering this gap is almost invisible and won’t ever happen because of external barriers on it, I’m not worried. Vertically there’s a bigger barrier, which is the grounded downward collision offset (since your character should still appear to be standing on the ground, not in it). However, every character’s upward offset plus their aerial downward offset exceeds their grounded downward offset, so there isn’t any need to worry. If they can squeeze in there while airborne, they can compress just fine.
So that’s how I took a very rigid collision system and made it malleable. I will have to look into that vertical slipping thing and see if I can leverage my existing quadrant checking code to do that. It would make for a very nice smoothing out of ledge dashes if I could work that into the ejection routine, and would eliminate this weird “figure out how much to nerf vertical by if you eject based on how far you’ve moved horizontally” logic.
TLDR yap yap yap nerd shit math shit collision box squishes to fit add luna etc