MINIATURE ARCADE GAME COLLECTION

INTRODUCTIONBOIDS

Our project leverages two potentiometers to create an “etch-a-sketch” type interactive device and arcade game collection. We wanted to create a fun game that uses much of what we learned previously in the course, including flocking simulation, hardware input though potentiometers, optimization, and graphic interface control.

When the user first enters the program, they will see a main menu with several options that they can select by either potentiometer to scroll down and then a button to select the menu option. There will be 5 games to choose from.

1. The first will be a normal etch-a-sketch device on the TFT where the user can draw a picture by rotating both potentiometer knobs.
2. The second will be a classic snake game where the user steers a snake to lengthen it by eating red dots.
3. Our third option leverages our previous work with boids to control a predator using the knobs.
4. Our fourth game is the classic brick-breaker game where you win by destroying all the bricks with a ball and a paddle.
5. Finally we have the notorious pong, a two-player game where you win by using your paddle to hit the ball to the other person’s side.

HIGH LEVEL DESIGN

The miniature arcade collection idea was born from the 1 DOF helicopter lab when we noticed how it was extremely satisfying to turn the potentiometer. We wanted to leverage the feeling of turning the potentiometer as an input control to a simulation or game (in addition to our previous work with boids). After realizing that etch-a-sketch had similar input controls, we decided to re-imagine what other games would look like if they were controlled by potentiometers instead of the classic keyboard input. This gave way to the idea of a miniature arcade collection with a main menu to select different games.

When the user first enters the program, they will see a main menu with several options that they can select by either potentiometer to scroll down and then a button to select the menu option. There will be 5 games to choose from.

Logical Structures

Since we have multiple games, we make a separate thread for each game. We also leverage additional threads for peripherals such as timers (to keep track of system time), potentiometer inputs, and button inputs.

Hardware/Software Tradeoffs

Our project is heavily focused on much more software implementation than hardware setup. For hardware setup, we built two low pass filter circuits to take in the two potentiometer readings. We also set up two active high buttons (with protective circuitry) for selection and return functions. The hardware modules we used on the PIC32 include the ADC module for converting the analog voltages of the potentiometers to a digital value, the SPI module for communication between the PIC32 and TFT, and I/O module to take in the button readings. Since our hardware setup is fairly simple, the software implementation becomes more challenging. For example, we had to resolve issues with the discontinuity and random noise of the continuous potentiometer in addition to complex game logic such as collision physics and input thresholding. The figure below shows the high level block diagram of our system.

Relevant Patents, Copyrights, and Trademarks

We believe our project does not have any patents, copyrights, and trademarks issues because we are building those games from scratch and are not using the project for business purposes. There are no pressing intellectual property considerations since the patent for Etch-A-Sketch expired in 1990, 17 years after the patent was filed in 1973. Additionally, though the trademark for Nokia’s original snake game still exists, it is filed under “SNAKES” and has no impact on our project. Other companies, such as Google, have made games with the name “Snake” without violating the trademark since the original trademark does not claim exclusive rights to the word or game. The same situations apply to brick-breaker and pong.

HARDWARE SETUP

There are two circuits that we need for this project: a potentiometer circuit and a button circuit. We reused the circuit from lab3 to take in the potentiometer readings. The potentiometer we use is 10KΩ. The output of the potentiometer goes through an anti-aliasing low pass filter that has a corner frequency of about 1kHz. Since the resistor value of the low pass filter is 100kΩ, to achieve a corner frequency of 1kHz, the capacitor value should be 1.6nF. We use a 1nF capacitor in our circuit to construct the low pass filter. The low pass signal is then fed into a unity gain buffer, and the output of the unity gain buffer is sent to the MCU ADC. The unity gain buffer here isolates the potentiometer circuit from the development board. The high input impedance of the op-amp also draws very little current from the V_dd supply.

The button circuit is very simple. The button we use in lab has four terminals, and each pair of terminals are connected internally as shown in the figure below. One of the button terminals is connected to RB7 or RB8 on the development board as the input. When the button is not pressed, it will register a LOW; when the button is pressed, it will register a HIGH.

SOFTWARE IMPLEMENTATION

Since we have multiple games, we make a separate thread for each game. We also leverage additional threads for peripherals such as timers (to keep track of system time), potentiometer inputs, and button inputs. This project has 8 protothreads in total along with the main function.

RESULTS & DISCUSSIONS

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.

CONCLUSIONS

The design that we came up with matched very closely with our expectations. Originally, we had planned for 4 games with basic audio design, but after realizing that several of our games were only one player, we wanted to add another game that could be played between two people. Therefore, we decided to spend more time on a multiplayer game and take out audio design for the rest of our games.

Improvement in the Future

If we had more time next time, we would likely come up with a unified group of methods to leverage throughout the code in all of our games. However, since we ended up approaching each game slightly differently, we ended up with a unique implementation and software-hardware interface for each game (and therefore a challenge for us to resolve). Moreover, sound effects will be a cool addition to our game collection. Making the available game more challenging and engaging (such as making the snake go faster as it eats more dots, different topologies for brick breaker, and more complicated ball movements for pong) will also be something that we can do in the future.

Conformity to Standards

We looked at the current designs for existing games that we based ours off of. Based on the capabilities of these games, we determined what parts of the game were essential to keep to make it recognizable. Other than these also added some of our own additions to the games. For example, in etch-a-sketch, we included the ability to draw when moving the potentiometers around. However, we also added the ability to have your drawing wrap around to the other side for a continuous and smoother experience. In addition, we allow the user to erase with a simple press of a button rather than shaking the module.

Intellectual Property Considerations

Game designs were based off of current games. The listed games include Snake, Etch-a-Sketch, Brick-Breaker, Boids, and Pong. Boids was based on the design listed in Cornell’s ECE 4760 course website. Pseudocode for collision checking in our brick-breaker game was inspired from PasteBin. Pseudocode for boids was used from Cornell’s ECE 4760 course website .

We are reverse-engineering the designs for all the games listed. Certain games listed have copyright and trademark protection. These are not infringed upon currently as we are not selling our device as a product. If one does choose to market this as a product, one will likely need to use a different name than the original name. Simple game mechanics can stay the same, since those are difficult to place under copyright protection. For the etch-a-sketch physical control mechanic, we can potentially argue that the setup is different enough to avoid copyright issues.

We did not have to sign non-disclosures for our project. Potentially, there are patent opportunities for our product. We could patent a product that has an Etch-a-Sketch interface and is capable of playing classic games, but the games themselves cannot be patented. It is unlikely that there are publishing opportunities for our project. This project does not contain much that is novel. In a stretch of imagination, we could potentially publish the design as a novel way to use continuous potentiometers in a gaming setting.

Safety Concerns

There are no parts of the design that could cause significant harm. Very minimal harm could be caused by loose wires or pinch points in reproductions of this design.

Ethical Considerations

We believe our project meets the ethics standards outlined by IEEE. For each section within the IEEE Code of Ethics, we list choices we made that were consistent with the standards:

“To uphold the highest standards of integrity, responsible behavior, and ethical conduct in professional activities.”

• In the design for our project, we avoided any factors that could endanger the public or the environment.
• We communicate our design and choices we made in an online format to improve the understanding of society.
• We avoid real and perceived conflicts of interest by listing any legal and intellectual property considerations. We disclose what information we have on our online website.
• We have no unlawful conduct in our project to our knowledge.
• We have reflected on our technical work, acknowledged and attempted to correct errors, and were honest to the extent of our knowledge in communicating the results of our project.
• We undertook tasks that we knew we were qualified to attempt.

“To treat all persons fairly and with respect, to not engage in harassment or discrimination, and to avoid injuring others.”

• All members of our team were treated with respect to the extent of our knowledge.
• No harassment has occurred on our team to the extent of our knowledge.
• No verbal or physical abuse was observed on our team.

“To strive to ensure this code is upheld by colleagues and co-workers.”

• We disclose our consistency with the IEEE Code of Ethics under the ECE 4760 course requirements as well as to support colleagues in following this code.

Source: MINIATURE ARCADE GAME COLLECTION