Alright, update time. Good news and bad news.
Bad news is, my weekend is basically shot - I spent almost the whole time writing, then rewriting a player-to-player collision detection system that already worked well enough because of a situation that will probably never happen.
Good news? It works.
First, I'll explain how the first version of the collision detection worked so that I can explain the problem situation and the resulting new collision detection system. Initially, I detected collisions between two pucks based on the distance between the center of the pucks at the positions they'll be on the next update (based on velocity). If the positions were less than the summed radii of the pucks, boom collision! ... well, MOST of the time...
The problem that I'd theoretically run into if the pucks sizes were small enough relative to their velocity is: What if the pucks had sufficient speed to cross each other's paths so fast, that on the next update, they're already past each other? This may be easier to visualize if, say, you shot a bullet at a wall. At a given frame N, the bullet is ALMOST touching the wall. At frame N+1, the bullet's velocity is SO FAST that the bullet's updated position is on the other side of the wall! Technically, they never collided because there was no validation between updates! With my old system, this situation COULD POSSIBLY MAYBE occur.
The new system meant to alleviate this issue, was found in Mathematics for 3D Game Programming and Computer Graphics, Third Ed. by Eric Lengyel, chapter 12 section 4. I don't want to bore you (any more than I have already) with details, but basically, given initial position and velocity, you can know when two objects on a collision course are going to hit. Given this impact time, you then have the positions of the objects at that time, and can then do your impulse resolution to 'bounce' get the objects to get them to move away from each other. SO this new method of collision detection doesn't have any holes!
The aforementioned impulse resolution was next. I found the solution to this in an article written by Randy Gaul - How to Create a Custom 2D Physics Engine: The Basics and Impulse Resolution. Now my two pucks bounce off each other in a realistic fashion and I'm guaranteed not to miss any possible collisions!
Why, you ask, did I spend practically my entire weekend doing this? Well, 1) Math is hard. I don't remember much from college, so just figuring out what was going on at first took most of my time. 2) I didn't plan on it taking this long. I definitely thought about just using the 'good enough' system. However, I thought about future-proofing: What if I add some super-speed power-up? Or I have to limit the simulation clock for performance-sake? 3) I learned a lot, which is part of the reason I'm participating in the jam!
The rest of my weekend was setting up a version control repository for myself, but also for my friend/roommate/co-worker who's agreed to help me out! He spent some time looking at and integrating a controller library for Processing called Game Control Plus. Right now it just detects different controllers, but it's a great start. Having controller support is practically essential because analog control gives you finer-tuned controls over angles AND I'd like this game to be local multiplayer at some point. Having a teammate will definitely help this project along faster!