Final Project Documentaion
Instructor: Marcela
Partner: Justin Wu
Project Title: Tip Tap Snap
Conception and Design
While the functionality of our final project strayed quite far from our original idea stated in our Final Project Essay, the underlying idea was still the same: providing a fun and enjoyable experience through music. Through a lot of self-testing, user-testing, and conversations with IMA fellows and professors, we came to our final form. Initially, we wanted to resemble our project after games like Tap Tap Revenge and Guitar Hero. We used Processing to create a visual game of the balls dropping. We created a start and end page that displays the users score. The song is triggered to start when the user clicks the screen and the game ends when the duration of the song is over. We wanted to include a start and end page, so the user could try and get the full experience of a game. However, when we imported the images, it slowed down Arduino and made the music sound weird. We learned that you could adjust the image to the size of the screen we had set and that most of the time, Processing lags when the background images are different sizes and when we have something constantly looping, rather than being called on in void setup(). We used the class function for each of the balls that dropped, used Arduino to procession serial communication to connect the button input to Processing. So, when a connection for the button was made at the same time the ball that dropped aligned with the area of the circle destination below, the ball would disappear, and the score would go up.
However, our original scoring system also made it difficult for the user to receive a positive score. We originally had 2 balls below: one bigger outer ball and a smaller inner ball. If you made the connection in the area in between the 2 balls you would only get 10 points, but if you miss you lose 20. But if you get the ball perfectly aligned with the middle ball, you would gain 50 points. But, it was too hard to ever get the balls perfectly aligned, and most people would miss, making the scores accumulate to negative. We decided to make the target ball only one at the bigger outer ball size and have it just gain 20 when the button is pressed anywhere in the target ball. This way, the user wouldn’t be discouraged and would incentivize the player to continue playing or play again.
We planned to differentiate our project by having a physical box with buttons and an additional feature that would take a picture of the player at a moment of distress. We planned to map out the beats to the song ourselves, however, we found that it was a bit too difficult to figure out in the time constraint we had. We would have had to create a CSV file that would update every millisecond to track what the player was doing using the table function. Rather, we let the balls drop randomly. However, to make it more challenging for the user, we adjusted each ball drop’s speed and took away the aspect of the camera capture because now we wouldn’t be able to tell the moment of distress. But, we figured that just pressing buttons while watching some balls drop on the screen wouldn’t attract and retain user attention enough, therefore we came to the idea of having buttons directly on the body. This way, rather than being able to see the buttons right in front of you, the user would have to register where the buttons were on their body and where each color was. Our medium was a soccer jersey.
The next thing that came into our design process was how we were going to place the buttons on our body. Originally, we wanted to order real, physical buttons and place that on the body. But, after talking to Leon, we realized a hard button might be painful for the user to wear and press. Instead, Leon suggested we create our own button using conductor tape. This way, Arduino would register that a button was pressed without using a physical button. By using the conductor tape, we could make a flat button that can be pressed on if placed on your body. Our initial prototype was just on paper. We use the copper wires over the regular silver wire to account for flexibility. However, the strands of wires were difficult to solder, but manageable. We put the tape on a piece of leather, to allow for flexibility to attach to the jersey fabric. To eliminate the amount wires attached, we utilized the pull up resister function on Arduino. This essentially lets us remove the power wire and the resistor. This works because the pull up resistor flips the circuit and always has the input at 1, rather than 0.
Finally, since we put the buttons on the body and were unable to map out the notes itself, we decided to have the game be collaborative rather than competitive. Through user testing, we learned that it was too difficult for the user to manage and press all 4 buttons via one vest. So, as a solution, we moved 2 of the buttons to another vest and made our game collaborative rather than competitive. Originally, we wanted to have the game more competitive, and have either one player compete with themselves or 2 players go back to back to compete. This actually turned out for the better because now 2 people can play together and have a collaborative experience.
Fabrication and Production
Process:
First, we started out with keys on the keyboard to make the ball connections. Then, we switched to sending Arduino values to Processing by putting buttons that would resemble our larger buttons on the breadboard. Then we moved from these buttons to our conduction buttons.
Ball Drop:
Mapping the ball drop rhythm was a very important aspect of our production process. We started with random dropping to test if the buttons on Arduino were able to process the information. From there, we planned to map out our own beats using Arduino and saving that file as the file that the users mapping would be compared to. However, after talking to Nick (as his robot project used some of the same mapping functions), we learned that we needed to include a table function that registers long lines of data and imports them to an excel file that is refreshed every few milliseconds. After using this method to try and map out the beats, we decided that we wouldn’t have enough time to complete this and that we should focus on creating the conductor tape buttons first before we focus on this. After we were able to successfully create out buttons, we consulted with Marcela on another possible strategy of mapping a ball drop pattern. She suggested we try the amp function we had learned in class (when sound was louder the ball would move further down the screen), however, after a few failed attempted, we decided to focus our attention on making the conductor buttons compatible to the body. Thus, going back to our original state of random ball dropping. This process taught us that sometimes, if you are under a time constraint that restricts you from continuing on with the project, to move on instead of staying stuck.
Button Arrangement:
After user testing, we implemented a number of changes. First, rather than have one vest with 4 buttons, we split the number of buttons and have 2 buttons on 2 vests. Before, it was a bit difficult for the user to balance 4 dropping balls at once. Most people were getting negative points. This way, we made it easier for the user to play, and introduced the aspect of a collaborative game. Before, it was only one person playing at a time, but this way, we allow two players to work together, making the game more engaging and fun. Also, since we were still working with cords, it made the cord organization less messy. User testing also helped us better understand the optimal button arrangement. We originally have 4 buttons on the front but found that most people found it unnatural to be pounding their chest. This prompted us to change the locations of the buttons and also contributed to the expansion to 2 vests. This way, users were able to more comfortably press the buttons and work together rather than frantically trying to individually find the button connections.
Gloves:
User testing also changed out medium for the gloves. In the very beginning, we wanted to create a button that has cushioning in the middle that would separate the 2 conduction tapes. However, since we decided to put the button on a vest with flexible fabric, we decided to use gloves to make the connection instead. We were afraid the flexibility of the leather would make the fabric bend and already have the connection made. During user testing, our original idea was to have gloves with an x shape of conduction tape across the palm, but it kept falling off and was difficult for people to make the connection. And the gloves were a bit too small for everyone’s hands to fit. So, this led us to our idea to have adjustable Velcro straps that would be attachable to the hand.
Conclusion
Our goal of this project was to create a fun and enjoyable experience for users through the medium of music. Even though out project strayed quite far from our original idea, I still feel that our project aligns with my definition of interaction. My definition of interaction requires a continuous relationship between two or more actors, composed of communication through either verbal, physical, and/or emotional feedback. And in order for the interaction to have meaning, the relationship between the actors must echo some sort of feeling of personal connection that drives the relationship to be either held or persuaded further. Our project involves more than 2 actors: the computer, the vest, and 2 players. The interaction between these actors have a feedback loop where the computer displays the game, the user tries to make the connection between the buttons, and if they do the ball on the screen disappears and the score goes up, but if they miss the score goes down. If the game is challenging enough or interesting enough to the user, the user will then attempt the game again and try to beat his/her previous score.
Regarding to the strength and meaning of this interaction, some people may not feel a connection to our project. They may not like the song or the fact that they have to wear a vest, or because they have to collaborate with someone. Our project also lacked verbal feedback. No sound was given off to the user to indicate that they made the connection at the right spot or didn’t make the connection. If we have more time, I would have liked to include a more drastic visual and verbal change that indicates to the user that they made the point or lost it. Many users were confused if they got the connection because the change wasn’t big enough. I would also have loved to make the vests Bluetooth. The cords were pretty messy and limited the movement of the user because it had to be attached to Arduino.
From this experience, I’ve learned that teamwork is essential to persisting. Justin and I made a really good team and bounced positively off each other. While we had different strengths, it made it easier to share knowledge and learn from each other. For instance, he understood the pull up resistor and explained how it worked to me but I understood more of the coding and so I was able to explain to him more about the functions, etc. One of the most frustrating setbacks we had was the ball mapping. We circled through a lot of attempts and felt constantly discouraged, thinking it was too hard. At one point, we wanted to change our whole project idea. But, we decided to stick with this idea and see how far we could take it. And I think it shows that we were able to do it! And it was due to the fact that we kept trying and didn’t give up. We are very proud of our project and have grown very fond of it. At first, we were just brainstorming random ideas and thought about this one for fun. But, I never thought that we would actually be able to execute a game like this! But of course, none of it would have been possible without the great IMA fellows and professors that helped us out along our way, especially when we felt discouraged. Overall, I’m really happy with how our project turned out and I am super proud of this work.