bowling.
There were many design constraints we put on this game that determined the final outcome of the ball throwing mechanic. From the beginning, we wanted the controls to mimic the feel of Wii bowling. We also decided that because it was an atmospheric horror game, we didn't want any hud elements, all of the information given to the player should be diegetic. These two decisions provided a unique challenge in figuring out how to translate player input to a satisfying gameplay experience.
Learning to Throw
Wii Sports bowling has a strong tactile feel to it that makes its control system feel natural, like the player is really throwing a ball, however it has the benefit of 3d motion controls. With this as my main source of inspiration for bowling., I wanted to see if a similar tactile control system could be achieved only using the mouse. I observed that there would be 4 axis of control that would need to be addressed for throwing the ball if I wanted a good feeling bowling game: position, aim, power, and ball spin.
​
​
Positioning and Aim
Analyzing other bowling games, I determined that positioning and aiming should have a certain level of precision to them, the player should be able to line themselves up for a shot with ease. I decided that if mouse movements should control the throwing of the ball, then having the mouse also aim would make precision almost impossible. Thus, I took to a more traditional approach of using the keyboard for side to side positioning.
​
As a group, we had determined that the player shouldn't have complete control of the camera, instead deciding there should be set camera positions that can be switched to via button presses. With sideways movement and camera controls on keyboard, I felt that the number of keyboard inputs needed to navigate the game was getting high, so I didn't want rotational aiming to also be a keyboard input. I decided that we could instead use the mouse if we assigned different actions to different mouse clicks. This was what lead to the system in the final build wherein you can hold right click and move the mouse to rotate the players aim, then hold left click to start throwing the ball.
​
This system for aiming was functional, if a little clunky. This was also where I discovered that precision aim was harder to achieve with our commitment not to use UI elements. However, as a group, we decided that clunkiness and imprecision weren't necessarily problems. We weren't just making a bowling game, we were making a bowling horror game, and we wanted the player to be immersed in the world. In a strange way, the controls actually helped contribute to that immersive feel. Real bowling has a sort of clunky, deceptive difficulty to it, as you'd think that you can just go and roll a ball in a straight line, but if you've ever been bowling before, a lot of people have a hard time getting the ball to go straight. So while the control scheme may not provide the perfect sense of control we expect from video games, it does provide an experience closer to real bowling, which I believe helped immerse the player into the horror atmosphere, as was our goal.
Power and Spin
The main concept for using the mouse to throw the ball seemed obvious from the beginning: use the vertical mouse movement to determine the power of the throw and the horizontal mouse movement to determine the spin. Actually achieving this, however, proved to be a more difficult challenge.
​
In the initial design of this system, the game would wait for the player to press down left click, then it would record the mouse position each frame until left click was released,
​
and use the positions to determine the average speed of the mouse to set the speed of the ball. This created an issue, as I saw many players would naturally click, then move, putting a delay between the two, hurting the average movement speed because there was a large chunk of time with no movement. I also realized that if the player held down the button for a long time, the number of calculations would hurt performance. So I switched to storing the mouse positions as a circular array, so that only the final 25 frames of mouse movement are stored. I also added a minimum threshold to the calculation so that if the player barely moved the mouse from one frame to the next, that wouldn't be included in the average.
​
At this point, the system was close to functional, however it still had problems. It was easy to accidentally throw the ball with nearly zero speed. It was also easy to cheat the game by shrinking your window size, allowing you to throw the ball faster than should be possible, and getting a strike every time. To fix this, I took the speed values and ran them through a log function, creating a threshold under which the ball is dropped, returning it to the ball return, while also boosting lower speed values and harshly crushing down higher values, giving a better average throw speed in general. This solution mostly worked as intended. I think there were some variables in the log function that could have used some more fine tuning if I had more time, the average ball speed should probably be a little higher in general, but the systems themselves worked pretty well and I'm happy with how it turned out.
This is the equation used to determine final ball speed from the average mouse speed. Average inputs were around 5 to 40, so average output is around 15 to 30. This equation provided the effect I wanted, but was faulty because I did most of my testing in the Unity editor, and the inputs in the final build had a lower average
​
Ultimately, I think that while the system I made may not have been perfect, it worked pretty well for delivering the experience we wanted it to. Most people who played it seemed like they had a good time, so while some of the systems I made could use a little tweaking, I'm happy with the game that we delivered.