Reaction Times Game: Group 4
Project 3
How Fast is your Reaction? Interactive Game Design
Having quick reactions are great indicators of your alertness level and in certain
cases to the level of activity and logical organisation within your cognitive thinking.
Reaction testing games have been quite popular for decades and the secret behind
their success is their simple yet effective user-interface design which has been
improving and progressing throughout the years. You are asked to design an Arduino
based circuit that tests the user’s reaction speed and accuracy through various
interfaces such as LED lights, buzzers, etc. Keep in mind the principles of interactive
design and also the requirements of effective user interface when producing your
solution.
Post #1 Speed base-2 : The Initiation
Meeting No. 1: Wednesday 22nd November 2017
Planning, initial ideas, time management…
Our Concept
Round 1: Each player has four different coloured buttons. The motor displays random color (out of four). Users need to react to the color displayed by pressing the coloured button that correlates to the colour on the motor. The user will be notiified if answer was wrong or right via sounds. One sound positive the other negative. This round goes for ten times before moving on to round two. (Buttons are in a diamond formation.)
Round Two: Two tones correlated with two buttons (right and left buttons). Players press button that represents the tone that is played. This round goes for ten times before moving on to the optional round three. One LED on breadboard that will change colour (red or green) based on the player’s answer being wrong or right after each reaction to tone played.
Winner announced at the end.
Components Required:
- MP3 player shield
- LED screen shield
- 2X 4 button shields
Meeting No.2: Friday 24th November 2017
Ordered materials for the game:
- LCD display with coloured TFT LED display
- Coloured buttons
Materials from the lab for the game:
- MP3 Arduino Shield
- Coloured buttons (that may be used)
Still need to get:
- Headphone splitters
Meeting No. 3: Monday 27 November 2017
Name for the game: Speed2 ( base 2)
We were inspired by the goal of the game, which is to be the fastest to react to sound and visuals as well as the computer science aspect and use of binary.
Font for the game: barbatrick
Logo for the game: flames attached to the common symbol of the play button (to represent game mode) and base 2.
This picture represents the brainstorming process for naming the game, choosing a font, and a logo. The circled items represent what we chose for the name, font, and logo.
Delegated tasks for next meeting, which will occur on Friday 1st December 2017 at 1:30pm.
- Michael pseudocode: Round 1 and working prototype of audio
- Karla pseudocode: Round 2
- Dalilah pseudocode: Relating to extra functionality such as introduction, announcement of win, accumulation of points, etc
Prototyping
Exercise in class:
Notice: Instead of calling the two different parts of the game “round,” we will call it Part One and Part Two so rounds one through ten can be announced every time. For example: After Part One directions are announced, then “Round one, ready set go!” is announced and repeated until round ten is completed.
Pick one function/dimension of your project: Prototyping Part 1: speedy colour visual
Brainstorm about the user’s goals
- What does the player want to do? To react to colour that appears on screen by pressing the correct coloured button before their opponent does.
- What info will player need? To understand that coloured buttons correlate with colours that appear on screen.
- What kind of interface supports these tasks? LCD display with coloured TFT LED display, coloured buttons, and audio.
Create an initial low fidelity prototype:
- Materials: paper, markers, index cards, pen, and scissors
- Iteration of game: 1. Four paper screens are created to showcase four different colours that can appear on LCD display, which will be controlled with a random functionality. 2. Two index cards are used as breadboard representation with coloured buttons in diamond formation to create the two player experience. 3. Karla acts as game, which will randomly show coloured screens for Michael and Dalilah to act as players racing to react the fastest. 4. Karla will randomly show coloured screens and tally points for ten rounds.
*Part One: If player is guesses correctly but too late, they will receive another different negative confirmation sounds indicating they didn’t receive a point. Therefore, there are now three different sounds occurring as feedback: one for a correct guess and point, one for correct guess but no point, and one for wrong guess.
*If there is tie after Part One or Part Two, there is a Sudden Death of three rounds of the part that just occurred. Therefore, if there is a tie after Part One then Sudden Death occurs right after.
Results:
- Round 1: Dalilah, 8 points
- Round 1: Michael, 5 points
- Round 2: Dalilah, 5 points
- Round 2: Michael, 6 points
- Winner is: Dalilah!!!!
Possible additions to Part One:
- On coloured screen, the colour will be spelled out but in a different colour, which will confuse the players but the players need to press the button matching the screen background colour.
- LED coloured buttons: buttons change position for every round.
- The change in position makes Part One more competitive meaning more fun!
Possible additions to Part Two:
- LED coloured buttons: buttons change position for every round.
- The change in position makes Part Two more competitive meaning more fun!
Pseudo Code Part A
- DECLARE int variable for maximum number of rounds (default is 10) (maxRounds)
- DECLARE int variable to record number of rounds passed (default is 0) (currentRound)
- DECLARE colour Array of possible colours displayed on LED (possibleColours[])
- DECLARE class for all the possible colour combinations to be stored in colour array
- DECLARE random int from 0- Length of array of possible colours
- DECLARE int variable for number of points gained for both Player 1 and Player 2 (default is 0)
SETUP link all buttons to correct digital pin (eg. 1-4 for player1, 5-8 for player2)
//(PLAYER1) 1 = red, 2 = green, 3 = black, 4 = white
//(PLAYER 2) 5 = red, 6 = green, 7 = black, 8 = white
Game Flow:
LOOP FOR maxRounds (default is 10){
- Text on screen: “Round ” + currentRound
- Play sound file (currentRound announcement)
- currentRound increment by 1
- display random LED colour
- DECLARE int variable for number of milliseconds passed (updates)
- if player1 presses correct random LED colour, DECLARE int variable (p1miliseconds passed)
- if player2 presses correct random LED colour, DECLARE int variable (p2miliseconds passed)
- COMPARE which is the smaller amount
- If player1 is smaller, player1Point++
- If player2 is smaller, player2point++
}
IF currentRound == maxRounds
Move on to part 2!!
CLASS
- DECLARE int array (0-3) (each index corresponding to the 4 different BG colours)
- DECLARE int array (0-3) (each index corresponding to the 4 different FG colours)
DECLARE function to generate the displayed LED screen
Project Tasks
Major tasks:
Ideation
- Brainstorming – all
- Game objectives – all
- Idea development #1 – all
- Choosing final idea – all
- Storyboard – Karla
Planning
- Delegation of tasks – Karla
- Time and plan chart – Karla
- Pseudocode – all
Testing
- Test components – Dalilah & Michael
- Test code – Dalilah & Michael
- Make hardware prototype – Dalilah & Michael
- Make material product prototype – Karla
Development
- Idea development #2 – all
- Planning of components – Michael
- Planning of materials – Karla
- Final design idea sketches – Karla
- Final design idea documentation – all
- Logo design – Dalilah & Karla
Making
- Write the code – all
- Construct arduino hardware – all
- Construct the product – Karla
Documentation
- Design blog – Dalilah & Michael
- Project task list – Karla
- Maker manual – all
- Overview – Dalilah
- Tools and supplies – Michael & Karla
- Layout and circuit diagram – Michael
- Build – Michael & Karla
- Commented and well organised code – Michael
- Discussion of testing conducted and known shortcomings – Dalilah
- Presentation for assessment – all
- Project idea – all
- Evolution of project – Dalilah
- Design principles and choices – all
- Goals of the product and how we achieved or fell short of them – Dalilah and Michael
Project Tasks: A closer look
http://wp.me/p9nDm4-xK
Further Development with Speed^2
First, the logo for the game has been completed. The new design is based off of the original but created with tiny squares to keep the “squared” theme continuous. The play symbol is used to represent game and the flames behind it add an element of speed and energy. The two of course is used to represent the name of the game: Speed^2.
Second, while coding the visuals for the game using Processing it was decided to have a square be the shape to change colours to test the user’s speed. Rather than have a random shape or the full screen change colours. The square shape throughout the game creates a product that is uniform. Note: the image used below is not the final product but just a visual of how rounds and the coloured square will appear on the screen.
Third, due to the size of the TFT display, Michael, Karla, and Dalilah decided to use one laptop in order to have the two controllers connected to one screen. The laptop screen is big enough for both users to comfortably look at the screen for direction and feedback.
Fourth, due some technically difficulty with the audio mp3 shield, it will no longer be used. Instead, there will be audio to give instructions to the users.
Fifth, originally the game had 10 rounds per part. But since 10 is not a squared number, the rounds were changed from 10 to 16 rounds since 16 is a squared number. Hence most design decisions that were not technically based were changed to do uniformity with the brand and name created for the game: Speed^2.
Maker Manual
The final product of our project Speed Squared (Speed^2) was developed to be a game coming prepackaged with 2 controllers. It focuses on the 2 controllers which is plug in and play when connected to any PC/Mac. The game tests the reactions of 2 players as they compete to see who has the fastest reaction time. It works well as a party game and a fun gadget perfect for a gift. It is inspired by retro games from the 1980s following in the lines of games like Pacman and Tetris. The product is aimed at children, ages 5 and up.
The packaged game that we focused on developing is only one example that we would like to show that these controllers are compatible with.
The theme of our game is “Squares!”. For example, we ensured that the Arduino would be hidden in a square box, the buttons are squares, the number of rounds is 16 (Square Number), the logo is built out of squares, the window of the game is a perfect 900×900 square.
Each Controller uses:
- 4 Square Tactile Push Buttons
- 1 Red Tactile Cover
- 1 Blue Tactile Cover
- 1 White Tactile Cover
- 1 Black Tactile Cover
- 4 10K ohm resistor
- 10 Jumper Wires
- 8 Additional Jumper Wires (soldered onto push buttons)
- 1 Arduino Uno board
Additionally:
- PC/Mac to run the game (with at least 2 USB ports)
- 1 Arduino to USB Plug
We make the controller using:
- Acrylic Box
- Sheet of Acrylic with 4 laser cut holes
How to build it
Materials:
- Black acrylic sheet with 5mm width
Tools:
- Ban saw
- Laser cutter
- Double sided sticky tape (real product will use solvent based glue)
CONTROLLER:
1. On a CAD program, draw the following blueprint with the dimensions shown. The red outline represents the lines needed to be laser cut. Draw two of the outlines. Save as a dxf file and laser cut.
2. After laser cutting, mark the cut pieces of acrylic as illustrated in blue on the blueprint with the following dimensions.
3. Bend the pieces of cut acrylic according to the marked lines with a bending acrylic machine.
4. Cut two pieces of rectangular acrylic with dimensions of 10mm by 88mm using a ban saw. This piece will be the seat of the buttons.
5. Sit one set of buttons onto the rectangular piece mentioned in step 4 and align them so that the buttons can go through the four holes.
6. Use double sided sticky tape or a solvent based glue to stick the buttons onto the rectangular bench.
7. Tape the rectangular piece behind the controller with tape or a solvent based glue.
The controllers would then look like as shown below.
8. Gather the wires for each controller and put them through two 6.4mm heat shrink in order to keep the wires tidy.
Code
This is the Arduino side of the code used for our project. Since we also use Processing code (the bulk of the program), we’ll show that as well. Although the code is a simple push button mechanism that utilises 4 buttons, we ensure we use 2 separate Serial ports as both are opened up for each controller.
In Processing, we specify the exact point we want to cut off reading from the Arduino Serial ports as they are then converted into strings. It’s important that we use to trim() function built into processing to get rid of excess white space and allow easy casting to int variable type. String variable types however, can also be used in some cases if we compare the Strings using .equals().
We use Game classes for each of our rounds. They contain all the necessary functions and instance variables that control the flow and timing of each part. For example, we use a currentTime float variable which updates at a certain speed. When the currentTime reaches a certain value, it either activates a boolean enabling another part of the game or it enables the range in which the user is allowed input (the user isn’t always allowed input where it might not be necessary).
Another class that we made use of was a Shape class which which produced all the different scenarios of different squares appearing. Each shape object generated a random scenario, x position, y position, speed and size as seen from the Shape class constructor. Scenarios ranged from squares dashing across the screen, to random text appearing to confuse the player.
Part of our draw() function can be seen below. It shows how the flow of our game works using simple boolean logic. The advantages of using booleans to control our game was that it allowed us to easily debug certain rounds without having to play the whole game from the start every time.
Discussion of testing conducted
Testing occurred multiple times during the coding process. The first thing tested was the buttons functionality; therefore, if a red button is pressed the serial monitor would print: “red button pressed.” Testing for functional code, specifically quickly identifying what button was pushed and if it is a correct or wrong answer, occurred multiple times while creating Part One and Two of the game. Testing occurred when working with the additional effects added to Part On, such as having some squares move off screen or having another colour written on the coloured square, in order to confuse the player. The directional voice recordings done by Dalilah and background music also had to be tested. For example: how the directions given by Dalilah’s voice recordings worked with the background music as well as the audio occurring at the correct time matching the proper text.
One of the last tests done dealt with colours and visuals for the game. Originally the numbers appearing in Part Two were in the colour black but because of the black square being used, the colour for the numbers changed to grey, in order for all the numbers to appear clearly in all the coloured squares.
Any known shortcomings
Shortcomings involving the physical equipment were: 1. creating to finished boxes with lids for the two Arduinos and the two breadboards 2. Remove the black and white buttons and replace them with other colours, while still being colorblind friendly. The two main visual feedbacks appear at the bottom of the screen for the players, which are the points (in Part One) and check & ‘x’ marks (appearing in Part One and Two) to represent right and wrong. In addition to those visuals appear on the bottom of the screen, it would also be efficient to have the speed of each player appear in milliseconds. Since the game is called Speed^2, the players speed appearing in milliseconds for every round would give the players a concrete idea of how fast they are. The ability to create a database containing the players’ scores and highest speeds would be an additional aspect of the game, which would increase the competition. The announcing the best speed, for each particular part of the game, would also give the players an idea of who is the fastest between the two. Announcing the fast round played by one of the two players at the end of the game would also bring up user satisfaction.