No changes of any Magnitude (Vector Pun!)

This week’s update is about as action packed as last week’s; not a lot of forward progress has been completed as far as actual game coding is concerned. I finished updating the code in ts-tennis to use the new features in ts-game-engine (it was a few minor revisions behind) and got back to the ultimate goal, which is to finish all of the extended exercises for this particular game.

In actuality, there are only two exercises left that I hadn’t already completed (although I added a couple of extras to the list just for a small bit of polish, which are not outlined here):

  1. Fix tunneling issues with collisions between the ball and the paddles when the ball is moving too fast
  2. Restrict the vertical motion of the paddles to not be the full height of the court

Issue #1 is a “classic” collision detection problem; if collisions are detected by checking for bounding box overlaps, it’s possible for one object to be moving so fast that between one update and the next the position switches from being on one side of the other object to the opposite side; no overlap means no collision. In a Pong type game, that’s the height of annoyance.

The solution is to perform the collision detection by detecting if the line segment between the current and future position of the ball intersects the paddle; if so, there is definitely a collision and further steps can be taken. This isn’t 100% foolproof, mind you; imagine that the line segment between the two positions missed the top corner of the paddle by even a pixel. In this case the ball actually DOES collide (because unlike the line, it has width). There are limits to how far one should perhaps go in their quest for a perfect pong simulation, though.

In any event, this was a reminder to me of what my original goal when I started out with collision detection a couple of weeks ago was: collisions between lines and rectangles/circles. I started off with that as the ultimate goal but as I proceeded I forgot that the reason I wanted to do that was specifically because I needed to, and decided to stop before doing that so that I could get back to the business at hand.

Whoops.

In fact I have the basis of the code to do this already; I have projection code that determines exactly where the ball is going to cross the paddle edges on either side (including reflections from the top and bottom of the “court”) which is used in the AI to move the computer controlled paddles. Thus I could easily pull that out and repurpose it.

However, I would much rather have a more “generic” solution for future use. I already have code that does collisions between line segments, so it would be easy to write something that checks for collisions with any of the four segments that make up a rectangle to know if it collides. Detecting collisions with circles is a little bit trickier, though.

I don’t know if this is the best way to go about it or not, but the only way I can think of to do this at the moment is to project a line perpendicular to the line we are testing  that passes through the center of the circle, and test the distance between that endpoint and its intersection with our line to see if it’s within the radius of the circle or not.

To do that, I feel like I need a bit of a refresher on Vector math; back in my high school days, Math and Physics were my jam (original career choice before becoming a software developer: electrical engineer) but it’s been a while.

To this end I’ve pulled out some old textbooks and we’ll see what happens. I want to write some pages for this in my math for game developers pages as well, since having to explain to someone else is a great way to ensure that you understand something yourself.