Introduction

This project is a game intended to entertain users while also testing their reactions. The game measures the user’s reactions over the course of four rounds before creating an averaged result to provide the user with. The game was designed with an emphasis on fun rather than to test, and can be played by teenagers and adults.

Project task list

Ideation

Development

Documentation

Time chart

Ideation

Initial brainstorming revealed to us that the basic concept of reaction games involves having the user wait for a signal, and once the signal has been given, the user has to respond as quickly as possible. This can come in the form of a simple test where the user just has to click once given the signal or it can be more entertaining as can be seen with whack-a-mole.

The next step in our ideation process was asking people around us what they liked about the two different forms of reaction games mentioned before. Their responses informed us that they liked the hitting aspect of whack-a-mole as well as the element of not knowing where the moles will pop up. They also disliked how the tests told them that they were too slow or said that their reactions were like that of a 70-year-old’s, which made these games less fun for them. From this, we decided to emphasise the fun element but still provide feedback on the user’s reaction as inevitably, some will want to know.

Another inspiration for the game included a structure in a playground that was similar in concept to whack-a-mole but each button was spaced some distance apart and at different heights. We were particularly interested in the distance factor as it added a layer of challenge. Additionally, Zi Yen was interested in being able to test the reaction of our legs. These were also considered when designing our reaction game.

Design

The first prototype involves having eight green LEDs in a row with eight RGB LEDs running parallel to the green row. The user will have six sensors attached to different parts of their body (shoulders, thighs and underneath the feet). Each sensor corresponds to a specific colour that has a chance of appearing as a light in the RGB LED. The game involves having a randomly selected green LED light up in the first row, letting the player know that LED is the target position. The user then has to wait for the RGB LED of the same position to light up in the second row. Whichever colour lights up in that position, the user has to respond as quickly as possible by hitting the sensor that matches that colour.

Not pictured is what would happen if an RGB LED lit up as the colour corresponding to a sensor located under the foot. Ideally, the user would be sitting to remove pressure from the underfoot sensors. If the user wants to respond with that sensor then they should step on the floor.

Although not featured in the storyboard above, there will be auditory feedback to let the user know if their response is correct or incorrect. This will be done via the piezo speaker. A high pitched sound will indicate that their response was correct while a low pitched sound will indicate that the response was incorrect. This relies on the natural mapping of high pitched sounds such as ding ding ding representing a correct answer and a low pitched buzz for wrong answers.

The number of LEDs and sensors that would be used were reduced later, from eight to four, to make the game simpler and more memorable for users. Additionally, the RGB LEDs would be replaced with addressable LEDs since addressable LEDs only require one connection to the Arduino compared to the three connections that need to be made for RGB LEDs. This ensured that we had enough connections for other components.

The location of the sensors would be changed as well. Concern about the first prototype was wire management as having loose wires would be a hazard for the user. This would initially be resolved by providing a jacket that the user could wear so that we could control where the wires go. However, as we also wanted to be able to test the reactions of our legs, the jacket idea was rejected in favour of the user laying out two sensors on the table and two sensors on the floor. This was done to make starting the game more convenient for users as now they wouldn’t have to put on a jacket and a pair of shoes.

Sketches about how to organise the sensors

The above shows sketches of some ideas to control where the wires fall. Attaching sensors to the jacket and soles of the shoes was suggested. The wires would be taped down initially but if this idea reached the later stages, a needle and thread would be used to sew them down on the inside of the jacket to achieve a more discreet appearance, as well as being more secure in the long term. However, in the end, the two sensors on the table and two on the floor option was picked. This way, users do not have to bother wearing specific items of clothing for such a quick game. They also have the option to place the sensors wherever they desire.

The serial monitor is used to show users their performance. For each round, the serial monitor will remind the user to tap the sensor when the LEDs match. The serial monitor is also designed to show the user’s reaction time for each round and the average reaction time when all rounds are completed. Then, comments will be given based on the user’s average performance to encourage the user.

Later, a red LED was added. This is to provide visual feedback to the user when they press on the wrong sensor. This adds onto the existing feedback system which relies on the piezo speaker emitting high and low pitched sounds. The red LED takes advantage of mapping correct answers with green and red with wrong answers.

A shell was made to encase the Arduino. This is to prevent the user from seeing more than they have to and draw their attention to what they only need to see, which are the LEDs and the button. The sensors are also covered with colour paper. This is to help the user to understand which colour the sensor corresponds to in a simple and effective way. A downside to using these sensors is that they are not shaped like a button and appear flat, so the user might not immediately understand they are supposed to tap these. The sensors don’t have strong affordances, however, they are mapped to the colours that the RGB LEDs display. This tells the user that the lights and the sensors are connected. The pushbutton on the breadboard has strong affordances, however, it has low visibility due to its small size. A bigger button would be more visible and convenient for the user to see and use.

Some constraints implemented include covering the rest of the Arduino. Anything the user does not need to see is hidden. This limits interaction as the user cannot be distracted by what would otherwise be exposed. There are also only five sources of inputs so the user’s options are limited to only what is relevant to playing the game. The user also cannot press the button during the game or use the sensors before or after the game and expect a response. Since the game is unlike those seen on the market, the instructions are written on the shell. This means that the game has weak affordances since it requires the user to read instructions on how to play the game.

Demo Video

Maker Manual

Overview

This is a high fidelity prototype of our reaction game. It tests both the user’s reactions and their accuracy by seeing how quickly the user can respond and provide the correct answer. To play the game, the user has to press the button on the breadboard. The first round is counted down and then a green LED is lit up to mark the target location. RGB LEDs will start to light up in various positions and colours. When the position matches the target location indicated by the green LED of the first row, the user must respond as quickly as possible with the correct answer. Their response is timed. This repeats for four rounds in total, where the transition of RGB LEDs light up will gradually get faster when the round increases. After that, the user will receive the result as an average of the four rounds they played.

How to play

1. Press the button on the breadboard to start the game.
2. At the start of the round, the game will randomly select a green LED from the top row. This represents the target location that the player should be aware of. The player should keep an eye out for when the LED in the second row with the same position as the target lights up.
3. Random RGB LEDs in the second row will begin to turn on and then off in one of four colours – red, green, blue or yellow. If the positions of the lit-up RGB LED and the target LED match, the player should respond as quickly as possible by hitting the FSR that matches the colour the RGB LED has lit up in. The player will then receive their reaction time for this round. If the player responds with the incorrect answer then they will hear the speaker make a low pitched buzz but they will still be able to attempt the round.
4. Repeat steps two and three for three more rounds. The speed at which the RGB LEDs turn on and off will increase with each round.
5. The player will receive their averaged time and performance comment at the end of the fourth round.

Tools and supplies

• Arduino Uno
• Breadboard
• 4 force-sensitive resistors (FSR)
• 4 green LEDs
• 4 addressable LEDs
• 1 red LED
• 1 pushbutton
• 1 piezo speaker
• 5 560 Ohm resistors
• 5 10k Ohm resistors
• Wires
• Wire strippers or scissors if the wire ends aren’t already stripped or do not need stripping

Layout and circuit diagram

Build

To build this game, first get the supplies listed above and then follow the instructions below.

1. Using the circuit layout provided above, place the components (not including the FSRs) onto the breadboard.
2. Connect the components to the pins on the Arduino Uno using the wires.
3. The FSRs will need to be soldered to their wires and then the wires will need to be connected to the breadboard. First, solder two wires to the FSR and connect the other ends of the wires to the breadboard after.
4. Use the code provided below to make the game work.
5. Play the game to know your reaction time. Enjoy!

Code

Testing

Each component was tested to ensure that they worked, especially the addressable LEDs and the FSRs as we had no previous experience with them.

The FSRs were tested by connecting them with their resistors and to analog pins 1 to 4. The value of each FSR is read and shown in the Serial monitor. Force is applied to each sensor and changes in the values are outputted and observed to confirm that the FSRs were all functioning as expected.

The addressable LEDs were tested by connecting the first LED’s ‘data in’ lead to digital pins 3. Then, the ‘data out’ of the first LED is connected with the ‘data in’ of the second LED. Same applies to the remaining LED’s ‘data in’ and ‘data out’, while the last LED’s ‘data out’ doesn’t need to be connected to anything. The LEDs were initialised and the basic code of turning on and off the LEDs was uploaded and run to confirm that the LEDs were all functioning as expected. The library needs to be included in the code to use the addressable LEDs’ functions.

When testing the code, the game was tested incrementally. Each function was tested on its own to see if it worked as expected, rather than running the code all at once. This was to ensure any errors found can be located more precisely.

After consulting one of the people we asked during the ideation phase, we decided to make the game more challenging by increasing the speed at which the addressable LEDs blink. This was in response to their criticism that the game was too easy.

Shortcomings

A downside of the final design is that the positions the user can put the sensors cannot be enforced. While this can give the game a second life by allowing users to create new challenges to entertain themselves, it also raises safety concerns about the wires once more. Using a wireless alternative of FSRs (and an Arduino capable of receiving wireless signals) would solve this problem. Although there would be trade-offs such as the number of sensors due to the budget restriction. In some situations, it would be too difficult to order certain components because of delivery times to consider and where suppliers ship from. We would also need to consider the impact of learning how to code for wireless components on the project schedule.

Additionally, the user has to look to the Serial monitor for instructions or to receive feedback about their performance. It is not ideal to have the user look at the Serial monitor and effort has been made to avoid it as much as possible by using sound and visual cues to inform the user when possible. For example, a red LED was added. Using an LCD display could further reduce the number of times the user has to look at the Serial monitor. The display would be able to show instructions for the user instead as well as improve the overall visual appeal of the game since the Arduino IDE’s interface is something we can’t control.

A known shortcoming is that since the Arduino can only do one task at a time, it might miss an input because it was doing something else. A situation where this would occur is when the user presses the incorrect FSR. The piezo would buzz to tell the user that their input is wrong, however, a user might act quickly or they may realise on their own that they pressed the wrong FSR and try to correct themselves while the piezo is still buzzing. Due to the pandemic, we are unable to do enough testing to see if this is a problem or if users would see this as part of the game as punishment for getting the answer wrong.

There is also no response for when the user presses too early. The code written only begins to read values from the FSRs when the LEDs match. This allows users who are over-eager to get away with accidentally pressing the FSRs when they should be told that they acted too soon. However, we are unsure of how to implement this since the Arduino can only do one task at a time.

A larger push button should be used to replace the button that is used to start the game. The current button is too small to comfortably press and because of its size, it’s not very visible either. Having a larger button makes it clearer to the user that they are able to press it, whereas having a small button can lead to users not being able to see it and not using it. A button that is located outside the breadboard will also avoid the breadboard over clustering with components. The size of the breadboard is also a limitation for having more LEDs for the game. This is because each addressable LED has 4 leads, which will occupy 4 half-rows at a time. This also prevents adding more LEDs to signal a countdown timer before each round starts. Currently, the countdown relies on the user interpreting the piezo tones correctly.

When the user is observing the LED changes, there is no other feedback which might make the process boring if the matching process is long. Music or melody should be played using the piezo element during the matching process to make the process more interesting and interactive. The same applies to the situation before the game starts. Although the addressable LEDs are doing a light show by changing their colour randomly, there is no music to invite the people to play.