[3] Pong WIP [2/4]

I'd be lying if i said this entire week was free of annoyance. For each day this week (and for a bit of last week), I felt at some point that I was jury-rigging something, if I even completed anything substantial at all. This is evident in my attempts to add a custom movement style to the Pong game.

To have the paddles swing in a consistent manner around a singular point, I wanted to adjust the bounding box of the image to put the origin farther away whilst still being in the center.

I'd also see to it that the collision polygon stays the same:

To test the rotation, the collision, and just how the ball would react, I added a simple thing where an "a" or "d" press would add to the bar's rotational velocity. What I mean by that is a global called something like 'bar1rvel' would be added to the bar's current angle every tick, and every key event would add/subtract from that global: (the text in the lower-left is bar1vel)

I noticed a few things after the test:

• The rotation of the paddle doesn't affect the ball beyond simply changing its angle of movement

• The paddle isn't restricted by the walls, rather it's limited by the bounding box of the entire layout

• The ball can enter a sharp vertical angle to where it gains a ton of speed before ever hitting the next paddle

• Particles weren't being consistently placed

Before I started fixing any of that, though, I figured I'd quickly try a different control scheme, where moving up and down is different from flapping the paddle to a specific side (ex. w+d points north-east). I also redesigned the paddles to not literally be 4 pixels:

For this, I had to disable the touch controls because of the added complexity of 6 inputs.

(I also deleted the "bound to layout" behavior.)

This alone was a bit troublesome to add, even with the more convenient 'rotate x degrees toward y' action. I didn't want to reinvent the wheel by creating a physics engine when there's already one present. So using that engine, I made a revolute joint using an anchor point (shown in yellow in the video) to have the paddle swing around.

The following is the result of trying that:

The paddle now seems to follow the anchor whenever it feels like it, seemingly resetting if it's touched by the ball.

After some tinkering, I was simply told to make the paddle immovable with the pin behavior.

After doing so, I could no longer apply torque to the paddle, nor set its rotational velocity.

So on a whim I tried this stupid thing:

I don't know why I thought even for a picosecond it would work.

To properly rotate the paddle at all using this setup, I was to manually implement the rotational behavior.

This puts me back at square 1, of reinventing the wheel.

I obviously didn't want to do this, so I thought of a simpler solution:

This image shows how the strength of a hit would be handled.

The speed of the ball is to be affected by the closest image point on the paddle.

Ball B will be closest to image point 4, and as such will take the 2nd weakest hit

(with 5 being the weakest).

In contrast, ball A will take the maximum strength hit possible, due to it being

closest to image point 1 over the others.

Instead of the physics for the ball, I'm just going to use the bullet behavior, because it more easily handles bouncing off of an object.

I also plan to overhaul the controls again to where I might be able to add back

in those touch controls. The bar's rotation would be clockwise or counter-clockwise

based on the ball's y position relative to the bar's anchor point.

Here's the current state of the game, with an added bug that I need to work out:

If you swing too far, you will inadvertently score a point for the other player.

I call it the double-bounce bug.

I plan on finishing this to move on to something else starting Monday.

Anyway, that's it for this week.