The most common feedback about the software controllable part of the game concerned ball speed. At the high end, in a short rally the ball quickly got up to speeds that were un-hittable. At the low end, a slow ball felt like it took forever to die. The portion of my code that controls the speed of the ball can be tuned to fix this.
Problems I Want to Solve
Drag
Drag is wrong. My drag is proportional to the ball’s velocity, it should probably be proportional to the square of the velocity or treated like an acceleration. Assuming my light ball did have drag, then it should also have a terminal velocity, which it doesn’t.
The drag coefficient is also very small. I arrived at the current value by trial and error of “what felt good.” A higher value and the ball didn’t make it to the other side without quite a wallop; a lower value and it never died. A value much higher than were I have it set now made the game unplayable for all but the strongest swingers.
Players, however, don’t mind the drag except at very slow speeds when it doesn’t die fast enough. At high speeds the drag isn’t noticeable because the hit of the bat has a much greater effect on the speed than the drag, and the time between hits is very short. What I really want is the opposite of how drag works, I want greater drag at slow speeds.
Energy Transfer
Currently I add speed to the ball based on the velocity of the bat. A slow swing will add a small amount of speed, while a fast swing will add a lot. The two bad results from this are:
- The ball gets going too fast in just a few good hits. It’s very hard to have a long rally at reasonable speeds.
- The ball only slows down due to meager drag, so a bunt can’t change the tempo of the game.
Baseballs and bats work very differently than my simple model. (See this summary.)
- Baseballs have a coefficient of restitution (COR) of about .55, meaning they lose 45% of their energy when they bounce. But bats have their own properties, and depending where if you’re in the sweet spot or the dead spot they can vary the apparent COR can be anywhere from .59 down to 0. Ugh.
- According to The Physics of the Bunt, a home run hit adds about a 22% increase in speed to the ball, while a bunt can slow a ball down up to 100%.
Luckily I’m not trying to simulate baseball, I just want players to have fun and be able to control the ball in a meaningful and expected way.
Serving Errors
Here I’m mixing up my baseball and tennis terms. I refer to a player’s first hit of the static ball a “serve.” (And I’ll continue to do so!)
Players experience a lot of accidental serves from breaking the beam accidentally before their intended swing.
Solutions
In easy-to-hard order:
Serving Errors
This problem seems easy to fix, and separate from the Drag and Energy Transfer solution. I’m going to just use a minimum swing speed necessary for a serve.
Drag
The problem players want solved is to kill the ball when it’s going to die anyway from lack of speed. Early, I found that if I killed the ball too soon the players might not understand that it was on its death bed, so I let it slow down a lot to be clear. I’m going to implement a method to increase drag as the ball slows down, effectively simulating it hitting the ground and having additional rolling friction.
Energy Transfer
For my first try at this fix I’m going to find a swing speed that feels like it should bounce the ball back at about the same speed (a “mid-gentle” swing perhaps?). Swings above that speed will add proportionally more energy up to a 50% (?) increase in speed, and slower swings will reduce the speed up to 50% (?) for a bunt. The two 50% numbers are the starting points, and I’ll do some testing and tweaking to tune them.
This is different from the method used before, which just added a speed of between 0 and 45 mph to the ball based on how hard you were swinging. A 30 mph ball in that scenario could exit at up to 75 mph. In the new scheme its fastest exit speed would be +50%, or 45 mph. In the old model, after five hits in a rally, a ball could be going 255 mph. In the new scenario, it could theoretically be going 228 and getting to higher speeds much more quickly, BUT under the new scenario it would be difficult for a bat to get up to high swing speeds in under one second between hits. This should help keep the ball in a playable zone.
I wrote this post because I was struggling with what the right solution might be for the ball algorithm. I’ve been letting it percolate for about a week and had come up with a few ideas, but I felt like I had stalled out. I thought that if I tried to explain it to someone else I would have to clarify my own thoughts.
It worked! By the time I finished writing this I knew what my next steps would be.