1

I have an array of points that I will use to generate a closed polygonal fence on the outside of a game stage (2D). I wish to have collision detection between this fence and a bouncing ball-like object on the inside.

Additionally, I would like to be able to arbitrarily add/remove/redraw the fence in realtime and have the collision detection still operate realistically.

I have considered drawing a Sprite/Shape from the points and doing a HitTest at each frame to check whether to bounce or not.

My question: is this the best/correct way to accomplish this goal? Consider something like JezzBall with diagonal lines of any angle a simulation of what I'm trying to do.

Ilmari Karonen
  • 49,047
  • 9
  • 93
  • 153
Bryce
  • 11
  • 1

2 Answers2

0

Check the corners of your bouncing ball with four hitTestPoints. If it succeeds, then do hitTestPoints from the fence with shapeflag set to true.

There may be better solutions as I do not know the performance impact of shapeflag, but combined with the corners optimization I think it will be good, but I'm also interested if there is a better way.

apscience
  • 7,033
  • 11
  • 55
  • 89
0

Math will be your friend here. Do a quick search for circle-line, or point-line collision (here's one: Circle line-segment collision detection algorithm?).

What you do is run through your array of points, creating lines. So line 1 will be points[0] and points[1], and line 2 will be points[1] and points[2]. After that you check each line against your ball (if you want proper collision that will work no matter the frame rate, then you create a ball line, which is the line that the ball has travelled along between the last frame and this one). Do your collision detection against the ball line and each line made from your points (there's tons of line-line collision detection algos on the web). What you'll get out of an algorithm like that is the time the collision takes place in the current time step, as well as the normal of the colliding line, which will give you the reflection angle.

If you don't know Vector math, then learn it, it'll make your life a ton easier. Again, there are tons of implementations of a Vector2 class on the net.

You can arbitrarily remove parts of the wall as needed by just ignoring those points in your check.

Another lazy solution would be to use a physics engine like Box2D http://box2dflash.sourceforge.net/ or Nape: http://code.google.com/p/nape/ - it might be overkill for what you want for your game, but hey, it's easy.

For bonus points, another technique which might be easier for you is the Separating Axis Theorem, which is used in the flash game N: http://www.metanetsoftware.com/technique.html

Community
  • 1
  • 1
divillysausages
  • 7,883
  • 3
  • 25
  • 39
  • `if you want proper collision that will work no matter the frame rate.` Are you saying this is an expensive computation? – Bryce Sep 18 '11 at 22:11
  • No, it just all depends on your frame rate and how fast you're moving. Take a simple example; a ball moving towards a wall. Frame-dependant collision detection works like this; move ball, is it colliding: yes/no, if no, keep going. if yes, move the ball to just be touching the wall (as the ball needs to be penetrating in order to detect the collision), then bounce. Where this breaks down is when your ball is moving very quickly, or your wall is too thin. In frame 1, it's on the right, in frame2, the left. In nether frame it's colliding, though it's passed through – divillysausages Sep 19 '11 at 07:33
  • frame-independant collision detection means that no matter your frame rate (i.e. slow, fast), or the speed of your objects, it will always detect a collision, usually by "tunneling" the object from it's position in the last frame to the current position. You take the first collision with this line/tunnel, reflect, then check again with the remainder of the time frame. It's not really any more expensive, just more difficult to do - frame dependant is often easier, and depending on your game, you can get away with it – divillysausages Sep 19 '11 at 07:36
  • a lot depends on what you're trying to do in your game. if you have multiple moving objects that can collide with each other, fast moving objects, thin collidable objects etc. – divillysausages Sep 19 '11 at 07:38