6
\$\begingroup\$

So I'm messing around with collision detection in my tile-based game and everything works fine and dandy using this method. However, now I am trying to implement sprite sheets so my character can have a walking and jumping animation.

For one, I'd like to to be able to have each frame of variable size, I think. I want collision detection to be accurate and during a jumping animation the sprite's height will be shorter (because of the calves meeting the hamstrings). Again, this also works fine at the moment. I can get the character to animate properly each frame and cycle through animations.

The problems arise when the width and height of the character change. Often times its position will be corrected by the collision detection system and the character will be rubber-banded to random parts of the map or even go outside the map bounds. For some reason with the linked collision detection algorithm, when the width or height of the sprite is changed on the fly, the entire algorithm breaks down.

The solution I found so far is to have a single width and height of the sprite that remains constant, and only adjust the source rectangle for drawing. However, I'm not sure exactly what to set as the sprite's constant bounding box because it varies so much with the different animations.

So now I'm not sure what to do. I'm toying with the idea of pixel-perfect collision detection but I'm not sure if it would really be worth it. Does anyone know how Braid does their collision detection? My game is also a 2D sidescroller and I was quite impressed with how it was handled in that game.

Thanks for reading.

\$\endgroup\$
1
  • \$\begingroup\$ Once I solved this by setting separate collision rectangle for each frame (in animation file) and then just using this value. Spriter does it same way (brashmonkey.com/spriter.htm) \$\endgroup\$
    – Kikaimaru
    Aug 22, 2012 at 6:34

5 Answers 5

2
\$\begingroup\$

I think you need to approach this issue on a slightly larger scale. As others have pointed out, changing the bounding box in-game at runtime might be quite tricky from the gameplay perspective. What do you want to happen for example when a player jumps, fits into some small place (where his bounding box wouldn't fit if he wasn't jumping) and then finishes jumping? You probably need some sort of "crouch" mode. And if you have that, you can easily apply it to jumping.

In the collision detection method itself, I guess the solution will depend on whether you want a discrete change or a progressive increase/decrease in size that lasts multiple frames.

\$\endgroup\$
0
\$\begingroup\$

Your objects will be thrown all over the place during collision resolution when their shape/size increases.

This is normal. If your object ends up inside another one it will "bounce". Your problem can be solved by:

  • making sure that when you change the shape your character's feet don't enter into the ground. To do so if you collide with the ground while the shape size increase move the shape's position so your character stands up on the ground instead of ending up with his feet in the ground.
  • Make sure there is room for your character to "stand-up". If your character ends-up in a place where there is no room to standup you have to make sure that the character doesn't end-up with his head inside the ceiling. It that was to happen add a crouching animation to fallback to in that case.
\$\endgroup\$
0
\$\begingroup\$

Have to different lods for collision detection. One that is simply a bounding box for terrain collision and another that morphs to best fit your player that is used for damage calculations.

You dont want to change the size of the player in regards to terrain collision. First its technically very difficult. Second because if I fall off the map because I stop walking and my arms stopping swinging causes me to fall to my death while trying to line up jumps I'm going to dislike you strongly.

This is also most forgiving and fair to the player. No BS death because a projectile hit the larger terrain BB. And no BS death because your BB changes while platforming. I really would not change the BB used for terrain collisions at all for a platformer.

\$\endgroup\$
0
\$\begingroup\$

A possible approach is to define if the growing/shrinking is a force, and so it should be reflected during a collision or if it should be a particular case that the engine should handle separately.

In your case, increasing the size of a sprite is seen as a sudden increase in its speed in every direction pointing away from its center.

If you want it to grow in any case, you can't let it sink into some other sprite so you could handle it by calculating the grow, checking where collisions would occur and applying an increase in speed (using an arbitrary value representing how fast it is growing) in every direction point away from a collision surface.

Those vectors will combine to form the fake -controlled- collision result.

That way, before the collision detection system could react automatically, you have the special case wrapped up and fixed. You could also just move away the sprite of the amount of space it needs to grow, without letting it register as speed and avoiding potentially dangerous collisions.

\$\endgroup\$
0
\$\begingroup\$

I'm assuming you push the player back when they collide with an object so they aren't inside the object thus making them no longer colliding.

The problem is probably occurring when your player starts to return to original size, the player was pushed out of collision with the object, then the player grew, colliding once again, or perhaps kept growing and you kept pushing the player back causing them to move back drastically, possibly inside of an object which then tried to push the player out, etc. Basically it creates a mess.

Assuming this there are 2 fixes I see:

  1. You find the overlap of the player and push them back by the difference of the overlap. This is a technique I use for platformers, but can also be used in top-down tile based games. You can also push them back by the overlap of the original sprite size, this might work better.
  2. An easier solution, and you can also use this with the solution I mentioned above. When calculating the bounding box collision use the original width and height rather than the scaled width and height.

Bounding box is pretty simple to implement. Here's a simple example in lua: https://love2d.org/wiki/BoundingBox.lua All bounding box does is check if given dimensions overlap based on there position, you don't need to create rectangles to check for bounding box. All you need is the width, height and x, y of 2 objects. I'm not sure if the implementation you're using allows that or if you give it a rectangle object to perform the check.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .