determining if angle is inside arc on a circle...

Yesterday (November 29, 2022) was the video game Pong's 50th Birthday! Not the first video game but the first to really take off in the public imagination.

To celebrate, I made an (not very) original game: Rotato Solo Pong

You can mess with the program online. (The version on my site adds a little code to help with mobile, so the finger control doesn't drag the whole screen around....)

I used to make a lot of online games and toys but I haven't been lately... going over some of the cool stuff with my niece made me think I should get back into it a bit? It's a very pleasurable and satisfying hobby, even if I don't know how to publicize a game to get it in front of more people...

This one was trickier than I expected - specifically, figuring out if the ball was hitting the paddle, which I was content with saying "is the angle the ball is at relative to the circle (easily calculable with atan2 function) inside the edges of the paddle, when the ball is on the circle border (easily calculable with the dist() function)" 

At the time of development, it was two paddles - a cooler visual but less fun game mechanic, since you barely had to move to hit the ball...

So circles go from 0 degrees to 2 * PI... and then they start over (at 3 o'clock on a clockface.)  The trouble occurs at that zero = 2 * PI boundary - like when a paddle is perched with one end on either side, it's tough to figure out what angle values to compare vs the angle of the ball.

To work my way through it, I set up a lot of visuals within the game - click here for an interactive recreation to show the problem - an exclamation point shows up when it has detected an overlap of the circle with either paddle:

This shows my first attempt at normalizing angles (like adding 2*PI if the angle was negative, for example) It shows the basic double rotatopong board, with color coded displays  below of the linear values I'm trying to compare to figure out the overlap. You can see that the blue paddle is near that troublesome boundary bit, and so the visual segment of the endpoints (shown underneath) is elongated, and tilted the "wrong direction" 

It was frustrating that this problem was as hard as it was - in fact I reached out to a friend who works at Google but I ended up solving it before he got back to me. One trick was this: for the paddles, I couldn't normalize the angle one at a time: if I had to make an adjustment, it needed to be on both ends of the paddle, so to speak.

That prevented the "weird elongated bar" problem, but there were still misses. My final technique normalizes all angles, but then uses a duplicate of the ball angle - i.e. comparing both the ball angle AND ball angle + 2*PI to see if either is inside the especially normalized paddle end points.

So I think that works? I don't know if there's a more sane way of doing it though. It seems like the problem should be straight forward, but the whole thinking radially is actually pretty tricky...

(I tackled a similar and seeming more difficult problem way back when, figuring out which direction to turn for a heatseeker effect.)