Each controller consisted of one XplainedMini board and a sliding potentiometer mounted in a wooden casing. The sliding potentiometer was a PS45L-R02BR10K model which varied resistance from 0-10kΩ, with a sliding range of 45mm. It was chosen because the range of resistance was broad enough to produce many values, allowing the virtual paddle to move in “real time”. Another reason this specific potentiometer was used was its visual appeal and compatibility with a breadboard. The ability to easily insert and remove the device streamlined the design process, where any shortcomings could be easily corrected. A 10kΩ resistor was connected, in series, to the potentiometer’s voltage pin. This extra resistor was used to vary the voltage; without it, the voltage would have been a constant +5V and the virtual paddles would not move.
This project served as a chance to use topics learned in previous labs, to create a fun video game, playable by all ages. Using serial communication, a pong game was constructed. The software to build it used a combination of Python, C, and Assembler languages, and was and programmed in Windows and run on Windows and the ATMega boards, with an intent to port to a Raspberry Pi 3 model B. The hardware for the controllers was implemented using two XplainedMini boards, each with a sliding potentiometer mounted on a breadboard. These components were all set in a wooden casing. At runtime, the game displayed on a PC and players could maneuver their paddles using the potentiometer to pass a “ball” back and forth.
Since this game was meant to be played by anyone, it was imperative to create user friendly graphics and controllers. For the software, this goal was a bit of a challenge. The frame and data transfer rates had to be adjusted to make the sliding motion of the potentiometer match the movement of the paddle. For the hardware, this meant making a handheld, sturdy controller that was easy to assemble and disassemble.
When the game was played, the ball appeared to hit the floor and ceiling; however, it did not actually collide with either. Instead, the ball’s range of motion was limited to bounce the ball from the top to the bottom. This was a y-axis range of 88-502, and when the ball reached either limit it reversed its direction. In order to make the ball collide with the floor and ceiling, both would have needed to be sprites (moving images), then pygame would have to check for a collision in each frame. This process would have been similar to the collision of the ball with the paddle, but it was simpler to limit the ball’s vertical range of motion.
Even though the ball did not actually collide with the bounds of the game, it did collide with the paddles. The function that checked for a collision was “spritecollide”, which was included in the pygame library. When a collision occurred, an empty list “block_hit_list” was filled with whichever object the ball collided with when a collision was detected. The parameters of this function included a list of both players, the reference to the ball object, and “False” which told the program to not delete the player object that the ball hit.