“Don’t Touch Me” – Kat Van Sligtenhorst – Rudi

After a group project dealing with such heavy topics as climate change, the destruction of the environment, and declining quality of life for many people, I knew I wanted a bit of a lighter focus for the midterm, so Chloe and I decided to make a game.

However, since the buzzwire game has been done before, as shown above, we wanted to add a collaborative twist by making it a two-person experience. In my research, I couldn’t find any examples of the game being collaborative. Early on, we also considered making two wire tracks for single-players so that people could race simultaneously. However, we were ultimately more interested in the idea of both users having to balance the force of the other, which can be felt pulling on their control of the loop’s speed and maneuvering, by adjusting and learning to work together without explicitly speaking to each other about how to approach the course.

In my last project, there wasn’t much response generated from the user after the computer output, so I wanted to add an increased level of interaction in this game by really trying to provoke strong reactions in the players.

The “Don’t Touch Me” buzzwire game was intended for a wide variety of users and circumstances, from school children developing fine motor skills and cooperation to coworkers or peers that want a fun, simple team-building exercise. During user testing, it was also brought up that our game could be used for couples, or as an almost meditative single-user activity, since it requires so much focus on the task at hand.

We wanted the game to be understood very intuitively, so we designed it with long handles on either side of the course and a one-way track, which we hoped would clue the user in to its purpose. We used chopsticks for the handles, an object that is already heavily associated with manual manipulation. We also added obvious negative-response visual and auditory output (a buzzer, a line of text that said “Hit,” and a red LED) to signal when the user had made an error. For the wire and loop, we had to use that particular metal material so they would respond when they touched each other. For our base, we used cardboard because we did not have the tools at our disposal to make it from wood instead. If we were to do another iteration of the project, we would build a sturdier base and then drill through to place the wire. We would also place the LEDs directly on the gameboard rather than on a mini breadboard, which was then affixed to the board with tape. This setup would also allow us to conceal the wires and the Arduino circuit more neatly.

The user testing was probably the most helpful part of the designing process. We got a lot of feedback that we incorporated into our final product. Right off the bat, people knew intuitively how to play the game and were excited about the difficulty of completing the course without touching the wire. Some people thought it might be easier as a single-player game, but acknowledged that it was an interesting challenge to balance the actions of another player.

Many users wanted higher stakes to the game, like something to indicate that they had won or lost. In response, we tried to code victory music to play when they reached the end of the course, but it was much more difficult than expected to integrate it with the other code we had already written, so we were ultimately unable to include it. We did, however, have the computer show “Hit! You lose.” whenever the wire was touched. We also added the red LED after user testing to reinforce the output from the buzzer and give the user another indication that they had made an error. Some users were confused about the green LED serving as a timer, since it only came on and then turned off after 30 seconds to indicate the end of the game. For the final product, we changed the code to have the light blink with increasing speed to add pressure to the user. We also made both LEDs more central and easier for the players to see, since before they were just off to the side and could be missed. Finally, we struggled a few times during testing with wires we had taped coming apart, which kept the buzzer and LED from working, so we soldered them together.

 

Above photos show before and after user testing.

I think all of the changes we made after user testing were very effective. They made the game both more entertaining and easier to understand.

In terms of significant failures and successes, we had several. The first time we got the whole circuit working, and the buzzer went off as soon as the wire and loop touched, we were very excited. We were also able to get the victory music and LED control working separately. However, one of our biggest failures was integrating all of the code into one cohesive program, which ended up being much more challenging than we anticipated. We had to rework a lot of what we had written, and weren’t able to include everything we had hoped to.

This project definitely aligns with my definition of interaction: the exchange between human and computer in which both sides receive information from the other, process it, and then create a response, communicating in turn. The output of the buzzer sound and the red LED flash indicate to the users that they have done something wrong in touching the wire. The users absorb this information, then respond by maneuvering the handles more carefully. The users also respond to the increasing speed of the green LED’s flashing by moving through the course more quickly. Ideally, to add another level of interaction and make it more complex, we would add more stimulus for the users, such as the handles vibrating to add difficulty and force even further strategy development in the gameplay.

In the end, the audience’s reaction to the finished game was essentially what we had anticipated. They responded with excitement and a competitive spirit to the computer’s triggered outputs, wanting to try again and do better in order to master the game. As mentioned earlier, there are several things we would add if we had more time to develop this project further: victory music, vibrating handles, a sturdier base. To go even further, it would be cool to have different gameplay options, like a single-player mode that used the vibrating handles to challenge the user and had a shorter time limit, or a three-life mode in which the user could hit the wire thrice before losing the game.

Through this experience, I learned more about what users want from an interactive game. Positive and negative rewards, such as a warning buzzer or victory music, may seem small and insignificant, but they are huge in determining how enthusiastically a player responds to the interaction and how likely they are to want to keep engaging with the game.

Credits:

Make an Arduino Buzzwire Game. https://www.youtube.com/watch?v=mXleSlmRQuc.

Leave a Reply