Overall Gameplay

Following the original game, each player will take turns throwing and aiming at each other until one player gets hit. In general, the overall gameplay can be summarised as follows:

With our physical model, the most important element was the launcher and the ability to adjust the speed and angle. Angle was the relatively simple parameter to change using a servo motor, but speed was where we needed a lot of physics and online references.

Hence, one of the key working principles is that which governs the flywheel launcher and its projectile speed.

Flywheel Launcher

We decided to go with a flywheel launcher as it is driven by a DC motor. The speed of a DC motor can easily be varied by varying the voltage across it. Subsequently, this speed can be checked and verified simply by using a highspeed camera to capture the distance travelled by the ball. This data can then be used to calculate its speed of launch using some projectile motion concepts.

There are a few things that we can change for a flywheel launcher. First, we can choose between having one or two driving motors.

Image from https://www.vexforum.com/t/physics-of-the-flywheel-launcher/29357

Between the two configurations, we decided to go with one driving motor like the one pictured on the left. We also decided to add a stationary wheel on the other side to better guide the ball in a straight trajectory. If we used two motors, despite applying the same voltage across each motor, the angular velocity might be different. This results in a situation similar to the one on the right, where the ball steers towards a particular side.

Another variable that we could change is the distance between the two wheels.

We need to ensure that the distance is just nice to ‘squish’ the ball a little bit. Essentially, we needed sufficient friction between the ball and the wheels to accelerate the ball forward. At the same time, the distance cannot be too close such that the ball is unable to pass through. This was one of the parameters that we had to experiment with a lot before we settled on the final design.

Gorilla Fall Detection

Another key principle for our physical game is to detect if the gorilla has been hit. After all, that is the whole point of the game. Unfortunately, we couldn’t find an Apple Watch small enough for the gorillas to wear to detect when it falls.

Instead, we used touch sensors which could register when there is something in contact with it. Since our gorillas are plastic, we had to add aluminum foil on the bottom for the touch senor to sense it.

(Image from https://osoyoo.com/2018/11/14/arduino-lesson-digital-touch-sensor-module/)

However, we found out later that the touch sensor requires some pressure to register the touches, and our 3D printed plastic gorillas were too light. Additionally, the program was rather unstable when we changed the touch sensor to ‘game mode’, where the player only loses when the gorilla loses contact with the sensor. We had flipped the modes when testing and troubleshooting to make the process more convenient.

In retrospect, a light dependent resistor (LDR) could be used instead to sense if the gorilla has fallen. Since our gorilla is a opaque, there would be a change in resistance across the LDR which can similarly be tracked by the Arduino. Additionally, we could test the ‘game mode’ earlier simply by taping over it with an opaque tape before assembling.