The upward-moving crusher adds extra complexity. So with horizontal and vertical detection points in the same place, you couldn't get case 4, even before you add movement direction to the mix. If a crusher is down, the player should not be able to walk forwards - it should act like a wall. So your cases 3 and 5 don't exist.Īs for collision detection, as has previously been said, you need to consider movement direction, and you have two axes of movement to consider. With that in mind, the idea of having separate points for horizontal and vertical collision simply doesn't fly. There were few experiences more frustrating than dying when a weapon/crusher/enemy was clearly several pixels away from your character - and that kind of experience is what stops people playing. For example, if the character's sprite was a simple green square, the collion points would look something like this:Īs someone who grew up with 80s platformers, my first comment is that the contact points must be exactly on the sprite, not anywhere outside it. To clear up some confusion, the red collision points would be within the sprite and the grey lines were only used to denote the relevant axis for each collision point.
UNITY FALLING BLOCKS DETECT COLLISION HOW TO
I've been racking my brain on a solution, but nothing I've come up with has worked particularly well, so I'm wondering if anyone out there has an idea or insight into how to solve these problems. Two objects are far enough apart for the bottom collision points to clear, allowing the player to fall, but no to so far as to allow the side collision points to clear, causing an unwanted horizontal crush. But now, having done so, the object is intersecting a top collision point causing an unwanted vertical crush.Ī similar scenario is shown in #5. Now, if the object continues to move up and the player continues to move right (as shown in #4), the object clears the players right-side collision point and the player moves to the right. A right-side collision point is hitting the object, causing a collision and stopping the player. In #3, the player is moving toward the object, which is moving up. #3, 4, and 5 present problematic scenarios. The player is grounded and the top collision points are intersecting with the falling object. In #2, you can see a normal crush scenario. If they are, the player is being crushed. The simple solution to detecting when the player is crushed is to see if the collision points on opposite sides are both triggering. In the following images, the light blue box represents the ground, the orange box is an object, and the arrows indicate direction of movement. Everything works exactly as I'd like it except for one problem: crush detection. I like the results I get from checking collision this way (versus, say, bounding box). The red dots are the pixels that are checked and the grey lines indicate the axes they pertain to.
I'm checking collision for a platformer character as shown in #1.
0 kommentar(er)
