Results & DiscussionsBOIDS
Problems Faced
We ran into a lot of issues whether with hardware debugging or game logic as discussed below:
Self collision bug for Snake
Initially we noticed that our code for self-collision was not working. We had checked each element of the snake array and compared it with the front of the snake. We supposed that if they were equal, then collisions would be noted and the game over screen would be displayed. However, in no case did we find a single collision being registered.
After thinking through our process, we realized that we should not have compared the front of the snake to each element from the start of the array to the length of the snake. This is because the location of the snake’s body moves within the array (such as in a first-in-first-out algorithm). Thus, we fixed the bug by checking from the front of the snake and moving back to the position listed as the front minus the length of the snake.
Potentiometer Discontinuity
Since we are using continuous potentiometers, we had to resolve the issue in which the ADC value would jump from 1024 to 0 or vice versa. For each game, we had to decide how we wanted to handle the discontinuity and struggled a great deal. Several methods we ended up implementing included mapping the ADC values to position, mapping the ADC value to velocity, or just thresholding the ADC value such that something happened when it surpassed a specified variance in a time period.
What we decided to do was register a change greater than 600 as passing the discontinuity. For example, if a normal change greater than 100 is a right turn. A change greater than 600 would be registered as a left turn.
Brick collision for Brick-Breaker
We had a bit of confusion with how to deal with brick collisions in a clean and straightforward way. This is because once we know that the ball has collided, we still need to know whether to change the x or y velocity. Initially we wanted to check every edge of every brick to see if it would be a horizontal or vertical edge. This would have been very computationally expensive.
However, after looking at pseudocode online, we found a much better method. We first update the x and check if there is a collision. If there is, we will negate the x velocity. Then we update the y and do the same thing. This makes it so we do not need to rely on extremely fast processing as it only checks one at a time.
Execution Speed --- Flickering and Concurrency
Overall, our game runs very smoothly, we used various techniques to make sure that there are no flickering screens that will affect the visual appeal of our project. For the main menu, we erase and redraw the screen only when ADC input changes to avoid unnecessary drawing and redrawing of the menu.
Using the potentiometer for menu selection shows no significant delays. Screen change happens in less than 0.5 seconds after a button pressed for a game. Game feedback also shows no significant delay from input to visible output.
Accuracy -- Video Signal Timing
The ADC has values ranging from 0 to 1024. For the Etch-A-Sketch game, the ADC value is directly mapped to the position of the ADC. Each increment in ADC value is equal to 0.3125 pixels in y and 0.234 pixels in x. For the snake game, a change in ADC values corresponds to a direction change of the snake. The threshold is 100 for normal situations and 600 for discontinuity. The speed of the snake is controlled by sys_time_seconds and it is updating itself every 250ms. For the boids simulation, we used PT_YIELDTIME (33- (begin_time - end_time))to make sure that it is running at 30 FPS. The ADC values are used to control the speed of the predator instead of positions. Brick breaker and pong also use the same strategy to control the movement of the paddles for smoother transitions. These two games are also kept at an FPS of 30.
Safety Enforcement
We ensured that wires were effectively plugged in and of the proper length whenever adding to the circuit. This prevents loose wires. Additionally, any pinch hazards are avoided by making components such as the potentiometers a reasonable distance apart. There are no hazards with the display since the brightest setting will not cause health concerns for the eyes. Additionally, the only moveable components are not electric powered and can only move if a human is turning the knob of the potentiometer.
Interference with Other Pople's Designs
The miniature arcade project has very little interference for other people’s designs. Since it does not use any radio communication, actuators, or power-intensive components, there are no noise or interference concerns with other designs or projects. Additionally, since the software is self-contained in the PIC32, there are very few security concerns with hackability or interfering with other electrical or software systems.
Usability by Us and Other People
The interface that we have created has a small learning curve which makes it fun to interact with. Since each game has slightly different ways of taking the potentiometer input to influence the game, the games do not feel too similar. For example, snake requires the user to do quick turns by passing a certain threshold value of the potentiometer, while Etch-A-Sketch requires more intentional and thought out movements. Meanwhile, the boid simulation gives users visual entertainment while the Pong Game focuses on the multiplayer aspect.
In terms of being user friendly, no game requires both button and potentiometer input at the same time (which might lead to some awkward hand positions). Some games such as Etch-A-Sketch and Boids are more user-friendly while Snake, Brick Breaker, and Pong all provide challenges for players to overcome and get accustomed to (though the learning curve is not large). Since we are using a potentiometer, we believe that it is more user friendly to people with special needs who might have a difficult time with small keys (compared to a simple rotation of a large knob). Additionally, rotations are more lenient than button pushes because they are mapped to a spectrum of movement rather than a period of time that the button is depressed. Therefore, the controller that we have designed can be more finely tuned for small movements. Additionally, it is a lot easier to filter out noise caused from a trembling hand on a potentiometer than from random button presses caused by a trembling hand. Lastly, all of our games account for common color blindness except for Pong (which can be easily differentiated by moving one of the knobs since players are unsure of which player they are until they move the knob).