Adam Weesner

Among the core features I wanted to add, the user input was the absolute priority. I wanted a smooth and responsive experience. Most mini-golf games rely on using showing a power meter to determine shot direction and power. However, I wanted something more intuitive and skill-based. I came up with swiping the ball to putt instead. In essence, the player swipes the ball in the direction they want to putt, and the length of that swipe will determine the power of the shot. This added a touch of finesse to the act of putting.

​

This is how I accomplished that. Below is an image detailing what happens when the user begins a swipe. First, the function draws a line of the swipe. The angle between the end-points determine the angle of the shot, while the distance between the two end-points determines the power:

All of these calculations must be performed despite the orientation of the camera. Speaking of the camera, the player can simultaneously orientate the camera by dragging the screen in any which direction. The code below accomplishes that:

Getting the physics for the golf-ball down right was another priority for this project. The ball had to jump, bounce, collide, and roll as a normal golf-ball would. I underwent a long, iterative process of fine-tuning the physics just right so that the ball would behave in such a way. As for the physics involved in moving the ball after a shot input, I had to make sure the ball rolled in the direction of the swipe and not the camera. The image below shows how I did this:

One of the major issues many mini-golf games face is the rolling problem. How does the ball know when to stop once it begins rolling? I had to implement a function that will stop the ball from rolling when it reaches a threshold. See below: