We were tasked with creating a game that would test a user’s reaction speed. In order to do this, we implemented a game that resembles a Bop-It, which requires a user to complete one of a set number of tasks randomly within a given time constraint. Our game starts the user off with three lives, on the first of three levels. Based on how quickly the user is able to progress through all three levels without missing any components, their final ‘score’ (which will be displayed using an RGB light) will be either Green, Yellow, or Red.

Time Chart

Brainstorming:  Coming up with basic ideas of how the game should operate, the organization of game flow, and building of hardware

Game Objectives: Deciding what the final goals of the game should be (how to keep/display score, what is being measured and how to measure it)

Prototyping:  Drawing up storyboards of the game as well as deciding which components should be included and excluded from the final hardware implementation

Choosing Final Idea: Finalizing prototyping and game objectives

Game Flow:  Stepping through the game method by method to determine variables, game logic, and score keeping

Documentation: Keeping track of meetings and task items

Test Code For [component]: Writing test code for each component to test the ideas that were created in Game Flow

Beginning Hardware: Wiring up each component from the early prototypes

Final Hardware: Finalizing wiring in a way that is more feasible for coding and game play

Integrating Code for Each Component:  Combining the individual test codes for each component

Testing Finalized Code: Running integrated code to see if proper output is produced

Testing Finalized Hardware: Running integrated code with hardware connected to see if proper signifiers and actuators are functional

Writing Final Code and Documentation: Finalizing/cleaning up code and adding final elements of hardware

Creating Powerpoint: Creating short powerpoint to be presented on assessment day

Meeting 1: November 19, 2018

The group met on this day to discuss our project’s goals and to outline a general approach of how we would go about meeting them. We outlined the goals of our project, and drew pictures of two potential prototypes for the final product.

Concept:

It was decided that the goals of the game is to challenge the user’s reaction times. We are creating a game similar to Bop-It, which requires the user to complete different tasks as quickly as possible. The game will get increasingly more challenging as the user progresses by increasing the speed. In order to interact with the game, the user will need to know what component on the board they should be interacting with at any given time. We decided that this would be made clear to the user using LED lights assigned to each task. The lights will turn on when the component should be interacted with, and will only be turned off if the user completed the correct action in the appropriate amount of time.

Prototype 1:

• Red LED lights connected to each input device to signal if the component should be interacted with
  • Multiple LED lights for certain input devices (button/potentiometer/photoresistor)
• Game is continuous
  • User automatically progresses through levels (indicated by faster LED light display)
  • Seven segment display indicates what level user is on
  • RGB LED lights indicates what level user is on and colors indicate user’s performance
    • Flashing while user is playing
    • Color once user completes level (red, yellow, or green)
  • Piezo element
    • Sound indicating new level
    • Sound when hit the right input device
    • Sound when hit the wrong input device
    • Possible input device?

Prototype 2:

• Red LED lights connected to each input device to signal if the component should be interacted with
  • Multiple LED lights for certain input devices (button/potentiometer/photoresistor)
• Game is not continuous (?)
  • User can skip through levels
• RGB LED lights for level display and potentiometer to move through levels
  • Green if user performed well (3 stars)
  • Yellow if user performed okay (2 stars)
  • Red if user performed poorly (1 star)
• Seven segment display for level timer?

Other thoughts

• Piezo element could also be used to indicate time or how well user is doing

Meeting 2: November 28, 2018

Our second meeting was used to discuss how the game play would flow from beginning to end.

Overview:

We decided that the game would progress steadily from level 1 to level 3 based on the user’s performance in each level. Similar to a bop it, we decided that if a user missed a turn, or did not interact with a component in the allotted amount of time, they would lose 1 of their 3 lives. If all three lives are lost, the game will be over and the user’s final scores would be given. We decided to use the seven segment display to show how many lives a user has left at any given point in the game.

Basic Game Flow:

**Game will loop through as long as userLives is greater than 0**

1. Random number between 1 and 3 will be generated in order to decide which component will be turned on
   1. Button component: Three LED lights will be positioned next to the button. A random amount (1, 2, or 3) lights will be turned on, and the user will need to press the button that many times to complete this stage
   2. Potentiometer component: When the LED by the potentiometer is on, the user will need to turn the trim pot a certain amount in order to complete this stage
   3. Photoresistor: When the LED by the photoresistor is on, the user will have to press their finger on to the photoresistor to block the light. This is how they will complete this stage
2. Each component’s method will return a boolean that will signal if the action was completed on time. If the boolean is false, then a life will be docked from the userLives.
3. After 10 booleans are returned from each level, the next level will begin. The current level will be displayed to the user on the arduino board by illuminating 1, 2, or 3 LED lights in the corner of the board. A sound from the piezo element may also be used to signify an advancement in the level. When the level is incremented, the amount of time given to the user to complete each task will be shortened.

Meeting 3: December 3, 2018

Started writing sample/test code for the button component of the game. The sample code chose a random integer between 1 and 3, then turned that many lights on. The button would then have to be pressed that number of times for the light to turn off. Global and local variables declared are not final, and purely meant for testing. The serial monitor was also used to check that the button registered the appropriate number of clicks, and exited the function once enough clicks were processed. In the final result, the end string was printed over and over repeatedly, but this will easily be fixed when this code is sectioned out into a specific method instead of inside of the loop.

Test Code:

 

Meeting 4: December 4, 2018

Below shows the test code for the photoresistor as an input. When the photoresistor is touched by the player’s finger the LED light should turn off. This code tests that functionality by writing the LED to HIGH unless the photoresistor is covered by the finger. analogRead will determine whether the photoresistor is being covered by comparing it against a chosen threshold. This threshold was determined by using the serial monitor to see what value  the photoresistor was detecting when the finger covered it. After determining that the minimum that threshold could be was approximately 160, that value was used to compare against the analogRead value of the lightPin and determine that light state of the LED pin.

This code is testing the potentiometer and trying to figure out the best way to get the functionality we want for the game. Ideally, whenever the LED that indicates that the user should twist the potentiometer lights up, the user would be able to twist the potentiometer, no matter its current position, and have that action be registered. So far I’ve noticed an issue that prevented that functionality in the way I was trying to implement it because the potentiometer never registered the same value each loop it would always be different by +/-1. This caused issue when trying to compare the previous and current state and implement a behavior that only occurred once the two states didn’t match. Since the potentiometer value was different each loop, this condition (two states not matching) was always read as true, even if the potentiometer wasn’t changed, thus causing issue with trying to achieve our desired result.

 

This led to coming up with two other possible solutions that should work fine in our game, but not as optimally. The first option uses a while loop, and essentially what happens is that once the potentiometer is in a certain threshold, the LED will turn off and not turn on again until the condition of the while loop is changed to be true. This seems like it will make the most sense in the context of a game.The second option uses an if/else statement that essentially allows the LED to turn on or off depending on if the value of the potentiometer is in the correct threshold. This probably won’t make much sense in a game, but I did want to include the code as an option.

 

Both of these options are really just tests for the potentiometer, and the code will most likely change as we progress through the creation of the game.

 

 

Meeting 5: December 5, 2018

 

The group met on this day to set up the circuit with all of the components and to integrate each of the methods for the individual components. The final wiring of the circuit can be seen below. When the board is facing the user, there are 6 LEDs on the right hand side, 3 blue and 3 green. The 3 green LEDs are meant to replace the 7 segment display that we included in the prototype to represent the number of lives the user has left. This is because the 7 segment display could easily confuse the user, while the 3 LEDs are more straight forward. The 3 blue LEDs will be used to represent the level that the user is on at any given point in the game. Each component has been placed towards the center of the board, so that they are all easy to reach/interact with without disturbing the wiring. The 3 LEDs that are in line with each component towards the left side of the board each represent the signifiers that alert the user to interact with specific elements.

After attempting to test our code on this board, we realized that the wiring was wrong. Instead of respecting the vertical connections of each section of the arduino board, we attempted to wire all of our components and lights horizontally. After rewiring everything so that the wiring for the 3 red LEDs and the button component were correct, our board looked like this: 

Once more, we ran each of the test code for the separate input components of our game. We confirmed their functionality and moved onto starting some test code for our game. We wanted this code to test the random component of the game. After separating each of the input test code into separate functions of one single Arduino sketch, we began to write code that would randomly call each of the functions. We had to create while loops with a condition in each of the functions to ensure that the function did not return to loop() before the user interacted with the input device. We were not concerned about the timing element of the game at this point. The goal of this test code was to verify that when the user interacted with the input device that correlated with the turned on LED,  the light would turn off and the subsequent function would be called. The next function call should light up the LED that corresponded with that function. We included print statements so that we could keep track of the functions calls and the different positional values of the potentiometer. We did have to spend more time on the pot() function as it provided more difficulty than the other functions. We created a new variable called previousValue so that we could take the absolute value of the difference between the the previous and current positional values of the potentiometer to verify that it was greater than or equal to 10. This would ensure that the user turned the potentiometer a sufficient amount to turn off the LED light and trigger the next function call.

 

By the end of this meeting, we were able to:

1. Implement the lives and levels LEDs
2. Implement the timer for each level
3. Implement the random function generator
4. Finalize the hardware implementations

 

Next meeting, we plan to finish the game by including the following elements:

1. An RGB light to indicate how good or bad the user’s response time was
2. An piezo element to alert the user of hits, misses, end of game, and start of game
3. Include endgame and startgame methods that will make these events clear to users
4. Polish code and documentation

 

Meeting 6: December 6, 2018

 

In this meeting we have started to finalize and polish all of the components of our game. We have added the piezo element that we plan to use for producing sound at the start and end of the game, as well as for when the user either successfully or unsuccessfully reacts with the input devices. We decided that instead of incorporating three RGB LED lights to display both levels and performance of the user’s reaction time, we will be keeping the blue LED lights that we had for levels and adding in one RGB light that will display the user’s performance after each level is completed.

 

We started off with adding several new functions to our code. Two functions were created to indicate the start of a new game with each function producing a light sequence and sound sequence, respectively. We decided to create two separate functions for the miss noise and the hit noise and a final function that indicates the end of the game. All of the noise functions call the playTone method, passing in the tone(s) to be played and the duration for the tone(s).

 

 

For further polishing of our game we decreased the time duration for the LED lights for each level of the game, essentially making each level slightly more difficult because we found that the previous time duration for the LED lights was too easy. The last element that we wanted to incorporate was the RGB LED light that indicates the user’s performance in the game. Initially, we planned on using the RGB LED light after the user’s completion of each level, but after playing the game we determined that it progressed too quickly for that method to be effective. Instead, we will display the RGB LED light at the completion of the game to indicate the user’s performance for the entire game. In doing this, we have add some logic into both the endGame() function and the loseGame() function as only one of these methods is called at the end of each game depending on the user’s performance. We will calculate the user’s performance as shown below:

1. 2-3  misses results in a red light and indicates a poor performance
2. 1 miss results a yellow light and indicates an okay performance
3. 0 misses results in a green light and indicates a great performance

 

Due to the RGB LED light being the last component that we added, unfortunately we had to rearrange some of the wiring on our arduino board because the RGB LED light requires three pins with post width modulation in order for it to be able to produce the range of colors that we desire. The colors will be set by first defining which pins each of the colors (red, green, blue) are associated with. Then each of the pins will be set to OUTPUT using the pinMode() method. We will be able to achieve our desired colors by changing the brightness of each of the RGB colors. 0 means off and 255 means maximum brightness. We will set the brightness for red to 255 and green and blue to 0 in order to achieve the red color that indicates a poor performance. We will set the brightness for red and blue to 0 and green to 255 in order to achieve the green color that indicates a great performance. Finally, we will set the brightness of red and green to 255 and the brightness of blue to 0 in order to achieve the yellow color that will indicate an okay performance. These colors are essential to our game because they are the actual indicators of the performance of the user. They will provide some sort of incentive for the user to improve their performance because the goal is achieve the green light at the end of the game because the color translates to the optimum performance of the user.

We had difficulties getting our RGB LED to work, so we plan to meet in the lab tomorrow and speak with an instructor to figure out how to resolve our problem. If we are not able to use the RGB LED, we plan to wire green, red, and yellow LED that will display the same final score colors that we would have gotten with the RGB.

 

Meeting 7: December 7, 2018

Today our primary focus was to incorporate the RGB LED. We had a lot of difficulties getting the RGB LED to light up so we asked some instructors in the electronics lab for help. The instructor plugged in her RGB LED to our circuit and the RGB LED lit up. We were happy to know that the problem was the RGB LED and not our wiring. We got a new RGB LED and plugged it into our circuit. Initially, the RGB LED still did not light up so, but after further discussion, we realized the LED was an anode RGB LED so the wire that we had plugged into ground should actually be plugged into 5v. After changing the wiring our LED finally lit up. We had to change two of our pins from the digital input side of the Arduino board to the analog side of the Arduino board, using the analog pins for our digital input. Finally, with all of our wiring correct, we were ready to get to work on coding our RGB LED.

Every time we started our game, or whenever our circuit was connected to power, the RGB LED was lit up a bright white color. We explored many different options within our code in attempts to make the RGB LED turn off. It was not until we changed our code in setup() to make the mode of the redPin, greenPin, and bluePin of the RGB LED to INPUT instead of OUTPUT. We were successful in turning the RGB LED off at the beginning of our game, but now we found issues in making the LED display the desired color. We are playing around with our code and trying to figure out how to make the RGB display the green, yellow, and red colors that display the performance of the user after playing the reaction game. After playing around with the code, we realized that each of the pins was inverted because our LED is an anode instead of a cathode, so in order to display the correct color we needed to invert our color combinations. For example, instead of the RBG code for green being (0, 255, 0) in our program, we had to invert it to be (255, 0, 255). After fixing this we saw that there was still a problem with the LED color displaying when we wanted it to. We played around with the code some more and then realized that the numbers we assigned to the redPin, greenPin, and bluePin were incorrect. After switching the pin numbers, our colors started displaying correctly in the game.

During the testing of our game to make sure the RGB LED displayed the correct color at the correct time, we also realized that the time intervals we chose for each level weren’t very user-friendly. Our original time intervals for each level were 4 seconds for level one, 2 seconds for level two, and 0.5 seconds for level three. While we were testing we saw that once we reached level three the game moved to fast for the user to have a reasonable chance at winning the game. Realizing this, we changed our time intervals to be 5 seconds for level one, 3 seconds for level two, and 2 seconds for level 1.

 

Maker Manual

Overview

Bop-It^2 is a reaction game that tests a user’s ability to quickly respond to flashing LED lights that are each associated with a different type of input device. The goal of the game is to interact with as many input devices as possible in the time allotted, whilst advancing through three levels without losing any lives. The three levels are indicated by three blue LED lights. One lit blue LED light indicates level one, two lit blue LED lights indicate level two, and three lit blue LED lights indicate level three. The duration of the flashing lights decreases with each level. The user must progress through the game with only three lives that are lost when the user is unable to shut off the light corresponding with its input before the light shuts off on its own. These lives are indicated by three green LED lights that all start on at the beginning of each game. Every time a user is unable to turn off an LED light, a life is lost and one a green light is turned off. If all three green LED lights are off this indicates three misses and the end of the game. An RGB LED light will indicate the user’s performance at the end of each game. Zero misses is the ideal performance and will result with a green color from the RGB LED, 1 miss is an okay performance and will result with a yellow color from the RGB LED, and 2 or more misses is a poor performance and will result with a red color from the RGB LED.

Tools & Supplies

• Arduino Uno board
• Power source
• Large breadboard
• Multicolored wires
• 3 red LEDs
• 3 green LEDs
• 3 blue LEDs
• 10 resistors 560 Ohms (green, blue, brown)
• 2 resistors 10k Ohms (brown, black, orange)
• 3 resistors 220 Ohms (red, red, brown)
• 1 push button
• 1 potentiometer
• 1 photoresistor
• 1 piezo element

Layout & Build

Input Devices:

Pushbutton-The pushbutton is on the leftmost side in the V1 section of the breadboard. It is connected to G1, G3, I1, and I3. A wire plugged into K3 is connected to digital pin 4. A 10k resistor is jumped from L3 to power. A wire is connecting K1 to ground.

Potentiometer-The potentiometer is in the middle area of V1 section of the breadboard. It is connected to I13, G12, and G14. Three wires are connecting L14 to power, L13 to analog pin 1, and L12 to ground.

Photoresistor- The photoresistor is in the rightmost side in the V1 section of the breadboard. It is connected to G24 and G26. A 10k Ohm resistor is connecting to J26 and power. A wire is connecting L26 to analog pin 0 and another wire is connecting L24 to ground.

Output Devices

Green LEDs- The green LEDs are on the rightmost side in the V4 section of the breadboard. The first LED is connected to F23 and F24, the second LED is connected to F25 and F26, the third LED is connected to F27 and f28. There is a wire connecting A24 to digital pin 8, a wire connecting A26 to digital pin 9, and a wire connecting A28 to digital pin 10. There are three 560 Ohm resistors connecting A23, A25, and A27 to ground respectively.

Blue LEDs- The blue LEDs are on the upper rightmost side in the V3 section of the breadboard. The first LED is connected to F7 and F8, the second LED is connected to F9 and F10, the third LED is connected to F11 and f12. There is a wire connecting A8 to digital pin 13, a wire connecting A10 to digital pin 12, and a wire connecting A12 to digital pin 11. There are three 560 Ohm resistors connecting A7, A9, and A11 to ground respectively.

Red LEDs- The red LEDs are spaced out evenly along the top of the breadboard in section V2. Each red LED is aligned with its corresponding input device. The pushbutton LED is connected to J1 and J2, the potentiometer LED is connected to H12 and H13, and the photoresistor LED is connected to H24 and H25. There is a wire connecting K2 to analog pin 3, a wire connecting I13 to analog pin 4, and a wire connecting I24 to digital pin 2. There are three 560 Ohm resistors. One is connecting K1 to ground, one is connecting I25 to ground, and one is connecting H1 to ground. There is a wiring that is jumping I12 to G1.

RGB LED- The RGB LED is placed on the lower rightmost side in section V3 of the breadboard. The RGB LED is connected to F1, F2, F3, and F4. There is a wire connecting A1 to digital pin 9, a wire connecting A2 to digital pin 5, a wire connecting A4 to digital pin 3, and a wire connecting E3 to 5v. There are three 220 Ohm resistors connecting E1 to B1, E2 to B2, and E4 to B4.

Piezo Element- The Piezo element is placed in the left-middle side in section V2 of the breadboard. The piezo element is connected to B5 and B8. There is a wire connecting E8 to digital pin 7 and a wire connecting E5 to ground.

Jumping Wires:

There are two wires located in the uppermost side in section V4 of the breadboard that is connecting power to 5V and ground to ground on the Arduino board. There are two wires jumping power from section V2 to power in section V4 and ground from section V2 to ground in section V4. There are two wires jumping power from section V1 to power in section V4 and ground from section V2 to ground in section V4. There are two wires connecting power from section V3 to power in section V4 and ground from section V3 to ground in section V4.

 

 

 

Code

Initialize the variables of our program and the conditions to start the game.

Create the methods to control the button, potentiometer, and photoresistor based on user interaction.

Create the method to start the game.

Create the method for when the user wins the game.

Create the method for when the user loses the game.

Create the methods to control the sounds the game plays when the game starts and when the user hits or misses an input.

Create the method to control the RGB LED that indicates how the user did after the game ends.

Testing Conducted

Several aspects of the game were tested throughout the planning and building process. Each input component of the game was separately tested before they were brought together on to one breadboard. Additionally, testing was conducted to ensure that the randomness of our game accurately switched between LED lights and input devices during the game. We took advantage of the Serial monitor throughout this entire process and it provided much aid when conducting the tests. We also separately tested the RGB LED on a separate breadboard before we incorporated it into the game. Below are several videos of the testing that was conducted during this process.

Pushbutton Video

Photoresistor Video

Potentiometer Video

Game Prototype Video

 

Shortcomings

While we are pretty satisfied with the product that we were able to make with the time allotted, there are several things that we would like to improve about our product: A wider range of input devices for user interaction, a more visually pleasing interface, an extension to allow for multiplayer games, a more precise indication of user reaction time performance, and more variation in the sounds of the game. These are some of the aspects of our game that we feel would make it more compelling and provide a more polished finish than what we were able to accomplish with the time given.