Alright, since I need to blog more about development, AND talking to someone about my problems often helps me solve it, this will be the first of potentially many posts where I stream-of-consciousness about a problem until I run solve it or run out of steam. I’ll think of a clever title later.
Right now I’m making a breakout clone, titled Breakthrough until I think of something more original. To avoid programming the physics from scratch, I’m using Unity physics, which isn’t 100% intuitive to me.
Objects using the physics engine to control their motion require a collider and a ‘rigidbody’ component, both of which have several configurable settings. The ball has both of these components, and that’s simple. On a basic level, it just goes.
Blocks have no rigidbody but do have a collider. This means they get collision messages and the ball bounces off them, but they don’t move. That’s good.
The bat is were life gets tricky, since it’s motion is not dictated by the physics engine but by player input, but it has to interact with things that are solely controlled by the physics. So far, I’ve found a few options for dealing with this, some of which work. You can slap on a rigidbody and have player input apply forces to the object. That works, but has a problem, in that the ball bouncing off the bat pushes the bat down.
EUREKA: An idea I haven’t tried is having the bat rebound after it gets hit. This seems like it’d look cool and fix the problems. Not trivial to implement, so I’ll keep going and try it after finishing this post.
I’ve tried to solve this problem two ways. First is to turn on the rigidbody flags that restrict motion in particular directions. This turns out to be a terrible idea, because it apparently makes conservation of momentum break down and makes the ball stop moving.
EUREKA 2: I need to set up a minimum speed for the ball in addition to a max speed to keep unforseen physics quirks from tanking gameplay. Also enforce a minimum amount of the vector being vertical motion to keep from getting stuck in flat trajectories.
The second solution is to jack up the bat’s mass so that the vertical motion imparted upon it is utterly undetectable. That works, but it means you are hitting the ball, massing 1 kilogram, with a bat massing 1 million metric tons. Understandably this transfers a lot of momentum into the ball, making it hit my speed cap pretty hard. Not exactly ideal.
Alternately, I can tag the rigidbody as kinematic and directly manipulate its position. This works, but it feels like some of the bounces of the ball off the moving bat are wrong. This doesn’t particularly surprise me, but I’m not sure if it’s just perception or not. I’m also not sure what to do about it.
If the ball bounces off the immobile blocks when they don’t have rigidbodies, can I just pull the rigidbody off the bat? I haven’t tried that, but it seems as though it’d sacrifice some of the advantage of using the physics engine, namely the ability to impart sideways motion by hitting moving the bat as the ball hits it. This may not be any better or worse than a kinematic rigidbody. I’ll try it.
Turns out that seems to be the best solution. No sudden hyperballs, the bounces all seem right, and I feel like I have more control over where the ball goes than I did before. I guess the moral of the story is once again KISS.