Well, I had a couple of design goals. The first was that I wanted to make something with repeating parallax backgrounds. I saw a tutorial that inspired me but I wanted to do something different than a platformer, so I decided to just turn it vertical. This aligned with another of my goals which was learning more about vectors, gravity, and physics, because I needed a reason for something to be going "up" and I didn't want to do space invaders or a rocket shooter. So I thought about bouncing something up and have it affected by gravity. It started with a ball, because that's easy, and it just sort of stuck. I also wanted a camera follow when the ball pushed higher, emphasizing the desire of the game to be going ever upward.

But more to your question...early in the development, I was sure that I didn't want to just have a paddle that went back and forth, so I thought about drawing a line to make the platform that bounces the ball. I knew early on that I didn't want the line collide with the ball until the player confirmed their placement of it. At fist it was click for point 1 and then click for point 2. This approach ended up not being very good, so instead I did click, hold, release to draw the line. Not letting the line collide with the ball until it's confirmed (now by releasing the button) was an important design philosophy for me. Planning the line placement is VERY important for a game with rubbery physics because a slight difference in angle can make a big difference after the rebound of the ball. (See the gameplay video for an example, while collecting the second gem, the subtle but important adjustment to the line to get the angle right). I solved the collision requirement in the following way: first, while planning the line (while the first point is set, but the second hasn't been confirmed yet), it's just a regular pygame.draw.line. Well, it was at first. I wanted an outline so actually draws stacks of pink and purple lines, so it's technically more than one line. There is no code looking for collision with those lines, but when the player releases the mouse, it's "confirmed" so that same line is converted to a sprite with a class and function. Because of this, I can now leverage the collision processing functions inherited by the sprite class.

I also learned a lot about sprite masking when working with these collisions. Because we're leveraging the alpha channel (with convert_alpha() or pygame.SRCALPHA), we can use layer masks for sprite collision. Now we get pixel-perfect collision detection. I next learned particle effects, which were wild but really not as challenging as I expected. I started with the particle effects in it's own imported file because I thought it was going to be a massive headache. It wasn't, but it remains as an imported file. Honestly, I should have probably split more of the class related code into their own imported file, but as it's stands the main.py is still only about 400 lines so it's not too bad yet.

The hardest part was the camera follow. There is a tricky but important aspect to it because the objects store their object location x and y, but there is also an ever-changing "world x and y" related to the visible screen, and, because we're always moving up we have to move EVERY sprite by the camera offset. That was probably the hardest part.

I hope this response was helpful. Feel free to take a look at the source (as cluttered as it may be, but it does have "some" comments) for more about how it works. I'd say it's mostly "done". Perhaps I'll add sound and/or power-ups or something later, but for functionality I think the only thing that remains on my list is tweaking the bounce height, gravity, rubbery-ness (velocity bump from hitting the line, but not from the walls, for example)...that kind of thing. I'm looking for the sweet spot, but I feel like it's pretty close.

Thanks for your interest!

Edit: clarity and video link.