The game itself was a a lot of fun to write, and wasn't too difficult. But I'm having a couple problem with it, and whilst they are not entirely Perl problems I suspect there is a module which could help me. I've searched CPAN for collision detection and gaming modules and come up short.

My problem is soley related to maths. My main (circular) sprite has an X,Y position, and each "tick" of the game this is updated:

You might save cycles by doing an initial check whether the bounding box around the ball intersects the bounding box around the line -- depending on the length of the line and its angle.

The other approach may be to avoid performing a calculation on every (dx, dy) step. In particular, if the ball is moving in a straight line (or any other path that you have a polynomial for), you can calculate where the centre will be if it meets the line, then after each step you can check if the centre has gone past that point (the bounding box (x, y, x+dx, y+dy) encloses the impact point). Until, of course, the ball changes direction.

First of all the game is quite nice, but there's a simple method with which you can win every level pretty fast, which kind of kills the fun as it is now.

just make a line from the far left, at about 1/3 height of the screen, to the right lower corner, all sprites will disappear quite fast

How can I tell whether the circular sprit intersects with an arbitrary line.

I don't know how familiar you are with linear algebra, it really helps ;-)

(Update: When I talk about "points", I really mean "position vectors to points". Thanks FunkyMonk)

I'll call the end points of your line A and B, the center of your sprite M, the point on the line which is the closest to M is called C (all those are vectors), the radius of the sprite is r (a scalar value).

Since C is on the line between A and B, it must be expressible in the form A + x * (B-A). Since it's the closest point to M, the connection line from C to M is perpendicular to the original line, or as a formula:

Are you sure dx, dy aren't so big that the ball teleports right past the line? It may be that all the ball needs to do is quantum tunnel far enough that the center of the ball is on the other side of the line? Maybe you could post a little code showing your calculation and indicate the range dx, dy are likely to take?

So in fact you need to perform a complicated area intersection with the area traced out by the moving object and the boundary line unless you can guarantee that the object won't move twice it's "diameter" or more in a single update.

you can easily see that f(X,Y) = 0 only if point X,Y is on the line, and, f(X,Y) > 0 for each points of one half-plane defined by the line, and, f(X,Y) < 0 for each point of the other half-plane.

Consequently, it is directly usable for testing if two points are on the same half-plane. But you want to test something different a bit. Let you construct two helper lines parallel to the [1] line, both in the distance equal to circle radius, g(X,Y) in positive half-plane and h(X,Y) in negative half-plane of the [1], with the same "orientation" of positivity/negativity. You can construct these functions just once when program starts, regardless on the position of the circle.

Let (X1,Y1) is position of the circle center before movement and (X2, Y2) is position after movement. Exploring signs of f(X1,Y1), f(X2,Y2), g(X1,Y1), g(X2,Y2), h(X1,Y1), h(X2,Y2) will give you, what do you need.

When putting a smiley right before a closing parenthesis, do you:

Use two parentheses: (Like this: :) )
Use one parenthesis: (Like this: :)
Reverse direction of the smiley: (Like this: (: )
Use angle/square brackets instead of parentheses
Use C-style commenting to set the smiley off from the closing parenthesis
Make the smiley a dunce: (:>
I disapprove of emoticons
Other